[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

Let’s top post my responses to your specific questions:

 

1)  LAN partitioning can occur. So R1 and R2 may be able to talk to each 
and R3 and R4 may be able to talk to each – but the two partitions have no 
connectivity. Yet all nodes will advertise the LAN subnet – which in your world 
means that you think you have full connectivity when you do not. 

[WAJ] If the partition is occurred by design, then R1-R4 should not declare the 
same subnet; if the partition is occurred by the switch faulty, it needs other 
OAM tools to detect. This is also true for the P2P based existing 
solutions(RFC9346/RFC5392).

 

2)  Your draft says: “It will be help for the router R0, to know the 
attributes of the stub links and select the optimal Anycast server to serve the 
customer's application.”.

Given that you don’t actually know which of the anycast servers each of the 
border routers can reach (you just “assume” it is all of them) the ability of 
R0 to make a correct decision is compromised.

[WAJ] Here, “the optimal Anycast server” refer to the “the optimal path(exits) 
to Anycast server”.  The reason that we use Anycast is that all these servers 
can provide the same services. The difference is that the path 
attributes(internal links and stub link) to them.

 

Wish the above explanations can address your concerns.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les 
Ginsberg (ginsberg)
发送时间: 2024年1月19日 0:51
收件人: Aijun Wang 
抄送: 'Christian Hopps' ; 'Huzhibo' ; 
'Acee Lindem' ; 'Yingzhen Qu' ; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun –

 

Frankly, I have a limited tolerance for these exchanges because your responses 
to specific points are evasive.

You are like a boxer whose main goal is to avoid any punch thrown by your 
opponent from landing directly. This is a pretty useful skill in a boxing ring, 
but pretty tiresome when trying to have a frank exchange of views on the 
technical points of a draft.

I am unlikely to respond further after this – but please find some responses 
inline. See [LES2:].

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Thursday, January 18, 2024 1:29 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: 'Christian Hopps' mailto:cho...@chopps.org> >; 
'Huzhibo' mailto:huzh...@huawei.com> >; 'Acee Lindem' 
mailto:acee.i...@gmail.com> >; 'Yingzhen Qu' 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
抄送: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzh...@huawei.com> >; Acee Lindem 
mailto:acee.i...@gmail.com> >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun -

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzh...@huawei.com> >; Acee Lindem 
mailto:acee.i...@gmail.com> >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

Let’s keep the discussions simple.

 

Please answer the following two questions that you haven’t responsed directly 
in previous mail:

1)How the existing point-to-point based solution(RFC9346/RFC5392) solve 
the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are 
multiple neighbors on one interfaces, which are located in different AS. How to 
encode the information within one inter-AS reachability TLV? 

 

[LES:] In the absence of the existence of an advertisement of the LAN itself 
(the “pseudonode” in IS-IS), a LAN is represented as a set of P2P links between 
each of the nodes connected to the LAN.

Less scaleable but just as functional.

 

You, however, think you can get away with “If R1 advertises connectivity to the 
LAN subnet and R2 and R3 also advertise connectivity to the same subnet that we 
can assume that they are all connected” – which is an assumption that works 
some of the time – but is not guaranteed.

It is easy to imagine this case if there is a switch and one of the ports on 
the switch is faulty. (Other failure scenarios exist)

 

[WAJ] If one of the ports on the switch is faulty, then the router that 
connected is disconnected from the subnet. The topology recovery will not 

Re: [Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

And, for broadcast networks, if you can only encode them via the p2p link style, there are still the following questions:1) whether one interface can be appointed to different neighbor? Will the latter override the former? 2) The efficiency. The total neighbor information will be O(N*N), the operator must get and verify them manually(no automatic method,  not relevant to the NMS management), where if we use the subnet instead, the operator needs only confirm one information—-the shared subnet/prefix.Then, should we find some more efficient way to accomplish the goal, instead of sticking to the most onerous one?Aijun WangChina TelecomOn Jan 18, 2024, at 17:29, Aijun Wang  wrote:Hi, Les: 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)发送时间: 2024年1月18日 0:16收件人: Aijun Wang 抄送: Christian Hopps ; Huzhibo ; Acee Lindem ; Yingzhen Qu ; lsr@ietf.org主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Aijun - From: Aijun Wang  Sent: Tuesday, January 16, 2024 10:56 PMTo: Les Ginsberg (ginsberg) Cc: Christian Hopps ; Huzhibo ; Acee Lindem ; Yingzhen Qu ; lsr@ietf.orgSubject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Hi, Les: Let’s keep the discussions simple. Please answer the following two questions that you haven’t responsed directly in previous mail:1)    How the existing point-to-point based solution(RFC9346/RFC5392) solve the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are multiple neighbors on one interfaces, which are located in different AS. How to encode the information within one inter-AS reachability TLV?  [LES:] In the absence of the existence of an advertisement of the LAN itself (the “pseudonode” in IS-IS), a LAN is represented as a set of P2P links between each of the nodes connected to the LAN.Less scaleable but just as functional. You, however, think you can get away with “If R1 advertises connectivity to the LAN subnet and R2 and R3 also advertise connectivity to the same subnet that we can assume that they are all connected” – which is an assumption that works some of the time – but is not guaranteed.It is easy to imagine this case if there is a switch and one of the ports on the switch is faulty. (Other failure scenarios exist) [WAJ] If one of the ports on the switch is faulty, then the router that connected is disconnected from the subnet. The topology recovery will not include this router.  2)    How the inter-AS based solutions solve the non inter-AS scenario requirements(A.2)? [LES:] An interesting question given that you haven’t addressed this yourself.What does it mean to advertise reachability to an anycast address (as you propose to do)?Does that tell you if you are connected to one of anycast servers? Some of the anycast servers? All of the anycast servers?[WAJ] All of the anycast servers You don’t know – you are just assuming.But since your goal is “topology discovery” it is important to actually know whether you have a link to a particular anycast server or not.You don’t know – you just assume.[WAJ] For A.2, the aim is not topology discovery, the aim is to select the optimal path(or exits) that to the anycast server, based not only the internal link information, but also the stub link information that connects to the server. One point that I want to remind for your misunderstanding: the proposed Stub-link TLV can contain other attributes sub-TLVs of the link.And, if the interfaces share the same prefixes, they are in the same IP subnet. Is there any ambiguously for the IP topology recovery? What I want to emphasize is that the existing solutions are suitable for inter-AS point-to-point TE, the proposed solutions are suitable(more efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and also other non inter-as traffic optimization scenarios.  They are not contrary.  [LES:] AFAICT, your sole aim is efficiency – and you have given no thought to validating the actual topology.[WAJ]: If you have any scenario, that the proposed solution can’t give the actual topology, please illustrate it or them. Les  Aijun WangChina Telecom On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg)  wrote: Aijun – Please see inline. From: Aijun Wang  Sent: Tuesday, January 16, 2024 12:18 AMTo: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; 'Huzhibo' Cc: 'Acee Lindem' ; 'Yingzhen Qu' ; lsr@ietf.orgSubject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Hi, Les: -邮件原件-发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)发送时间: 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les 
Ginsberg (ginsberg)
发送时间: 2024年1月18日 0:16
收件人: Aijun Wang 
抄送: Christian Hopps ; Huzhibo ; Acee 
Lindem ; Yingzhen Qu ; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun -

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >
Cc: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzh...@huawei.com> >; Acee Lindem 
mailto:acee.i...@gmail.com> >; Yingzhen Qu 
mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

Let’s keep the discussions simple.

 

Please answer the following two questions that you haven’t responsed directly 
in previous mail:

1)How the existing point-to-point based solution(RFC9346/RFC5392) solve 
the broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are 
multiple neighbors on one interfaces, which are located in different AS. How to 
encode the information within one inter-AS reachability TLV? 

 

[LES:] In the absence of the existence of an advertisement of the LAN itself 
(the “pseudonode” in IS-IS), a LAN is represented as a set of P2P links between 
each of the nodes connected to the LAN.

Less scaleable but just as functional.

 

You, however, think you can get away with “If R1 advertises connectivity to the 
LAN subnet and R2 and R3 also advertise connectivity to the same subnet that we 
can assume that they are all connected” – which is an assumption that works 
some of the time – but is not guaranteed.

It is easy to imagine this case if there is a switch and one of the ports on 
the switch is faulty. (Other failure scenarios exist)

 

[WAJ] If one of the ports on the switch is faulty, then the router that 
connected is disconnected from the subnet. The topology recovery will not 
include this router.

 

 

2)How the inter-AS based solutions solve the non inter-AS scenario 
requirements(A.2)?

 

[LES:] An interesting question given that you haven’t addressed this yourself.

What does it mean to advertise reachability to an anycast address (as you 
propose to do)?

Does that tell you if you are connected to one of anycast servers? Some of the 
anycast servers? All of the anycast servers?

[WAJ] All of the anycast servers

 

You don’t know – you are just assuming.

But since your goal is “topology discovery” it is important to actually know 
whether you have a link to a particular anycast server or not.

You don’t know – you just assume.

[WAJ] For A.2, the aim is not topology discovery, the aim is to select the 
optimal path(or exits) that to the anycast server, based not only the internal 
link information, but also the stub link information that connects to the 
server.

 

One point that I want to remind for your misunderstanding: the proposed 
Stub-link TLV can contain other attributes sub-TLVs of the link.

And, if the interfaces share the same prefixes, they are in the same IP subnet. 
Is there any ambiguously for the IP topology recovery?

 

What I want to emphasize is that the existing solutions are suitable for 
inter-AS point-to-point TE, the proposed solutions are suitable(more 
efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and also 
other non inter-as traffic optimization scenarios.  They are not contrary. 

 

[LES:] AFAICT, your sole aim is efficiency – and you have given no thought to 
validating the actual topology.

[WAJ]: If you have any scenario, that the proposed solution can’t give the 
actual topology, please illustrate it or them.

 

Les

 

 

Aijun Wang

China Telecom

 

On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg) 
mailto:ginsberg=40cisco@dmarc.ietf.org> > wrote:

 

Aijun –

 

Please see inline.

 

From: Aijun Wang mailto:wangai...@tsinghua.org.cn> 
> 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> >; 
'Christian Hopps' mailto:cho...@chopps.org> >; 'Huzhibo' 
mailto:huzh...@huawei.com> >
Cc: 'Acee Lindem' mailto:acee.i...@gmail.com> >; 
'Yingzhen Qu' mailto:yingzhen.i...@gmail.com> >; 
lsr@ietf.org  
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

-邮件原件-
发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org> >
抄送: Acee Lindem mailto:acee.i...@gmail.com> >; Yingzhen 
Qu mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Robert: 

 

For VRF interface, we can treat it specially, similar as the unnumbered 
interface in the draft. (Add one “V” bit to identify them and attach the remote 
identifier manually---there is no other automatic way to accomplish the 
topology recovery )

But for other non-VRF interfaces, the proposed solution is more efficient that 
the existing solution. The operator can omit many onerous work.

 

And, the proposed solution is not only for topology recovery, it can also cover 
other use cases(for example A.2/A.3)

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Robert Raszuk
发送时间: 2024年1月17日 16:33
收件人: Aijun Wang 
抄送: Les Ginsberg (ginsberg) ; Christian 
Hopps ; Huzhibo ; Acee Lindem 
; Yingzhen Qu ; lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Aijun,

 

> And, if the interfaces share the same prefixes, they are in the same IP 
> subnet.

 

That is unfortunately a wrong assumption. 

 

In number of deployments all external links can share the same IP addresses as 
they are terminated in VRFs and on the other side belong to completely 
different peers. 

 

So unless you add an RD to those prefixes and make them domain wide unique I am 
afraid your proposal has serious issue. As Les said when we define a protocol 
extension the most important is to review how it will work in all deployment 
cases - not to pick just a few and declare a success. 

 

Regards,

Robert

 

 

 

