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

From: Christian Hopps <[email-masked]>
Date: Tue, 04 Jan 2022 01:58:57 -0500

Hi Folks,

This begins a 2 week WG Adoption Call for the following draft:

https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

Please indicate your support or objections by January 18th, 2022.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts.

Thanks,
Chris.

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 4 Jan 2022 16:23:48 +0800

Hi, Christian and all:

The stub links are used in widespread within the network, and it is useful
to identify them within the IGP in several scenarios (as described in
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02
#section-1).
I support its adoption.
 
I am not aware of any IPR that related to this draft.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Christian
Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

Authors, please respond to the list indicating whether you are aware of any
IPR that applies to these drafts.

Thanks,
Chris.

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

---

From: <[email-masked]>
Date: Tue, 4 Jan 2022 17:37:42 +0800 (CST)

Hi WG,

Support adoption.

Regards,
PSF

------------------原始邮件------------------
发件人：ChristianHopps
收件人：[email-masked];
抄送人：[email-masked];[email-masked];[email-masked];[email-masked];
日 期 ：2022年01月04日 15:04
主 题 ：[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/
Please indicate your support or objections by January 18th, 2022.
Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts.
Thanks,
Chris.
_______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 4 Jan 2022 08:15:51 -0500

I am not aware of any undisclosed IPR.

I support WG adoption.

Thanks

Gyan

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: Huzhibo <[email-masked]>
Date: Wed, 5 Jan 2022 08:11:36 +0000

Hi, WG:

This draft provides a way to advertise the stub link and their associated attributes.
I support its adoption as a co-author.

Best Regards

Zhibo hu

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

Thanks,
Chris.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Jan 2022 11:44:17 +0100

Hi,

I'm afraid the draft has some serious issues that would need to be 
addressed if it is to become a WG document.

Below comments use ISIS as an example, but most of it applies to OSPF as 
well.

1. The draft says:

"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 sub-TLV within this
  TLV to identify the stub link and transfer the associated attributes."

- there is an existing mechanisms to advertise inter-AS link. There is 
existing mechanisms to advertise external prefix. What exactly is the 
reason to define a new TLV?

It's still not clear to me what exactly is the use case for the new TLVs 
defined in the document.

2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV of 
the existing Inter-AS Reachability TLV:

- it advertises prefix. The advertisement of the prefix and link 
information is strictly decoupled in ISIS. Here the proposal is to 
advertise the prefix inside the Inter-AS Reachability TLV, which is 
advertising a link. Why do we need the prefix of the inter-AS link to be 
advertised inside the link advertisement?

2. The new ISIS Stub-link Sub-TLV includes sub-TLVs, the text says:

  "Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs
    22, 23, 25, 141, 222, and 223" can be included if necessary."

The parent Inter-AS Reachability TLV already has Sub-TLVs from the exact 
same space. Not to mention that the new sub-TLV itself comes from the 
same space. Looks broken.

3. Link Type in ISIS Stub-link Sub-TLV - what is it used for and why do 
we need it?

thanks,
Peter

---

From: Aijun Wang <[email-masked]>
Date: Wed, 5 Jan 2022 20:01:51 +0800

Hi, Peter:

Thanks for your comments.
Please see replies inline.

Aijun Wang
China Telecom

> On Jan 5, 2022, at 18:45, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi,
> 
> I'm afraid the draft has some serious issues that would need to be addressed if it is to become a WG document.
> 
> Below comments use ISIS as an example, but most of it applies to OSPF as well.
> 
> 
> 1. The draft says:
> 
> - there is an existing mechanisms to advertise inter-AS link. There is existing mechanisms to advertise external prefix. What exactly is the reason to define a new TLV?
> 
> It's still not clear to me what exactly is the use case for the new TLVs defined in the document.

[WAJ] RFC 5392 and RFC 5316 defines the TLV to carry the information about other endpoint for the inter-AS link, for example , the remote ASBR ID, the remote AS etc.
Such information are normally derived from the manual configuration.

For stub link, there are situations that the above information can’t easily be obtained or doesn’t exist, what we can get only the information about the local end, not the information about the remote end.

Then It is better to use different TLV to differentiate the local information from the remote information. Define the Stub-Link TLV to contain such local obtained information is then the reasonable way.

The use case of stub link can be referred at the introduction part of the draft.
> 
> 2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV of the existing Inter-AS Reachability TLV:
> 
> - it advertises prefix. The advertisement of the prefix and link information is strictly decoupled in ISIS. Here the proposal is to advertise the prefix inside the Inter-AS Reachability TLV, which is advertising a link. Why do we need the prefix of the inter-AS link to be advertised inside the link advertisement?

[WAJ]For stub link, what we can get is only the interface addresses of the local end and its associated prefixes. The associated prefixes can be used to match the two ends of the stub-link, it can also indicate the server’s address as that described in https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/.

> The parent Inter-AS Reachability TLV already has Sub-TLVs from the exact same space. Not to mention that the new sub-TLV itself comes from the same space. 

[WAJ] 141(inter-AS reachability information) is mentioned in the above sentence.

> 
> 3. Link Type in ISIS Stub-link Sub-TLV - what is it used for and why do we need it?

[WAJ] There are different kinds of stub link. Differentiate them via the link type can help the precise control and analyze these stub links.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Jan 2022 14:53:24 +0100

Hi Aijun,

please see inline (##PP):

On 05/01/2022 13:01, Aijun Wang wrote:
>> On Jan 5, 2022, at 18:45, Peter Psenak 
>> <ppsenak=[email-masked]> wrote:
>>
>> Hi,
>>
> [WAJ] RFC 5392 and RFC 5316 defines the TLV to carry the information 
> about other endpoint for the inter-AS link, for example , the remote 
> ASBR ID, the remote AS etc.
> For stub link, there are situations that the above information can’t 
> easily be obtained or doesn’t exist, what we can get only the 
> information about the local end, not the information about the remote end.

##PP

All link related TLVs, including Inter-AS Reachability TLV share the 
same Sub-TLV space, including Link Local/Remote Identifiers IPv4/IPv6 
local/remote address, etc. What exactly is missing?

All you have defined is the prefix advertisement with the link? What is 
the exact usage of the prefix that is advertised with the link?

> 
> Then It is better to use different TLV to differentiate the local 
> information from the remote information. Define the Stub-Link TLV to 
> contain such local obtained information is then the reasonable way.

##PP
I don't understand the above. We have existing sub-TLVs that include 
both local and remote link data.

> The use case of stub link can be referred at the introduction part of 

##PP
the description in the draft is very high level. Please provide an exact 
use case for the prefix that is advertised with the link.

>>
>> 2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV 
>> of the existing Inter-AS Reachability TLV:
>>
>> advertising a link. Why do we need the prefix of the inter-AS link to 
>> be advertised inside the link advertisement?
> 
> [WAJ]For stub link, what we can get is only the interface addresses of 
> the local end and its associated prefixes. The associated prefixes can 
> be used to match the two ends of the stub-link, it can also indicate the 
> server’s address as that described in 

##PP

ok, so you want to use the prefix information of the Inter-AS 
Reachability TLV to link the two endpoints of such link together?

Inter-AS Reachability TLV includes:

a) the "IPv4/v6 remote ASBR identifier" which identifies the remote
end-point and should carry the TE Router ID (see sections 3.3.2 and 
3.3.3 of RFC5316).

b) The local end-point  ID is advertised in the form of the "IPv4/IPv6 
TE Router ID" in the IS-IS Router Capability TLV of the originator.

These two are sufficient to pair the two endpoints of the inter-AS link 
together.

> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ 
> <https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/>.
> 
>>
>> The parent Inter-AS Reachability TLV already has Sub-TLVs from the 
>> exact same space. Not to mention that the new sub-TLV itself comes 
>> from the same space. 
> 

##PP
what you have is:

Inter-AS Reachability TLV
  Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
   ISIS Stub-link Sub-TLV
    Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223

where ISIS Stub-link Sub-TLV is part of the
  "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223"

> [WAJ] There are different kinds of stub link. Differentiate them via the 
> link type can help the precise control and analyze these stub links.

##PP
exact use case please.

thanks,
Peter

---

From: Aijun Wang <[email-masked]>
Date: Wed, 5 Jan 2022 23:20:46 +0800

Hi, Peter:

Aijun Wang
China Telecom

> On Jan 5, 2022, at 21:54, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Hi Aijun,
> 
> All link related TLVs, including Inter-AS Reachability TLV share the same Sub-TLV space, including Link Local/Remote Identifiers IPv4/IPv6 local/remote address, etc. What exactly is missing?
> 
> All you have defined is the prefix advertisement with the link? What is the exact usage of the prefix that is advertised with the link?
[WAJ] Yes, they all share the same sub-TLV space, but there is no place to identify the link is one stub link. There is also no sub-TLV to define the associated prefixes for the stub-Link. 

> I don't understand the above. We have existing sub-TLVs that include both local and remote link data.

[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such information is possible, but we should still to define the link type(as that in RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  Comparing the two different approaches, we select to define one new sub-TLV to contain the above information in one place together.

> the description in the draft is very high level. Please provide an exact use case for the prefix that is advertised with the link.

[WAJ] it can be used to pair the two ends of the stub-link, it can also be used to identify the severs address that attached to the stub link.

>> [WAJ]For stub link, what we can get is only the interface addresses of the local end and its associated prefixes. The associated prefixes can be used to match the two ends of the stub-link, it can also indicate the server’s address as that described in 
> 
> ##PP
> 
> ok, so you want to use the prefix information of the Inter-AS Reachability TLV to link the two endpoints of such link together?
> 
> end-point and should carry the TE Router ID (see sections 3.3.2 and 3.3.3 of RFC5316).
> 
> b) The local end-point  ID is advertised in the form of the "IPv4/IPv6 TE Router ID" in the IS-IS Router Capability TLV of the originator.
> 
> These two are sufficient to pair the two endpoints of the inter-AS link together.

[WAJ] The above remote information must be configured manually on the local device. It is paired by manual. Thinking there are many links among the ASBRs, would you like to configure them manually for every remote ends on each link? We are looking for the automatic pairing solution.
The prefixes that associated with the stub link can assist to accomplish this task automatically.

> 
> 
>> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ <https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/>.
>>> 
[WAJ] It seems to define one new TLV that at the same level of “Inter-AS reachability TLV”, for example “Stub-Link reachability TLV” is better. If acceptable, will update the draft.

>> [WAJ] There are different kinds of stub link. Differentiate them via the link type can help the precise control and analyze these stub links.

[WAJ] For example, the stub-link(loop back type) can be used to identify the router; the stub-link(AS boundary type) can be used to identify the boundaries of AS; the stub-link(Vlan interface type) can be used to identify the logical GW for layer 2 domain etc.

---

From: Peter Psenak <[email-masked]>
Date: Wed, 5 Jan 2022 16:56:39 +0100

Aijun,

> The prefixes that associated with the stub link can assist to accomplish this task automatically.

If the ISIS/OSPF adjacency is not formed over the link, you need to 
manually configure remote endpoint parameters. Defining a new TLV is not 
going to make any difference.

Using the local subnet information for identifying two endpoints of the 
same link does not sound appealing to me.

We have link local/remote IDs (and IP addresses) to pair the two 
endpoints of the link in both OSPF and ISIS. We do not need another 
mechanism for the same. In addition, what you propose does not work for 
unnumbered links.

I don't see a need for the new stub-link advertisement.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 5 Jan 2022 21:26:18 +0000

I'm not aware of any IPR.
Thanks,
Acee

On 1/4/22, 2:04 AM, "Christian Hopps" <[email-masked]> wrote:

    Hi Folks,

    Thanks,
    Chris.

---

From: Aijun Wang <[email-masked]>
Date: Thu, 6 Jan 2022 07:32:55 +0800

Hi, Peter:

Aijun Wang
China Telecom

> On Jan 5, 2022, at 23:57, Peter Psenak <ppsenak=[email-masked]> wrote:
> 
> Aijun,
> 
> If the ISIS/OSPF adjacency is not formed over the link, you need to manually configure remote endpoint parameters. Defining a new TLV is not going to make any difference.

[WAJ] Automatic Pairing and Manual Pairing has big differences for operators. 

> 
> Using the local subnet information for identifying two endpoints of the same link does not sound appealing to me.
> 
> We have link local/remote IDs (and IP addresses) to pair the two endpoints of the link in both OSPF and ISIS. We do not need another mechanism for the same. In addition, what you propose does not work for unnumbered links.

[WAJ] The unnumbered link is seldom used within the operator network, especially for the boundary link. The proposed solution can cover almost all the stub-link related scenarios. 

> I don't see a need for the new stub-link advertisement.

[WAJ] Such TLV/sub-TLV can also be used to transfer the attributes that related to the edge computing servers.

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 7 Jan 2022 02:42:49 +0000

Hi Everyone,

    I read the draft and support its adoption.

Best Regards,
Huaimo
________________________________
From: Lsr <[email-masked]> on behalf of Christian Hopps <[email-masked]>
Sent: Tuesday, January 4, 2022 1:58 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=KDGtq1muOp7w7TzMB2oc8gHF93GFFZJ2U2oArusK7rA%3D&amp;reserved=0

Thanks,
Chris.

_______________________________________________
Lsr mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=X1ic6sdRo2naXF2iDvAfbHgyitrwonRhGBmHTh6Kx6o%3D&amp;reserved=0

---

From: Shraddha Hegde <[email-masked]>
Date: Fri, 7 Jan 2022 05:17:26 +0000

Hello,

I read this document and have two basic questions.

1.  The advertisement of inter-AS TE LSA in OSPFV2/V3 itself indicates that the link is outside IGP domain.
      This information is good enough to apply special treatment to these links. 
      Why is it necessary to advertise additional stub-link TLV to indicate this same information?
2. The inter-As TE LSAs in OSPF carry the link TLV. All the TE attributes related to the link can be
     Advertised as part of this link TLV including interface addresses (in local interface address sub-TLV).
It is not clear reading the draft what additional value this new TLV is bringing in.

Rgds
Shraddha

Juniper Business Use Only

-----Original Message-----
From: Lsr <[email-masked]> On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 12:29 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

[External Email. Be cautious of content]

Hi Folks,

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/__;!!NEt6yMaO-gk!T4jYJBqpTXVICbt3k4d93C7fz-81ikudKyYJpnLHoGUxYTQDjMV428Z-gGZ1XObC$

Thanks,
Chris.

_______________________________________________
Lsr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!T4jYJBqpTXVICbt3k4d93C7fz-81ikudKyYJpnLHoGUxYTQDjMV428Z-gEw6hnV4$

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 7 Jan 2022 16:14:13 +0000

Hi Everyone,

Best Regards,
Linda Dunbar

________________________________
From: Lsr <[email-masked]<mailto:[email-masked]>> on behalf of Christian Hopps <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, January 4, 2022 1:58 AM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=KDGtq1muOp7w7TzMB2oc8gHF93GFFZJ2U2oArusK7rA%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-lsr-stub-link-attributes%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C805a81c0cf464ba4e7e108d9d18773d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637771201983574636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=uJHx3Vve%2F39dWPFLWX2Yf0TpM05Y0ltWtZhcH3UrHno%3D&reserved=0>

Thanks,
Chris.

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cc8e9ddfed01546ea489408d9cf507442%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637768766727894253%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=X1ic6sdRo2naXF2iDvAfbHgyitrwonRhGBmHTh6Kx6o%3D&amp;reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C805a81c0cf464ba4e7e108d9d18773d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637771201983574636%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ldoBe47FMYzIx4Nrti%2FnNpiL3ZoXSGC0yv7NsVVq4rI%3D&reserved=0>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 15:13:09 +0000

I oppose WG adoption of this draft.

In addition to my comments below, I am in agreement with the points made by Peter and Shraddha previously in this thread.

My comments below are in the context of IS-IS/RFC5316, but I believe are equally valid in the context of OSPF/RFC5392.

There are two types of new information the draft proposes to advertise under TLV 141:

1)Identifying a link by the prefix locally configured on the link rather than by the local/remote addresses.

The motivation for this addition seems to be to avoid the need for the operator to locally configure the remote address. But I think this is not a desirable change.

As pointed out by Peter, this does not work for unnumbered links. (It also would not work for Pt-2-MP links). The authors assert that it is unlikely that unnumbered links would be used in the expected use cases - but I do not find this argument convincing. Even if unnumbered links are not currently being used, the restriction that they could not be used in the future seems highly undesirable. It would put us in the position of having to revise this functionality in the future in an incompatible way in order to add such support. This is a bad design choice.

Aside: The assertion that unnumbered links will not be used seems at odds with the inclusion of "loopback" as a link type. More on that below.

Also, as the draft builds on top of existing RFC5316 functionality, it is still required to advertise remote AS Number and Remote ASBR ID as well as remote Router IDs (IPv4 and/or IPv6) (see https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 ) - all of which still need to be locally configured since there is no IGP operating on the link. So the suggestion that not having to configure the remote link address provides significant simplification in deployment does not stand up to scrutiny.

2)New link type information (AS boundary link/Loopback link/Vlan interface link) to be advertised

