IDR meeting at IETF 126

Chairs:
    Susan Hares <skh@ndzh.com>
    Jeffrey Haas <jhaas@pfrc.org>
    Keyur Patel <keyur@arrcus.com>

Secretary:
    Jie Dong <jie.dong@huawei.com>

===============================================================================

Materials:
https://datatracker.ietf.org/meeting/126/session/idr/

Meetecho:
1st session: https://meetecho.ietf.org/client/?session=35495
2nd session: https://meetecho.ietf.org/client/?session=35496
3rd session: https://meetecho.ietf.org/client/?session=35649

Collaborative Note Taking：
https://notes.ietf.org/notes-ietf-126-idr

Chat room:
https://zulip.ietf.org/#narrow/stream/idr

First IDR Session: July 20, 2026

Topic: BGP Core protocol extensions

16:30 - 18:30 (UTC+2) Monday session IV

Room: Park Suite 7

0. Agenda bashing and Chairs' Slides (5 mins)

[Chairs]

Ketan: Would appreciate if Xiaohu could send a mail on IPR to both IDR and BESS list. Also need to clarify whether there is IPR on the BESS DMZ draft.

1. BGP BFD Strict-Mode (5 mins)

 draft-ietf-idr-bgp-bfd-strict-mode-18
 draft-ietf-idr-bgp-fsm-iana
[Jeff Haas]

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.

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

2. BGP YANG Update (BGP-4) (5 mins)

draft-ietf-idr-bgp-model-19
[Jeff Haas]

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.

Xueyan Song (BBF Liaison): noted that BBF's upcoming specifications depend directly on this model and urged its publication.

Jeff Haas: Appreciate the partipation in WG LC and review from BBF and other organizations.

Xueyan Song: Consider send liaison to BBF and let them know how to participate.

Ketan Talaulikar: This is one of the largest YANG models in the IETF (at 240 pages) and strongly encouraged participants to voice opinion on the mailing list.

3. Fully Adaptive Routing Ethernet (10 mins)

draft-xu-idr-fare-05
draft-xu-idr-fare-in-mpson-00
[Xiaohu Xu]

Krishnaswamy Ananthamurthy: Why a default route cannot be advertised to the NIC instead？

Xiaohu Xu: Prefer to advertise aggregated routes.

Krishna: As a contributor to the UPA draft, there is a new revision, can discuss how the overlaps are handled.

Xiaohu Xu: the Pros and cons of each option were considered.

Jeff Tantsura: Cannot use default because AI networks are rail-optimized, requiring specific subnets to prevent traffic rails from breaking down.

Keyur Patel: Agree with what Jeff said, there is east-west traffic patterns, you need subnets.

Jeff Haas: Thanks for clearing the IPR issue. There is a five author limit for documents. The fare base draft will get into the adoption queue. For the other one more discussion would be needed.

4. YANG Data Model for BGP Outbound Route Filtering (10 mins)

draft-zw-idr-bgp-orf-yang-model-00
[Fan Zhang]

Jeff Haas: Thanks for building YANG for all ORFs. Once the base BGP model is finalized, the chairs and routing working groups will need to establish a consistent review process for all such augmentations.

(from chat)
Ketan Talaulikar: Suggest 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.

6. BGP RR Deployment Considerations (15 mins)

draft-smith-idr-rr-deployment-considerations-00
[David Smith]

Keyur Patel: Suggest to look at all the RR related documents in the past and refer to them, incorporating considerations for hot-potato routing and RR, full-mesh vs. non-full-mesh client behaviors, IGP integration and transit forwarding, and Graceful Restart optimization.

John Scudder: Why placing this in IDR and not in GROW? Seems more in charter for GROW.

David Smith: It is a valid point.

Jeff Haas: Agree with John that this is within GROW's charter. GROW already has a related opeartional security draft, there is a 15% overlap with this draft. The chairs will discuss about this, and please continue the discussion on the list.

Keyur Patel: Didn't see guideines for implementors. Should there be some guidlines for implementors?

(from chat)

Jeffrey Haas: For the RR draft, some overlapping GROW work: draft-ietf-grow-routing-ops-sec-inform

James Cumming: For the RR draft, consider how/if the RRs being on generalised compute impacts the recommendations. Additionally, consider how ORR might play a role in design decisions.

7. Border Gateway Protocol 4 (BGP-4) (15 mins)

draft-ietf-idr-bgp4-rfc4271bis-01
[John Scudder]

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".

Susan Hares: Some of the parameters for FSM were already optional features. We hava a pattern that you can follow.

Keyur Patel: Would like to keep things out of this spec, the document has reached 100 pages.

John Scudder: Which one is more painful? 100 pages plus a bunch of other documents, or 120 pages in one document?

Keyur: Prefer to keep things out.

Susan: How much of the doc is about FSM?

John: About a half.

Ketan: As WG participant, the extended message is required for BGP-LS.

Keyur Patel: When this document bacomes a standard, do we need to worry about interoperability? Should we change the language in a way that change the old text?

John Scudder: The goal was not to have normative changes. If we make normative changes, the WG needs to be very clear about it.

Jeff Haas: Please see the IEPG discussion which is about origin attribute. The next topic will talk about route resolution and cost.

(from chat)
Jeffrey Haas: For John, we also have in YANG a "feature" as a concept. Aligning them is just picking some names and discussing how to make sure elements are flagged hard as optional is what's needed. We'll try something and see how it works out.

Jeffrey Haas: https://github.com/ietf-wg-idr/RFC4271bis/issues - please consider filing there.

Susan Hares: Sunday LACNIC - indicate that Origin is used in South America for operational.

Jeffrey Haas: Item for study for how origin field is being used is whether it's intended to have inter-domain impact, or solely impacting intra-domain and the use case is leaky.

8. BGP best path next-hop selection enhancements (10 mins)

draft-vroonen-idr-bgp-bestpath-nh-selection-03
[Olivier Vroonen]

Zhenqiang Li: This work is useful, while it has overlap with another draft. Have sent an email to the authors and the list.

Xiaohu: Could we use anycast as the endpoint of the SR Policy case?

Jeff Haas: Please send the question to the list.

John Scudder: 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.

Jeff Haas: We have more than one draft on this topic, chairs will figure out which document should be called for WG adoption first. This is also related to 4271bis and the cost community draft.

(from chat)
Susan Hares: Would you review all potential Color sources (CAR/CT/RFC9012), Extended Community)

Jie Dong: BGP CPR (RFC 9723) may also needs to be taken into consideration?

9. Source-Selective BGP (15 mins)

draft-braet-idr-source-selective-bgp-framework-00
draft-braet-idr-bgp-source-selective-attr-00
[Kamiel Braet]

Alexander Azimov: Do you believe L3 firewall can be the solution for vlumeric ddocs attack?

Kamiel Braet: Source Selective BGP is an extension.

Alexander Azimov: What would you do for attacks at layer-4?E.g. SYN flood with spoofed address space.

Kamiel: It relies on the source address validation.

Jeff Haas: The first comment is on scailing consideration. the second comment is some people may not be comfortable with this feature, just like UPA. There are security considerations.

(from chat)

John Scudder: I'm struggling to understand what this brings to the table that flow-spec doesn't. I'd say it at the mic if we weren't out of time.

Nat Kao: Same. Why not use FS to do this?

Ketan Talaulikar: Thanks Kamiel for bringing your problem statement and solution for discussion and feedback to IDR as a new participant and an operator.

Keyur Patel: he seems to be talking about a preemptive mechanism.. versus FS which is a reactive means.

John Scudder: ISTM either FS or this thing can be done preemptively or (more realistically) reactively.

Robert Raszuk: We spoke about using FS on the list. Kamiel says it is too inflexible and hard to deploy in the internet as it requires new AFI/SAFI ...

Robert Raszuk: and he has a point ... to me the most scary part is the uncontrolled blast radius of his new attribute

Jeffrey Haas: This is a strongly coupled dest route + source filter. It's that strong coupling that makes this challenging in a normal unicast destination routed internet.

10. Canonical textual representation of BGP Path Attributes (10 mins)

draft-marenamat-idr-bgp-attribute-formatting-01
[Maria Matějka]

Luuk Hendriks: This work is useful. Would like to see how it scores my implementation. Is the open source library kind of minimal test cases?

Maria Matějka: Need contributors for that.

Luuk Hendriks: Suggest to also talk to the maintainer of BGP dump who is also at this IETF.

Jeff Haas: This is useful work. YANG is not the only tool. Suggest to coordinate with Martin Pels' parallel BGP community formatting draft in the GROW working group and suggested utilizing YANG display hints.

(from chat)

Susan Hares
@Maria - +1 on good work. Ext-Comm is mess. Would like to discuss FlowSpec v2 Extended communities. See wiki at https://wiki.ietf.org/group/idr/FSv2-Alloc/actions/FSv2-extcom

11. BGP Enhancements for ECMP EBGP Scenarios (5 mins)

draft-lin-idr-bgp-ecmp-ebgp-enhancements-00
[Changwang Lin]

