Hello, Mukul, thanks for the comments! I did some adjustments here https://github.com/ietf-wg-idr/draft-ietf-idr-linklocal-capability/pull/34. Are you able to see that?
On Fri, May 22, 2026 at 9:12 PM Srivastava, Mukul <[email protected]> wrote: > + 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] > -- Donatas
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