There is no mention in the draft as to how this information will be used. Indeed, I do not even know what a "loopback link" is unless it is an unnumbered link to which a loopback address has been associated - which makes me wonder why the authors have dismissed the use of "unnumbered" in deployments.

I therefore conclude that existing functionality defined in RFC 5316/RFC5392 is sufficient and there is no need for the extensions defined in this draft.

    Les

> Sent: Monday, January 3, 2022 10:59 PM
> To: [email-masked]

---

From: Aijun Wang <[email-masked]>
Date: Tue, 11 Jan 2022 00:33:32 +0800

Hi, Les:

Wish the below explanation can correct your understanding of this draft, and also your conclusions.

Aijun Wang
China Telecom

> On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> The motivation for this addition seems to be to avoid the need for the operator to locally configure the remote address.
[WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t. 

> But I think this is not a desirable change.
> 
> As pointed out by Peter, this does not work for unnumbered links. (It also would not work for Pt-2-MP links). The authors assert that it is unlikely that unnumbered links would be used in the expected use cases - but I do not find this argument convincing.
[WAJ] Is there any operator adopt unnumbered link at its boundary network? There is even very rare case for the unnumbered interface be used within the operator network. And, with the IPv6 deployment, what is the usages of unnumbered interface? Won’t it be depreciated in future? Very curious you and Peter stick to this point, but not considering its wider use scenarios.

> Even if unnumbered links are not currently being used, the restriction that they could not be used in the future seems highly undesirable.

[WAJ] Would like to hear the reason and scenarios that the unnumbered interface will be used in future. I think it should be deprecated instead.

> It would put us in the position of having to revise this functionality in the future in an incompatible way in order to add such support. This is a bad design choice.

[WAJ] We should keep the trend, not stick to the obsolete obstacles.

> 
> Aside: The assertion that unnumbered links will not be used seems at odds with the inclusion of "loopback" as a link type.

[WAJ] The loop back address won’t borrow address from others. Or if you consider it maybe, please give the reason.

> More on that below.
> 
> Also, as the draft builds on top of existing RFC5316 functionality, it is still required to advertise remote AS Number and Remote ASBR ID as well as remote Router IDs (IPv4 and/or IPv6) (see https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 )

[WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the above information manually then. And for other stub link type(for example, the edge router that connects the server) there will be no remote-AS, no remote ASBR, how can you configure them?

> - all of which still need to be locally configured since there is no IGP operating on the link. So the suggestion that not having to configure the remote link address provides significant simplification in deployment does not stand up to scrutiny.

[WAJ] Please see the previous explanation.
> There is no mention in the draft as to how this information will be used.
[WAJ] The information about various stub link type is mainly for the controller. If necessary, we can add some potential use cases for such type information, but this is not the main points of this draft.

> Indeed, I do not even know what a "loopback link" is unless it is an unnumbered link to which a loopback address has been associated - which makes me wonder why the authors have dismissed the use of "unnumbered" in deployments.

[WAJ] Actually, it is loopback interface, not loopback link, which you have imaged that one unnumbered link borrows the address from the loopback interface.
The loopback interface is one type of Stub Link, which has the characters that doesn’t send out IGP LSA.

> I therefore conclude that existing functionality defined in RFC 5316/RFC5392 is sufficient and there is no need for the extensions defined in this draft.
[WAJ] Wish the above explanation can correct your conclusions.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Jan 2022 19:49:48 +0000

Aijun -

Please see inline.

> From: Aijun Wang <[email-masked]>
> Sent: Monday, January 10, 2022 8:34 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> 
> Hi, Les:
> 
> > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg)
> <ginsberg=[email-masked]> wrote:
> >
> > In addition to my comments below, I am in agreement with the points
> made by Peter and Shraddha previously in this thread.
> >
> > My comments below are in the context of IS-IS/RFC5316, but I believe are
> equally valid in the context of OSPF/RFC5392.
> >
> > The motivation for this addition seems to be to avoid the need for the
> operator to locally configure the remote address.
> > As pointed out by Peter, this does not work for unnumbered links. (It also
> would not work for Pt-2-MP links). The authors assert that it is unlikely that
> unnumbered links would be used in the expected use cases - but I do not
> find this argument convincing.
> [WAJ] Is there any operator adopt unnumbered link at its boundary
> network? There is even very rare case for the unnumbered interface be
> used within the operator network. And, with the IPv6 deployment, what is
> the usages of unnumbered interface? Won’t it be depreciated in future?
> Very curious you and Peter stick to this point, but not considering its wider
> use scenarios.
> 
[LES:] Aijun - Unnumbered links are in common usage today. We should not define extensions which do not allow support for this.

> > Even if unnumbered links are not currently being used, the restriction that
> they could not be used in the future seems highly undesirable.
> 
> [WAJ] Would like to hear the reason and scenarios that the unnumbered
> interface will be used in future. I think it should be deprecated instead.

[LES:] Deprecating the use of unnumbered is outside the scope of this specification - and I would argue is not something we (the WG) should be advocating in any case.

> 
> > It would put us in the position of having to revise this functionality in the
> future in an incompatible way in order to add such support. This is a bad
> design choice.
> 

[LES:] Unnumbered is not obsolete - it is only you who have arbitrarily decided that it is no longer needed.

> 
> >
> > Aside: The assertion that unnumbered links will not be used seems at odds
> with the inclusion of "loopback" as a link type.
> 
> [WAJ] The loop back address won’t borrow address from others. Or if you
> consider it maybe, please give the reason.
> 
> > More on that below.
> >
> > Also, as the draft builds on top of existing RFC5316 functionality, it is still
> required to advertise remote AS Number and Remote ASBR ID as well as
> remote Router IDs (IPv4 and/or IPv6) (see
> https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 )
> 
> [WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the
> above information manually then. And for other stub link type(for example,
> the edge router that connects the server) there will be no remote-AS, no
> remote ASBR, how can you configure them?
>
[LES:] Indeed - which means your extensions to TLV 141 violate RFC 5316. Please read the referenced section I provided and pay attention to the normative statements ("MUST") there.
So, RFC 5316 conformant implementations will not accept the TLVs you apparently intend to send.
This is not something which can be ignored.

> > - all of which still need to be locally configured since there is no IGP
> operating on the link. So the suggestion that not having to configure the
> remote link address provides significant simplification in deployment does
> not stand up to scrutiny.
> 
> [WAJ] The information about various stub link type is mainly for the
> controller. If necessary, we can add some potential use cases for such type
> information, but this is not the main points of this draft.
> 
[LES:] There is still nothing in the draft which explains what value the new information provides.
For example, why does a controller or a router care whether a given link is a VLAN or not a VLAN?

> > Indeed, I do not even know what a "loopback link" is unless it is an
> unnumbered link to which a loopback address has been associated - which
> makes me wonder why the authors have dismissed the use of
> "unnumbered" in deployments.
> 
> [WAJ] Actually, it is loopback interface, not loopback link, which you have
> imaged that one unnumbered link borrows the address from the loopback
> interface.
[LES:] The draft introduction discusses 

"... stub  links is in a data center Layer 2 and Layer 3 Top of Rack(TOR) switch
   where the inter connected links between the TOR switches"

This is clearly a link connecting two (or more) boxes - which means it isn’t a loopback.
If you are including loopbacks proper in what your draft is addressing, then clearly a link TLV (TLV 141) isn’t appropriate.
You seem unable to clearly define whether you are trying to advertise a prefix or a link which is truly an interconnect.
They aren’t at all the same thing.

> 
> >
> > I therefore conclude that existing functionality defined in RFC
> 5316/RFC5392 is sufficient and there is no need for the extensions defined in
> this draft.
[LES:] No it does not.
What it does do is convince me that the draft is at best confusing, incomplete, and non-interoperable with existing RFC 5316 implementations.
All of which are good reasons NOT to adopt the draft.

    Les

> >> Cc: [email-masked]; [email-masked]; [email-masked]; draft-wang-
> lsr-
> >> [email-masked]

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 12:38:28 -0800

I object to the adoption of this draft. 

I don’t think that it’s fundamentally a correct approach.

One of the important things that we’ve learned over the years is that we need to build general designs and not simply add new elements and mechanisms for each use case that we think of.

I understand the AS boundary use case. I agree that’s worthy of consideration. Not so much the others.

I would suggest that the authors spend a bit more time cogitating.

Regards,
Tony

> On Jan 3, 2022, at 10:58 PM, Christian Hopps <[email-masked]> wrote:
> 
> Hi Folks,
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Jan 2022 14:18:34 +0800

Hi, Les:

There is the way to solve your concern.
1. https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.1 and https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.2 includes also the sub-TLVs field, which is pointed to the corresponding part for TE-Link TLV(for OSPF) and Inter-AS Reachability TLV (TLV 141).
  That is to say, the draft doesn't preclude the inclusion of Remote-AS, IPv4/IPv6 remote ASBR Identifier sub TLV.
  So, if you insist that the unnumbered link will be used between the ASes, then for such stub-link type(we can add one new stub link type), the operator should configure the remote information manually. And for such stub link type, the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST be included(same as the rules defined in RFC5316).
  For other numbered interface, such information needn't be manually configured. This can certainly save the cost for management of the network, and also meet your mentioned scenario.
  Is it OK for you?

2. For the consideration of current extension violate the rules defined in RFC5316, I have proposed another solution at https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/ upon the comments from Peter. That is to say:
  "[WAJ] It seems to define one new TLV that at the same level of “Inter-AS reachability TLV”, for example “Stub-Link reachability TLV” is better. If acceptable, will update the draft."

For the above two proposals, do you have other comments? If not, will update the draft to reflect it.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: Tuesday, January 11, 2022 3:50 AM
To: Aijun Wang <[email-masked]>
Cc: Christian Hopps <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

Please see inline.

> Cc: Christian Hopps <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; 
> > There are two types of new information the draft proposes to 
> > advertise
> under TLV 141:
> >
> > 1)Identifying a link by the prefix locally configured on the link 
> > rather than by
> the local/remote addresses.
> >
> would not work for Pt-2-MP links). The authors assert that it is 
> unlikely that unnumbered links would be used in the expected use cases 
> - but I do not find this argument convincing.
> used within the operator network. And, with the IPv6 deployment, what 
> is the usages of unnumbered interface? Won’t it be depreciated in future?
> Very curious you and Peter stick to this point, but not considering 
> its wider use scenarios.
> 