Jeff Haas: encourage to discuss this on the list. Any change to path selection especially time-based needs to be careful.

(from chat)

Keyur Patel
hmm.. I dont get this extension.. isn't it an implementation specific change?

John Scudder：As a piece of historical trivia, if I remember right either RFC 1771 or some other piece of BGP history specified that a route must not be advertised back to the AS it came from, but this was later removed for reasons. (Maybe related to some idea about multidomain multicast routing that never came to fruition.)

krishnaswamy ananthamurthy：Implmentations have old best path to prefer in case of conflict. This not new.

Susan Hares: John Scudder - IT was also an earlier RFC1771 thing Yakov had another plan for. MDSP was the 2nd.

12. Threat Model for BGP Color Extended Community (8 mins)

draft-yuan-idr-bgp-color-threats-00
[Yuan Yuan]

Susan Hares: You may also want to consider the community container as another way to bind it, the security issues may be better done in RPKI.

Jeff Haas: These are good security considerations. There is related work in GROW, suggest to coordinate with them.

(from chat)

John Scudder: Is anyone actually promiscuously forwarding based on Color received from the big I Internet? If "yes" then ZOMG.

Second IDR Session: July 24, 2026

Topics: BGP SR, BGP-LS and core protocol extensions (overflow)

14:00 - 15:30 (UTC+2) Friday Session III

Room: Park Suite 8

0. Agenda bashing (5 mins)
   [Chairs] [Susan Hares Presenting]

1. BGP Signaling of MASQUE Tunnel Encapsulation (10 mins)

draft-rosomakho-idr-bgp-masque-tunnel-00
[Alvaro Retana]

Alvaro Retana: Could add then Tunnel Encapsulationm Endpoint, the same way as other tunnels do. Opinions?

David Schinazi: I noticed that you specified the ALPN. Not a BGP expert, suggest to include the HTTPS DNS Resource Record (RR) format instead of the current sub-TLVs.
This HTTP DNS Records givse you everything you need. This provides built-in extensibility for all ALPN and address hints.
This would be added instead of the ALPN and the Tunnel Encapsulation TLV.

Alvaro Retana: It would still be encoded as sub-TLVs.

John Scudder: Have concerns regarding routing mechanisms relying on DNS, but conceded it might be acceptable for overlay scenarios. Prefer to have explicit IP addresses in the attribute.

Warren Kumari: [from chat] Support David Schinazi’s suggestion of embedding the record data directly rather than dynamically querying DNS.

John Scudder: Have concerns regarding routing mechanisms relying on DNS, but conceded it might be acceptable for overlay scenarios. Prefer to have explicit IP addresses in the attribute.

Jeff Haas: The BGP next hop should have some relationship to the tunnel endpoint. Suggest to talk about this in the draft. It seems DNS sec is not mandatory here. Have you thought about using DANE for this?

David Schinazi: The answer from Masque people on DANE is abosolutely not. MASQUE is implemented on top of http, and http has accepted the reality that the web does not have PKI. Therefore, the http does not have DNSSEC,

Jeff Haas: Even the SMTP groups have though about the DNSSEC, and they are barely a service with protection.

David Lamparter: Want to ask whether you are pointing at DNS or just inlcuding the record data. The latter seems to be a good idea.

David Schinazi: Not suggesting to query that from DNS. Put in an HTTPS address.

(from chat)
Keyur Patel: @Alvaro - if the DNS record is included then am hoping there will be some texts that ensures that the URI is only resolved using the address carried in the DNS record?

Keyur: I should have said: URI only uses IP address....

2. BGP Unreachable Prefix Announcement (UPA) (15 mins)

draft-krierhorn-idr-upa-03
[Jakub Horn/Serge Krier]

Haibo Wang: (Huawei) Changing the solution to MP_REACH based is good for this solutionm, and it is good to have newly added data center scenario. This scenario was mentioned in Xiaohu's presentation in first IDR session, and the solution needs further discussion about the details.

Maria Matějka: how does this work with best hop selection at route reflectors? When mixing, and partial deployment - what's expected to happen?

Serge Krier: yes, we did consider this, maybe we need to add more text to describe the operation in this case. For excampl,e you need to describe the stand-alone case

John Scudder: much better than -00. BGP Identifier in the community, this crosses eBGP boundaries - not unique past the AS Boundary. What does that mean, imply?

Serge Krier: will consider

Aijun Wang: using MP-reach to advertise, is there any effect on servers(?) if it can't understand the semantics of the community, won't it be used as route?

Serge Krier: The goal is limit this to only speakers supporting UPA. It should not be sent to bgp peers not supporting UPA.

Aijun Wang: The peer that does not understand the new community may installed a new detailed route for the prefix.

Serge Krier: The aggregate would still have the aggregate.

Aijun Wang: Perhaps you should consider the details discussed in the IGP discussion on UPA.
(... taken to list)

Jeff Tantsura: nVidia is developing an implementaion, and plan to report on it at San Francisco IETF. It works well for some topologies/scenarios, but not as well for others. Testing to evaluate.

Jeff Haas: this feature is terrifying. Therer are lots of security considerations, especially if it leaks. I would be curious to see why you choose transitive instead of non-transitive for this feature.
But as John said, this version much better than the first version. The chat discussion suggests that a new AFI/SAFI is useful for this state.
We are not trying to attract or generate state with this AFI/SAFI, but injecting a black hole with this address family.

Jeff Tantsura: The unreachability stuff does exactly that.

Jeff Haas: Please don't ship code for this, there will be malfunctions and very public outages.
We understand the use case needs to be solved. Let's work on improving the proposal.

3. BGP PORT EC for AIDC (10 mins)
   draft-zhang-idr-portid-ec-02
   [Junye Zhang]

Jeff Haas: chat comment, standard community aggregation functionality allows taking more than one route and aggregate the list of communities into the same route

(from chat)
Jeffrey Haas: For @junye Zhang - You will find that extended community procedures have, in the past, permitted "community aggregation".
That may be helpful here for limited cases of aggreation where you have more than one route for the same destination. and you could send out the aggregated list. (small numbers of communities).
These procedures for aggregation of communities are not consistently implemented by vendors.
You could take inspiration from the DMZ procedures for the DMZ procedures for link bankwidth.

Zheng Zhang: @Jeffrey Haas, we would also like to get guidance in this regard (community aggregation).

4. Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios (10 mins)
   draft-ietf-idr-rtc-hierarchical-rr-05
   [Jie Dong]

Jeff Haas: There are implementations of two of the options in the draft,
for the third option which does not have implementation, consider to put it in the appendix.

5. BGP Link-State Extensions for BGP-only Networks (10 mins)
   draft-ietf-idr-bgp-ls-bgp-only-fabric-05
   [Aravind Babu MahendraBabu]

Jeff Haas: How soon until this draft's done (ready for publication)?
Aarvind: We have almost covered we wanted to cover. If we receive feedback, we'll add to the text.

Jeff Haas: If authors think this document is close to finish, we can do the last call in next IETF meeting in San Francisco.

6. Advertising p2mp policies in BGP (10 mins)
   draft-ietf-idr-sr-p2mp-policy-01
   [Hooman Bidgoli]

Jeff Haas: There is overlap with with the draft-ietf-bess-bgp-multicast-controller (which refers to draft-bess-bgp-mulicast).
Did you have any plans to do any interoperation testing with draft-ietf-bess-bgp-multicast-controller or is this ships in the night?
Hooman Bidgoli: This is ships in the night. We wanted to make this close to the unicast.
Jeff Haas: We will want to coordinate with BESS on this drasft.

7. BGP SR Policy Extensions for BFD Configuration (5 mins)
   draft-li-idr-bgp-sr-policy-bfd-extension-02
   [Zhenqiang Li]

Jeff Haas: For coordination suggest to also present this draft in SPRING.

8. BGP Extensions for Inter-Domain Flexible Algorithm with Segment Routing over IPv6 (SRv6) (5 mins)

   [Liyan Gong]

Keyur Patel: What if the same prefix has multiple Flex-Algos? It seems only one will be carried across the domain?
What happens if the extended community is filtered? The IGP flex-algos do provide a constrained way of computing SPFs.
What happens if the same prefix carries multiple flex-algos? The BGP best path selection will probably pick one whichi is not what you want.
You probably want to think about this carefully.

Liyan Gong: Thank you for your feedback. Last meeting we received similar feedback. This veersion we have highlighted the scenario
where we want to use this technology. So if the flex Algo ID are different, we can map it from the configuration.
Maybe on this scenario the CPR approach will be very similar. We want to constrain the scenario with the same flex algo ID.
Do you think this is suitable.

Jeff Haas: Following up on what Keyur is saying. We have two circumstances. The first one utilizes a community (to set flex algo),
this has all sorts of security considerations. This feedback is overlapping (similar) to the feedbacvk we
gave the authors of the UPA draft. This is a generic problem (with communities).
Also, as Keyur is pointing out - many use cases carrying the same flex algo have the same destination over
more than one topology. If you are going to have disjoint forwarding, it is important to be able to send more than
one route for the same destination with the different flex algos. What you are proposing is acceptable for some scenarios but may not others.
Our collected suggestion is to spend some time thinking about those different scenarios, and whether that impacts your proposal.

Liyang Gong: This is solution for a simple and exact deployment scenario. We do not want to cover all the scenarios.

Jeff Haas: I realize you do not want to cover every single scenario (because this is a very generic feature),
it is a generic feature and it will need some of that discussion. Discussion on the mailing list can help refine this point.

Liyang Gong: We can continue this on the mailing list.

9. BGP Extensions for Network Resource Partition (10 mins)
   draft-li-idr-bgp-nrp-01
   [Zhenqiang Li]

Keyur: How would color be carrried for VPN routes together with NRP ID? Is it 1 to 1 or N to 1?
Zhenqiang Li: Many to 1.
Keyur: Will it exceed normal BGP packet size or 255 communities?
Zhenqiang Li: The private routes for different colors are adverised by the endpoit separately.
Keyur: So does that mean 1 to 1? One route to one color community?
Zhenqiang li: 1 NRP ID for one customer, and may customers can share the same SR policy path.
Keyur: I'll take this to the email list.

Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 100 minutes

Third IDR Session: July 24, 2026

Topics: BGP Flowspec, overflow.

16:00 - 17:30 (UTC+2) Friday Session IV

Room: Park Suite 8

0. Agenda bashing (5 mins)
   [Chairs]

1. Problem Statement and Roadmap for BGP FlowSpec Monitoring (8 mins)
   draft-cui-idr-flowspec-feedback-roadmap-00
   [Yujia Gao]

From Robert: This information is valuable only the controller, and BGP is a spray and pray protocol.
Robert does not think this information should be in BGP.

Jeff Haas (co-author hat); Not everything here can or should be carried in BGP for the ecosystem.
She has on the prior slides information on the components. Installation state will be monitored through BMP, and forward state via IPfix.
So this work is going to be hitting many WGs. It will be informed by what we do here in IDR for flowspec.

Sue Hares: Feedback on your chart. For completeness we should include BGP-LS (even though I have some quandries on BGP-LS).

2. BGP Flow Specification Version 2 - for Basic IP (15 mins)
   draft-ietf-idr-fsv2-ip-basic-07
   [Susan Hares]

(Moved from the 2nd session)
3. Advertising SAV Rule-related Information using BGP Link-State (5 mins)
draft-tong-idr-bgp-ls-sav-rule-05
[Jing Zhao]

Jeff Haas: The scailing mechanism of BGP-LS will need to be discussed for SAV and other use cases.

4. Bitwise IP Filters for BGP FlowSpec (10 mins)
   draft-kao-idr-bitwise-ip-filters-05
   [Nat Kao]

Jeff Haas: You'll make note that as Nat was talking about for prioritization, the Bitcoin twice filter masks are more specific
then the source and destination fields they govern.

5. BGP Extensions to Enable BGP FlowSpec based IFIT (10 mins)
   draft-he-idr-bgp-flowspec-ifit-03
   [Xiaoming He]

Susan Hares: This is the combination of IFIT attribute and other actions in BGP communities. The interaction with other marking actions needs to be further considered.
Will send comments on the interactions with other FSv2 filters and actions.

6. BGP Flow Specification for QUIC (5 mins)
   draft-lin-idr-flowspec-quic-00
   [Changwang Lin]

Joel Halpern: I'm puzzled about the use of Quic connection ID. They are random numbers, and can change during the communication.

Changwang: The connection ID may be reported to the controller.

Joel: They Quic Connection ID are not reported to anybody.

Haibo: The connection ID is deep in packet, and can be variable length. It will make hardware processing complex.

Jeff Haas: Echo to Joel's comment. And think this is part of the function may be done with Flowspec V2. Hardware with different capabilities are expected in FSv2.
We are going to scenarios were complex firewall hardware is mixed with other hardware that can only layer 3 and layer 4.
This mixture of haredware causes us to consider how do we incrementally deploy these things, and how we have mixed networks with different levels of sophistication.

7. BGP Flowspec Redirect Load Balancing Group Community (8 mins)
   draft-wu-idr-flowspec-redirect-group
   [Haibo Wang]

Jeff Haas: Looking forward to the discussion about mixing of multiple actions.

8. BGP Flow Specification by ClassID (8 mins)
   draft-song-idr-flowspec-classid-filter-01
   [Jinming Li]

Susan Hares: Is Class-ID written to the packets?

Jinming: No.

Jeff Haas: This has a little overlap with some of the use cases with the path redirect feature。

Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 74 minutes