Add BGP peer and route flap control operations

[atul-nexthop]

Addresses #484

What this adds

On-the-fly flap operations (start/stop while the session is up, no config change), per the requirements in #484:

• action.protocol.bgp.peer.flap — flap BGP peer sessions.
• action.protocol.bgp.route.flap — flap BGP route ranges.

Design

Flapping is only supported on BGP peers and route ranges in IxNetwork; ISIS/OSPF route ranges have no flap fields (only a static Active flag). So both flap operations are modeled BGP-scoped under Action.Protocol.Bgp, alongside notification and initiate_graceful_restart:

• Action.Protocol.Bgp.Peer.Flap — peer_names (BGP peers), enable, up_time, down_time.
• Action.Protocol.Bgp.Route.Flap — route_names (BGP v4/v6 route ranges), enable, up_time, down_time, plus the extra route-range controls IxNetwork exposes:
  • delay — delay (seconds) before flapping begins.
  • partial_flap — flap only a subset of the routes within each range.
  • flap_from_route_index / flap_to_route_index — inclusive index window for the subset when partial_flap is enabled.

Flap is a triggered operation with timing, which fits the action scope per control/readme.md (states are representable purely by enums; actions are triggers). x-field-uids are appended so existing fields are untouched. Both new operations are marked x-status: under_review.

Note on scope (changed from the earlier revision of this PR)

Route flap was initially placed on the generic State.Protocol.Route (cross-protocol via its x-constraint). That advertised a flap capability for ISIS/OSPF that the backend can't honor, and the extra fields (partial_flap, flap_from/to_route_index) are BGP-route-range specific. It has been moved to action.protocol.bgp.route.flap and removed from State.Protocol.Route (which keeps names + state withdraw/advertise, honored by BGP/ISIS/OSPF via Active).

Files

• control/bgp.yaml, control/protocol.yaml (source)
• artifacts/openapi.yaml, artifacts/otg.proto (regenerated via build.py)

Testing

• python build.py passes (openapiart validation green).

[atul-nexthop]

@apratimmukherjee @sasubrata this implements #484 — on-the-fly flap for BGP peers and routes. I've raised it as a proposal and I'm happy to adjust the modeling to fit the project's conventions. Could you take a look or assign a reviewer when you have a chance? Thanks!

[apratimmukherjee]

@atul-nexthop Thanks for raising this — appreciate the initiative on both the issue and the PR.

I want to check this against a related ask: I was forwarded an email thread describing a need to not auto-advertise routes on session up, and instead control route transmission (and flapping) explicitly from the test.

Could you clarify whether this PR is:

An additional requirement — i.e., flap control exposed via the API itself, rather than driven from test code (e.g., a loop issuing adv/withdraw), or
Related to the same need described in that email thread?
That'll help us figure out whether this should land together with the session-bringup/route-advertisement separation work, or as its own item — will follow up once we hear back. Thanks!

[atul-nexthop]

I want to check this against a related ask: I was forwarded an email thread describing a need to not auto-advertise routes on session up, and instead control route transmission (and flapping) explicitly from the test.

@apratimmukherjee Thank you for your quick response.

This is separate task from the one raised via support team.

• So the first ask which was raised via support team, It was ability to bifurcation of the route advertisement or withdrawl from BGP session establishment - currently, The routes are auto advertised when session comes up - The specific use for this is to allow us to measure route programing learning capability.
• The ask in this PR is separate - We would like the ability to set the flap and timers via api - If you refer to the screenshot attached on this Issue description - IXIA already has flap parameter in BGP Peer and BGP route ranges - so, This PR is to allow us ability to set those so specific routes are only flapped allowing us better control over flap timers as well.

Please let me know if this makes sense.