> future in an incompatible way in order to add such support. This is a 
> bad design choice.
> 

> [WAJ] The loop back address won’t borrow address from others. Or if 
> you consider it maybe, please give the reason.
> 
> > More on that below.
> >
> [WAJ] No. With the newly defined TLV/sun-TLV, we need not configured 
> the above information manually then. And for other stub link type(for 
> example, the edge router that connects the server) there will be no 
> remote-AS, no remote ASBR, how can you configure them?
>

> operating on the link. So the suggestion that not having to configure 
> the remote link address provides significant simplification in 
> deployment does not stand up to scrutiny.
> 
> controller. If necessary, we can add some potential use cases for such 
> type information, but this is not the main points of this draft.
> 

> unnumbered link to which a loopback address has been associated - 
> which makes me wonder why the authors have dismissed the use of 
> [WAJ] Actually, it is loopback interface, not loopback link, which you 
> have imaged that one unnumbered link borrows the address from the 
> loopback interface.
> The loopback interface is one type of Stub Link, which has the 
> characters that doesn’t send out IGP LSA.
> 

> 5316/RFC5392 is sufficient and there is no need for the extensions 
> defined in this draft.
[LES:] No it does not.

    Les

> >> draft-wang-
> >> Authors, please respond to the list indicating whether you are 
> >> aware of
> any

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Jan 2022 14:21:23 +0800

Hi, Tony:

For the AS boundary use case, do you have other better solution? 
I have responded to Les for his mentioned/insisted unnumbered link scenario. if it is acceptable, is it the general design then?

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 4:38 AM
To: Christian Hopps <[email-masked]>
Cc: lsr <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 10 Jan 2022 22:39:00 -0800

Hi Aijun,

> For the AS boundary use case, do you have other better solution? 

Is there some way that this could be modeled as a normal link instead of a stub link?  In any case, I am not responsible for coming up with a better solution. The onus is on you to convince us that this is a Good Thing to do.

> I have responded to Les for his mentioned/insisted unnumbered link scenario. if it is acceptable, is it the general design then?

I don’t understand this comment. I agree with Les that unnumbered links are important.

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Jan 2022 15:02:50 +0800

Hi, Tony:

We are trying to reuse the existing mechanism to solve such problem, but as mentioned in https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:

"[WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such information is possible, but we should still to define the link type(as that in RFC3630) to identify the stub-link, also the prefixes related sub-TLV.  Comparing the two different approaches, we select to define one new sub-TLV to contain the above information in one place together."

And as mentioned in Les, there are strict requirement for the inclusion of "Remote-AS", "IPv4/IPv6 Remote ASBR ID" sub-TLV in RFC5316(similar for RFC5292). In almost all of the inter-AS scenario(numbered inter-as links), these information needn't be configured and transferred.

Then redefine the new stub-link TLV is the reasonable way, it also provides the container for other possible information.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Tuesday, January 11, 2022 2:39 PM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun,

Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 11 Jan 2022 16:20:48 +0800

Hi, All experts:

Upon the responses from this adoption call, we have updated to the draft
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes to
address the comments received from now.
If you have still other concerns, please responses.
We are glad to address your concerns during the adoption call process.

The updated contents are mainly the followings:
1. Adding the description for the "Unnumbered AS boundary link" and the MUST
associated sub-TLVs.
2. Define the Top-Level TLV for IS-IS---"Stub-Link TLV", instead of putting
it under the inter-AS reachability TLV(141).

The above updates align the OSPF and IS-IS and the existing defined sub-TLVs
in more reasonable style.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----

Hi Folks,

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Tue, 11 Jan 2022 07:44:55 -0500

Peter Psenak <ppsenak=[email-masked]> writes:

>> [WAJ] The above remote information must be configured manually on the local
>> device. It is paired by manual. Thinking there are many links among the ASBRs,
>> would you like to configure them manually for every remote ends on each link?

No one with large scale networks, and/or routers with lots of links is doing any sort of manual configuration. It seems to me that I keep seeing this mentioned as justification for changes or extensions to the IGPs. It is not reasonable justification b/c no-one is doing it.

I think it would be very useful if manual configuration or the assumption that we need to make that less painful, stopped being brought up so we can focus on other reasonable justifications (or lack thereof :)

Thanks,
Chris.
[as wg member]

> If the ISIS/OSPF adjacency is not formed over the link, you need to manually
> configure remote endpoint parameters. Defining a new TLV is not going to make
> any difference.
>
> We have link local/remote IDs (and IP addresses) to pair the two endpoints of
> the link in both OSPF and ISIS. We do not need another mechanism for the same.
> In addition, what you propose does not work for unnumbered links.
>

---

From: Aijun Wang <[email-masked]>
Date: Tue, 11 Jan 2022 21:51:25 +0800

Hi, Christian:

The benefit of the proposed solution is that for inter-AS scenarios, it can accomplish the automatic pairing for the two ends of inter-AS link without the explicitly configuration for the remote end information.
In other scenarios,  it can also contain useful information for the edge computation services, aid the operator know exactly the boundary of the network and apply special security policy at such stub link if necessary etc.

I have updated the draft today in order to address the concerns for unnumbered interface and sub-TLV hierarchy that raised by Peter and Les. Please review it if there exists any other concerns.

Thanks.

Aijun Wang
China Telecom

> On Jan 11, 2022, at 20:55, Christian Hopps <[email-masked]> wrote:
> 
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 11 Jan 2022 15:05:58 +0000

Aijun -

I am aware that, subsequent to this email, you posted a revised version of the draft. But in regards to how I prefer to move forward I am choosing to respond to this email.

It is important to remember that this thread is a 2 week WG adoption call. The primary purpose of this thread is to determine the WG consensus as to whether the draft is ready for adoption - not to do major revisions of the draft. 

I believe you have received meaningful feedback from multiple WG members that indicate there are significant issues with the draft in its current form. The issues raised question not just the implementation details, but whether the goals of the draft as currently stated are desirable. This, in my mind, is sufficient to conclude that the draft in its current form is NOT ready for WG adoption. The new version you posted does not come close to fully addressing these issues.

The most practical way forward (IMO of course) is for you to voluntarily withdraw your request for WG adoption. This will give you an opportunity to address the substantive issues that have been raised. It will also demonstrate that you are listening to the feedback being given. 

You can, of course, choose not to follow this path - in which case it will fall to the WG Chairs to determine the outcome of the adoption call.

Thanx.

   Les

> Sent: Monday, January 10, 2022 10:19 PM
> Cc: 'Christian Hopps' <[email-masked]>; [email-masked]; [email-masked];
> 1. https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-
> 02#section-4.1 and https://datatracker.ietf.org/doc/html/draft-wang-lsr-
> stub-link-attributes-02#section-4.2 includes also the sub-TLVs field, which is
> pointed to the corresponding part for TE-Link TLV(for OSPF) and Inter-AS
> Reachability TLV (TLV 141).
>   That is to say, the draft doesn't preclude the inclusion of Remote-AS,
> IPv4/IPv6 remote ASBR Identifier sub TLV.
>   So, if you insist that the unnumbered link will be used between the ASes,
> then for such stub-link type(we can add one new stub link type), the
> operator should configure the remote information manually. And for such
> stub link type, the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST be
> included(same as the rules defined in RFC5316).
>   For other numbered interface, such information needn't be manually
> configured. This can certainly save the cost for management of the network,
> and also meet your mentioned scenario.
>   Is it OK for you?
> 
> 2. For the consideration of current extension violate the rules defined in
> RFC5316, I have proposed another solution at
> https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/
> upon the comments from Peter. That is to say:
>   "[WAJ] It seems to define one new TLV that at the same level of “Inter-AS
> reachability TLV”, for example “Stub-Link reachability TLV” is better. If
> acceptable, will update the draft."
> 
> [LES:] Aijun - Unnumbered links are in common usage today. We should not
> define extensions which do not allow support for this.
> 
> [LES:] Deprecating the use of unnumbered is outside the scope of this
> specification - and I would argue is not something we (the WG) should be
> advocating in any case.
> 
> >
> [LES:] Indeed - which means your extensions to TLV 141 violate RFC 5316.
> Please read the referenced section I provided and pay attention to the
> normative statements ("MUST") there.
> If you are including loopbacks proper in what your draft is addressing, then
> clearly a link TLV (TLV 141) isn’t appropriate.
> You seem unable to clearly define whether you are trying to advertise a
> prefix or a link which is truly an interconnect.
> What it does do is convince me that the draft is at best confusing,
> incomplete, and non-interoperable with existing RFC 5316 implementations.

---

From: Tony Li <[email-masked]>
Date: Tue, 11 Jan 2022 12:24:20 -0800

Hi Aijun,

> We are trying to reuse the existing mechanism to solve such problem, but as mentioned in https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:

This link doesn’t work.

> Then redefine the new stub-link TLV is the reasonable way, it also provides the container for other possible information.

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.

T

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 12 Jan 2022 09:39:45 +0800

Hi, Les:

I think we should find the most efficient way to accomplish the work.
The draft that is adopting, or is adopted, or is in the WGLC or in the IESG view process is reasonable to be updated to address the comments during the process.
I think update the draft accordingly to address the issues raised during the call demonstrate the authors are listening the feedback, and it also help the following readers to review it on the latest version, and are not hindered by the past/solved issues.

Such interaction can certainly improve the quality and efficiency of our work.

We are glad to hear more comments on the updated version of this draft. 
I think defining such new TLV within OSPF/ISIS can give more flexibility for the application of IGP protocol/information, especially for constrained based SPF(flexalgo) or controller based application.

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: Les Ginsberg (ginsberg) <[email-masked]> 
Sent: Tuesday, January 11, 2022 11:06 PM
To: Aijun Wang <[email-masked]>
Cc: 'Christian Hopps' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

Thanx.

   Les

> Cc: 'Christian Hopps' <[email-masked]>; [email-masked]; 
> 1. 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attribu
> tes-
> 02#section-4.1 and 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-
> stub-link-attributes-02#section-4.2 includes also the sub-TLVs field, 
> which is pointed to the corresponding part for TE-Link TLV(for OSPF) 
> and Inter-AS Reachability TLV (TLV 141).
>   So, if you insist that the unnumbered link will be used between the 
> ASes, then for such stub-link type(we can add one new stub link type), 
> the operator should configure the remote information manually. And for 
> such stub link type, the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST 
> be included(same as the rules defined in RFC5316).
> configured. This can certainly save the cost for management of the 
> network, and also meet your mentioned scenario.
>   Is it OK for you?
> 
> 2. For the consideration of current extension violate the rules 
> defined in RFC5316, I have proposed another solution at 
>   "[WAJ] It seems to define one new TLV that at the same level of 
> “Inter-AS reachability TLV”, for example “Stub-Link reachability TLV” 
> is better. If acceptable, will update the draft."
> 
> > network? There is even very rare case for the unnumbered interface 
> > be used within the operator network. And, with the IPv6 deployment, 
> > what is the usages of unnumbered interface? Won’t it be depreciated in future?
> [LES:] Aijun - Unnumbered links are in common usage today. We should 
> not define extensions which do not allow support for this.
> 
> > [WAJ] Would like to hear the reason and scenarios that the 
> > unnumbered interface will be used in future. I think it should be deprecated instead.
> 
> specification - and I would argue is not something we (the WG) should 
> be advocating in any case.
> 
> >
> > future in an incompatible way in order to add such support. This is 
> > a bad design choice.
> >
> [LES:] Unnumbered is not obsolete - it is only you who have 
> arbitrarily decided that it is no longer needed.
> 
> >
> > >
> > the above information manually then. And for other stub link 
> > type(for example, the edge router that connects the server) there 
> > will be no remote-AS, no remote ASBR, how can you configure them?
> >
> > operating on the link. So the suggestion that not having to 
> > configure the remote link address provides significant 
> > simplification in deployment does not stand up to scrutiny.
> >
> > controller. If necessary, we can add some potential use cases for 
> > such type information, but this is not the main points of this draft.
> >
> > [WAJ] Actually, it is loopback interface, not loopback link, which 
> > you have imaged that one unnumbered link borrows the address from 
> > the loopback interface.
> If you are including loopbacks proper in what your draft is 
> addressing, then clearly a link TLV (TLV 141) isn’t appropriate.
> You seem unable to clearly define whether you are trying to advertise 
> a prefix or a link which is truly an interconnect.
> > >> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attribu
> > >> te
> > >> s/
> > >>

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 12 Jan 2022 10:42:11 +0800

Hi, Tony:

-----Original Message-----
From: [email-masked] <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 4:24 AM
To: Aijun Wang <[email-masked]>
Cc: lsr <[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Aijun,

> We are trying to reuse the existing mechanism to solve such problem, but as mentioned in https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/:

This link doesn’t work.
[WAJ] I checked the above link again and it work from my side. Anyway, I have copied the key points of the above link in the following sentences.

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?

T

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 12 Jan 2022 08:08:51 +0000

Hi 

This is a useful document, and it looks mature to  me though it is very short, so I support the adoption.

Thanks,
Cheng

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

Thanks,
Chris.

---

From: Zhuangshunwan <[email-masked]>
Date: Wed, 12 Jan 2022 10:07:14 +0000

Hi WG,

I have read the updated draft and think it has already addressed the comments/issues that raised until now. It is an valuable work for the inter-AS topology recovery and the edge computing service optimization.
I support its adoption.

Best Regards,
Shunwan

-----Original Message-----
From: Lsr [mailto:[email-masked]] On Behalf Of Christian Hopps
Sent: Tuesday, January 4, 2022 2:59 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi Folks,

Thanks,
Chris.

---

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

Hi Aijun,

> 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.

Tony

---

From: Christian Hopps <[email-masked]>
Date: Wed, 12 Jan 2022 15:19:13 -0500

Doesn't this reduce to: "The operator configures one of their routers with an IGP "passive" link config, and then uses this IGP extension so their other routers (in the same AS) can discover that configuration"?

Thanks,
Chris.
[as wg member]

> On Jan 11, 2022, at 8:51 AM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Christian:
>

---

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

Hi, Christian:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 04:19, Christian Hopps <[email-masked]> wrote:
> 

[WAJ] Yes, this is same behavior for the normal link within IGP. 
The difference is that we need not configure the remote end information(in numbered AS boundary interface scenarios) again.
The advertising information within the IGP is only information about its own.

Aijun Wang
China Telecom

---

From: Christian Hopps <[email-masked]>
Date: Wed, 12 Jan 2022 18:10:35 -0500

> On Jan 12, 2022, at 5:35 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Christian:
> 
> Aijun Wang
> China Telecom
> 

I'm having a little trouble fully understanding what you're saying here.

However, I think what is being done is the user configures one router (e.g., configures "isis passive" on "interfaec Foo0"), and the fact of that configuration is then transmitted inside the IGP. Other routers in the same domain then see and act on this configuration.

That is exactly what a network management system is for. This can and should all be done with a network management system not the routing protocol.

Thanks,
Chris.
[as wg member]

---

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

> On Jan 12, 2022, at 3:10 PM, Christian Hopps <[email-masked]> wrote:
> 
> m having a little trouble fully understanding what you're saying here.
> 

Chris,

We have ample precedent for carrying TE information in the IGP.  While you may regret that precedent, it is set.

AFAICT, the only thing different here is that there’s no actual adjacency on the link.  I see no reason to treat it as anything other than a normal adjacency (perhaps to system id 0000.0000.0000?). The two-way check will exclude it from within SPF.

Tony

---

From: Christian Hopps <[email-masked]>
Date: Wed, 12 Jan 2022 19:00:30 -0500

> On Jan 12, 2022, at 6:53 PM, Tony Li <[email-masked]> wrote:
> 
> 
> 

This isn't the same as TE information which can be/is based dynamic values on the router. I'm pretty sure that it isn't even using the 2-way connectivity check. It's literally just saying "Router A has a stub link B (i.e., it has the config 'isis passive' on it)".

That infomration is already a part of an operators NMS b/c that NMS is what generated that router's configuration and stuck it on that router in the first place. That same NMS is going to be configuring the other router that would be looking for that "stub link" information in the IGP. Unless I've mis-understood something here, the proposoal is literally just pushing static configuration details around inside the IGP.

Thanks,
Chris.

---

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

Chris,

> This isn't the same as TE information which can be/is based dynamic values on the router.

Are you sure? First, much of the TE information that we have distributed is static (administrative group, SRLG, etc.).  The dynamic part has been bandwidth reservation.  That still seems applicable to inter-AS stub links, even tho Aijin hasn’t articulated that yet. It does seem inevitable, again assuming I understand the use case.

> I'm pretty sure that it isn't even using the 2-way connectivity check. It's literally just saying "Router A has a stub link B (i.e., it has the config 'isis passive' on it)".

As the draft has it, you’re correct. However, there’s all that undefined subTLV space just begging for TE information.  The current ‘link type’ information seems somewhat pointless if it isn’t intended to be a item for TE consideration.

> That infomration is already a part of an operators NMS b/c that NMS is what generated that router's configuration and stuck it on that router in the first place. That same NMS is going to be config…

Agreed 100%.  But it’s also what we do today with much of the static TE information. Again, there’s precedent.

T

---

From: Christian Hopps <[email-masked]>
Date: Wed, 12 Jan 2022 21:32:26 -0500

> On Jan 12, 2022, at 9:03 PM, Tony Li <[email-masked]> wrote:
> 
> 
> Chris,
> 

The thing about the TE information is that it's being used to make live routing decisions (i.e., in a CSPF). We have pretty consistently denied requests to ship generic router configuration around using the IGPs.

Consider the case of configuring an inter-AS bgp connection, for that I'm imagining configuring a "BGP peer" service in my NMS. Part of that service is going to specify the neighbor AS and perhaps the router (or routers) to connect over. The NMS is going to look inside it's router information DB and use that information to construct the configurations for the service. If I tell it to deploy that service, it's going to then push those generated configuration files out to the affected routers, etc.

I'm not seeing any need yet for this information to be shipped around in the IGP.

Thanks,
Chris.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 Jan 2022 03:03:32 +0000

Here is my takeaway from this back-and-forth.

Several highly experienced routing folks have been looking at this draft in detail and they are unable to come to a common understanding on what the draft is trying to do. This alone indicates that the draft needs more work. Maybe the authors have a clear idea on what they are trying to do but if expert readers cannot determine what it is then clearly the draft needs further revision.

It also indicates to me that it is premature to determine whether the WG should adopt this or not. If experienced folks reading the draft can’t easily determine what the draft is trying to do, then it does not seem possible to make a judgment as to whether the WG should adopt it.

Additional comments:

I tend to agree with Tony (and others) that the draft is aimed at advertising some form of TE information – which is why I suggested even in my first post on this thread that RFC 5316 seemed like it was enough. The problem that has been exposed during the discussion is that RFC 5316 requires an AS number and in this deployment case we may not have one. But perhaps this limitation can be addressed by using the reserved AS #0 – a la RFC 7607.  (BGP experts please comment – I do not claim to be a BGP expert.)

There is then the additional sub-TLV defined in the document:

<snip>
Link Type: Define the type of the stub-link.

   o  1: Numbered AS boundary link

   o  2: Unnumbered AS boundary link

   o  3: Loopback link

   o  4: Vlan interface link
<end snip>

Ignoring the first two which were only added recently to try to address the lack of an AS #:

What is a “loopback link”? I have no idea.
And while I know what a VLAN is, I have no idea why advertising that a link is a VLAN is useful.
The draft provides no definition or clue as to the use case for this information.

Finally, there is the relationship between this draft and draft-dunbar-lsr-5g-edge-compute – which continues to mystify me. Given that the latest version of the 5G draft only defines a new metric to be advertised in Prefix Reachability advertisements, I have no idea what the relationship between the two drafts may be.

What makes sense to me is NOT to adopt the draft at this time.
The authors can then spend time revising the draft, addressing the many issues which have been raised, continue to get feedback from the WG, and at a future time decide whether the revised version is suitable for WG adoption.

    Les

From: Lsr <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 6:04 PM
To: Christian Hopps <[email-masked]>
Cc: Peter Psenak <ppsenak=[email-masked]>; Aijun Wang <[email-masked]>; [email-masked]; lsr <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Chris,

T

---

From: Aijun Wang <[email-masked]>
Date: Thu, 13 Jan 2022 20:42:37 +0800

Hi, Christian: 

Tony’s explanations are correct.
The proposed TLV is mainly one container, in order to include the related attributes of the Stub-Link, not the configuration. Actually, such proposal can reduce the configuration headaches(no matter via NMS or Manual) when you want to do some kind of inter-AS TE.

The motivation we do this are for controlling , or optimization or engineering of the traffic in/out these stub links. 
It may have some relation to other AS(inter-AS scenarios), or the application server(5G Edge Computation scenarios), or only the AS boundary(security control scenarios)

Aijun Wang
China Telecom

> On Jan 13, 2022, at 10:32, Christian Hopps <[email-masked]> wrote:
> 
> 
>

---

From: Chongfeng Xie <[email-masked]>
Date: Thu, 13 Jan 2022 21:53:37 +0800

Hi， all
I have read the draf and support its adoption.

Chongfeng 

> 2022年1月4日 下午2:58，Christian Hopps <[email-masked]> 写道：
> 
> Hi Folks,
>

---

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

Hi, Les:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> 
> Several highly experienced routing folks have been looking at this draft in detail and they are unable to come to a common understanding on what the draft is trying to do.

[WAJ] I think most of them have gotten the key points of this draft along the discussion and the reading of the related drafts. If they have still some questions, we can discuss and explain on the list.

> This alone indicates that the draft needs more work. Maybe the authors have a clear idea on what they are trying to do but if expert readers cannot determine what it is then clearly the draft needs further revision.

[WAJ]This is the WG adoption call, not the WGLC. We certainly will update the draft according to the comments from the WG. For adoption call, I think enough interests is the main criteria for its adoption. 

> It also indicates to me that it is premature to determine whether the WG should adopt this or not. If experienced folks reading the draft can’t easily determine what the draft is trying to do, then…

[WAJ] I think Gyan has given the good summary for the use cases, or motivation of this draft at https://mailarchive.ietf.org/arch/msg/lsr/R9JW8pHpNK1zt_jHx-KuMMOeJV8/.

I think if you read https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10, you can get the key points of inter-AS use case.

>  
> Additional comments:
>  
> I tend to agree with Tony (and others) that the draft is aimed at advertising some form of TE information –

[WAJ] Yes. The proposed TLV is one container and aim to convey the attributes of the Stub-Link, also as stated in the draft name.

> which is why I suggested even in my first post on this thread that RFC 5316 seemed like it was enough. The problem that has been exposed during the discussion is that RFC 5316 requires an AS number and in this deployment case we may not have one. But perhaps this limitation can be addressed by using the reserved AS #0 – a la RFC 7607.  (BGP experts please comment – I do not claim to be a BGP expert.)

[WAJ]Reuse the existing TLVs need to  update RFC5316, RFC5392 or other potential RFC document , to relax the “MUST” rules that defined in these documents. It will also influence the existing implementation and deployment. Won’t it encounter more resistances?

And, as mentioned in your proposal, there still need some unproved bypass methods to solve the situations that not the original scenarios of RFC5316 and RFC5392.

Start from the clean state is the most efficient way. Isn’t it?

> What is a “loopback link”? I have no idea.

[WAJ] Change it to “loopback interface” maybe more accurate. It is also one kind of “Stub Link”, which there is no IGP neighbor on the other end(and certainly no Remote AS, remote IPv4/IPv6 ASBR Router ID” that the RFC5316 and RFC5392 required.)
We should extract such stub link from other types of stub link.

> The draft provides no definition or clue as to the use case for this information.

[WAJ] VLAN interface is the logical interfaces that connected to servers that are out side of the IGP domain. It is also different from the inter-AS link that described in RFC5316 and RFC5392.
Some information that related to the attached severs or some policy to these server can be applied to these kind stub link.

> Finally, there is the relationship between this draft and draft-dunbar-lsr-5g-edge-compute – which continues to mystify me. Given that the latest version of the 5G draft only defines a new metric t…
[WAJ]No. It gives two kinds of proposals for the new metric. Please see https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7. You may ignore it. 
Actually, I prefer to advertising the edge server related information via the Stub-Link TLV.  The advantage of such approaches is that it can contain more granular information, not only the aggregated cost.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Jan 2022 15:28:50 +0100

> [WAJ] VLAN interface is the logical interfaces that connected to servers
> that are out side of the IGP domain. It is also different from the inter-AS
> link that described in RFC5316 and RFC5392.
> Some information that related to the attached severs or some policy to
> these server can be applied to these kind stub link.
>

Let's observe that there can be 4K VLANs on each trunk interface on a given
PE. There can be multiple trunks attached to each edge node going to
switches then in form of subnets to physical or virtual computes/pods/VMs
etc... .

Are we ready to take the product of (# of PEs) * (N trunks from each PE) *
(Max 4K VLANs)  in the form of new links into even local area IGP ?
Especially as we are learning that some of the values carried may be
dynamic in nature.

Thx,
R.

---

From: Aijun Wang <[email-masked]>
Date: Thu, 13 Jan 2022 23:03:51 +0800

Hi, Robert:

Aijun Wang
China Telecom

> On Jan 13, 2022, at 22:29, Robert Raszuk <[email-masked]> wrote:
> 
> 
>  
> Let's observe that there can be 4K VLANs on each trunk interface on a given PE. There can be multiple trunks attached to each edge node going to switches then in form of subnets to physical or virtual computes/pods/VMs etc... . 
> 
> Are we ready to take the product of (# of PEs) * (N trunks from each PE) * (Max 4K VLANs)  in the form of new links into even local area IGP ? Especially as we are learning that some of the values carried may be dynamic in nature. 

[WAJ]If there are so many of servers attached around all the PEs, we certainly need all of the associated servers’ prefixes. Right? 
If you want to some traffic engineering from/to these servers, or some policies on the boundary, you should also need additional attributes of them.

Stub-Link TLV just the container for these information.

---

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

HI Aijun,

I am simply highlighting three points -

* link is not the same as a leaf - prefix of the subnet

* Today PE usually aggregates all subnets of VLANs into just one or few
supernets. Links can not be aggregated.

* Subnets are static. Here we are discussing adding dynamic data into this
new amount of (stub) link information.

Kind regards,
R.

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

> Let's observe that there can be 4K VLANs on each trunk interface on a
> given PE. There can be multiple trunks attached to each edge node going to
> [WAJ]If there are so many of servers attached around all the PEs, we
> certainly need all of the associated servers’ prefixes. Right?
> If you want to some traffic engineering from/to these servers, or some
> policies on the boundary, you should also need additional attributes of
> them.
>

---

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

And one more question - apologies if it was already discussed and I missed
it.

How will the PE / edge router receive information describing current (for
example) load of the compute or LB sitting behind the switch on one of the
VLANs ?

Many thx,
R.

On Thu, Jan 13, 2022 at 4:08 PM Robert Raszuk <[email-masked]> wrote:

>> Are we ready to take the product of (# of PEs) * (N trunks from each PE)
>> * (Max 4K VLANs)  in the form of new links into even local area IGP ?

---

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

HI Aijun,

As I discussed off line with Les would you care to elaborate what is
missing from RFC 5316 which would substantially require a new draft/RFC ?

Don't you think update to this already published RFC (if anything is
missing) would be not sufficient ?

For peer ASN you can use private AS number as example if that would ever be
the concern.

Many thx,
R.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Jan 2022 01:18:16 +0000

Aijun –

In my first post on this thread I indicated that I thought RFC 5316 is sufficient for the use cases described in this draft. The subsequent lengthy discussions on this thread has convinced me that RFC 5316 is indeed sufficient and there is no need for this draft.

Along the way some issues discussed were:

The requirement of RFC 5316 that AS # be advertised. It is true that in some of the use cases you won’t have an AS #, but this can be addressed by using one of the reserved ASNs (0 or 65535) or one of the private ASNs. So that issue has been resolved.

You continue to promote the need to use a new sub-TLV to advertise a link type – but there is no demonstrated need for this nor any description of how such information would be used. (I say this even after reading your responses below.)

You also continue to promote the need to use an RFC 5316 like TLV to advertise the address of loopbacks – but again there is no need. The prefix associated with a loopback is advertised in Prefix Reachability TLVs. That the prefix is associated with a loopback is identified by the presence of the N flag in the associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback is identified by the RFC 7794 defined Router-ID sub-TLV(s).

As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft only needs to advertise a new type of prefix metric – which is to be advertised in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link TLV defined in this draft should be removed. It suggests that a Link TLV is the correct container for Prefix information – it is not.

There is no need for this draft – therefore it should not be adopted.

    Les

From: Aijun Wang <[email-masked]>
Sent: Thursday, January 13, 2022 6:13 AM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Tony Li <[email-masked]>; Christian Hopps <[email-masked]>; Peter Psenak <ppsenak=[email-masked]>; [email-masked]; lsr <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

Aijun Wang
China Telecom

On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:

Additional comments:

<snip>

   o  3: Loopback link

   o  4: Vlan interface link
<end snip>

    Les

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 6:04 PM
To: Christian Hopps <[email-masked]<mailto:[email-masked]>>
Cc: Peter Psenak <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>; Aijun Wang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; lsr <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Chris,

T

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 14 Jan 2022 10:44:48 +0800

Hi, Les:

Sent: Friday, January 14, 2022 9:18 AM

Aijun –

[WAJ] Not only the non-existing remote AS, but also the non-existing IPv4/IPv6 Remote ASBR ID sub-TLV.  And, you may propose we can assign other specific IPv4/IPv6 Remote ASBR ID. 

Not mentioned the unnecessary configuration on such kind links, the IGP will also advertise such useless information for each boundary link. 

Considering also what the Robert has mentioned scenario(the product of (# of PEs) * (N trunks from each PE) * (Max 4K VLANs) ), how many invalid information will be advertised within the IGP?

Why we must limit our deployment to the guideline of unsuitable RFCs?

[WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not like the Link Type Sub-TLV that defined in https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1. 

If you view them from the controller POV(the consumer of the BGP-LS information), you may know the below responses well.

[WAJ] Yes, You are right on the above information and I also know this.

The primary thought for defining this type, is that we want to filter such kind stub interface from advertising to the BGP-LS Stub-Link NLRI( https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5) on the router that run BPG-LS, or filer it easily on the controller.

[WAJ] Would you like to provide the reason, not just directly jump into to the conclusion? 

    Les

From: Aijun Wang <[email-masked] <mailto:[email-masked]> > 
Sent: Thursday, January 13, 2022 6:13 AM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >
Cc: Tony Li <[email-masked] <mailto:[email-masked]> >; Christian Hopps <[email-masked] <mailto:[email-masked]> >; Peter Psenak <ppsenak=[email-masked] <mailto:ppsenak=[email-masked]> >; [email-masked] <mailto:[email-masked]> ; lsr <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

Aijun Wang

China Telecom

On Jan 13, 2022, at 11:04, Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> > wrote:

 

 

Additional comments:

 

<snip>

   o  3: Loopback link

   o  4: Vlan interface link

<end snip>

 

    Les

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Tony Li
Sent: Wednesday, January 12, 2022 6:04 PM
To: Christian Hopps <[email-masked] <mailto:[email-masked]> >
Cc: Peter Psenak <ppsenak=[email-masked] <mailto:ppsenak=[email-masked]> >; Aijun Wang <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; lsr <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Chris,

 

 

 

T

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Jan 2022 07:22:06 +0000

Aijun -

From: Lsr <[email-masked]> On Behalf Of Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: 'Peter Psenak' <ppsenak=[email-masked]>; 'Christian Hopps' <[email-masked]>; [email-masked]; 'Tony Li' <[email-masked]>; 'lsr' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Peter Psenak <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>; [email-masked]<mailto:[email-masked]>; lsr <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

[LES:] The ASBR ID is simply the router ID of the peer at the remote end of the link. You need to know this in order to identify the peer since you do not have a protocol identifier (IS-IS system ID or OSPF Router ID) as you would if the IGP were enabled on the link.
So there is no reason that this information should be bogus.

[LES:] I called it a sub-TLV because that’s what it was in the previous version of the draft – before you invented a new top level TLV to avoid using TLV 141.
But regardless of the encoding details, my point is this information is not useful and not needed. There is no reason to advertise a loopback interface as a link. And there is no value in knowing whether the non-loopback link is a VLAN or top level ethernet or some type of P2P media. I have asked repeatedly of what use this information is and you have failed to provide any answer.

[LES:] If you never advertise loopbacks in the TLV then there is no need to filter them out.

As far as the relationship with draft-dunbar-lsr-5g-edge-compute, that draft only needs to advertise a new type of prefix metric – which is to be advertised in the Prefix Reachability TLVs. Mention in that draft of using the Stub Link TLV defined in this draft should be removed. It suggests that a Link TLV is the correct container for Prefix information – it is not.
[WAJ] Would you like to provide the reason, not just directly jump into to the conclusion?
[LES:] This has been discussed many times. Using a link TLV to advertise Prefix Reachability information is incorrect.

   Les

    Les

From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 13, 2022 6:13 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Tony Li <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; Peter Psenak <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>; [email-masked]<mailto:[email-masked]>; lsr <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

Aijun Wang
China Telecom

Additional comments:

<snip>

   o  3: Loopback link

   o  4: Vlan interface link
<end snip>

    Les

Chris,

T

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 14 Jan 2022 17:03:00 +0800

Hi, Les:

1)     For non-inter-AS stub link, the ASBR doesn’t exist. Even in the inter-AS stub link, we don’t need it.

2） For the 5G edge scenario, I think you should also refer to https://datatracker.ietf.org/doc/html/draft-dunbar-idr-5g-edge-compute-app-meta-data-05#section-7 about the process of “Soft Anchoring of ANYCAST FLOW”.

I think this will be also needed in the IGP scenario. To achieve this goal, the “AggCost” or “AppMetaData” shouldn’t be the metric of the prefix, it should be the metric of the stub link.  

The usage of such information is to differentiate the exit point of the LDN, not the prefix, which is same in the ANYCAST scenario.

And, we should also consider the situation when the Flexalgo is not used, but can also achieve the same goal(as described in the above reference)

Anyway, I think we can discuss this point in another thread in more thoroughly.

What I want to say it is hasty to conclude such metric should be associated to the prefixes.

3） For the “stub-link type”, the original consideration is that when one interface is configured as “passive”, the related information should be advertised via the “Stub-Link” TLV. 

Then the loopback address is one kind of such type and should be filtered out. If you advertise the loopback interface within the normal IGP LSA, such type can be eliminated. 

        And we consider there are some differences for the logical VLAN interface and its associated Ethernet interface, for example, the bandwidth control and the isolation characteristic etc.

      These types can certainly be combined or separated later upon further discussion, and they are not the key part of this draft.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 3:22 PM
To: Aijun Wang <[email-masked]>
Cc: 'Peter Psenak' <ppsenak=[email-masked]>; 'Christian Hopps' <[email-masked]>; [email-masked]; 'Tony Li' <[email-masked]>; 'lsr' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

From: Lsr <[email-masked] <mailto:[email-masked]> > On Behalf Of Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >
Cc: 'Peter Psenak' <ppsenak=[email-masked] <mailto:ppsenak=[email-masked]> >; 'Christian Hopps' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; 'Tony Li' <[email-masked] <mailto:[email-masked]> >; 'lsr' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

From: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> > 
Sent: Friday, January 14, 2022 9:18 AM
To: Aijun Wang <[email-masked] <mailto:[email-masked]> >
Cc: Tony Li <[email-masked] <mailto:[email-masked]> >; Christian Hopps <[email-masked] <mailto:[email-masked]> >; Peter Psenak <ppsenak=[email-masked] <mailto:ppsenak=[email-masked]> >; [email-masked] <mailto:[email-masked]> ; lsr <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: RE: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun –

 

   Les

    Les

Hi, Les:

Aijun Wang

China Telecom

 

 

Additional comments:

 

<snip>

   o  3: Loopback link

   o  4: Vlan interface link

<end snip>

 

    Les

 

Chris,

 

 

 

 

 

T

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 14 Jan 2022 17:06:42 +0800

Sorry，one correction:

It should be “For non-inter-AS stub link, the Remote ASBR doesn’t exist. Even in the inter-AS link, we don’t need it”

From: [email-masked] <[email-masked]> On Behalf Of Aijun Wang
Sent: Friday, January 14, 2022 5:03 PM
To: 'Les Ginsberg (ginsberg)' <ginsberg=[email-masked]>
Cc: 'Peter Psenak' <ppsenak=[email-masked]>; 'Christian Hopps' <[email-masked]>; [email-masked]; 'Tony Li' <[email-masked]>; 'lsr' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

1)     For non-inter-AS stub link, the 【Remote】ASBR doesn’t exist. Even in the inter-AS stub link, we don’t need it.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> > On Behalf Of Les Ginsberg (ginsberg)

Aijun -

Hi, Les:

Aijun –

 

   Les

    Les

Hi, Les:

Aijun Wang

China Telecom

 

 

Additional comments:

 

<snip>

   o  3: Loopback link

   o  4: Vlan interface link

<end snip>

 

    Les

 

Chris,

 

 

 

 

 

T

---

From: John E Drake <[email-masked]>
Date: Fri, 14 Jan 2022 15:43:10 +0000

I agree with Les.  This draft is gratuitous and ill-considered.

Yours Irrespectively,

John

Juniper Business Use Only
From: Lsr <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Friday, January 14, 2022 2:22 AM
To: Aijun Wang <[email-masked]>
Cc: 'Peter Psenak' <ppsenak=[email-masked]>; 'Christian Hopps' <[email-masked]>; [email-masked]; 'Tony Li' <[email-masked]>; 'lsr' <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun -

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Aijun Wang
Sent: Thursday, January 13, 2022 6:45 PM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: 'Peter Psenak' <ppsenak=[email-masked]<mailto:ppsenak=[email-masked]>>; 'Christian Hopps' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 'Tony Li' <[email-masked]<mailto:[email-masked]>>; 'lsr' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Les:

Aijun –

You continue to promote the need to use a new sub-TLV to advertise a link type – but there is no demonstrated need for this nor any description of how such information would be used. (I say this even after reading your responses below.)
[WAJ] It is the field within the Stub-Link TLV, not new sub-TLV.  It is not like the Link Type Sub-TLV that defined in https://datatracker.ietf.org/doc/html/rfc3630#section-2.5.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3630*section-2.5.1__;Iw!!NEt6yMaO-gk!X-98qsVOziyN85o3KP84-1xQm5tL-oRKaugF4f8e58Ieg_jojmKjo5n1GaZvI0g$>.
If you view them from the controller POV(the consumer of the BGP-LS information), you may know the below responses well.

You also continue to promote the need to use an RFC 5316 like TLV to advertise the address of loopbacks – but again there is no need. The prefix associated with a loopback is advertised in Prefix Reachability TLVs. That the prefix is associated with a loopback is identified by the presence of the N flag in the associated RFC 7794 prefix attributes sub-TLV. The owner/source of the loopback is identified by the RFC 7794 defined Router-ID sub-TLV(s).
[WAJ] Yes, You are right on the above information and I also know this.
The primary thought for defining this type, is that we want to filter such kind stub interface from advertising to the BGP-LS Stub-Link NLRI( https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09*section-5__;Iw!!NEt6yMaO-gk!X-98qsVOziyN85o3KP84-1xQm5tL-oRKaugF4f8e58Ieg_jojmKjo5n1K_jlHiA$>) on the router that run BPG-LS, or filer it easily on the controller.

   Les

    Les

Hi, Les:

Aijun Wang
China Telecom

[WAJ] I think Gyan has given the good summary for the use cases, or motivation of this draft at https://mailarchive.ietf.org/arch/msg/lsr/R9JW8pHpNK1zt_jHx-KuMMOeJV8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/R9JW8pHpNK1zt_jHx-KuMMOeJV8/__;!!NEt6yMaO-gk!X-98qsVOziyN85o3KP84-1xQm5tL-oRKaugF4f8e58Ieg_jojmKjo5n1CxP6Il8$>.

I think if you read https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-10__;!!NEt6yMaO-gk!X-98qsVOziyN85o3KP84-1xQm5tL-oRKaugF4f8e58Ieg_jojmKjo5n1q1UVJZY$>, you can get the key points of inter-AS use case.

Additional comments:

<snip>

   o  3: Loopback link

   o  4: Vlan interface link
<end snip>

Finally, there is the relationship between this draft and draft-dunbar-lsr-5g-edge-compute – which continues to mystify me. Given that the latest version of the 5G draft only defines a new metric to be advertised in Prefix Reachability advertisements, I have no idea what the relationship between the two drafts may be.
[WAJ]No. It gives two kinds of proposals for the new metric. Please see https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03*section-7__;Iw!!NEt6yMaO-gk!X-98qsVOziyN85o3KP84-1xQm5tL-oRKaugF4f8e58Ieg_jojmKjo5n1SiwBEqM$>. You may ignore it.
Actually, I prefer to advertising the edge server related information via the Stub-Link TLV.  The advantage of such approaches is that it can contain more granular information, not only the aggregated cost.

    Les

Chris,

T

---

From: Christian Hopps <[email-masked]>
Date: Fri, 14 Jan 2022 11:01:57 -0500

WG Member Hat: I think the un-adopted 5G draft should be left out of any justification for adopting the stub link draft.

Chair Hat: One un-adopted draft using another un-adopted draft cannot serve as the justification to adopt the referenced draft. If that worked then 2 drafts could refer to each other and that would justify them both being adopted.

Thanks,
Chris.

> On Jan 13, 2022, at 9:44 PM, Aijun Wang <[email-masked]> wrote:
> 
> [WAJ]No. It gives two kinds of proposals for the new metric. Please see https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7 <https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03#section-7>. You may ignore it.

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 07:03:14 +0800

Hi, John:

Please gives concrete responses for my responses to Les’s comments at https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/

If not, I would say both you and Les’s understanding of this draft is not correct.

Aijun Wang
China Telecom

> On Jan 14, 2022, at 23:43, John E Drake <jdrake=[email-masked]> wrote:
> 
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 15 Jan 2022 00:15:20 +0100

Hi Aijun,

> If not, I would say both you and Les’s understanding of this draft is not

If two (or more) subject matter experts like Les & John can not understand
the IGP draft I would not draw an immediate conclusion that this is their
perception fault.

Instead I would take a step back and see that perhaps there is something
wrong with the draft itself ?

Thx,
Robert.

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 07:39:39 +0800

Hi, Robert:

I would say some people are likely to hear other’s explanations, some are reluctant. 
Anyway, I am eager to hear the independent technical analysis.

For the current scenarios and solutions, we have analyzed that RFC 5316 and RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.

I would like to hear the constructive comments, or other solutions that better the the one in this draft.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 07:15, Robert Raszuk <[email-masked]> wrote:
> 
> 
> Hi Aijun,
>  
> If two (or more) subject matter experts like Les & John can not understand the IGP draft I would not draw an immediate conclusion that this is their perception fault. 
> 
> Instead I would take a step back and see that perhaps there is something wrong with the draft itself ? 
> 
> Thx,
> Robert.
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 15 Jan 2022 00:59:45 +0100

> For the current scenarios and solutions, we have analyzed that RFC 5316
> and RFC5392 are not suitable for such purposes—we must generate bogus AS,
> bogus Remote ASBR Router ID on every inter-AS, or non inter-AS boundary
> links.
>

Why do you think those values need to be "bogus" ? And Inter-AS is just a
perfect example on what you call a "stub link" so I would not hold on that
much to the nomenclature.

I would like to hear the constructive comments, or other solutions that
> better the the one in this draft.
>

I think what has been suggested is just that, but of course you are
entitled to have your own opinion.

Kind regards,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 08:09:52 +0800

Hi, Robert:

Sorry, the correct description should be “For inter-AS stub link, we must generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that described in  https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
 For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote ASBR Router ID”

Aijun Wang
China Telecom

> On Jan 15, 2022, at 07:59, Robert Raszuk <[email-masked]> wrote:
> 
> 
>  
> Why do you think those values need to be "bogus" ? And Inter-AS is just a perfect example on what you call a "stub link" so I would not hold on that much to the nomenclature. 
> 
> I think what has been suggested is just that, but of course you are entitled to have your own opinion. 
> 
> Kind regards,
> Robert
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 14 Jan 2022 19:18:54 -0500

> On Jan 14, 2022, at 6:39 PM, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Robert:
> 

Chair Hat,

Just to be clear, whether this draft is adopted or not does not require that people agree with your solution or provide better ones.

The WG has to decide if it actually thinks it's worthwhile to work on the problem at all. Then it also has to decide if this draft in it's current form is the right vehicle to do this work. Only if those 2 things are satisfied will the document be adopted as a WG document.

Thanks,
Chris.

---

From: John E Drake <[email-masked]>
Date: Sat, 15 Jan 2022 00:31:20 +0000

If I agree with Les, why do I need to repeat everything he has said?

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Friday, January 14, 2022 6:03 PM
To: John E Drake <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Peter Psenak <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; Tony Li <[email-masked]>; lsr <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, John:

Please gives concrete responses for my responses to Les’s comments at https://mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/lsr/eH2TxbbLswA2jALjOZ6a2Lwien8/__;!!NEt6yMaO-gk!TD39mWfi5WWuFscpR6z6DLsI3GKpQfu32CCnr0iF7kcS5HnJ6Lpe_7l9L6PY0ac$>

Aijun Wang
China Telecom

On Jan 14, 2022, at 23:43, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Yours Irrespectively,

John

From: Lsr <[email-masked]<mailto:[email-masked]>> On Behalf Of Les Ginsberg (ginsberg)

Aijun -

Hi, Les:

Aijun –

   Les

    Les

Hi, Les:

Aijun Wang
China Telecom

Additional comments:

<snip>

   o  3: Loopback link

   o  4: Vlan interface link
<end snip>

    Les

Chris,

T

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 08:45:15 +0800

OK, then I can conclude that you have no more comments for my responses to Les.

Then, you and Les should notice that RFC5316 and RFC5392 are not appropriate to solve the scenarios that described in https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1. I have given the reasons in previous mail.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:31, John E Drake <jdrake=[email-masked]> wrote:
> 
>

---

From: John E Drake <[email-masked]>
Date: Sat, 15 Jan 2022 00:49:04 +0000

This seems to be argument by emphatic assertion.

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]>
Sent: Friday, January 14, 2022 7:45 PM
To: John E Drake <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; Tony Li <[email-masked]>; lsr <[email-masked]>; [email-masked]; [email-masked]; Peter Psenak <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Then, you and Les should notice that RFC5316 and RFC5392 are not appropriate to solve the scenarios that described in https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09*section-5.1__;Iw!!NEt6yMaO-gk!VOQyl9lKgK7cbrw7Q4Ahv-o_EsmlaIkdOxBy-L6hQIQqtq6ZSZf1MfJrFwa1oKU$>. I have given the reasons in previous mail.
Aijun Wang
China Telecom

On Jan 15, 2022, at 08:31, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> wrote:

Yours Irrespectively,

John

Juniper Business Use Only
From: Aijun Wang <[email-masked]<mailto:[email-masked]>>
Sent: Friday, January 14, 2022 6:03 PM
To: John E Drake <[email-masked]<mailto:[email-masked]>>
Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; Peter Psenak <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tony Li <[email-masked]<mailto:[email-masked]>>; lsr <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, John:

Aijun Wang
China Telecom

Yours Irrespectively,

John

Aijun -

Hi, Les:

Aijun –

   Les

    Les

Hi, Les:

Aijun Wang
China Telecom

Additional comments:

<snip>

   o  3: Loopback link

   o  4: Vlan interface link
<end snip>

    Les

Chris,

T

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 15 Jan 2022 00:49:15 +0000

Aijun –

I believe there is a fundamental disagreement here which derives from your belief that it is correct/sufficient to describe a link interconnecting two or more nodes using a prefix.
This has been discussed on the list for a long time now. It has been pointed out to you that this is a broken model. It does not work for multiple cases (true broadcast links, unnumbered links, point to MP links).
Your response to date when this is pointed out to you is either:

“I don’t care about those cases”

Or

“I don’t think those cases are important.”

But I (and others) do not see the value of adopting a model that has limited applicability – especially when we already have a model that is much more robust.

Sure – if you think a prefix is enough to define the connection between two nodes, then you can view the identifiers for the neighbor as “unnecessary”.
But this is the wrong model.

So long as we disagree on this fundamental point, we are never going to agree on anything else and rehashing details is a waste of time for everyone.

   Les

From: Aijun Wang <[email-masked]>
Sent: Friday, January 14, 2022 4:10 PM
To: Robert Raszuk <[email-masked]>
Cc: Les Ginsberg (ginsberg) <[email-masked]>; lsr <[email-masked]>; John E Drake <[email-masked]>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Hi, Robert:

Aijun Wang
China Telecom

On Jan 15, 2022, at 07:59, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Kind regards,
Robert

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 08:58:37 +0800

Hi, Christian:

Actually, https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1 is the main scenario that want to be solved by this adopting draft.
The reason that we mentioned https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute is that we should consider more possible scenarios to find the extensible solution. 
For standard activities and working group, we should look further. 

I admire everyone’s opinions and won’t expect everyone agree me. But knowing the reason or viable solution can certainly aid the solve of the problem, or make thing forward.
We all expect constructive suggestions, right?

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:19, Christian Hopps <[email-masked]> wrote:
> 
> 
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 09:33:59 +0800

Hi, Les:
Thanks for your analysis. If these are your main concerns, here is my responses:

I am hearing your every opposition points(also from others, same points or not.)
I am always trying to address the comments, although reluctant to some corner cases(sorry if it irritated you). But as you insist the solution should cover all possible scenarios, then how about the following considerations:

1) We have updated the draft to reflect the solution to “unnumbered link”. 

2) P2MP stub-link type, we can take the same approach.(the stub link type “P2MP” should be added)

3) For broadcast stub link, the nodes that share the same prefix can certainly be connected together.

 Are the above considerations solve your concerns? If so, we can update the draft again to reflect this.

