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

From: Aijun Wang <[email-masked]>
Date: Thu, 13 Jan 2022 07:06:01 +0800

Hi, Tony:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 02:16, Tony Li <[email-masked]> wrote:
> 
> 
> Hi Aijun,
> 
>> 
>> It would seem to me that if you re-used existing TLVs, you could be adding subTLVs to carry any additional information.  This would probably be a lot cleaner.
>> [WAJ] Then we should update RFC5316, RFC5292, RFC3630 etc. It may also influence the existing deployment. 
>> There are also other situations that the RFC5316 and RFC5292 does not cover, for example, for the associated information that the edge computing wants to utilize etc.
>> Start from the clean slate will be more acceptable?
> 
> 
> Yes, I’m suggesting that you consider a way of using existing TLVs and adding subTLVs to them in order to convey the information.
> 
> A big point of using TLV encoding in the first place is to provide extensibility. It would be a design error not to use it, when appropriate. Creating a new entity every time you add a feature leads to more complexity in the design and in the resulting code.

[WAJ] If the proposed stub link follow the same rule as the existing link, we can adding the new sub-TLV to achieve the goal.
But current it is not. If we change or update the rule, we should consider the back compatibility or the existing implementation.
The TLV type design assure it can be extended at the same TLV level, and if the router can’t recognize, it just ignores. The process of existing TLV is not influenced. 

> Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 00:54:25 +0100

Aijun,

[WAJ] If the proposed stub link follow the same rule as the existing link,
> we can adding the new sub-TLV to achieve the goal.
>

What puzzles me in this proposal is why are you insisting on making a stub
link not-so-stubby instead of treating it as a passive interface (as others
already suggested) ?

What additional (I infer dynamic) attributes are you planning to
advertise of this link ?

The draft is so focused on the mechanics and there is very little there
about the real use cases.

Frankly when watching this discussion and reading the draft I am asking
myself what is missing from already available encoding which you think is
necessary to be part of the IGP advertisements ?

Many thx,
R.

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Jan 2022 15:55:25 -0800

Hi Aijun,

> But current it is not.

Could you please be more specific? AFAICT, the whole point is to inject stuff into the LSDB for TE purposes.

> If we change or update the rule, we should consider the back compatibility or the existing implementation.

Correct, if you use existing TLVs, and extend the semantics with subTLVs, you can be reasonably well assured of backward compatibility.  New TLVs won’t do that for you.

Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Jan 2022 15:58:04 -0800

> On Jan 12, 2022, at 3:54 PM, Robert Raszuk <[email-masked]> wrote:
> 
> What puzzles me in this proposal is why are you insisting on making a stub link not-so-stubby instead of treating it as a passive interface (as others already suggested) ? 

Robert,

A pure passive interface results in the node advertising the prefixes associated with the interface, but no link attributes.

This would give an implementation the option of advertiseing link attributes for TE to pick up.  Note that this would be a new feature even without any subTLVs.  One could advertise the administrative group (i.e. color) of an inter-AS link, for example.

T

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 01:01:52 +0100

Hi Tony,

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 ?

Kind regards,
R.

On Thu, Jan 13, 2022 at 12:58 AM Tony Li <[email-masked]> wrote:

> A pure passive interface results in the node advertising the prefixes
> associated with the interface, but no link attributes.
>
> This would give an implementation the option of advertiseing link
> attributes for TE to pick up.  Note that this would be a new feature even
> without any subTLVs.  One could advertise the administrative group (i.e.
> color) of an inter-AS link, for example.
>
> T
>
>
>

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Jan 2022 16:59:54 -0800

> On Jan 12, 2022, at 4:01 PM, Robert Raszuk <[email-masked]> 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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 02:06:43 +0100

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.

---

From: Tony Li <[email-masked]>
Date: Wed, 12 Jan 2022 18:05:09 -0800

Robert,

> On Jan 12, 2022, at 5:06 PM, Robert Raszuk <[email-masked]> wrote:
> 
> 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. 

BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it into the LSDB and let BGP-LS convey it to the controller for you.

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 13 Jan 2022 00:27:52 -0500

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 <[email-masked]> wrote:

>> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 11:40:02 +0100

Hi Tony,

If you originate BGP-LS on the PE of interest it seems you can stuff it
with whatever you like. I read RFC9086 as one example of it.

Thx,
R.

On Thu, Jan 13, 2022 at 3:05 AM Tony Li <[email-masked]> wrote:

> BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it into
> the LSDB and let BGP-LS convey it to the controller for you.
>
> Tony
>
>

---

From: Aijun Wang <[email-masked]>
Date: Thu, 13 Jan 2022 19:02:17 +0800

Hi, Robert:

I remembered we have discussed this. RFC9086 requires every border router run BGP-LS.
But normally, we need only one router within IGP run BGP-LS.

I think Tony has gotten one of key use use case for this draft. The difference between us is how to accomplish it.

Aijun Wang
China Telecom

> On Jan 13, 2022, at 18:40, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Tony,
> 
> If you originate BGP-LS on the PE of interest it seems you can stuff it with whatever you like. I read RFC9086 as one example of it. 
> 
> Thx,
> R.
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 12:08:12 +0100

Hi Aijun,

> But normally, we need only one router within IGP run BGP-LS.

True - if we keep adding opaque stuff to the IGP to limit the number of
BGP-LS sessions per area.

In my view BGP-LS should and perhaps will be replaced with a real pub-sub
mechanism sooner or later and that will be part of every edge node. Hence
trashing the IGP protocol is IMHO a wrong thing to do if the goal here is
just to export the information to the controller in the first place.

Best,
R.

On Thu, Jan 13, 2022 at 12:02 PM Aijun Wang <[email-masked]>
wrote:

> I think Tony has gotten one of key use use case for this draft. The
> difference between us is how to accomplish it.
>
> Aijun Wang
> China Telecom
>
>> BGP-LS can’t pick it up unless it’s in the LSDB.  Thus, you inject it
>> into the LSDB and let BGP-LS convey it to the controller for you.
>>
>> Tony
>>
>>