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

[Yingzhen Qu]

Hi all,

The adoption call is closed, and the document is not adopted.

The author has requested an extension of the adoption call for one week,
however since we fail to see new technical points being discussed, the
chairs decided to close the call as planned.

During the second adoption call,  the discussion has been focusing on
simplifying inter-as link discovery and topology management although there
are existing solutions. Additionally the added use cases were discussed,
but are also covered by existing solutions. No rough consensus has been
reached about the use cases, nor the solution. Please note: many of the
same points were discussed in the first adoption call.

In the future, if the authors are to request another adoption call, the
condition will be to have a discussion on the list first and achieve rough
consensus of the use case and solution.

Thanks,
Acee, Chris and Yingzhen (LSR Co-chairs)

On Thu, Jan 18, 2024 at 5:52 PM Aijun Wang 
wrote:

> 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' <
> 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 –
>
>
>
> 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 
> *Sent:* Thursday, January 18, 2024 1:29 AM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* 'Christian Hopps' ; 'Huzhibo' ;
> 'Acee Lindem' ; '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月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 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Christian Hopps ; Huzhibo ;
> Acee Lindem ; Yingzhen Qu ;
> 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)H

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

[Les Ginsberg (ginsberg)]

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 
Sent: Thursday, January 18, 2024 1:29 AM
To: Les Ginsberg (ginsberg) 
Cc: 'Christian Hopps' ; 'Huzhibo' ; 
'Acee Lindem' ; 'Yingzhen Qu' ; 
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> 
[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<mailto: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<mailto: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.

[LES2:] You have missed the point. 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.

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.

[LES2:]  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.

   Les

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

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

[Les Ginsberg (ginsberg)]

Aijun -

From: Aijun Wang 
Sent: Tuesday, January 16, 2024 10:56 PM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Huzhibo ; Acee 
Lindem ; Yingzhen Qu ; 
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)


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

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.

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<mailto: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> 
[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<mailto: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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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 

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

[Robert Raszuk]

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 
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)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Aijun –
>
>
>
> Please see inline.
>
>
>
> *From:* Aijun Wang 
> *Sent:* Tuesday, January 16, 2024 12:18 AM
> *To:* Les Ginsberg (ginsberg) ; 'Christian Hopps' <
> cho...@chopps.org>; 'Huzhibo' 
> *Cc:* 'Acee Lindem' ; '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 ; Huzhibo <
> huzhibo=40huawei@dmarc.ietf.org>
> 抄送: Acee Lindem ; Yingzhen Qu <
> 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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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/
>
>
>
> *[LES:] I have no idea why you think the email you point to resolved the
> issue. It was an early email in a very long thread, the lack of support for
> unnumbered etc. continued to be discussed in subsequent emails by multiple
> participants and has been raised again by multiple participants in this
> second adoption call thread.*
>
> *The minor changes you made to the encoding of Stub L

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

[Aijun Wang]

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 WangChina TelecomOn Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg)  wrote:







Aijun –
 
Please see inline.
 



From: Aijun Wang 

Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps' ; 'Huzhibo' 
Cc: 'Acee Lindem' ; 'Yingzhen Qu' ; 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 <cho...@chopps.org>; Huzhibo <huzhibo=40huawei@dmarc.ietf.org>
抄送: Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu <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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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/
 
[LES:] I have no idea why you think the email you point to resolved the issue. It was an early email in a very long thread, the lack of support for unnumbered etc. continued to be discussed in subsequent
 emails by multiple participants and has been raised again by multiple participants in this second adoption call thread.
The minor changes you made to the encoding of Stub Link advertisement does nothing to resolve the issue.
The fundamental issue is that the same prefix can be associated with multiple links, so what you have defined is ambiguous in some cases.
Either you don’t understand this or don’t think this is important – I am not sure which – but many of us do believe this is important.
 
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? 
 