Aijun Wang
China Telecom

> On Jan 15, 2022, at 08:49, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 
> 
> Aijun –
>

---

From: Aijun Wang <[email-masked]>
Date: Sat, 15 Jan 2022 10:57:30 +0800

Hi, Les:
I do a short search work and find even for P2MP stub-link type, the process can be same as the numbered p2p interface.

 Please see the reference at your company’s doc site: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-2/iro-xe-2-book/iro-cfg.html

In these cases, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers not directly connected will go through the router that has VCs to both routers. Note that you need not configure neighbors when using this feature. 
An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface having one or more neighbors. It creates multiple host routes. An OSPF point-to-multipoint network has the following benefits compared to NBMA and point-to-point networks: 

 Point-to-multipoint is easier to configure because it requires no configuration of neighbor commands, it consumes only one IP subnet, and it requires no designated router election.

Then all the neighbor should also under one common prefixes.

So, the proposed draft can meet the scenarios for all kinds of numbered interfaces.

Do you have other concerns then?
Also ask for John? Robert? Or other experts?

Aijun Wang
China Telecom

> On Jan 15, 2022, at 09:34, Aijun Wang <[email-masked]> wrote:
> 
> Hi, Les:

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 17 Jan 2022 15:09:37 +0800

I support the adoption.

B.R.
Weiqiang Cheng

> Authors, please respond to the list indicating whether you are aware of
any IPR
> that applies to these drafts.
> 
> Thanks,
> Chris.
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2022 15:25:31 +0800

I support its adoption.
Based on the discussion on the list, we can know that following the guideline of RFC5316 and RFC5305 is not the efficient way to extract the inter-AS topology as that required by https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1。we should also consider the further usage of the informtion that associated the stub link.

B.R.
Yongqing Zhu

[email-masked]
 
From: Christian Hopps
Date: 2022-01-04 14:58
To: [email-masked]
CC: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
Hi Folks,

 

Thanks,
Chris.

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2022 15:38:32 +0800

Hi WG,

I support the adoption.

Regards,
Peng Liu

[email-masked]
 
From: Christian Hopps
Date: 2022-01-04 14:58
To: [email-masked]

 

Thanks,
Chris.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 18 Jan 2022 03:34:53 +0000

Hi,

I've read this document and support its adoption.

My understanding of this document is that it aims to identify a link attached to an IGP node, while the link itself does not run IGP. Some attributes of such link may be used in determining the path to an external network via that link. This may apply both to the inter-AS cases and the data center cases as mentioned in the draft. It seems that define a generic mechanism for such case is a reasonable approach. 

Best regards,
Jie