Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Extended coverage for Interface hold-time test#5662

Open
ram-mac wants to merge 1 commit into
openconfig:mainfrom
ram-mac:interface_hold_time
Open

Extended coverage for Interface hold-time test#5662
ram-mac wants to merge 1 commit into
openconfig:mainfrom
ram-mac:interface_hold_time

Conversation

@ram-mac

@ram-mac ram-mac commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Enhancing the coverage for Interface hold-time test
-Updated the summaries and procedures to test the current design specifications: hold-time down of 300 ms and hold-time up of 180,000 ms (3 minutes).
-Modified TC4 - long up to wait for 185 seconds and assert state recovery matching the 180s timer.
-Added a new testcase TC6 - traffic loss duration to inject continuous data-plane traffic and assert that the total packet loss duration

@ram-mac ram-mac requested a review from a team as a code owner July 3, 2026 04:30
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the test coverage for interface hold-time configurations. It updates existing documentation and test procedures to reflect new design specifications for hold-time up durations and introduces a new test case to validate traffic loss behavior during link failures.

Highlights

  • Updated Hold-Time Parameters: Modified the interface hold-time test specifications to support a hold-time up of 180,000 ms (3 minutes) and maintained the hold-time down of 300 ms.
  • Test Case Adjustments: Updated TC4 (long up) to wait for 185 seconds to align with the new 180s timer requirements.
  • New Test Case Addition: Added TC6 to verify traffic loss duration by injecting continuous data-plane traffic and asserting the total packet loss duration.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@OpenConfigBot

Copy link
Copy Markdown

Pull Request Functional Test Report for #5662 / 330a65c

Virtual Devices

Device Test Test Documentation Job Raw Log
Arista cEOS status
RT-5.5: Interface hold-time
d5b5dc33 Log
Cisco 8000E status
RT-5.5: Interface hold-time
376206c5 Log
Cisco XRd status
RT-5.5: Interface hold-time
a97a133c Log
Juniper ncPTX status
RT-5.5: Interface hold-time
7a925a6c Log
Nokia SR Linux status
RT-5.5: Interface hold-time
9f977e9e Log
Openconfig Lemming status
RT-5.5: Interface hold-time
783b80ae Log

Hardware Devices

Device Test Test Documentation Raw Log
Arista 7808 status
RT-5.5: Interface hold-time
Cisco 8808 status
RT-5.5: Interface hold-time
Juniper PTX10008 status
RT-5.5: Interface hold-time
Nokia 7250 IXR-10e status
RT-5.5: Interface hold-time

Help

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the interface hold-time test documentation to increase the hold-time up configuration from 5 seconds to 180 seconds (3 minutes) and adjusts the test procedure steps accordingly. It also introduces a new test case (TC6) to measure and verify traffic loss duration, and adds a canonical OpenConfig JSON snippet. The reviewer feedback suggests using standard GitHub Flavored Markdown inline math delimiters ($) instead of LaTeX-style delimiters to ensure correct rendering of math expressions.

Comment on lines +57 to +59
* Verify that the traffic loss duration \(t_{\text{loss}}\) satisfies the relation:
* \(t_{\text{loss}} \le \text{hold-time down} + \text{failover tolerance}\)
* Specifically, \(t_{\text{loss}} \le 300\text{ ms} + 100\text{ ms} = 400\text{ ms}\).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

GitHub Flavored Markdown (GFM) uses $ for inline math expressions instead of LaTeX-style \( and \) delimiters. Using \( and \) will prevent the math from rendering correctly on GitHub.

Suggested change
* Verify that the traffic loss duration \(t_{\text{loss}}\) satisfies the relation:
* \(t_{\text{loss}} \le \text{hold-time down} + \text{failover tolerance}\)
* Specifically, \(t_{\text{loss}} \le 300\text{ ms} + 100\text{ ms} = 400\text{ ms}\).
* Verify that the traffic loss duration $t_{\text{loss}}$ satisfies the relation:
* $t_{\text{loss}} \le \text{hold-time down} + \text{failover tolerance}$
* Specifically, $t_{\text{loss}} \le 300\text{ ms} + 100\text{ ms} = 400\text{ ms}$.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants