Aijun: Please remove the new concept per Ketan and Les.
Sue Hares Shepherd From: Aijun Wang <[email protected]> Sent: Thursday, June 25, 2026 3:35 AM To: 'Les Ginsberg (ginsberg)' <[email protected]>; 'Ketan Talaulikar' <[email protected]> Cc: Susan Hares <[email protected]>; 'Gunter van de Velde (Nokia)' <[email protected]>; [email protected]; [email protected]; 'lsr' <[email protected]> Subject: RE: [Idr] Re: [Shepherding AD review] review of draft-ietf-idr-bgpls-inter-as-topology-ext-34 Hi, Les and Ketan: I have explained how can we utilize the MTID in an IGP instance to allocate the inter-AS interface to an MT-ID in each of IGP domain. Utilize the passive interface is enough. The controller can direct the traffic from one MT in IGP A to another MT in IGP B, we needn’t the underlying IGP do any extra work. Best Regards Aijun Wang China Telecom From: Les Ginsberg (ginsberg) [mailto:[email protected]] Sent: Thursday, June 25, 2026 12:53 PM To: Ketan Talaulikar <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>> Cc: Susan Hares <[email protected]<mailto:[email protected]>>; Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; lsr <[email protected]<mailto:[email protected]>> Subject: RE: [Idr] Re: [Shepherding AD review] review of draft-ietf-idr-bgpls-inter-as-topology-ext-34 I am in full agreement with Ketan. The scope of an MTID is an IGP instance. It has no meaning across multiple IGP instances – nor across different IGPs. Therefore it clearly has no applicability between two different ASs. The new text should be removed. Les From: Ketan Talaulikar <[email protected]<mailto:[email protected]>> Sent: Wednesday, June 24, 2026 9:25 PM To: Aijun Wang <[email protected]<mailto:[email protected]>> Cc: Susan Hares <[email protected]<mailto:[email protected]>>; Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; lsr <[email protected]<mailto:[email protected]>> Subject: [Idr] Re: [Shepherding AD review] review of draft-ietf-idr-bgpls-inter-as-topology-ext-34 < as a co-author of this document > + LSR WG for their input on whether MT-ID is applicable for IS-IS (and OSPF) Inter-AS extensions Hi Aijun, MT is an IGP concept. So, if the relevant extensions are not supported for IGPs, I don't understand how they can be introduced in BGP-LS advertisements from IGPs. I also do not understand what you mean by "extract such information from the underlying IGP". Can you please explain this with references to existing specifications? Thanks, Ketan On Thu, Jun 25, 2026 at 8:42 AM Aijun Wang <[email protected]<mailto:[email protected]>> wrote: Hi, Sue and Ketan: Actually, the inter-AS links may belong to one particular MT-ID on each border router. Let these inter-AS interfaces act as the passive interfaces, and assign them the necessary MT-ID value, can reuse the existing MT-ID TLVs that defined in RFC 5120 and RFC 4915 to transfer the MT-ID information. The router that runs BGP-LS can then extract such information from the underlying IGP, no need to consider the “IS-IS or OSPF extensions for Inter-AS Link advertisements”. If necessary, we can the above additional descriptions into the document in next version. Aijun From: Susan Hares [mailto:[email protected]<mailto:[email protected]>] Sent: Tuesday, June 23, 2026 10:58 PM To: Ketan Talaulikar <[email protected]<mailto:[email protected]>>; Aijun Wang <[email protected]<mailto:[email protected]>> Cc: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: [Idr] Re: [Shepherding AD review] review of draft-ietf-idr-bgpls-inter-as-topology-ext-34 Aijun: Please remove MT-ID TLV from the Inter-AS Link NLRI until you have verified this with LSR (as Ketan requested). Sue Hares Shepherd From: Ketan Talaulikar <[email protected]<mailto:[email protected]>> Sent: Tuesday, June 23, 2026 9:10 AM To: Aijun Wang <[email protected]<mailto:[email protected]>> Cc: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [Idr] Re: [Shepherding AD review] review of draft-ietf-idr-bgpls-inter-as-topology-ext-34 < as co-author of this document > Hi Aijun, As a co-author of this document, I have concerns with the change you made in this update related to MT-ID. You've added the MT-ID TLV to the Inter-AS Link NLRI when it is not even present for the underlying IS-IS or OSPF extensions for Inter-AS Link advertisements—refer to RFC9346 and RFC5329. I asked for this to be verified with the LSR WG to confirm. It seems you found support for it, so can you explain how so? Thanks, Ketan On Tue, Jun 23, 2026 at 1:40 PM Aijun Wang <[email protected]<mailto:[email protected]>> wrote: Hi, Ketan and Gunter: I have updated the document according to your comments and suggestions. Please review it(https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Didr-2Dbgpls-2Dinter-2Das-2Dtopology-2Dext&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=6QfXbhMObYUhmU-Cy4Jp4cATis5FgQClNqM9ciDZqhUWkjKnYx-eS6GlPRrEKWUu&s=n_b_4R3KQNl4ajAiscEU9OUnxsLpI3gf41Im42hLsEs&e=>) and verify whether they address your concerns. More detail responses are inline below. Aijun From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Ketan Talaulikar Sent: Tuesday, June 23, 2026 1:20 PM To: Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Susan Hares <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [Idr] Re: [Shepherding AD review] review of draft-ietf-idr-bgpls-inter-as-topology-ext-34 < as co-author of this document > Hi Gunter, Thanks for your review and feedback. I'll let Aijun and my other co-authors who are holding the editor pen on this document respond and update the document as necessary. Please see my clarifications inline below. On Mon, Jun 22, 2026 at 8:47 PM Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> wrote: Hi Authors, WG, Please find here a AD Shepherd review for draft-ietf-idr-bgpls-inter-as-topology-ext-34. Before progressing the draft i have few observations that i would like the authors and the WG to consider. I think this draft is in great state, and the observations are generally easy to resolve. # Many thanks to Sue Hares for the Shepherd write-up and Michael Richardson & Andrew Stone for the RTGDIR reviews, Dave Thaler for the SECDIR review and Tina Tsou for the OPSDIR review # RFC8735 is currently listed as Normative, but the draft only uses it in Section 9 as background/use-case motivation. RFC 8735 is Informational, so keeping it normative creates a downward normative reference. I would move it to Informative KT> I agree. [WAJ]: Move RFC 8735 to Informative. # Update IANA section with TLV 1028/1029 inside the NLRI The draft says the Local Node Descriptors include “one or both of IPv4 and IPv6 Router-ID of the ASBR using TLV 1028 and/or 1029”, and notes that these RFC 9552 TLVs are being reused inside the NLRI. In RFC 9552, TLVs 1028/1029 are BGP-LS Attribute TLVs, not Node Descriptor sub-TLVs. RFC 9552 defines Node Descriptor sub-TLVs as 512, 513, 514, and 515. If this document extends tlv 1028/1029 allowed context from BGP-LS Attribute to NLRI descriptors, that should be stated explicitly in the IANA section and possibly reflected in the registry description. KT> The TLV code points for both the BGP-LS NLRI and Attribute are shared and maintained in a common registry which was renamed as "BGP-LS NLRI and Attribute TLVs" by RFC9552 to clear this aspect - https://www.iana.org/assignments/bgp-ls-parameters/bgp-ls-parameters.xhtml#node-descriptor-link-descriptor-prefix-descriptor-attribute-tlv<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_bgp-2Dls-2Dparameters_bgp-2Dls-2Dparameters.xhtml-23node-2Ddescriptor-2Dlink-2Ddescriptor-2Dprefix-2Ddescriptor-2Dattribute-2Dtlv&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=3QxUPy-fV0G16Z4tIRByiA&m=6QfXbhMObYUhmU-Cy4Jp4cATis5FgQClNqM9ciDZqhUWkjKnYx-eS6GlPRrEKWUu&s=cChgSc4kijER1-dPps5HxQX2nbqGjTJNBIzej7cG4VM&e=> KT> As such, there are no boundaries or ranges assigned/allocated for the two placements. An early convention existed but wasn't followed for a few allocations (see MSD TLVs), so this remains only in the minds of a few WG participants without any formal guideline. So I think we are good on this point? # The draft names TLVs 271/272 as: " 277 | 271 |IPv4 Remote ASBR ID | 25/22 | [RFC9346]/3.4.2| 278 | | | | [RFC5392]/3.3.2| 279 | 272 |IPv6 Remote ASBR ID | 26/24 | [RFC9346]/3.4.3| 280 | | | | [RFC5392]/3.3.3| " RFC 9346 uses"IPv4 Remote ASBR Identifier sub-TLV" and "IPv6 Remote ASBR Identifier sub-TLV" RFC 5392 uses “IPv4 Remote ASBR ID”, so the draft matches OSPF but not IS-IS exactly. Is this intentional? KT> Yes, that is correct. We had to pick one. # Incorrect or ambiguous reference to TE Router ID TLV Section 6.2 says the IPv4 Remote ASBR ID should use the TE Router ID “as specified in the Traffic Engineering Router ID TLV [RFC9346]”. For IS-IS, RFC 9346 defines “IPv4 TE Router ID” and “IPv6 TE Router ID” sub-TLVs in the Router CAPABILITY TLV context, not simply a generic “Traffic Engineering Router ID TLV”. For OSPF, RFC 5392 refers to the Router Address TLV / TE Router ID from OSPF TE. Please make the source-specific mapping precise: for OSPF, refer to the RFC 5392/OSPF-TE source; for IS-IS, refer to the IPv4/IPv6 TE Router ID mechanisms in RFC 9346. KT> I agree [WAJ] Done # Potential overstatement: “both MUST be present” " 227 - One or both of IPv4 and IPv6 Router-ID of the ASBR using TLV 1028 228 and/or 1029 [RFC9552], depending on whether the ASBR is configured 229 with one or both of the IPv4 and IPv6 TE Router-IDs. If both are 230 known, then both MUST be present. (Note: while [RFC9552] introduced 231 these TLVs for use in the BGP-LS attribute, this document also 232 leverages the same TLVs for use in the NLRI.) " The draft says if both IPv4 and IPv6 Remote ASBR IDs are known, both MUST be present. But RFC 5392 and RFC 9346 both say the IPv4 and IPv6 Remote ASBR ID/Identifier sub-TLVs MAY both be present. This draft can impose stricter BGP-LS encoding rules, but it should say that intentionally. Please clarify whether this document intentionally strengthens the source IGP requirements when exporting to BGP-LS. KT> Since this is about taking from the IGPs and encoding into BGP-LS, the text seems OK to me. i.e., if both are present in IGPs, they MUST also be encoded in BGP-LS. This is necessary because they are in the NLRI where we need a stricter and more precise specification. # Section 5: Missing MT-ID consideration Section 5 lists optional additional inter-AS Link Descriptors but omits Multi-Topology Identifier TLV 263. RFC 9552 says MT-ID MUST be included as a Link Descriptor if the underlying IGP link object is associated with a non-default topology. Please clarify whether MT-ID TLV 263 is valid/required for inter-AS Link NLRI when the underlying inter-AS TE advertisement is topology-specific. KT> I didn't find MT use in RFC9346 but we may have missed something. Perhaps this can be cross-checked with folks in LSR WG? [WAJ] I add back the MT-ID TLV 263 to cover the possible scenario. # Section 8 likely has an error: “protocol-id set to BGP” Section 8 says BGP EPE reports local information via Link NLRI with protocol-id set to BGP. However, RFC 9552 Protocol-ID values are IS-IS L1, IS-IS L2, OSPFv2, Direct, Static, and OSPFv3; there is no base RFC 9552 Protocol-ID named “BGP”. Please verify this text. It may need to reference the protocol-id used by RFC 9086, or avoid saying “per RFC9552” if the value is not from RFC 9552. KT> I agree. It needs to reference RFC9086 for the BGP protocol ID. [WAJ] Actually, current text for EPE, refer exactly to RFC 9086. # Section 8: Is this a normative section or a informative section on alternate use-case beyond current specification? Please consider adding informative use-cases into an appendix to avoid operators and implementors to observe this section as Normative instead of an Informative procedure extension. The alternative is to make it explicitly clear that this is Informative. KT> It is a mix of normative (the text about encoding) and informative (the text related to the figure and its description). [WAJ] Actually, it is encoding guideline for another possible scenario. # Section 8 inconsistency: Local Node Descriptors for Direct/Static Section 8 says Local Node Descriptors include Autonomous System TLV 512, Router-ID of ASBR BGP Node using TLV 1028/1029, and Inter-AS Link Descriptors. But RFC 9552 says IGP Router-ID TLV 515 is mandatory for Direct or Static configuration. Section 8 should include IGP Router-ID TLV 515 for Direct/Static, or clearly define why TLV 1028/1029 is being used instead. KT> I agree some clarification is needed. [WAJ] Update TLV 1028/1029 with IGP Router-ID(TLV 515) # Section 11.2 title says “Link Descriptors”, but the registry is “BGP-LS NLRI and Attribute TLVs”; make clear these are used as inter-AS Link Descriptor TLVs. KT> I agree. The title of Figure 9 needs fixing. [WAJ] Done Thanks, Ketan Thanks again for this great document. It was a pleasure reviewing. Brgds, Kind Regards, Gunter Van de Velde Routing Area Director
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
