Robert: I agree with you that the Inter-AS links have been marked as IGP passive in the past. I suspect (based on the spread of initial technologies (e.g. Cisco and Gated) that the IGP passive concept is still in use. The implementation for this technology is H3C and FRR. I do not personally know how IGP passive is used in these implementations.
It defines a new type within the BGP-LS NLRI of inter-AS Link, plus three new TLVS (AS, Remote-ASBR IPv4, Remote-ASBR-IPv6). Section 5 states The "Protocol-ID" is set to the value indicating the source protocol of the inter-AS Link information, as specified in Section 5.2 of [RFC9552]. When the information is sourced from OSPF or IS-IS, the value MUST correspond to one of IGP values as specified in [RFC9552]. The purpose of this new information is to help controllers glue two parts of an Inter-AS Link together as part of a topology calculation. As the truckload of BGP-LS information passes by, I do not think this small addition to the normal IGP information is significant – unless it conflicts with a BGP-LS feature I am unaware of. The reasonable question is about the use of “static” or “direct links” as part of the use case shown in Section 8. As Les notes, this use case could have been explained in section 5 – but we had enough arguments that the authors wrote section 8 to be clearer on the use case. In this use case the SDB1 node is the BGP-LS speaker, and the Inter-AS node with the “inter-AS” link hanging off the node. The authors propose that in this second use case, the protocol ID could be “directly connect interface” or a “static” link to the link (VPN, GRE tunnel, etc). As Acee mentioned, I am aware of the Stub-Link debate. And this email is to ensure that IDR does not approve anything LSR does not agree to add to BGP-LS. Please let me know if I am missing something. Cheerily, Sue From: Robert Raszuk <[email protected]> Sent: Tuesday, May 26, 2026 4:28 PM To: Susan Hares <[email protected]> Cc: Acee Lindem <[email protected]>; lsr <[email protected]>; idr-chairs <[email protected]>; Dongjie (Jimmy) <[email protected]>; Ketan Talaulikar <[email protected]> Subject: Re: [Lsr] Re: Request for comment on BGP-LS draft: draft-ietf-idr-bgpls-inter-as-topology-ext-32 - (1 Week for comment: 5/26 to 6/1) Hi Sue, For tens of years we have been marking Inter-AS links in IGP as passive. Remember the times where edge nodes were not setting next hop self on everything ? This was the method to actually advertise in IGP the BGP next hops of the peer. I think you may have interpreted "passive link" as not an "active link" but this is completely not the case. I am using "passive" as in IGP terminology. Claude explains it like this: Passive link — an interface that the router advertises into the IGP but on which it does not send or process hello packets. No adjacency will ever form over it, even if a neighbor exists. You configure this with passive-interface in OSPF or by marking a circuit passive in IS-IS. The reachability gets advertised, but no IGP traffic crosses the link. Thx, R. On Tue, May 26, 2026 at 10:19 PM Susan Hares <[email protected]<mailto:[email protected]>> wrote: Robert: The draft specifies Inter-AS links (see diagram in document). These are not passive links. The links are active for inter-AS traffic, and the BGP-LS is helping the controller made decisions on traffic. I believe these are not related to the stub-links for IGP. We are waiting for Ketan and Aijun to comment. Sue From: Robert Raszuk <[email protected]<mailto:[email protected]>> Sent: Tuesday, May 26, 2026 2:24 PM To: Acee Lindem <[email protected]<mailto:[email protected]>> Cc: Susan Hares <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>>; idr-chairs <[email protected]<mailto:[email protected]>>; Dongjie (Jimmy) <[email protected]<mailto:[email protected]>>; Ketan Talaulikar <[email protected]<mailto:[email protected]>> Subject: Re: [Lsr] Re: Request for comment on BGP-LS draft: draft-ietf-idr-bgpls-inter-as-topology-ext-32 - (1 Week for comment: 5/26 to 6/1) Wouldn't passive interfaces be sufficient instead of stub-links ? Thx, r. On Tue, May 26, 2026 at 6:59 PM Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Hi Sue, > On May 26, 2026, at 12:39 PM, Susan Hares > <[email protected]<mailto:[email protected]>> wrote: > > Acee: > > If the data comes from IGP (OSPF and ISIS), the answer is yes. > > However, section 8 allows for an Inter-AS link information from a BGP peer > (BGP-LS from BGP only) to set the source on the inter-AS links as either > static or "directly" connected. Please review sections 8 and 9. > > Do these two sections provide enough detail to avoid the issues from the IGP > Stub-links draft? I would think so and if the information were to advertised in OSPF or IS-IS, the existing TE encodings would be used. However, this is a good question for the authors. We don't want to rehash these stub-links drafts under any circumstances. Thanks, Acee > > Sue > > > -----Original Message----- > From: Acee Lindem <[email protected]<mailto:[email protected]>> > Sent: Tuesday, May 26, 2026 12:32 PM > To: Susan Hares <[email protected]<mailto:[email protected]>> > Cc: lsr <[email protected]<mailto:[email protected]>>; idr-chairs > <[email protected]<mailto:[email protected]>>; Dongjie (Jimmy) > <[email protected]<mailto:[email protected]>>; Ketan Talaulikar > <[email protected]<mailto:[email protected]>> > Subject: Re: [Lsr] Request for comment on BGP-LS draft: > draft-ietf-idr-bgpls-inter-as-topology-ext-32 - (1 Week for comment: 5/26 to > 6/1) > > Speaking as both WG chair and WG member: > > I don't have a problem with this draft as long as RFC 5392 (OSPF) and RFC > 9346 (IS-IS) are used as the source of the BGP-LS inter-AS topo information. > We don't have time in LSR to rehash the IGP stub-links drafts just because > IDR is advancing this document. > > Thanks, > Acee > >> On May 26, 2026, at 8:45 AM, Susan Hares >> <[email protected]<mailto:[email protected]>> wrote: >> >> Greetings LSR: >> IDR has reached consensus to publish >> draft-ietf-idr-bgpls-inter-as-topology-ext-32. >> This draft defines a new type within the BGP-LS Network Layer Reachability >> Information (NLRI) for an Inter-AS Link, as well as three new >> type-length-values (TLVs) for the BGP-LS Inter-AS Link descriptor. It >> allows the following two types of use cases: 1) IGP (ospf or isis) to >> BGP-LS and 2) BGP-only (import data from static/direct interfaces) to >> BGP-LS). >> Please respond to this message if you object to the publication of the >> draft. Otherwise, the IDR chairs will forward this to the IESG for >> publication on 6/1/2026. >> Cheerily, Sue Hares >> Shepherd >> IDR co-chair _______________________________________________ >> Lsr mailing list -- [email protected]<mailto:[email protected]> >> To unsubscribe send an email to [email protected]<mailto:[email protected]> > > _______________________________________________ Lsr mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