On Wed, Jan 17, 2024 at 7:56 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Les:

 

Let’s keep the discussions simple.

 

Please answer the following two questions that you haven’t responsed directly 
in previous mail:

1) How the existing point-to-point based solution(RFC9346/RFC5392) solve the 
broadcast(LAN, A.1 Figure2) inter-AS topology recovery scenario---There are 
multiple neighbors on one interfaces, which are located in different AS. How to 
encode the information within one inter-AS reachability TLV? 

2) How the inter-AS based solutions solve the non inter-AS scenario 
requirements(A.2)?

 

One point that I want to remind for your misunderstanding: the proposed 
Stub-link TLV can contain other attributes sub-TLVs of the link.

And, if the interfaces share the same prefixes, they are in the same IP subnet. 
Is there any ambiguously for the IP topology recovery?

 

What I want to emphasize is that the existing solutions are suitable for 
inter-AS point-to-point TE, the proposed solutions are suitable(more 
efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and also 
other non inter-as traffic optimization scenarios.  They are not contrary. 

 

 

 

Aijun Wang

China Telecom





On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org> > 
wrote:

 

Aijun –

 

Please see inline.

 

From: Aijun Wang <  
wangai...@tsinghua.org.cn> 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) <  ginsb...@cisco.com>; 
'Christian Hopps' <  cho...@chopps.org>; 'Huzhibo' < 
 huzh...@huawei.com>
Cc: 'Acee Lindem' <  acee.i...@gmail.com>; 
'Yingzhen Qu' <  yingzhen.i...@gmail.com>;  
 lsr@ietf.org
Subject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi, Les:

 

-邮件原件-
发件人: forwardingalgori...@ietf.org   
[mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps mailto:cho...@chopps.org> >; Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org> >
抄送: Acee Lindem mailto:acee.i...@gmail.com> >; Yingzhen 
Qu mailto:yingzhen.i...@gmail.com> >; lsr@ietf.org 
 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

I respect that individuals may have different opinions - but it is important to 
distinguish what is factual from what is not.

Opinions based upon false information are clearly compromised.

 

Please do heed Chris's (as WG chair) admonition to review the first WG adoption 
thread. That will reveal to you what the substantive objections were.

 

  
https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/

  
https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0

 

 

Please also do examine the delta between the previous version which was put up 
for WG adoption (V3) and the current version (V8) so you can see what has 
changed.

 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
代表 Les Ginsberg (ginsberg)
发送时间: 2024年1月16日 0:16
收件人: Christian Hopps ; Huzhibo

抄送: Acee Lindem ; Yingzhen Qu
; lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)

 

I respect that individuals may have different opinions - but it is important
to distinguish what is factual from what is not.

Opinions based upon false information are clearly compromised.

 

Please do heed Chris's (as WG chair) admonition to review the first WG
adoption thread. That will reveal to you what the substantive objections
were.

 

 
https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/

 
https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0

 

 

Please also do examine the delta between the previous version which was put
up for WG adoption (V3) and the current version (V8) so you can see what has
changed.

 

https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attribute
s-03=draft-wang-lsr-stub-link-attributes-08=--html

 

Some facts:

 

The substantive objections raised during the first adoption call had nothing
to do with use cases - they had to do with:

 

a)The use of a prefix to identify a link between two nodes is a flawed
concept. It is not robust enough to be used in cases of unnumbered or
Pt-2-MP.

[WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP
scenario, they share also the same subnet, please see our previous
discussion at
https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/

 

b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the
potential use cases and do so more robustly than the Stub-link proposal.

[WAJ] If you make such claims, then please give the encoding example for A.1
Figures 2(LAN scenario). How to configure/encode the several neighbors that
located in different AS in one inter-AS reachability TLV? 

 

The latest version of the draft makes no substantive changes to the stub
link concept or its advertisement.

The only substantive change in the latest version is a reorganization of the
presentation of use cases.

But lack of clarity in the use cases was not the basis on which first WG
adoption call was rejected.

 

In this thread (the second WG adoption call),  the authors have asserted
that they have addressed the concerns raised in the previous adoption call.

They have not. The concept and mechanism to identify a stub link has not
changed.

 

In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot
address the use cases.

This is FALSE.

As has been pointed out repeatedly, the existing mechanisms provide a robust
means to uniquely identify inter-AS links using endpoint identifiers - be
they IPv4/IPv6 addresses or Link IDs.

[WAJ] And, please give the solution for the non inter-AS scenario(A.2).
Please do not mention the bogus AS again

 

This addresses all cases - numbered and unnumbered.

There is therefore no need for a new mechanism.

[WAJ] Repeat again. The requirements of inter-AS TE solution are different
from the requirements of inter-AS topology recovery. We should find more
efficient solution to solve the latter scenario.

The inefficiency of existing solutions for inter-AS topology recovery lies
in that it requires the operators to get the other end information for every
inter-as links manually, this is very challenge and error-prone, as that
also indicated in RFC9346 and RFC5392 themselves.

 

No fact-based argument has been made to justify reconsideration of WG
adoption.

 

I hope when people post their opinions, that they consider the facts.

 

  Les

 

> -Original Message-

> From: Lsr <  lsr-boun...@ietf.org> On Behalf
Of Christian Hopps

> Sent: Wednesday, January 10, 2024 2:17 AM

> To: Huzhibo < 
huzhibo=40huawei@dmarc.ietf.org>

> Cc: Acee Lindem <  acee.i...@gmail.com>;
Yingzhen Qu 

> <  yingzhen.i...@gmail.com>;
 lsr@ietf.org

> Subject: Re: [Lsr] WG Adoption Call - 

> draft-wang-lsr-stub-link-attributes

> (01/05/2024 - 01/19/2024)

> 

> [As WG Co-Chair]

> 

>   Hi Folks,

> 

>   Before posting support reasons please read and considerl

>   *all* the email in the archive covering the first failed

>   adoption call.

> 

>  
https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/

>   https://www.mail-

> 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Acee: 

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee 
Lindem
发送时间: 2024年1月16日 6:44
收件人: Aijun Wang 
抄送: Christian Hopps ; Liyan Gong 
; Yingzhen Qu ; lsr 
; lsr-chairs 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 
- 01/19/2024)

 

Speaking as WG member: 

 

Hi Aijun,

 

I know you have gotten some of your co-authors on other drafts and colleagues 
to parrot your arguments in favor of this draft. However, you still have not 
addressed my comments. 

 

Why is better to advertise the link as stub link and surmise that it is an 
inter-AS link than it is to advertise this inter-AS status directly? 

 

Presumably, if you advertise this inter-AS link, you’re going to have routes 
using the link. If you have routes using the link, you’d think that you’d know 
the AS of these routes and this is not “inefficient” as you characterize it. It 
would seem if you going to use this link for intra-AS TE, you should know the 
AS to which this is directed. I don’t see why your encoding is any more 
efficient.

[WAJ]: The requirements for inter-AS TE and the requirements for inter-AS 
topology recovery are different. The key difference is that the previous covers 
only some of the inter-AS links, but the latter must cover all of the links 
between the AS. Then find some efficient way to solve the inter-AS recovery 
problem is necessary.

 

See inline. 





On Jan 15, 2024, at 09:02, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi, Chris:

 

The first adoption call focus on the A.1 use case(figure 1), not cover all of 
the use case that listed in A.1-A.3

For A.1(Figure 1) use case, previous discussions focus on mainly the benefits 
of the  configuration simplification, which you emphasize that IGP does not 
mainly for such work.wor

 

The use cases in A.2 and A.3 aren’t applicable. For anycast servers, why you 
this have anything to do with stub links? More protocol intuition? We have 
mechanisms advertise anycast prefixes - arguing that this a use case for stub 
links is just wrong. 

As for A.3, how does this even work? Why couldn’t this just be done on the 
prefix to which BGP routes resolve (as it is done today)? 

[WAJ]:The procedures for A.2 and A.3 are similar: the receiving router can 
select the optimal forwarding path(or network exit), based on the attributes of 
the stub links. Currently, all the selections are based on the 
characteristics/attributes of internal links.



 

OK, now let us consider other issues of the existing solutions——how to get the 
related information automatically and error-proofing? RFC9346 and RFC 5392 
mentioned all such challenges, they even propose to use BGP to cross verify 
such information, which is still on the imagination stage.

 

How is what you are proposing better? Since you are ASSUMING that a stub link 
connects another AS, it is even more error-prone. 

[WAJ] To rebuild the inter-as topology, we don’t need the above information 
from other sides, thus reduces the error-prone chances. What we assuming is 
that the stub link should share the same subnet, we can connect the two ends of 
the stub link automatically based on such assumption. If there is some errors 
for the shared prefix, the two ends can’t communicate with each other at all.

 

Thanks,

Acee





 

Then, if there is solution can bypass such requirements, should we consider it 
then? Especially from the deployment viewpoint of the operator?

 

Together with the above points, the proposed solution can cover other use 
cases, which are not discussed throughly in previous adoption call.

 

If one proposal can simply the deployment requirements of existing solution for 
some cases(A.1 Figure 1 and A.3), can solve some case that existing solution 
can’t(A.1 Figure 2 and A.2) should we accept it then?

 

We can discuss throughly on the above statements then for the second adoption 
call, pass the configuration simplification arguments.

 

 

Aijun Wang

China Telecom





On Jan 15, 2024, at 20:19, Christian Hopps mailto:cho...@chopps.org> > wrote:







On Jan 15, 2024, at 06:27, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi, Chris：

 

There are significant changes from the last adoption call(version 02) to the 
current version(version 08). Then I doubt the valid information from the 
previous discussions.

 

For example, there is no concrete use cases description in the previous 
version, which is provided in the appendix A.1-A.3 of current version.

 

[As WG member]

 

The original use case may not have been listed in previous document, but it was 
discussed very thoroughly during the adoption call.

 

It did not convince the WG to adopt the first time, b/c the WG felt existing 
solutions were sufficient -- nothing changed with respect to this for this 
second adoption call that I see.

 

Thanks,

Chris.





 

There are also the updates for the protocol extension, which absorbs the 

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Chris:

For the use case A.1(inter-as topology recovery), RFC9346/RFC5392 based 
solution requires the prerequisite knowledge of remote identifier on each stub 
link. Considering there maybe tens/hundreds of links among the ASBRs, there is 
no easy way to get such information automatically now.

And, there are situations that the stub links are not the inter-as link【use 
case A.2(Egress Engineering for Anycast Servers)]】, which is not suitable to 
reuse the RFC9346/RFC5392 based solution.

Then, it is necessary to extend the protocol to solve the above scenarios in 
one general manner.

Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Christian Hopps
发送时间: 2024年1月10日 18:17
收件人: Huzhibo 
抄送: Acee Lindem ; Yingzhen Qu ; 
lsr@ietf.org
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

[As WG Co-Chair]

  Hi Folks,

  Before posting support reasons please read and considerl
  *all* the email in the archive covering the first failed
  adoption call.

https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/
https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0

  This adoption call should be considering if the changes
  made to the document since it failed to be adopted the
  first time, are sufficient to reverse the WGs previous
  decision.

[As WG Member]

  To repeat from the first failed adoption call...

  "Reducing configuraiton" is not a reason to modify the
  routing protocols. Operators aren't doing by-hand manual
  configuration, and even if they were we shouldn't be
  trying to support it in this day and age.

Thanks,
Chris.

Huzhibo  writes:

> Hi Acee:
>
>
>
>   You're right, there are alternatives to address inter-domain 
> link advertisements, and this document attempts to address such issues 
> in a more simplified way, reducing the number of BGP-LS sessions 
> required, or avoid the configurations related to the peering AS 
> domains as required by RFC 9346. Do you have any suggestions for the 
> problems this article is trying to solve?



>
>
>
> Thanks
>
> Zhibo Hu
>
>
>
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> Sent: Tuesday, January 9, 2024 3:03 AM
> To: Yingzhen Qu 
> Cc: lsr 
> Subject: Re: [Lsr] WG Adoption Call -
> draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)
>
>
>
> Speaking as WG member:
>
>
>
> I don’t support adoption of this draft.
>
>
>
> First of all, I think the basic premise of the draft is flawed in that 
> a link is advertised as a stub and, from that, one can deduce uses of 
> the link. Why not just advertise what is being deduced?
>
>
>
> Second, I don’t think the draft is necessary. The use case in A.1 is 
> solely for an IGP router to advertise this stub link characteristic to 
> a controller for inter-AS TE. Since it is only for the controller why 
> wouldn’t be BGP-LS be used? It seems this is how it ultimately gets to 
> the controller anyway. Furthermore, if it were to be put into the 
> IGPs, why wouldn’t something like RFC 9346 be used for inter-AS TE? 
> For the use case in A.2, anycast prefix advertisement is already 
> handled and documents exist to identify a prefix as an anycast 
> address. For the use case in A.3, I don’t even understand how it works 
> or what is supposed to happen between BGP and the IGPs? What is 
> different about this from normal BGP route recursion over the IGP 
> route? For this, the fact that it is a stub link is irrelevant.
>
>
>
> Thanks,
>
> Acee
>
>
>
>
>
>
>
>
>
> On Jan 5, 2024, at 19:23, Yingzhen Qu 
> wrote:
>
>
>
> Hi,
>
>
>
> 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 19th, 2024.
>
>
>
> Authors, please respond to the list indicating whether you are aware of 
> any IPR that applies to the draft.
>
> *** Please note that this is the second WG adoption poll of the
> draft. The first one was tried two years ago and you can see the
> discussions in the archive:
>
> [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> (ietf.org)
>
>
>
> Thanks,
>
> Yingzhen
>
>
>
>
>
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Peter:

There is no Remote Identifiers, IPv4 Neighbor address, IPv6 Neighbor address
information on each of these stub links, unless you configure or identify
them manually.
Image there are tens of links between the inter-AS neighbors, what you think
better ways is very inefficient.

There are also other cases(for example, A.2, which is not the inter-AS
scenarios) that can utilize these attributes of the stub links.

Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org]
代表 Peter Psenak
发送时间: 2024年1月10日 1:08
收件人: Yingzhen Qu ; lsr ;
lsr-chairs 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes
(01/05/2024 - 01/19/2024)

Hi,

I don't believe any of what is being proposed in the draft is necessary.

There are existing mechanism available to advertise an inter-AS link.

Using the prefix advertisement to pair the two ends of the inter-AS link is
a bad idea IMHO. There are better ways of doing it - e.g. 
Local/Remote Identifiers, IPv4 interface address/IPv4 neighbor address,
IPv6 Interface Address/IPv6 Neighbor Address - these are all allowed in the
inter-AS reachability information.

thanks,
Peter


On 06/01/2024 01:23, Yingzhen Qu wrote:
> Hi,
> 
> 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 19th, 2024.
> Authors, please respond to the list indicating whether you are aware 
> of any IPR that applies to the draft.
> 
> *** Please note that this is the second WG adoption poll of the draft. 
> The first one was tried two years ago and you can see the discussions 
> in the archive:
> [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
> (ietf.org)
>  />
> 
> Thanks,
> 
> Yingzhen
> 
> 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Les:

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Les 
Ginsberg (ginsberg)
发送时间: 2024年1月9日 5:03
收件人: Yingzhen Qu ; lsr ; lsr-chairs 

主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

I oppose WG adoption.

 

The reasons that I opposed adoption the first time remain valid:

 

1)  The use of a prefix to represent a link is a flawed concept

[WAJ] The prefix is one of the attributes of the link. Each end of the link 
will share this attribute.

 

2)  RFC 9346 (previously RFC 5316) and RFC 5392 (as well as BGP-LS) are 
available to address the use cases.

[WAJ] please see my response to Acee.

 

The updated draft does nothing to address these points.

 

I would be less than candid if I did not also say that the second adoption call 
is a waste of WG time.

