Markdown Version | Transcript | Recording 1 | Recording 2 | Recording 3 | Session Materials

IDR

Summary

The Inter-Domain Routing (IDR) Working Group met at IETF 126. The session focused primarily on BGP core protocols, management models, routing table scaling in AI datacenters, and operational/security enhancements.

Key discussions centered on advancing the BGP finite state machine (FSM) modifications, the BGP YANG base model, resolving route reflection scaling constraints, updating the base BGP-4 specification (draft-ietf-idr-bgp4-rfc4271bis), and introducing novel mechanisms for next-hop selection, canonical path attribute formatting, and source-selective BGP security.

Key Discussion Points

1. Working Group Status and Document Updates

Presenter: Susan Hares

• WG Process: Drafts are being grouped and run through the adoption and pre-adoption review process in five main tracks: Core, SR (Segment Routing), SRTE (SR Traffic Engineering), BGP-LS, and FlowSpec v2. Status tracking has moved to daily updates on GitHub.
• Document Status:
  • draft-ietf-idr-linklocal-capability has finished working group last call (WGLC) but needs further list comments to finalize.
  • draft-ietf-idr-sdwan-edge-discovery is waiting on minor shepherd updates.
  • draft-ietf-idr-ts-flowspec-srv6-policy received a late revision and shepherd review is progressing.
  • draft-ietf-idr-bgp-ls-sr-policy-admin-flags is in the adoption queue.

2. BGP BFD Strict-Mode & BGP FSM IANA

Presenter: Jeff Haas

• Slides: 1-2. BGP BFD Strict-Mode

• Drafts: draft-ietf-idr-bgp-bfd-strict-mode and draft-ietf-idr-bgp-fsm-iana

• Discussion: Jeff Haas detailed how differences in implementation timing between BFD state transitions and the BGP FSM can lead to wedged sessions or deadlocks. To prevent this, the proposed strict mode prevents BGP from transitioning to the Established state (by holding back the KEEPALIVE message) until BFD has successfully come up. The changes to the FSM are modeled using substates in the OpenConfirm state.

• Status: Both documents are stable, have at least three implementations, and are ready for Working Group Last Call (WGLC).

3. BGP YANG Update

Presenter: Jeff Haas

• Slides: 1-3. BGP YANG Update

• Draft: draft-ietf-idr-bgp-model

• Discussion: Jeff Haas reported on the final cleanup of the BGP YANG model. Key modifications include allowing neighbors to be keyed on values other than their IP address (flexible neighbor keys), aligning with IETF's semantic versioning standards, introducing a BNF representation for AS Path regex, and restructuring the extended community encodings to facilitate long-term maintenance.

• Feedback:

  • Weiqiang Song (Broadband Forum Liaison) noted that BBF's upcoming specifications depend directly on this model and urged its publication.
  • Ketan Talaulikar highlighted that this is one of the largest YANG models in the IETF (at 240 pages) and strongly encouraged participants to voice support on the mailing list consensus call.

4. Fully Adaptive Routing Ethernet (FARE) in Multi-Plane Scale-Out Networks

Presenter: Xiaohu Xu

• Slides: 1-5-1. Fully Adaptive Routing Ethernet (FARE) & 1-5-2. Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks (FARE in MPSON)

• Discussion: Large-scale AI training clusters use multi-plane fabrics where RDMA NICs (rNICs) need to compute reachability and path bandwidth across multiple planes without inter-plane links. In a network of 100K GPUs across four planes, rNICs cannot handle the resulting 400K host routes. Xiaohu Xu proposed two scaling mechanisms:

  1. Route Aggregation with Unreachability Notification: Aggregating host routes at leaf switches, combined with path-bandwidth advertisements set to zero or using Unreachability Prefix Announcements (UPA).
  2. Prefix Outbound Route Filtering (ORF) with FIB suppression at the leaf switches.

• Feedback:

  • Krishnaswamy Ananthamurthy questioned why a default route cannot be advertised to the NIC instead. Yingzhen Wang and Keyur Patel clarified that AI networks are rail-optimized (east-west traffic patterns), requiring specific subnets to prevent traffic rails from breaking down.
  • Jeff Haas reminded the authors to respect the five-author limit on the draft before adoption.

5. YANG Data Model for BGP Outbound Route Filtering (ORF)

