< 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]> 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]] > *Sent:* Tuesday, June 23, 2026 10:58 PM > *To:* Ketan Talaulikar <[email protected]>; Aijun Wang < > [email protected]> > *Cc:* Gunter van de Velde (Nokia) <[email protected]>; > [email protected]; [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]> > *Sent:* Tuesday, June 23, 2026 9:10 AM > *To:* Aijun Wang <[email protected]> > *Cc:* Gunter van de Velde (Nokia) <[email protected]>; > [email protected]; Susan Hares < > [email protected]>; [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]> > 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]] > *On Behalf Of *Ketan Talaulikar > *Sent:* Tuesday, June 23, 2026 1:20 PM > *To:* Gunter van de Velde (Nokia) <[email protected]> > *Cc:* [email protected]; Susan Hares < > [email protected]>; [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]> 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]
