Creating Readme Documentation for AIGP test

[toadeniy-g]

Creating Readme Documentation for AIGP test

[OpenConfigBot]

Pull Request Functional Test Report for #5216 / da516a3

Virtual Devices

Device	Test	Test Documentation	Job	Raw Log
Arista cEOS		RT-1.36: AIGP feature support test	435294bc	Log
Cisco 8000E		RT-1.36: AIGP feature support test	e9aa578e	Log
Cisco XRd		RT-1.36: AIGP feature support test	39544cc7	Log
Juniper ncPTX		RT-1.36: AIGP feature support test	140476de	Log
Nokia SR Linux		RT-1.36: AIGP feature support test	fb2001a5	Log
Openconfig Lemming		RT-1.36: AIGP feature support test	f106ea20	Log

Hardware Devices

Device	Test	Test Documentation	Raw Log
Arista 7808		RT-1.36: AIGP feature support test
Cisco 8808		RT-1.36: AIGP feature support test
Juniper PTX10008		RT-1.36: AIGP feature support test
Nokia 7250 IXR-10e		RT-1.36: AIGP feature support test

Help

[gemini-code-assist]

Warning

Gemini is experiencing higher than usual traffic and was unable to create the summary. Please try again in a few hours by commenting /gemini summary.

[toadeniy-g]

/gemini summary

[gemini-code-assist]

Summary of Changes

This pull request introduces a new, thoroughly documented test for AIGP (Accumulated Interior Gateway Protocol) feature support. The test is designed to validate the granular control over AIGP attribute transmission and reception, its modification via policies within both default and non-default network instances, and its behavior in various scenarios including next-hop self and explicit next-hop IP settings. The changes ensure that the new test is properly registered and its purpose and procedures are clearly outlined for future reference and execution.

Highlights

• New AIGP Feature Test Documentation: Added a comprehensive README.md file detailing the AIGP feature support test, including its summary, topology, configuration procedures for DUTs and ATE, testing steps, and pass criteria across multiple sub-tests.
• New AIGP Test Metadata: Introduced a new metadata.textproto file for the AIGP test, specifying its unique identifier, plan ID, description, and testbed configuration.
• Test Registry Update: Updated the test registry to formally include the new AIGP feature support test (RT-1.36), linking to its newly created documentation.

Changelog

• feature/bgp/otg_tests/aigp_test/README.md
  • Added detailed documentation for the AIGP feature support test, including topology, configuration, testing steps, and pass criteria across multiple sub-tests.
  • Included OpenConfig path and RPC coverage for the AIGP test.
• feature/bgp/otg_tests/aigp_test/metadata.textproto
  • Added metadata for the new AIGP feature test, specifying its UUID, plan ID, description, and testbed type.
• testregistry.textproto
  • Updated the test registry to include the new AIGP feature support test (RT-1.36) with its description and a link to its README.md.

Activity

• OpenConfigBot posted a functional test report for the pull request, showing test results across various virtual and hardware devices.
• gemini-code-assist[bot] reported an inability to create a summary due to high traffic.
• toadeniy-g (the author) requested a summary again.

[toadeniy-g]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive README file for the AIGP feature test (RT-1.36), along with the necessary metadata and test registry entries. The documentation is well-structured and detailed. My review focuses on improving the clarity and correctness of the new README file. I've pointed out several minor typos, grammatical errors, and inconsistencies that should be addressed. Additionally, there is a placeholder for the DUT platform that needs to be filled in. Overall, this is a great addition once these minor issues are resolved.

[ram-mac]

@toadeniy-g - Any reason why we mark this as TODO? this OC coverage seem to be critical

[ram-mac]

@toadeniy-g - Any reason why we mark this as TODO? this OC coverage seem to be critical

[ram-mac]

@toadeniy-g - This test is only doing a control plane check of the metric's, but how do we know if the preferred paths are installed for the data plane. We should be validating this using a traffic flow.

[toadeniy-g]

the OTG does not understand the AIGP metric, reference on https://github.com/open-traffic-generator/snappi/blob/main/gosnappi/bgp_route_advanced.go

[masood-shah]

i would suggest dd actual traffic flow verification using the OTG too
why: we often see "ghost routes" BGP table looks perfect (show ip bgp shows the AIGP metric) but the hardware (ASIC) hasn't actually programmed the FIB correctly...how: send traffic from the ATE to a prefix learned via AIGP

then intentionally change the AIGP metric on the fly so the "best path" flips to a different physical interface. verify that traffic moves to the new interface with zero loss. this prove hardware is actually listening to the AIGP attribute

[masood-shah]

would add we xplicitly test the BGP decision process hierarchy too. as Ram correctly pointed out that if both paths have the same AIGP value we arent testing the featur we re testing luck

how: scenario a: path 1 (AS-Path 3, AIGP 100) vs path 2 (AS-Path 2, AIGP 200)
expected result: path 1 should win because AIGP is checked before AS-Path in the decision process

scenario b: both paths have identical AIGP values. ensure it falls back to the next tie-breaker

[toadeniy-g]

would add we xplicitly test the BGP decision process hierarchy too. as Ram correctly pointed out that if both paths have the same AIGP value we arent testing the featur we re testing luck

how: scenario a: path 1 (AS-Path 3, AIGP 100) vs path 2 (AS-Path 2, AIGP 200) expected result: path 1 should win because AIGP is checked before AS-Path in the decision process

scenario b: both paths have identical AIGP values. ensure it falls back to the next tie-breaker

a new test-case (RT-1.36.2) has been added based on this review