Presenter: Weiqiang Cheng

• Slides: 1-4. YANG Data Model for BGP Outbound Route Filtering

• Discussion: This individual draft introduces two new YANG modules: ietf-bgp-orf (generic ORF and address prefix ORF) and ietf-bgp-vpn-prefix-orf (VPN prefix ORF quotas).

• Feedback: Ketan Talaulikar requested that the authors of this ORF module actively review and comment on the base BGP YANG model (draft-ietf-idr-bgp-model) WGLC since their work augments it. Jeff Haas added that once the base model is finalized, the chairs and routing working groups will need to establish a consistent review process for all such augmentations.

6. BGP Route Reflector Deployment Considerations

Presenter: David Smith

• Slides: 1-6. BGP RR Deployment Considerations

• Discussion: David Smith presented an informational draft analyzing route reflector deployment models (Multi-cluster, Multi-tier, and Multi-plane) and their associated performance trade-offs (such as client overload, blast radius, path hiding, and transport performance). The authors plan to rename the draft to "Route Reflector Design Considerations" to better align its scope.

• Feedback:

  • Keyur Patel suggested incorporating considerations for hot-potato routing, full-mesh vs. non-full-mesh client behaviors, IGP integration to avoid transit forwarding, and Graceful Restart optimization.
  • John Scudder and Jeff Haas suggested that this informational work belongs in the GROW Working Group rather than IDR, pointing out a 15% overlap with GROW's current operational security document. The chairs and ADs will coordinate to determine the best venue.

7. RFC 4271bis-Border Gateway Protocol 4 (BGP-4)

Presenter: John Scudder

• Slides: 1-1. RFC 4271bis-Border Gateway Protocol 4 (BGP-4)

• Draft: draft-ietf-idr-bgp4-rfc4271bis

• Discussion: John Scudder presented updates in the -01 version ("the low-hanging fruit edition"). He proposed a streamlined GitHub workflow where each issue maps to a pull request, avoiding mailing list confirmation for every single PR to prevent overhead.

• Key Design Issues Raised:

  • Graceful Restart: Since RFC 4724 heavily hacks the FSM, pulling it into the base spec as an optional feature would align the specification with running implementations.
  • Extended Message Sizes (RFC 8654): Required for BGP-LS attribute scaling and BGPsec.
  • Legacy NLRI Encoding: The current base spec only describes the IPv4-specific encoding. John suggested either pointing readers to RFC 4760 (Multiprotocol Extensions) or rolling it in to properly document IPv6.
  • Other features: Proposing to mandate TTL 255 by default, removing the terms "mandatory" and "discretionary" for path attributes, and documenting "Remove Private AS".

8. BGP Best Path Next-Hop Selection Enhancements

Presenter: Olivier Dugeon

• Slides: 1-7. BGP best path next-hop selection enhancements

• Discussion: Olivier Dugeon discussed how the traditional RFC 4271 next-hop resolvability assumptions break in modern MPLS and SRv6 networks, leading to traffic drops (if next-hop is reachable but no valid LSP exists) or suboptimal path selection (BGP defaulting to IGP metrics instead of intent-aware SR policy metrics). The authors proposed a "resolution preference" mechanism to filter path candidates and a formalized "path resolution tuple" (forwarding address + optional context).

• Feedback:

  • Chen Changli noted an overlap with an active China Mobile draft.
  • John Scudder advised that while this feature will not be standardized in time to be baked into draft-ietf-idr-bgp4-rfc4271bis, the working group should design the base spec's resolvability check to be pluggable to easily accommodate these enhancements later.

9. Source-Selective BGP

Presenter: Kamiel Braat

• Slides: 1-8. Source-Selective BGP

• Discussion: To mitigate terabit-level volumetric DDoS attacks, Kamiel Braat proposed "Source-Selective BGP." The mechanism introduces a "Source-Selective" BGP path attribute pointing to a new RPKI profile called "Source Prefix Authorization" (SPA). The SPA defines an allow-list of source prefixes authorized to send traffic to a given destination prefix. The solution requires Source Address Validation (SAV) to be deployed across participating customer cones.