[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify inter-AS links, verify two-way connectivity, and optionally advertise additional link attributes if desired. (Apply this portion
 of the response to your other comments below.)
You apparently think this is too onerous and you propose a different mechanism that isn’t robust, does not allow two-way connectivity verification, and doesn’t support link attribute advertisement.
But because you see it as “simpler” you think you have sufficient justification to overlook its flaws.
I don’t agree.
 
The long-lived success of the IGPs has happened because we hav

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

[Les Ginsberg (ginsberg)]

Aijun –

Please see inline.

From: Aijun Wang 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) ; 'Christian Hopps' 
; 'Huzhibo' 
Cc: 'Acee Lindem' ; 'Yingzhen Qu' 
; 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> 
[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<mailto: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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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/



[LES:] I have no idea why you think the email you point to resolved the issue. 
It was an early email in a very long thread, the lack of support for unnumbered 
etc. continued to be discussed in subsequent emails by multiple participants 
and has been raised again by multiple participants in this second adoption call 
thread.

The minor changes you made to the encoding of Stub Link advertisement does 
nothing to resolve the issue.

The fundamental issue is that the same prefix can be associated with multiple 
links, so what you have defined is ambiguous in some cases.

Either you don’t understand this or don’t think this is important – I am not 
sure which – but many of us do believe this is important.



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?



[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify inter-AS 
links, verify two-way connectivity, and optionally advertise additional link 
attributes if desired. (Apply this portion of the response to your other 
comments below.)

You apparently think this is too onerous and you propose a different mechanism 
that isn’t robust, does not allow two-way connectivity verification, and 
doesn’t support link attribute advertisement.

But because you see it as “simpler” you think you have sufficient justification 
to overlook its flaws.

I don’t agree.



The long-lived success of the IGPs has happened because we have worked 
diligently to provide robust solutions – not settle for solutions that only 
work some of the time.



   Les



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 

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

[Acee Lindem]

;> 
>>> Then, If there is solution that can bypass these challenges, why don’t we 
>>> adopt it?
>>> 
>>> For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot 
>>> solve the requirements.
>>> 
>>> For use case A.2, the inter-AS based solution cannot solve the non inter-AS 
>>> scenario. 
>>> 
>>> For use case A.3, it has the same benefits as that for use case A.1(Figure 
>>> 1) when compared with the existing solution. The differences are that 
>>> A.1(Figure) focuses on the topology recovery, A.3 focuses on forward path 
>>> optimization.
>>> 
>>> When we consider whether one proposal is reasonable enough, we should not 
>>> only consider the implementation possibilities, but also the deployment 
>>> challenges(not configuration/management). If it is not practical for the 
>>> deployment, then what’s the value of standard/implementation?
>>> 
>>> And, people are arguing that there exists inter-AS TE 
>>> solutions(RFC9346/RFC5392), but how many operators have deployed them in 
>>> the network? Are anyone considering the reason that hinders their 
>>> deployments?
>>> 
>>> Aijun Wang
>>> China Telecom
>>> 
>>>> On Jan 15, 2024, at 17:35, Christian Hopps  wrote:
>>>> 
>>>> 
>>>> Liyan Gong  writes:
>>>> 
>>>>> Hi WG,
>>>>> 
>>>>> 
>>>>> I Support its adoption.
>>>>> 
>>>>> Currently there is no automatic and error-proof way to get the
>>>>> related information of the other ends for inter-as links, it is
>>>>> difficult for operator to rebuild the complex inter-as topology.
>>>>> 
>>>>> The proposed protocol extension in this draft can assist the operator
>>>>> to overcome the above obstacles.
>>>> 
>>>> [As WG member]
>>>> 
>>>> This use-case is covered by other solutions, and was discussed and denied 
>>>> as a reason to adopt already in the first failed adoption call.
>>>> 
>>>> [As co-char]
>>>> 
>>>> This second call for adoption indicated that people should go and read the 
>>>> first failed adoption call and the ton of email it generated. Repeating 
>>>> the same points found technically lacking the first time is unproductive 
>>>> and will not positively influence rough consensus a second time just b/c 
>>>> they are being repeated over and over.
>>>> 
>>>> Thanks,
>>>> Chris.
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> Best Regards,
>>>>> 
>>>>> Liyan
>>>>> 
>>>>> 
>>>>>邮件原文
>>>>>发件人：Yingzhen Qu  
>>>>>收件人：lsr  ,lsr-chairs  
>>>>>抄　送: (无)
>>>>>发送时间：2024-01-06 08:23:00
>>>>>主题：[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 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

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

[Yingzhen Qu]

[As WG Co-chair]

I concur Chris's statement as WG co-chair.

The second adoption call should focus on the changes made since the first
one, and whether these changes addressed/fixed the issues raised during the
first adoption call.

Thanks,
Yingzhen

On Mon, Jan 15, 2024 at 8:15 AM Les Ginsberg (ginsberg) 
wrote:

> 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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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.
>
> 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.
>
> 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.
> This addresses all cases - numbered and unnumbered.
> There is therefore no need for a new mechanism.
>
> 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  On Behalf Of Christian Hopps
> > Sent: Wednesday, January 10, 2024 2:17 AM
> > To: Huzhibo 
> > Cc: Acee Lindem ; Yingzhen Qu
> > ; 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-
> > archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=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.
> >
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[John Drake]

 Hi,
As Les suggested in his email, below, I re-reviewed the first WG adoption 
thread and the delta between the version proposed for the first WG adoption and 
the version proposed for the second WG adoption, and I completely agree with 
him that this is a gratuitous and ill-advised change to the IGPs.
The only reason advanced for its adoption, in either adoption call, is the 
groundless assertion that somehow it is a better way of identifying inter-AS 
links, which seems to be nonsense based upon the past thirty or more years of 
experience.
Thanks,
John
   On Monday, January 15, 2024 at 08:16:59 AM PST, Les Ginsberg (ginsberg) 
 wrote:  
 
 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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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.

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.

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.
This addresses all cases - numbered and unnumbered.
There is therefore no need for a new mechanism.

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  On Behalf Of Christian Hopps
> Sent: Wednesday, January 10, 2024 2:17 AM
> To: Huzhibo 
> Cc: Acee Lindem ; Yingzhen Qu
> ; 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-
> archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=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.
> 
___
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

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

[Les Ginsberg (ginsberg)]

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&q=stub+link&x=0&y=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-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--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.

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.

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.
This addresses all cases - numbered and unnumbered.
There is therefore no need for a new mechanism.

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  On Behalf Of Christian Hopps
> Sent: Wednesday, January 10, 2024 2:17 AM
> To: Huzhibo 
> Cc: Acee Lindem ; Yingzhen Qu
> ; 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-
> archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=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.
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Aijun Wang]

cult for operator to rebuild the complex inter-as topology.
>>>> 
>>>> The proposed protocol extension in this draft can assist the operator
>>>> to overcome the above obstacles.
>>> 
>>> [As WG member]
>>> 
>>> This use-case is covered by other solutions, and was discussed and denied 
>>> as a reason to adopt already in the first failed adoption call.
>>> 
>>> [As co-char]
>>> 
>>> This second call for adoption indicated that people should go and read the 
>>> first failed adoption call and the ton of email it generated. Repeating the 
>>> same points found technically lacking the first time is unproductive and 
>>> will not positively influence rough consensus a second time just b/c they 
>>> are being repeated over and over.
>>> 
>>> Thanks,
>>> Chris.
>>> 
>>> 
>>>> 
>>>> 
>>>> Best Regards,
>>>> 
>>>> Liyan
>>>> 
>>>> 
>>>>邮件原文
>>>>发件人：Yingzhen Qu  
>>>>收件人：lsr  ,lsr-chairs  
>>>>抄　送: (无)
>>>>发送时间：2024-01-06 08:23:00
>>>>主题：[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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

> On Jan 15, 2024, at 06:27, Aijun Wang  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 
> experts’ various comments from the last update.
> 
> Until know, it seems people focus mainly on the use cases, we have explained 
> them to them at 
> https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If 
> there is more question on the responses, please continue the discussion.
> 
> Regarding to the use case A.1 (Figure 1)which what you mentioned as one 
> failed use case of the first adoption call, what we want to emphasize is that 
> it is not only the configuration challenges in the complex network, but also 
> how to get the correct/error-proof  information automatically from the other 
> sides. Such challenges are also mentioned in the existing RFC 
> https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, 
> https://www.rfc-editor.org/rfc/rfc9346.html#section-5
> and also the corresponding parts of RFC5392.
> 
> Then, If there is solution that can bypass these challenges, why don’t we 
> adopt it?
> 
> For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot 
> solve the requirements.
> 
> For use case A.2, the inter-AS based solution cannot solve the non inter-AS 
> scenario. 
> 
> For use case A.3, it has the same benefits as that for use case A.1(Figure 1) 
> when compared with the existing solution. The differences are that 
> A.1(Figure) focuses on the topology recovery, A.3 focuses on forward path 
> optimization.
> 
> When we consider whether one proposal is reasonable enough, we should not 
> only consider the implementation possibilities, but also the deployment 
> challenges(not configuration/management). If it is not practical for the 
> deployment, then what’s the value of standard/implementation?
> 
> And, people are arguing that there exists inter-AS TE 
> solutions(RFC9346/RFC5392), but how many operators have deployed them in the 
> network? Are anyone considering the reason that hinders their deployments?
> 
> Aijun Wang
> China Telecom
> 
>> On Jan 15, 2024, at 17:35, Christian Hopps  wrote:
>> 
>> 
>> Liyan Gong  writes:
>> 
>>> Hi WG,
>>> 
>>> 
>>> I Support its adoption.
>>> 
>>> Currently there is no automatic and error-proof way to get the
>>> related information of the other ends for inter-as links, it is
>>> difficult for operator to rebuild the complex inter-as topology.
>>> 
>>> The proposed protocol extension in this draft can assist the operator
>>> to overcome the above obstacles.
>> 
>> [As WG member]
>> 
>> This use-case is covered by other solutions, and was discussed and denied as 
>> a reason to adopt already in the first failed adoption call.
>> 
>> [As co-char]
>> 
>> This second call for adoption indicated that people should go and read the 
>> first failed adoption call and the ton of email it generated. Repeating the 
>> same points found technically lacking the first time is unproductive and 
>> will not positively influence rough consensus a second time just b/c they 
>> are being repeated over and over.
>> 
>> Thanks,
>> Chris.
>> 
>> 
>>> 
>>> 
>>> Best Regards,
>>> 
>>> Liyan
>>> 
>>> 
>>>邮件原文
>>>发件人：Yingzhen Qu  
>>>收件人：lsr  ,lsr-chairs  
>>>抄　送: (无)
>>>发送时间：2024-01-06 08:23:00
>>>主题：[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 i

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

[Aijun Wang]

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.

There are also the updates for the protocol extension, which absorbs the 
experts’ various comments from the last update.

Until know, it seems people focus mainly on the use cases, we have explained 
them to them at 
https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If 
there is more question on the responses, please continue the discussion.

Regarding to the use case A.1 (Figure 1)which what you mentioned as one failed 
use case of the first adoption call, what we want to emphasize is that it is 
not only the configuration challenges in the complex network, but also how to 
get the correct/error-proof  information automatically from the other sides. 
Such challenges are also mentioned in the existing RFC 
https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, 
https://www.rfc-editor.org/rfc/rfc9346.html#section-5
and also the corresponding parts of RFC5392.

Then, If there is solution that can bypass these challenges, why don’t we adopt 
it?

For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot solve 
the requirements.

For use case A.2, the inter-AS based solution cannot solve the non inter-AS 
scenario. 

For use case A.3, it has the same benefits as that for use case A.1(Figure 1) 
when compared with the existing solution. The differences are that A.1(Figure) 
focuses on the topology recovery, A.3 focuses on forward path optimization.

When we consider whether one proposal is reasonable enough, we should not only 
consider the implementation possibilities, but also the deployment 
challenges(not configuration/management). If it is not practical for the 
deployment, then what’s the value of standard/implementation?

And, people are arguing that there exists inter-AS TE 
solutions(RFC9346/RFC5392), but how many operators have deployed them in the 
network? Are anyone considering the reason that hinders their deployments?

Aijun Wang
China Telecom

> On Jan 15, 2024, at 17:35, Christian Hopps  wrote:
> 
> Liyan Gong  writes:
> 
>> Hi WG,
>> 
>> 
>> I Support its adoption.
>> 
>> Currently there is no automatic and error-proof way to get the
>> related information of the other ends for inter-as links, it is
>> difficult for operator to rebuild the complex inter-as topology.
>> 
>> The proposed protocol extension in this draft can assist the operator
>> to overcome the above obstacles.
> 
> [As WG member]
> 
> This use-case is covered by other solutions, and was discussed and denied as 
> a reason to adopt already in the first failed adoption call.
> 
> [As co-char]
> 
> This second call for adoption indicated that people should go and read the 
> first failed adoption call and the ton of email it generated. Repeating the 
> same points found technically lacking the first time is unproductive and will 
> not positively influence rough consensus a second time just b/c they are 
> being repeated over and over.
> 
> Thanks,
> Chris.
> 
> 
>> 
>> 
>> Best Regards,
>> 
>> Liyan
>> 
>> 
>>    邮件原文----
>>    发件人：Yingzhen Qu  
>>收件人：lsr  ,lsr-chairs  
>>抄　送: (无)
>>发送时间：2024-01-06 08:23:00
>>主题：[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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

Liyan Gong  writes:


Hi WG,


I Support its adoption.

Currently there is no automatic and error-proof way to get the
related information of the other ends for inter-as links, it is
difficult for operator to rebuild the complex inter-as topology.

The proposed protocol extension in this draft can assist the operator
to overcome the above obstacles.


[As WG member]

This use-case is covered by other solutions, and was discussed and denied as a 
reason to adopt already in the first failed adoption call.

[As co-char]

This second call for adoption indicated that people should go and read the 
first failed adoption call and the ton of email it generated. Repeating the 
same points found technically lacking the first time is unproductive and will 
not positively influence rough consensus a second time just b/c they are being 
repeated over and over.

Thanks,
Chris.





Best Regards,

Liyan


邮件原文
发件人：Yingzhen Qu  
收件人：lsr  ,lsr-chairs  
抄　送: (无)
发送时间：2024-01-06 08:23:00
主题：[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






signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Christian Hopps]

"duzongp...@foxmail.com"  writes:


Hi, all

I support the adoption. I agree with the idea:
Considering there are many links and complex interconnections
among the ASBRs that located in different AS domains, the proposed
protocol extension can certainly ease the recovery and management of
inter-AS topologies.


[As WG member]

Key word "Management", The WG has a long-standing agreement that the IGPs are 
not to be used as a replacement for a proper NMS system. This was also covered in the 
previous failed WG adoption call.

Exposing a possible inter-domain link is a use case covered by existing 
solutions and was considered a non-supporting use case in the previous failed 
adoption call.

[As co-chair]

The following comment regards more than just this mail since I've been seeing 
it in other supporting emails as well -- repeating points that were found 
technically lacking from the first failed WG adoption call are not going to 
positively influence rough consensus for adoption in this repeated adoption 
call, no matter how many people chime in to repeat them.

Thanks,
Chris.



Best Regards
Zongpeng Du


duzongp...@foxmail.com & duzongp...@chinamobile.com


From: Yingzhen Qu
Date: 2024-01-06 08:23
To: lsr; lsr-chairs
    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






signature.asc
Description: PGP signature
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Liyan Gong]

Hi WG,



I Support its adoption.

Currently there is no automatic and error-proof way to get the related 
information of the other ends for inter-as links, it is difficult for operator 
to rebuild the complex inter-as topology.

The proposed protocol extension in this draft can assist the operator to 
overcome the above obstacles.



Best Regards,

Liyan



邮件原文发件人：Yingzhen Qu  收件人：lsr  
,lsr-chairs  抄　送: (无)发送时间：2024-01-06 
08:23:00主题：[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

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

[duzongp...@foxmail.com]

Hi, all

I support the adoption. I agree with the idea:
Considering there are many links and complex interconnections among the 
ASBRs that located in different AS domains, the proposed protocol extension can 
certainly ease the recovery and management of inter-AS topologies.

Best Regards
Zongpeng Du



duzongp...@foxmail.com & duzongp...@chinamobile.com 
 
From: Yingzhen Qu
Date: 2024-01-06 08:23
To: lsr; lsr-chairs
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

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

[Huaimo Chen]

Hi Everyone,

I read through the draft and support its adoption.
At first, the draft covers some cases that the existing RFCs do not cover. For 
example, RFC 9346 (RFC 5316) and RFC 5392 are for point-to-point inter-AS 
links, but do not support broadcast inter-AS links. This draft supports 
broadcast inter-AS links (refer to A.1. Figure 2).
Second, for the cases that the existing RFCs support, the draft provides a more 
efficient way for these cases.

Best Regards,
Huaimo
From: Lsr  On Behalf Of Yingzhen Qu
Sent: Friday, January 5, 2024 7:23 PM
To: lsr ; lsr-chairs 
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)<https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/>


Thanks,

Yingzhen


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

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

[胖胖]

Hi all,

I have reviewed the draft，and support its adoption.

I think the proposed protocol extension can simplify significantly the recovery 
and management of inter-AS topology, and also facilitate the optimal forwarding 
path selection based on the attributes of stub links.


Best regards
Guozhen


> 2024年1月6日 08:23，Yingzhen Qu  写道：
> 
> 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

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

[Wei Wang]

Hi all,


    I support the adoption of this draft. 
    This solution is useful for the transmission of the information 
of stub link, which enables BGP-LS to not only collect the topology information 
of individual ASes, but also collect the connection information between 
different ASes. And this mechanism may make it easier for the controller to 
obtain the global network topology.




Best Regards,
Wei


-- Original --
From:   
 "Yingzhen Qu"  
  
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

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

[Christian Hopps]

[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&q=stub+link&x=0&y=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

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

[Huzhibo]

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 
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)<https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/>


Thanks,

Yingzhen



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

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

[Gyan Mishra]

I support WG adoption.

Gyan


On Fri, Jan 5, 2024 at 7:23 PM 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

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

[Peter Psenak]

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

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

[Les Ginsberg (ginsberg)]

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

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

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  On Behalf Of Yingzhen Qu
Sent: Friday, January 5, 2024 4:23 PM
To: lsr ; lsr-chairs 
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)<https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/>


Thanks,

Yingzhen


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

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

[John Drake]

 I think Acee is correct

On Monday, January 8, 2024 at 11:03:17 AM PST, Acee Lindem 
 wrote:  
 
 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

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

[Acee Lindem]

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] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Yingzhen Qu]

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