Hi, Robert:
Actually, the IGP stub link draft(https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/) starts from the ‘passive link’, then to more general concept ‘stub link’. We still think the proposed “Stub-Link” TLV in this document for OSPF/IS-IS is one more valid container to convey more information about the stub-link(especially for the non-inter-as scenario), not solely the current information that are conveyed via the OSPF/IS-IS TE TLV. Are you interested to forward it together? Aijun From: [email protected] [mailto:[email protected]] On Behalf Of Robert Raszuk Sent: Wednesday, May 27, 2026 4:28 AM 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: [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]