• Feedback:

  • Alexander Azimov raised concerns about how this handles Layer 4 attacks with spoofed IPs, to which Kamiel replied that SAV is an absolute prerequisite.
  • John Scudder and Keyur Patel discussed the comparison to FlowSpec on the list and chat. While FlowSpec is typically reactive, Source-Selective BGP functions as a proactive, inter-domain authorization mechanism. Robert Raszuk and Jeff Haas cautioned about the scale of source-specific routing tables and the potential blast radius of a new BGP attribute deployed internet-wide.

10. Canonical Textual Representation of BGP Path Attributes

Presenter: Maria Matejka

• Slides: 1-9. Canonical textual representation of BGP Path Attributes

• Discussion: Textual representations of BGP communities, extended communities, and AS paths vary significantly across vendor implementations and open-source tools. This inconsistency complicates machine parsing (e.g., in YANG and JSON engines) and human readability. Maria Matejka proposed defining a standardized canonical format for these attributes and creating JSON-based templates so that new communities can be dynamically parsed without router code changes.

• Feedback: Luuk Hendriks strongly supported the initiative. Jeff Haas recommended coordinating with Martin Pels' parallel BGP community formatting draft in the GROW working group and suggested utilizing YANG display hints.

11. BGP Enhancements for ECMP EBGP Scenarios

Presenter: Yingzhen Wang

• Slides: 1-10. BGP Enhancements for ECMP EBGP Scenarios

• Discussion: In data center topologies with parallel EBGP sessions, the persistent route selection algorithm (RFC 5004) can be bypassed depending on the arrival order of prefix advertisements, causing churn in the best path. Additionally, redundant routes are unnecessarily advertised back to parallel peers in the same AS. Yingzhen Wang proposed extending RFC 5004 persistence logic across parallel EBGP sessions and suppressing redundant advertisements.

• Feedback: Jeff Haas warned that any modifications to BGP path selection—especially time-based persistence—are highly delicate and prone to routing loops and bugs, requiring thorough scrutiny on the list.

12. Threat Model for BGP Color Extended Community

Presenter: Yuan Zhang

• Slides: 1-11. Threat Model for BGP Color Extended Community

• Discussion: Yuan Zhang presented security gaps in the BGP Color Extended Community. Because color is an ordinary transitive attribute without cryptographic binding to the AS_PATH or origin, transit ASes can manipulate, inject, or strip color values to redirect traffic or bypass policies. The draft defines threat vectors (injection, re-coloring, stripping) and proposes future directions, including cryptographically binding color to an origin AS (via BGPsec or signed objects) and introducing sequence numbers/timestamps to prevent replay attacks.

• Feedback: Susan Hares suggested investigating the use of the community container. Jeff Haas recommended coordinating with GROW's operational security and community scrubbing efforts.

Decisions and Action Items

1. draft-ietf-idr-bgp-bfd-strict-mode & draft-ietf-idr-bgp-fsm-iana: Approved to proceed to Working Group Last Call (WGLC).
2. draft-ietf-idr-bgp-model: The Working Group consensus call is active. Authors of dependent drafts (such as the ORF model) must review and provide final comments on the list.
3. BGP Route Reflector Deployment Considerations: The chairs and ADs will coordinate to decide whether this informational work belongs in the GROW or IDR Working Group.

Next Steps

• draft-ietf-idr-bgp4-rfc4271bis: John Scudder to continue merging low-controversy issues on GitHub and drive discussions on the list regarding the integration of Graceful Restart, Multiprotocol NLRI, and Attribute Flags registries.
• FARE (Fully Adaptive Routing Ethernet): Xiaohu Xu to trim the author list to meet the five-author limit in preparation for the base draft's adoption call.
• Next-Hop Selection Enhancements: IDR chairs to initiate a Working Group adoption call for the next-hop selection work after IETF 126.
• Canonical Textual Representation: Maria Matejka to coordinate with Martin Pels (GROW) on aligning canonical JSON formats for BGP communities.

Session Date/Time: 24 Jul 2026 12:00

IDR

Summary

The IDR Working Group met at IETF 126 (Session 1) to discuss core BGP protocol updates, Segment Routing (SR), SR Traffic Engineering (SRTE), BGP Link-State (BGP-LS), and multicast policy routing. Key discussions centered on signaling tunnel encapsulation for MASQUE, the controversial BGP Unreachable Prefix Announcement (UPA) v2 proposal, hierarchical route reflection improvements for Route Target Constrain (RTC), and various SR/BGP-LS extensions.

