Robert The primary use case for Stub Link Attribute is defined in the section 1 introduction excerpt below:
So the stub link on inter-as connection needs to advertise this stub link attribute in the IGP as a stub link TLV not TE information, so it can be picked up by BGP-LS to build E2E network graph. RFC 5392 and RFC 5316 define IGP extension to flood TE information about the inter-as link for inter-as LSP to be instantiated. So that is not the same as what we are trying to accomplish here with this draft as here the same stub inter-as link attribute is for BGP-LS to build network graph for SDN controller to instantiate inter-as path. So the bottom line for this to work with a centralized controller is we need a stub link attribute information encoded in the IGP as a TLV. OSPF[RFC5392] defines the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA to carry the TE information about inter-AS links. These LSAs can be used to transfer the information about the stub link which is located at the boundary of one AS. This document defines the Stub-Link TLV within these LSAs to identify the stub link and transfer the associated attributes then. ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE information about inter-AS links. This TLV can be used to transfer the information about the stub link which is located at the boundary of one AS. This document defines the Stub-Link TLV to identify the stub link and transfer the associated attributes. Section 1: For operator which runs different IGP domains that interconnect with each other via the stub links, there is desire to obtain the inter-AS topology information as described in[I-D.ietf-idr-bgpls-inter-as-topology-ext <https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-03#ref-I-D.ietf-idr-bgpls-inter-as-topology-ext>]. If the router that runs BGP-LS Within one IGP domain can distinguish stub links from other normal interfaces, it is then easy for the router to report these stub links using BGP-LS to a centralized PCE controller. The second use case is Dunbar 5G being discussed on the other LSR thread. The third use case is for any stub links are normally the boundary of one IGP domain, knowing them can facilitate the operators to apply various policies on such interfaces, for example, to secure their networks, or filtering the incoming traffic with scrutiny. This is using a centralized BGP policy controller. Excerpts from draft below related to the primary use case to help further explain the use case. BGP LS Inter-AS Topology https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10 This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. Such extension and process can enable the network operator to collect the interconnect information between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol. Draft [I-D.ietf-idr-bgpls-segment-routing-epe <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10#ref-I-D.ietf-idr-bgpls-segment-routing-epe>] defines some extensions for exporting BGP peering node topology information (including its peers, interfaces and peering ASs) in a way that is exploitable in order to compute efficient BGP Peering Engineering policies and strategies. Such information can also be used to calculate the interconnection topology among different IGP domains, but it requires every border router to run BGP-LS protocol and report the information to SDN controller. Considering there will be several border routers on the network boundary, such solution restricts its deployment flexibility. This draft analysis the situations that the SDN controller needs to get the interconnected topology information between different AS domains, defines the new Stub Link NLRI and some new TLVs within the BGP-LS protocol to transfer the key information related to them. After that, the SDN controller can then deduce the multi-domain 5 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10#section-5>. Stub Link NLRI [RFC7752] defines four NLRI types(No. de NLRI, Link NLRI, IPv4 Topology Prefix NLRI, IPv6 Topology Prefix NLRI) to transfer the topology and prefix information. For inter-as link, the two ends of the link locates in different IGP domains, then it is not appropriate to transfer their information within the current defined NLRI types. This draft defines one new NLRI type, called Stub Link NLRI, which is coded as the following format: 5.2 <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10#section-5.2>. Inter-AS TE Scenario When IGP A or IGP B in Figure 1 runs IS-IS TE/OSPF-TE protocol,[RFC5316 <https://datatracker.ietf.org/doc/html/rfc5316>] and [RFC5392 <https://datatracker.ietf.org/doc/html/rfc5392>] def.ine IS-IS and OSPF extensions respectively to deal with the situation for inter-AS traffic engineering. Three new sub-TLVs(Remote AS Number、IPv4 Remote ASBR ID、IPv6 Remote ASBR ID) which are associated with the inter-AS TE link are defined. These TLVs are flooded within the IGP domain automatically. They should be carried within the newly defined Stub Link NLRI within the BGP-LS protocol, as the descriptors for the inter-AS stub link. Kind Regards Gyan On Wed, Jan 12, 2022 at 8:07 PM Robert Raszuk <rob...@raszuk.net> wrote: > Hi Tony, > > Well if that would be controller based TE computation it seems that these > days BGP-LS (ugh!) would be used instead of IGP flooding to pass that info > around. > > Hence that makes (at least :) two of us pretty puzzled on the real use > case here. > > Thx, > R. > > > > > On Thu, Jan 13, 2022 at 1:59 AM Tony Li <tony...@tony.li> wrote: > >> >> >> On Jan 12, 2022, at 4:01 PM, Robert Raszuk <rob...@raszuk.net> wrote: >> >> Very honestly I must have missed that the objective here is to include >> those links in the TE constrained computation. You mean MPLS RSVP-TE ? >> >> Is that so in 2022 ? >> >> >> >> Robert, >> >> It is entirely possible that I have misunderstood the use case. >> >> I would also include SR-TE, SRv6 (ugh!), and any other controller based >> TE that you care to name. >> >> Tony >> >> _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr