Hi Sue, That is the most excellent summary of the current state of the draft I have seen so far on any of the lists !
Thank you, R. On Wed, May 27, 2026 at 9:12 PM Susan Hares <[email protected]> wrote: > 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]> 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]> > *Sent:* Tuesday, May 26, 2026 2:24 PM > *To:* Acee Lindem <[email protected]> > *Cc:* Susan Hares <[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) > > > > > > 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]> wrote: > > Hi Sue, > > > On May 26, 2026, at 12:39 PM, Susan Hares <[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]> > > Sent: Tuesday, May 26, 2026 12:32 PM > > To: Susan Hares <[email protected]> > > Cc: lsr <[email protected]>; idr-chairs <[email protected]>; Dongjie > (Jimmy) <[email protected]>; Ketan Talaulikar <[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]> 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] > >> To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
