+ Authors Thanks Mukul
From: Srivastava, Mukul <[email protected]> Date: Friday, May 22, 2026 at 1:48 PM To: Jeffrey Haas <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [GROW] Re: [[email protected]: WG last call and IPR call for draft-ietf-idr-linklocal-capability (May 13, 2026 to May 27, 2026)] I have reviewed draft-ietf-idr-linklocal-capability-04 and support its publication. The document addresses a well-known gap in RFC 2545 . This is relevant to data center fabrics, BGP unnumbered, and ZTP deployments. Below are few comments. 1. Incorrect RFC cited for YANG models (Section 6) Section 6 states: "Implementations SHOULD provide specific telemetry via the BGP Monitoring Protocol (BMP) [RFC7854] or YANG models [RFC9107]..." RFC 9107 is "BGP Optimal Route Reflection (BGP ORR)" and has nothing to do with YANG models. The authors should replace this with the correct reference for a BGP YANG model, or remove the specific RFC citation if the intended reference is still a work in progress. 2. Undefined behavior when only one side supports the capability (Section 2) Section 2 states that when the capability has not been negotiated, "the resulting behavior is considered undefined and out of scope for this specification." I think operators and implementers need guidance on fallback behavior. At a minimum, a SHOULD-level recommendation to fall back to RFC 2545 behavior (global-only next hop) would improve interoperability in mixed deployments. 3. LL/LL error handling needs justification (Section 5) The document states: "When both IPv6 next hops contain Link-Local IPv6 addresses, the second Link-Local IPv6 address should be used for forwarding." There is no explanation of how a legitimately formed UPDATE would ever contain two Link-Local addresses in a 32-byte next hop field. If this is an error handling case for malformed messages observed in the wild (as suggested by the Bird bug fix in Appendix B), it should be stated as such, and a rationale should be provided for why the second address is preferred over the first, or over treat-as-withdraw. 4. Route Reflector and capability negotiation interaction (Section 4) Section 4 correctly states that a Route Reflector MUST NOT advertise a link-local-only next hop to a client that does not share the same link-layer segment. However, the document does not address what happens when the RR has successfully negotiated Capability 77 with a client that is not on the same link. In this scenario the RR will silently suppress routes for that client with no diagnostic signal. A note acknowledging this operational implication and recommending logging or an operator notification would be helpful. 5. Relationship to BMP peer identification Deployments using Link-Local addresses for BGP peering introduce an ambiguity for BMP monitoring: since IPv6 Link-Local addresses (fe80::/10) are not globally unique, a BMP collector cannot distinguish two peers that share the same fe80:: address on different interfaces using only the information in the BMP per-peer header. This is a real operational concern for networks deploying BMP alongside LL-only BGP. I would like to note that this issue is being actively addressed in draft-lin-grow-bmp-peer-interface (currently at version -01), which defines a Peer-Interface TLV for BMP carrying interface index or interface name alongside the per-peer header. Combined with the BGP Router ID already present in the BMP per-peer header, this provides a fully unambiguous peer identifier. The two drafts are complementary, and it would be worth adding a reference to draft-lin-grow-bmp-peer-interface in Section 6 of this document. Nit: Section 1 (Introduction) contains a typo -- "Capbility” should be "Capability". Overall, this is a well-scoped document solving a real problem and I support its progression. I think comments 1 and 3 are substantive and should be addressed before publication. Comments 2, 4, and 5 are improvement suggestions and will this document better. Thanks to the authors for their work on this. Thanks Mukul From: Jeffrey Haas <[email protected]> Date: Thursday, May 21, 2026 at 2:43 PM To: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [GROW] [[email protected]: WG last call and IPR call for draft-ietf-idr-linklocal-capability (May 13, 2026 to May 27, 2026)] [cc: rtgwg, grow] It occurs to me that rtgwg and grow may not know that they care about this draft. For context, IPv6 linklocal peering are useful for building BGP fabrics (a topic rtgwg is overlapping) and for ISP inter-AS links. However, while the features are regularly in use, there are small interop issues that this draft addresses. IDR could use your scrutiny on this document. Please review and supply feedback or even "looks good to me!". Thanks. -- Jeff ----- Forwarded message from "Dongjie (Jimmy)" <[email protected]> ----- Date: Wed, 13 May 2026 06:30:45 +0000 From: "Dongjie (Jimmy)" <[email protected]> To: "[email protected]" <[email protected]> CC: idr-chairs <[email protected]> Subject: WG last call and IPR call for draft-ietf-idr-linklocal-capability (May 13, 2026 to May 27, 2026) This begins a 2-week working group last call for draft-ietf-idr-linklocal-capability-04. This WG last call ends on May 27th, 2026. https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-linklocal-capability__;!!NpxR!iYtBEQns2tJa_0zrX7yDPN2OrIfU3Ij0rAhD2PpvIyrEwDGzF8TxCJUf2EK1pS49o6KvLoO7V08D9deH$ Please review and provide feedbacks to this last call with an indication of "Support" or "Not Support". For "Not support", it is appreciated to also give explanations and suggestions to resolve them. For the purposes of the shepherd's report and according to IETF BCP 78/79, the authors are requested to declare whether they are aware of any undisclosed IPR covering this draft. Members of the working group are similarly obligated to report any IPR they are aware of as well. Best regards, Jie (as WG secretary & document shepherd) ----- End forwarded message ----- _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