Key Discussion Points

1. Welcome and WG Status

• Presenter: Susan Hares
• Slides: 1-0. IDR Chairs Slides
• Details: The IDR charter has been approved. The chairs have split drafts into parallel queues: BGP Core, SR/SRTE, BGP-LS, and Flowspec to streamline progress.

2. MASQUE Tunnel Encapsulation (RFC 9012 for Mask)

• Presenter: Alvaro Retana
• Technical Details: Proposes signaling MASQUE (multiplexed application substrate over QUIC encryption) tunnel encapsulation in BGP (RFC 9012). It defines four new tunnel types (connect-tcp, connect-udp, connect-ip, connect-ethernet) and two new sub-TLVs (ALPN and URI template).
• Discussion:
  • Alvaro Retana raised a validation issue: the current draft requires performing a DNS query to resolve the proxy URI and obtain the IP address to validate the tunnel egress endpoint. He proposed adding a tunnel egress endpoint sub-TLV to carry the IP address directly.
  • David Schinazi suggested using the HTTPS DNS Resource Record (RR) format inside the BGP payload instead of inventing new sub-TLVs. This provides built-in extensibility for all ALPN and address hints.
  • Warren Kumari supported David Schinazi’s suggestion of embedding the record data directly rather than dynamically querying DNS.
  • John Scudder expressed caution regarding routing mechanisms relying on DNS, but conceded it might be acceptable for overlay scenarios. He preferred having explicit IP addresses in the attribute.
  • Jeff Tantsura pointed out that the BGP next hop must maintain a logical relationship with the tunnel endpoint.

3. BGP Unreachable Prefix Announcement (UPA) v2

• Presenter: Yannick Voyer
• Slides: 2-2. BGP Unreachable Prefix Announcement (UPA) v2
• Technical Details: The proposal aims to signal the loss of reachability for a specific covered prefix/next hop under an aggregate route to trigger fast reroute (PIC) on ingress PEs. Since the last meeting, the design transitioned from using MP_UNREACH_NLRI to utilizing MP_REACH_NLRI carrying a "UPA Extended Community" with a D-bit (explicit drop) and a router ID for deduplication.
• Discussion:
  • Bo Wu agreed that using MP_REACH is a better implementation choice but noted that data center scenarios might have different requirements than service provider networks.
  • Maria Matějka and Jie Dong raised critical deployment concerns: if a node in a partial deployment does not support or understand the new UPA community, it will treat the route as standard reachable unicast, thereby attracting and silently blackholing traffic.
  • John Scudder noted that the BGP Identifier carried in the community may cross EBGP boundaries, where it is no longer guaranteed to be unique.
  • Yannick Voyer responded that UPA is intended to be strictly configured and scoped between UPA-capable neighbors.
  • Jeff Apcar expressed support for the use case and promised to share interworking implementation results by the next meeting.
  • Jeff Tantsura (chair) strongly cautioned against the current design, calling it "terrifying" due to the risk of attribute escape or community stripping, which would cause blackholes. He and several chat participants (including Jeffrey Haas and Robert Raszuk) suggested that a separate, dedicated AFI/SAFI (similar to the older unreachability SAFI concept) would be a much safer approach to ensure only capable clients receive and parse this state.

4. BGP Point/Port Extended Communities for AIDC

• Presenter: Jungha Zhao
• Technical Details: Proposes a new BGP Extended Community to advertise egress switch port IDs to the ingress nodes in AI data centers. This allows the sending sides to negotiate bandwidth and avoid congesting specific egress ports.
• Discussion:
  • Jeff Tantsura pointed out in the chat that standard community aggregation procedures (similar to those used in DMZ link bandwidth) could be leveraged to aggregate these communities without losing port information when multiple paths are merged.

5. Extensions to RT-Constrain in Hierarchical RR Scenarios

• Presenter: Jie Dong
• Draft: draft-ietf-idr-rtc-hierarchical-rr
• Technical Details: Addresses the problem where level-1 Route Reflectors (RRs) discard RTC routes received from level-2 RRs due to cluster ID loop detection, resulting in incomplete route distribution graphs.
• Discussion:
  • Jie Dong presented three optional solutions:
    1. Add-Path: Supported by multiple implementations.
    2. Cluster ID Loop Knob: Supported by at least one implementation.
    3. Most Disjoint Route Advertisement: No current implementations.
  • Jeff Tantsura suggested moving the third option (disjoint routes) to the appendix and progressing the draft toward Working Group Last Call (WGLC).

6. BGP-LS Extensions for BGP-Only Networks

• Presenter: Marvin d'Souza
• Draft: draft-ietf-idr-bgp-ls-bgp-only-fabric
• Technical Details: Updates include reducing attributes to a recommended baseline, consolidating SR Policy and SRv6 sections to reference existing RFCs rather than duplicating formats, and adding TI-LFA and SRv6 deployment use cases.
• Discussion:
  • Marvin d'Souza shared that there is an active implementation in Sonic FRR.
  • Jeff Tantsura noted that the draft seems close to completion and suggested targeting progression by the San Francisco meeting.

7. Advertising P2MP Policies in BGP

• Presenter: Hooman Bidgoli
• Draft: draft-ietf-idr-sr-p2mp-policy
• Technical Details: Introduces a new BGP NLRI containing three route types (P2MP Policy, Replication Segment, and OIF) to program multicast states via a controller.
• Discussion:
  • Jeff Tantsura asked if this is designed to interoperate with or run in parallel to standard MVPN procedures (RFC 6514).
  • Hooman Bidgoli replied that it is designed as a "ships in the night" solution to match unicast SR Policy workflows.
  • Jeff Tantsura noted that coordination with the BESS working group is required.

8. BGP SR Policy Extensions for BFD Configuration

• Presenter: Jiandong Jin
• Technical Details: Refines the proposal to configure Seamless BFD (SBFD) parameters via BGP SR Policy. The draft was modified to remove generic two-sided BFD configuration (since SR Policy is unidirectional and only targets the head-end). It dramatically simplifies encoding by keeping only the SBFD discriminator in the fixed field and nested optional sub-TLVs for timers.
• Discussion:
  • Jeff Tantsura suggested presenting this work to the Spring Working Group for coordination.

9. BGP Extensions for Intra-Domain Flex-Algo with SRv6

• Presenter: Liuyan Han
• Technical Details: Proposes a new BGP Extended Community to carry the Flex-Algo ID alongside IPv6 prefix/locator advertisements across domains.
• Discussion:
  • Ketan Talaulikar raised concerns that carrying critical routing constraints in an extended community is risky because communities can be filtered. He also noted that if a prefix has multiple algorithms, BGP best path selection might pick only one, which breaks disjoint topology requirements.
  • Liuyan Han clarified that this is designed for a single operator managing multiple domains where algorithm IDs are kept consistent.
  • Jeff Tantsura recommended that the authors analyze disjoint forwarding scenarios where multiple routes for the same destination must be advertised.

10. BGP Extensions for Network Resource Partition (NRP)

• Presenter: Jiandong Jin
• Technical Details: Proposes carrying an NRP ID within a new BGP Extended Community to map traffic to resource partitions. This allows many-to-one mappings where multiple NRPs share a single SR Policy path, and provides support for non-SR-Policy environments (like Flex-Algo or SR-MPLS).
• Discussion:
  • Ketan Talaulikar questioned the scalability of the approach, asking how many communities would be carried and if they would exceed standard BGP path attribute size limits.
  • Jiandong Jin clarified that the private routes are advertised separately per color, allowing scalable sharing of the underlying path.

Decisions and Action Items

• draft-ietf-idr-rtc-hierarchical-rr: The third option (Most Disjoint Route) will be moved to the appendix. The chairs will prepare the draft for Working Group Last Call (WGLC).
• draft-ietf-idr-bgp-ls-bgp-only-fabric: The authors are to finalize outstanding items and target progression at the next IETF meeting.
• SBFD Configuration: The authors of the BFD configuration draft will present and coordinate their work with the Spring Working Group.
• P2MP Policy: The authors of draft-ietf-idr-sr-p2mp-policy will coordinate with the BESS Working Group.

Next Steps

