Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[Gyan Mishra <[e-mail]>]

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&#12289;IPv4 Remote
   ASBR ID&#12289;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 <[e-mail]> 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 <[e-mail]> wrote:
>
>>
>>
>> On Jan 12, 2022, at 4:01 PM, Robert Raszuk <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*