idr

Summary

The IDR working group meeting covered a wide range of BGP-related topics, including extensions for flow specification, SR policy, and new proposals for performance-aware routing and device discovery. The meeting also included a brief discussion of the working group's rechartering efforts. Several drafts were presented and discussed, with calls for working group adoption on some. There were discussions about potential dependencies with other working groups such as SPRING, BEST, and TVR.

Key Discussion Points

Rechartering: The proposed recharter aims to balance ongoing work with openness to future extensions, facilitate cross-working group reviews, and cover both underlay and limited overlay routing aspects of BGP.
BGP Flow Specification Extensions (v2): A proposal to use community containers to redirect traffic to secondary routing policies using FlowSpec v2. There was positive reception to the approach of using community containers.
BGP SR Policy Extensions for Performance Metrics: A proposal to add performance metrics to SR policy to influence path selection. Concerns were raised about the complexity of changing route selection and the generality of the metric.
BGP SR Policy Extensions for Path Scheduling: A draft proposing scheduled activation of SR policies. Concerns were raised about dependencies and potential overlap with TVR data models.
SR Policy End Node SID Optimization: A draft proposing signalling whether the end-node SID in an SR policy should be suppressed.
NVMf over RoCEv2 Device Discovery: A proposal to use BGP to distribute device discovery information in NVMf over RoCEv2 networks. The AD suggested this might be better suited for the BEST working group.
Fully Adaptive Routing using BGP: A proposal for a new BGP attribute to propagate bandwidth information for adaptive routing in AI networks. Concerns were raised about the introduction of a new BGP extended community and the potential for rapid changes and volatility.
Incremental Update Accumulated Metric in NHC Report: A draft proposing to add multiple metrics that a BGP speaker can advertise in the NHC, as well as what secondary metrics a receiving router could use in a class topology.
BGP-Specific Route Reflector: A proposal for a new BGP refresh message for specific route reflection. There was significant overlap with the route refresh options that's in the works.
BGP Performance Aware Routing: A draft proposing a separate SAFI to carry latency-based routing information. Strong concerns were raised about the volatility of latency as a routing metric and its suitability for BGP.

Decisions and Action Items

FlowSpec v2: N/A, further reviews and comments are welcome.
SR Policy extensions: Authors to address concerns about code point formats and take discussion to the mailing list.
Scheduling Extensions: Authors to consider coordination and consistency with TVR models.
SR Policy End Node SID Optimization: Adoption to be discussed on the mailing list.
NVMf RoCEv2 Device Discovery: N/A, Author to consider the BEST WG as an alternative venue.
Fully Adaptive Routing using BGP: Author to address concerns about the proposed new attribute, consider existing link bandwidth solutions, add technical depth, and prepare IANA considerations before next adoption request.
BGP Specific Route Reflector: To consider and reference existing route refresh options.

Next Steps

Continue discussions on the mailing list for all drafts presented.
Authors to address feedback and update drafts accordingly.
WG to decide on adoption for the SR Policy End Node SID Optimization draft.
Address rechartering concerns.
Resume presentations on Friday.

Session Date/Time: 25 Jul 2025 09:30

IDR Session - IETF 123

Summary

The IDR session covered several key topics, including the effort to move BGP4 to a full standard, path attribute filtering, dynamic capabilities, a refresher on second label discussion, flow spec iFIT mechanisms, and unreachable prefix announcement. The discussions were lively, with significant focus on the scope and impact of proposed changes, and a call for broader participation in the working group.

Key Discussion Points

BGP4 to Full Standard (RFC4271bis):
- Need to fix existing errata and documented but unimplemented features before moving to full standard.
- Discussion on what should be included in the base BIS document vs. separate RFCs. The scope is to reflect the deployed design, not to invent new technology or fix perceived past mistakes.
- Strong support for including 4-byte ASNs.
- Consensus to remove AS-Sets entirely.
- Debate on whether to introduce new SHOULD statements.
- Acknowledgement that the working group would likely use GitHub for collaboration with the mailing list as backup communication.
- Timeline is expected to approach working group last call in a year, but not at the next meeting.
Path Attribute Filtering:
- Standardizing filtering mechanisms in EBGP to address issues related to unintended propagation of attributes and features.
- Discussion about the use of a bit vector to indicate attributes to be filtered.
- Concerns raised about the granularity of filtering and potential conflicts with existing features.
- Debate on default filtering policies (permit vs. deny).
- The goal is to socialize the proposal and solicit feedback on encoding and the overall approach.
Dynamic Capabilities:
- Update on the draft for revising capabilities during a BGP session.
- Focus on managing revisions of capability instances, error handling, and backward compatibility.
- Discussion of two-way handshake process and the need for acknowledgements.
Second Label Discussion:
- Problem statement and potential solutions regarding label allocation in topologies with route reflectors or ASBRs.
- Exploration of using NHC attribute or extended communities to address label exhaustion issues.
- The goal is to get input from the working group and carve out a better solution before the next IETF.
Flow Spec iFIT Mechanisms:
- Motivation for dynamic injection of iFIT-related state information via BGP flow spec.
- The proposed mechanism leverages BGP flow spec for telemetry-driven network operation.
Unreachable Prefix Announcement (UPA):
- Addressing slow convergence in overlay networks due to hidden egress PE failures.
- Proposal to propagate unreachability information via MP_UNREACH messages.
- Concerns about the security and complexity of various signaling options.
- Debate on the best approach to propagating the information.

Decisions and Action Items

John Scudder: Will upload an updated RFC4271bis draft to GitHub, based on Tony's effort.
Authors of each Draft: Incorporate working group feedback into updated versions and solicit further review and feedback on the mailing list.
Chairs: Establish the appropriate use of GitHub for the WG, ensuring inclusivity and transparency.
WG Members: Review the discussed drafts and provide feedback on the mailing list.

Next Steps

Focused discussion on the mailing list regarding:
- The scope of RFC4271bis
- Path attribute filtering policies
- Best approach to unreachable prefix announcement.
Further refinement of drafts based on working group feedback and continued collaboration on GitHub.