• MASQUE Tunnel Encapsulation: Alvaro Retana and coauthors will update the draft to utilize embedded HTTPS DNS Resource Records (RR) instead of custom ALPN/IP sub-TLVs.
• BGP UPA v2: The authors will address critical security concerns regarding attribute stripping, route leaks, and the potential transition of the design to a separate, safe AFI/SAFI.
• Flex-Algo & NRP Extended Communities: Authors must address scalability and filtering concerns raised during the sessions on the IDR mailing list.

Session Date/Time: 24 Jul 2026 14:00

IDR

Summary

The IDR Working Group met at IETF 126 to discuss advancements in BGP capabilities, focusing heavily on BGP Flow Specification Version 2 (FSv2), monitoring frameworks, and routing policies. Susan Hares and Jeffrey Haas chaired the session. Key presentations covered the core FSv2 specification for basic IP filtering, along with specific filtering extensions (bitwise filters, QUIC headers, Class IDs, and iFit capabilities) and redirect actions. Additional discussions addressed Source Address Validation (SAV) rule advertisement via BGP Link-State (BGP-LS), and a notable debate occurred regarding BGP Unreachable Prefix Announcements (UPA).

Key Discussion Points

BGP Flow Specification Version 2 - for Basic IP

Susan Hares and Jeffrey Haas presented updates on 1-0. IDR Chairs Slides and the primary design goals of draft-ietf-idr-fsv2-ip-basic.

• Design and Features: FSv2 introduces user-defined rule ordering, structured filter families, and frame-ordered components. Actions are carried via BGP Extended Communities, which transit the network cleanly.
• Fate-Sharing (Dependencies): A non-zero dependency ID can bind multiple filters together. If a device lacks hardware support for a component (e.g., DSCP), the entire dependent set of filters is ignored to prevent unintended traffic blackholing.
• Component Numbering: Filters are initially spaced out by 10 to allow additions. Future proofing may expand this to spacing of 100.
• Backward Compatibility: Carrie (Chunghwa) asked if FSv2 filters could be backward compatible with FSv1. Susan Hares clarified that they are not backward compatible due to modified PDU layouts and numbering schemas, though core filtering functionalities remain consistent.

BGP Flowspec Monitoring Roadmap

Yuzha presented a framework and roadmap targeting the operational gap between Flowspec control plane propagation and effective data plane enforcement.

• Proposed Framework: A multi-plane framework (intent, control, data) relying on five information categories: route lifecycle, event routing, status telemetry (via BMP), traffic outcomes (via IPFIX), and operational state.
• Discussion: Jeffrey Haas relayed Robert Raszuk's chat comment asserting that BGP is a "spray and pray" protocol and telemetry information is better suited for controllers rather than BGP. Jeffrey Haas (speaking as co-author) agreed that BGP should not carry all monitoring metrics; the design intends to use BMP and IPFIX for feedback. Susan Hares suggested considering BGP-LS for complete coverage.

SAV Rule Information using BGP-LS

A representative from China Unicom shared updates to the BGP-LS SAV rule distribution draft.

• Updates in -05: Clarified local node scope, aligned SAV mode TLVs with the general SAV capability specification, and detailed operational constraints for incremental updates.
• Discussion: Jeffrey Haas noted that large-scale BGP-LS distribution presents scaling challenges and advised looking into LSVR (Link-State Vector Routing) scaling mechanisms as a reference.

Bitwise IP Filters for BGP Flowspec v2

Nick Gao presented bitwise IP filters designed for symmetric traffic steering in multi-vendor edge environments.

• Mechanism: Targets the least significant bits of subscriber addresses. It matches source addresses at the subscriber-facing ingress and destination addresses at the Internet-facing egress.
• Encoding: Implements a logical OR across pattern-mask pairs. To ensure deterministic sorting and evaluation, don't-care bits must be set to zero on transfer and receipt.
• Discussion: Jeffrey Haas noted that bitwise filters are more specific than standard prefix fields, which dictates their sorting priority.

iFit Capabilities & Actions in BGP Flowspec

An iFit presenter discussed combining Inline Flow Information Telemetry (iFit) attributes with Flowspec actions to automate ACL generation and packet sampling.

• Discussion: Susan Hares highlighted the capability of this joint attribute-action model but warned that potential interactions with other marking actions (such as DSCP) require careful definition in the draft.

BGP Flowspec Extension for QUIC

Carrie (Chunghwa) proposed extensions to filter QUIC traffic based on unprotected header fields (such as Destination/Source Connection IDs and Header Flags).

• Discussion: Joel Halpern questioned the feasibility of matching QUIC Connection IDs in BGP Flowspec, noting they are random, dynamic values negotiated strictly between endpoints and not reported to external controllers. Carrie noted that they must be reported to the controller for the filter to work. Haibo (Bob) from Huawei raised concerns regarding variable-length Connection IDs in hardware chips. Jeffrey Haas observed that this highlight's the need for FSv2 to elegantly navigate varying levels of hardware sophistication.

BGP Flowspec Redirect Load Balancing Group

Haibo (Bob) from Huawei proposed a redirect and load-balancing community group to split Flowspec traffic dynamically across multiple next hops or SR Policies.

• Features: Introduced Control Flags (T, D, F) to handle unreachable tunnels or IP route fallbacks without losing traffic.
• Discussion: Jeffrey Haas expressed interest in this redirect mechanism and invited the authors to contribute to the general discussion on handling conflicting redirect actions.

Class ID Filter for BGP Flow Specification

Jimmy presented a Class ID filter designed to prevent TCAM rule explosion on PE routers by logically grouping prefixes under a local 2-octet identifier.

• Discussion: Susan Hares clarified that the Class ID is a logical binding policy concept rather than a field written into transit packets. Jeffrey Haas requested that the authors post a technical comparison between this proposal and existing Flowspec path redirect features to the mailing list.

Chat Discussion: BGP Unreachable Prefix Announcement (UPA) v2

An active chat-based debate arose regarding 2-2. BGP Unreachable Prefix Announcement (UPA) v2.

• Mechanisms & Concerns: Robert Raszuk and Srihari Sangli questioned the use of MP_REACH_NLRI to advertise unreachability. Jeffrey Haas clarified that while using MP_UNREACH to inject state violates BGP procedures, using MP_REACH to signal unreachability in the same AFI/SAFI risks "attribute escape." If a transit router strips the signaling community, the route is treated as normal reachability, creating security and routing loop risks.
• Alternatives: Robert Raszuk suggested utilizing a separate SAFI or resurrecting his aggregator withdraw concept (draft-raszuk-aggr-withdraw-00.txt`). Jeffrey Haas suggested Robert update and post his draft to the list.

Chat Discussion: Flex-Algo & BGP YANG

• Thomas Graf requested that configuration options and reason codes for path marking be aligned with draft-ietf-idr-bgp-model, which was discussed during 1-3. BGP YANG Update.
• Keyur Patel, Jeffrey Haas, and Jie Dong discussed representing Flex-Algo IDs within BGP-LS, noting that for SRv6, different locators can be advertised as standard IPv6 prefixes mapped to specific Flex-Algos.

Decisions and Action Items

• Action Item: Robert Raszuk to refresh and submit draft-raszuk-aggr-withdraw-00.txt` to the mailing list as an alternative solution to the UPA v2 problem space.
• Action Item: The authors of the Class ID Filter draft to post a comparison to the IDR mailing list contrasting their proposal with existing Flowspec path redirect mechanisms.
• Action Item: IDR Chairs to coordinate with the authors of individual Flowspec extension drafts to begin alignment and conversion to the FSv2 (draft-ietf-idr-fsv2-ip-basic) framework.

Next Steps

• The Working Group will target August to begin adoption polls for individual Flowspec v2 extension drafts.
• The chairs will monitor coordination progress across the FSv2 documents; an interim meeting may be scheduled if tight synchronization on numbering or feature interactions is required.

Related Documents

draft-ietf-idr-bgp-bfd-strict-mode, draft-ietf-idr-bgp-fsm-iana, draft-ietf-idr-bgp-ls-bgp-only-fabric, draft-ietf-idr-bgp-ls-sr-policy-admin-flags, draft-ietf-idr-bgp-model, draft-ietf-idr-bgp4-rfc4271bis, draft-ietf-idr-fsv2-ip-basic, draft-ietf-idr-linklocal-capability, draft-ietf-idr-rtc-hierarchical-rr, draft-ietf-idr-sdwan-edge-discovery, draft-ietf-idr-sr-p2mp-policy, draft-ietf-idr-ts-flowspec-srv6-policy, draft-raszuk-aggr-withdraw-00