I respect the fact that the draft authors may disagree with the conclusions of 
the WG – but that does not mean they have a right to ignore WG consensus.

 

Let’s please move on.

 

   Les

 

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Yingzhen Qu
Sent: Friday, January 5, 2024 4:23 PM
To: lsr mailto:lsr@ietf.org> >; lsr-chairs mailto:lsr-cha...@ietf.org> >
Subject: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Hi,

 

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 19th, 2024.
 
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

*** Please note that this is the second WG adoption poll of the draft. The 
first one was tried two years ago and you can see the discussions in the 
archive:

[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) 
 

 

Thanks,
Yingzhen
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, Acee:

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee 
Lindem
发送时间: 2024年1月9日 3:03
收件人: Yingzhen Qu 
抄送: lsr 
主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes 
(01/05/2024 - 01/19/2024)

 

Speaking as WG member:

 

I don’t support adoption of this draft. 

 

First of all, I think the basic premise of the draft is flawed in that a link 
is advertised as a stub and, from that, one can deduce uses of the link. Why 
not just advertise what is being deduced? 

[WAJ]: The stub links are existing at the network boundary. We can’t advertise 
them as one normal IGP link. Then, what’s your proposal that “why not just 
advertise what is being deduced”?

 

Second, I don’t think the draft is necessary. The use case in A.1 is solely for 
an IGP router to advertise this stub link characteristic to a controller for 
inter-AS TE. Since it is only for the controller why wouldn’t be BGP-LS be 
used? It seems this is how it ultimately gets to the controller anyway. 

[WAJ]: As explained in the document“it is required that the BGP-LS to be 
enabled on every router that has the stub links, which is challenging for the 
network operation. It is desirable to advertise the stub link info into the IGP 
to ease the deployment of BGP-LS on any router in the IGP domain.”

 

Furthermore, if it were to be put into the IGPs, why wouldn’t something like 
RFC 9346 be used for inter-AS TE?

[WAJ] It is very inefficient. We have explained this point several times 
before-the operator must appoint the identification of remoted devices for 
each stub link.

For the use case in A.2, anycast prefix advertisement is already handled and 
documents exist to identify a prefix as an anycast address. 

[WAJ] The motivation of use case in A.2 is not for advertising the anycast 
prefix, but for the selection of optimal path to the anycast server.“It 
will be help for the router R0, to know the attributes of the stub links and 
select the optimal Anycast server to serve the customer's application”

 

For the use case in A.3, I don’t even understand how it works or what is 
supposed to happen between BGP and the IGPs? What is different about this from 
normal BGP route recursion over the IGP route? For this, the fact that it is a 
stub link is irrelevant. 

[WAJ] There are multiple routes(include the stub links among the AS) between 
the BGP neighbors(R10 and R20). They can select the optimal ones to install 
into their RIB/FIB, to reach each other, after considering on the 
characteristics of the stub link.

 

Thanks,

Acee

 

 

 

 

On Jan 5, 2024, at 19:23, Yingzhen Qu mailto:yingzhen.i...@gmail.com> > wrote:

 

Hi,

 

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 19th, 2024.
 
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

*** Please note that this is the second WG adoption poll of the draft. The 
first one was tried two years ago and you can see the discussions in the 
archive:

[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) 
 

 

Thanks,
Yingzhen
 

 

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, All:

 

I am not aware of any IPR that applies to the draft.

 

The latest version of this draft(version-08) has made signification updates 
since its earlier version(version -02).

We are seeking one general solution that can cover more scenarios, as that are 
descried in Appendix A.1, A.2, A.3.

 

Wish to get to your support to forward and refine it.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2024年1月6日 8:23
收件人: lsr ; lsr-chairs 
主题: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 
01/19/2024)

 

Hi,

 

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 19th, 2024.
 
Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to the draft.

*** Please note that this is the second WG adoption poll of the draft. The 
first one was tried two years ago and you can see the discussions in the 
archive:

[Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 (ietf.org) 
 

 

Thanks,
Yingzhen
 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr