[Lsr] 【Please extend the adoption call for one more week】答复: WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024)

[Aijun Wang]

Hi, LSR chairs:

 

Along the adoption call procedure, I think we all noticed that there are some 
limitations for the p2p(RFC9346/RFC5392) based existing solutions for the 
potential scenarios(A.1-A.3) that mentioned in the draft.

Then we want to apply for extending the adoption call for one week or more, to 
confirm these limitations and also the values of proposed draft.

 

The limitation for the p2p (RFC9346/RFC5392) based solutions are the followings:

1) Scalability: 

Within the operator’s network, there are always tens/hundreds of the links 
between any two ASBRs.  It is very challenge to get/validate the information of 
other end of the inter-AS links, that is required by the existing solutions. 

We should find some scalable solutions to solve the issue.

 

2) Coverage:

RFC9346/RFC5392 cover only p2p link, it doesn’t support the broadcast network, 
also the P2MP network. 

If these types of network are represented by individual P2P link(as Les 
suggested), then the following two additional questions should be answered:

2-1) whether one interface can be appointed to different neighbor? Will the 
latter override the former? 

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

Should we find some efficient way to cover more types of network then?

 

3) Flexibility:

RFC 9346/RFC5392 requires the remote AS number and the IPv4/IPv6  Remote ASBR 
sub-TLVs must be presented in the advertisement, but in some scenarios(non 
inter-as scenario, for example A.2 in the draft), they are not exists or not 
necessary, stick to these standards lead the solution very rigid and can’t be 
deployed.

 

Actually, “Stub Link” is one more general concept than the “inter-AS link”, we 
can pair them(form the inter-as link), or not(act independently) upon our 
demands.

We all should know that the components are more flexible than the compounds.

 

The actual pair methods can be refined later to meet the various 
requirements/scenarios(for example, unnumbered scenario, VRF scenario(as Robert 
mentioned) etc.)

 

Then, if the LSR experts agree the above limitations of the existing solutions, 
we expect to forward this draft to solve these limitations. 

Or else, we expect to discuss them further and more deeper in the coming times.

 

As operators, we expect to find one more attractive solution.

 

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

[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 
<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月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 on

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 <wangai...@tsinghua.org.cn> Sent: Tuesday, January 16, 2024 10:56 PMTo: Les Ginsberg (ginsberg) <ginsb...@cisco.com>Cc: Christian Hopps <cho...@chopps.org>; Huzhibo <huzh...@huawei.com>; Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu <yingzhen.i...@gmail.com>; 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) <ginsberg=40cisco@dmarc.ietf.org> wrote: Aijun – Please see inline. From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: Tuesday, January 16, 2024 12:18 AMTo: 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.orgSubject: 答复: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) Hi, Les: -邮件原件-发件人: forwardingalgori...@ietf.

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

 

 

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

[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 < <mailto:wangai...@tsinghua.org.cn> 
wangai...@tsinghua.org.cn> 
Sent: Tuesday, January 16, 2024 12:18 AM
To: Les Ginsberg (ginsberg) < <mailto:ginsb...@cisco.com> ginsb...@cisco.com>; 
'Christian Hopps' < <mailto:cho...@chopps.org> cho...@chopps.org>; 'Huzhibo' < 
<mailto:huzh...@huawei.com> huzh...@huawei.com>
Cc: 'Acee Lindem' < <mailto:acee.i...@gmail.com> acee.i...@gmail.com>; 
'Yingzhen Qu' < <mailto:yingzhen.i...@gmail.com> yingzhen.i...@gmail.com>;  
<mailto:lsr@ietf.org> 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://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/

 <https://www.mail-archive.com/search?l=lsr%40ietf.org=stub+link=0=0> 
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 ve

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=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-attributes-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/
 
[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 on

[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 extens

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

[Aijun Wang]

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.

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.

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  wrote:
> 
> 
> 
>> 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
>>>> di

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

[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/
> <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

___
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/> 
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

[Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Aijun Wang]

Hi, Tony:

 

If the MP-TLV support capability declaration  doesn’t mean support all relevant 
TLVs, and conform to the draft can’t assure the interoperability, then, what 
the purpose of this draft?

If you persist this direction, as proposed by Bruno, I think that documents the 
capabilities(includes the definition of the key) for every TLV in one Yang 
file(draft-isis-pics-multi-TLV”?) maybe more better.

The operator can compare such yang files from different vendor, and if they 
support the multipart of the same TLV, and the key is same, then the operator 
can safely enable the sending and receiving of the multi-part of this TLV.

 

Or else, we should think other solution to solve this issue.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Tony 
Li
发送时间: 2023年11月29日 0:49
收件人: Aijun Wang 
抄送: Yingzhen Qu ; 
draft-pkaneria-lsr-multi-...@ietf.org; lsr 
主题: Re: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

 

Hi Aijun,

 

 





On Nov 26, 2023, at 7:05 PM, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Some additional questions:

 

The draft say “The contents of a multi-part TLV MUST be processed as if they 
were concatenated. If the internals of the TLV contain key information, then 
replication of the key information should be taken to indicate that subsequent 
data MUST be processed as if the subsequent data were concatenated after a 
single copy of the key information.”

 

1) How to deal with the TLV that has no key information? 

 

 

That’s the easiest case: the content between instances is not correlated, so 
each TLV can be individually processed independently.

 





2) And, to support multi-part TLV,  the key information (if the TLV has 
such information) for each applied TLV must also be standardized, or else, 
there will be error.

The draft wants to just avoid to tackle such issues(as stated in draft “Having 
inconsistent information in different parts of a MP-TLV is an error and is out 
of scope for this document.), but it should be the MUST part of the solution. 

 

 

I respectfully disagree. Having a single RFC that sorts through all of that is 
wholly unwieldy and guaranteed to be highly erroneous.  It’s far better to 
write separate documents that can be individually and carefully crafted and 
reviewed.





 

Or else, how to assure the interoperability?

 

 

Interoperability is never assured by documents. Careful thought, coding, and 
testing are required. This has not changed.

 

T

 





 

Best Regards

 

Aijun Wang

China Telecom

 

发件人:  <mailto:forwardingalgori...@ietf.org> forwardingalgori...@ietf.org [ 
<mailto:forwardingalgori...@ietf.org> mailto:forwardingalgori...@ietf.org] 代表 
Aijun Wang
发送时间: 2023年11月24日 16:11
收件人: 'Yingzhen Qu' < <mailto:yingzhen.i...@gmail.com> yingzhen.i...@gmail.com>; 
 <mailto:draft-pkaneria-lsr-multi-...@ietf.org> 
draft-pkaneria-lsr-multi-...@ietf.org; 'lsr' < <mailto:lsr@ietf.org> 
lsr@ietf.org>
主题: [Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人:  <mailto:forwardingalgori...@ietf.org> forwardingalgori...@ietf.org [ 
<mailto:forwardingalgori...@ietf.org> mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人:  <mailto:draft-pkaneria-lsr-multi-...@ietf.org> 
draft-pkaneria-lsr-multi-...@ietf.org; lsr < <mailto:lsr@ietf.org> lsr@ietf.org>
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv:  
<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org)

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

 

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

[Lsr] 答复: 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Aijun Wang]

Some additional questions:

 

The draft say “The contents of a multi-part TLV MUST be processed as if they 
were concatenated. If the internals of the TLV contain key information, then 
replication of the key information should be taken to indicate that subsequent 
data MUST be processed as if the subsequent data were concatenated after a 
single copy of the key information.”

 

1) How to deal with the TLV that has no key information? 

2) And, to support multi-part TLV,  the key information (if the TLV has 
such information) for each applied TLV must also be standardized, or else, 
there will be error.

The draft wants to just avoid to tackle such issues(as stated in draft “Having 
inconsistent information in different parts of a MP-TLV is an error and is out 
of scope for this document.), but it should be the MUST part of the solution. 

 

Or else, how to assure the interoperability?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Aijun Wang
发送时间: 2023年11月24日 16:11
收件人: 'Yingzhen Qu' ; 
draft-pkaneria-lsr-multi-...@ietf.org; 'lsr' 
主题: [Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org>  
[mailto:forwardingalgori...@ietf.org] 代表 Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人: draft-pkaneria-lsr-multi-...@ietf.org 
<mailto:draft-pkaneria-lsr-multi-...@ietf.org> ; lsr mailto:lsr@ietf.org> >
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> 

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

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

[Lsr] 答复: I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

[Aijun Wang]

Hi, Acee:

 

I have uploaded the updated version of draft, to address your concerns.

 

The major update contents are the followings:

1) Separate the OSPF and IS-IS protocol extension for stub-link attributes, 
redefines the relevant Sub-TLVs to conform the current OSPF/IS-IS format.

2) Change some descriptions for scenario A.3, from "Optimized BGP Next-hop 
Selection" to "Egress Engineering for the path to BGP Next-hop".

3) Updates the graph for scenario A.2, let it more general.

 

Detail replies are inline below.

Please let me know whether you have other issues or not, for the scenario, for 
the solution, for the encoding etc.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

-邮件原件-

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee 
Lindem

发送时间: 2023年11月16日 3:56

收件人: Aijun Wang 

抄送: Christian Hopps ; Yingzhen Qu ; 
draft-wang-lsr-stub-link-attribu...@ietf.org; Lsr 

主题: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

 

Speaking as WG member: 

 

Hi Aijun, 

 

See inline. I’ve added the co-authors and LSR to the discussion - lest we don’t 
need to repeat it. 

 

> On Nov 14, 2023, at 21:52, Aijun Wang  wrote:

> 

> Hi, Acee:

> 

> I explained in detail inline below to your comments. 

> Wish they can address your concerns.

> If you have any further questions, please let me know.

> 

> -邮件原件-

> 发件人: Acee Lindem [mailto:acee.i...@gmail.com]

> 发送时间: 2023年11月15日 6:07

> 收件人: Aijun Wang 

> 抄送: Christian Hopps ; Yingzhen Qu 

> 

> 主题: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

> 

> And for inter-AS use case, we already have: 

> 

> https://datatracker.ietf.org/doc/rfc5392/

> 

> I’m sure there is something similar for IS-IS. Why do we need anything more? 

> 

> 【WAJ】: Actually, we have explained the reason briefly at 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-07#section-3.
>  There are scenarios that inter-AS scenario can't cover. And even for 
> inter-AS scenario, to apply RFC 5392(OSPF), or RFC 5316(IS-IS, now is 
> obsoleted by RFC9346), it requires every inter-AS link be configured with 
> "remote AS", and "IPv6/IPv4 Remote ASBR Identifier", which is inefficient.

 

In the use case, given that there is an active BGP session between the routers, 
it would seem that the remote AS is known. 

 

【WAJ】: It is not only AS number, but also the "IPv6/IPv4 Remote ASBR 
Identifier" for each link. The operator must manually identify them if we use 
the current solution.

 

> 

> Thanks,

> Acee

> 

> 

>> On Nov 14, 2023, at 16:40, Acee Lindem  wrote:

>> 

>> Hi Aijun,

>> 

>> I have the following comments: 

>> 

>>  1. What would be the purpose of an unnumbered stub link - if the link 
>> doesn’t go anywhere and doesn’t have an address, it doesn’t seem to serve 
>> any purpose. However, see comment #5 as this would imply the links aren’t 
>> really stubs.

> 【WAJ】The information carried within the stub link will be flooding across the 
> IGP domain, and each of them have an address, and also the prefix.  The 
> scenario described in A.1-A.3 explain the use case of such information.

 

But unnumbered links don’t have a unique address. 

【WAJ】For unnumbered stub link, as explained and stated in the draft, they must 
be identified and labeled specially. And we should know that unnumbered 
interface is seldom used within the network now.  To include them is just for 
the integrity of the standard. 

 

> 

>>  2. For IS-IS, the TLVs and sub-TLVs have 1 octet type/length.

> 【WAJ】There is already the discussion about the limitation of 1 octet length, 
> should we avoid it happen again? And 
> https://www.rfc-editor.org/rfc/rfc7356.htm defines also the Extended TLVs and 
> Extended Sub-TLVs which use the 16bit type and 16 bit length.

 

Given the constraints of extend TLV/sub-TLVs in RFC 7356, they wouldn’t seem to 
apply to your area scope use cases. 

【WAJ】Have updated draft to address your concerns 

 

> 

> 

>>  3. For the prefix sub-TLVs, the first length in the sub-TLV is the length 
>> of the value in the TLV. It cannot double as the prefix length.

> 【WAJ】The length value in the container TLV is the sum of attached sub-TLV; 
> the length field in the sub-TLV is the length of each sub-TLV. What's the 
> meaning of "it cannot double as the prefix length”?

 

In sections 4.3 and 4.4 there is only one length and it should be the sub-TLV 
length, not the prefix length. 

【WAJ】Have updated draft to address your concerns

 

> 

>>  4. The Appendix A.2 use case is already typically done with prefix 
>> advertisements.

> 【WAJ】There is no existing sub-TLV to encode the prefix 

[Lsr] 答复: WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 12/09/2023)

[Aijun Wang]

Do not support its adoption.

 

The draft just enumerate the requirements of MP-TLV support for relevant TLVs, 
it is not the general solution to the issue.

 

There is no practical way in the draft to assure the current and future 
implementation conforms to the newly defined explicit requirements, because the 
MP-TLV Support sub-TLV is not per-TLV basis, and as stated in the draft, one 
implementation declares support “MP-TLV” can’t assure it supports all relevant 
TLVs. --“It is understood that in reality, a given implementation might 
limit MP-TLV support to particular TLVs based on the needs of the deployment 
scenarios in which it is used”-Will there be many interoperability issues 
arises then? And also varies loop accidents within the network when all of 
vendors declare they support “MP-TLV” but not all of the relevant TLVs?

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 
Yingzhen Qu
发送时间: 2023年11月18日 1:24
收件人: draft-pkaneria-lsr-multi-...@ietf.org; lsr 
主题: [Lsr] WG Adoption Call - draft-pkaneria-lsr-multi-tlv (11/17/2023 - 
12/09/2023)

 

Hi,

 

This begins a WG adoption call for draft-pkaneria-lsr-multi-tlv: 
draft-pkaneria-lsr-multi-tlv-04 - Multi-part TLVs in IS-IS (ietf.org) 
<https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/> 

 

Please send your support or objection to the list before December 9th, 2023. An 
extra week is allowed for the US Thanksgiving holiday.

 

Thanks,

Yingzhen 

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

[Lsr] 答复: Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan:

 

Please think it further:

 

No Prefix Originator--à Orphan Prefix-àThe associated prefix is unreachable

 

I am wondering why the WG select the detour way to standardize the solution……

 

发件人: Ketan Talaulikar [mailto:ketant.i...@gmail.com] 
发送时间: 2023年11月17日 21:44
收件人: Aijun Wang 
抄送: Les Ginsberg (ginsberg) ; John Drake 
; Peter Psenak (ppsenak) 
; lsr@ietf.org
主题: Re: [Lsr] Technical questions for draft about unreachable prefixes 
announcement

 

By this logic, when the Prefix Originator is set to 0.0.0.0, it means there is 
no Prefix Originator ... ;-)

 

Not sure why we are even arguing about this :-(

 

 

On Wed, Nov 15, 2023 at 1:50 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

The logic is that why we can set router-id equal to 0.0.0.0 to indicate some 
information in some standards, but we can’t set prefix originator information 
to 0.0.0.0 to indicate the prefix is unreachable?

 

Here are again two examples for the usages of router-id’s value as 0.0.0.0 to 
indicate some information, one is for OSPF another is for IS-IS:

1) For OSPF: https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.3.2

 

Designated Router ID
   The sending router's view of the identity of the Designated Router for this 
network.  The Designated Router is identified by its Router ID.  It is set to 
0.0.0.0 if there is no Designated Router.
 
Backup Designated Router ID
   The sending router's view of the identity of the Backup Designated Router 
for this network.  The Backup Designated Router is identified by its IP Router 
ID.  It is set to 0.0.0.0 if there is no Backup Designated Router.

 

2) For IS-IS: https://www.rfc-editor.org/rfc/rfc7981.html#appendix-A

 

If the originating node does not support IPv4, then the reserved value 0.0.0.0 
MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316 
<https://www.rfc-editor.org/rfc/rfc5316> ] MUST be present in the TLV.

 

What I insist is that there are already containers that can be used to indicate 
the unreachable information, why we pursue other non-existing, non-standard 
container?

Aijun Wang

China Telecom





On Nov 7, 2023, at 18:16, Ketan Talaulikar mailto:ketant.i...@gmail.com> > wrote:



Hi Aijun,

 

I am not sure what "logic" you are looking for while being somewhat dismissive 
of the arguments/logic provided.

 

Let us agree to disagree.

 

At least I've concluded that it is no more fruitful for me to try to convince 
you. C'est la vie ...

 

Thanks,

Ketan

 

 

On Tue, Nov 7, 2023 at 11:08 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

There are many examples within IETF that special values has special meanings, 
please see:

 

1) 
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

2) 
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

 

3) 
https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml

 

4) LS-Infinity

 

Then, please state clearly that why we cannot define specific value for prefix 
originator to indicate the unreachability.

 

We need the logic that supports your conclusions. Until now, none.

 

Or anyone else can elaborate the logic more clearly?

 

Aijun Wang

China Telecom





On Nov 7, 2023, at 10:19, Ketan Talaulikar mailto:ketant.i...@gmail.com> > wrote:



Hi Aijun,

 

I realize that continuing this argument with you is futile. 

 

However, perhaps one last response that I would address not to you but for 
other WG members (if any one is still following this thread).

 

On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan and Les:

 

There are two sub-TLVs to indicate the source information of the prefix within 
OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”

 

What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t 
such statements, this is also true for IS-IS,  as Les pointed out.

 

KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address 
should be clear to anyone that reads the procedures in Sec 3.

 

 

 

So, contrary to your happiness :) this give us the room to define the specific 
value to indicate “unreachability”.

 

And, to Ketan again, until now, you don’t explain clearly that if we can’t 
define specific value for “unreachability” why can we define the specific value 
for “LS-Infinity”?

 

KT> For LS-Infinity - please read RFC2328.

 

Thanks,

Ketan

 

 

Aijun Wang

China Telecom





On Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org> > 
wrote:

 

Ketan –

 

I am very happy to be wrong in this case. 

We are in full agreement.

 

Les

 

 

From: Lsr mailto:lsr-boun...@ietf.org> > On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 202

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan:The logic is that why we can set router-id equal to 0.0.0.0 to indicate some information in some standards, but we can’t set prefix originator information to 0.0.0.0 to indicate the prefix is unreachable?Here are again two examples for the usages of router-id’s value as 0.0.0.0 to indicate some information, one is for OSPF another is for IS-IS:1) For OSPF: https://www.rfc-editor.org/rfc/rfc5340.html#appendix-A.3.2Designated Router ID
   The sending router's view of the identity of the Designated Router for this network.  The Designated Router is identified by its Router ID.  It is set to 0.0.0.0 if there is no Designated Router.

Backup Designated Router ID
   The sending router's view of the identity of the Backup Designated Router for this network.  The Backup Designated Router is identified by its IP Router ID.  It is set to 0.0.0.0 if there is no Backup Designated Router.2) For IS-IS: https://www.rfc-editor.org/rfc/rfc7981.html#appendix-AIf the originating node does not support IPv4, then the reserved value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE Router ID sub-TLV [RFC5316] MUST be present in the TLV.
What I insist is that there are already containers that can be used to indicate the unreachable information, why we pursue other non-existing, non-standard container?Aijun WangChina TelecomOn Nov 7, 2023, at 18:16, Ketan Talaulikar  wrote:Hi Aijun,I am not sure what "logic" you are looking for while being somewhat dismissive of the arguments/logic provided.Let us agree to disagree.At least I've concluded that it is no more fruitful for me to try to convince you. C'est la vie ...Thanks,KetanOn Tue, Nov 7, 2023 at 11:08 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan:There are many examples within IETF that special values has special meanings, please see:1) https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml2) https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml3) https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml4) LS-InfinityThen, please state clearly that why we cannot define specific value for prefix originator to indicate the unreachability.We need the logic that supports your conclusions. Until now, none.Or anyone else can elaborate the logic more clearly?Aijun WangChina TelecomOn Nov 7, 2023, at 10:19, Ketan Talaulikar <ketant.i...@gmail.com> wrote:Hi Aijun,I realize that continuing this argument with you is futile. However, perhaps one last response that I would address not to you but for other WG members (if any one is still following this thread).On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan and Les:There are two sub-TLVs to indicate the source information of the prefix within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t such statements, this is also true for IS-IS,  as Les pointed out.KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address should be clear to anyone that reads the procedures in Sec 3.  So, contrary to your happiness :) this give us the room to define the specific value to indicate “unreachability”.And, to Ketan again, until now, you don’t explain clearly that if we can’t define specific value for “unreachability” why can we define the specific value for “LS-Infinity”?KT> For LS-Infinity - please read RFC2328.Thanks,Ketan Aijun WangChina TelecomOn Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) 40cisco@dmarc.ietf.org> wrote:







Ketan –
 
I am very happy to be wrong in this case. 

We are in full agreement.
 
    Les
 
 



From: Lsr <lsr-boun...@ietf.org> On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: John Drake 40yahoo@dmarc.ietf.org>; Peter Psenak (ppsenak) <ppse...@cisco.com>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Les,

 


I disagree with your reading of RFC9084 (OSPF Prefix Originator).


 


Sec 1


This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These
 extensions do not change the core OSPF route computation functionality.


 


Sec 2.1



For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be
 considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.¶

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be
 con

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan:There are many examples within IETF that special values has special meanings, please see:1) https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml2) https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml3) https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml4) LS-InfinityThen, please state clearly that why we cannot define specific value for prefix originator to indicate the unreachability.We need the logic that supports your conclusions. Until now, none.Or anyone else can elaborate the logic more clearly?Aijun WangChina TelecomOn Nov 7, 2023, at 10:19, Ketan Talaulikar  wrote:Hi Aijun,I realize that continuing this argument with you is futile. However, perhaps one last response that I would address not to you but for other WG members (if any one is still following this thread).On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan and Les:There are two sub-TLVs to indicate the source information of the prefix within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t such statements, this is also true for IS-IS,  as Les pointed out.KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address should be clear to anyone that reads the procedures in Sec 3.  So, contrary to your happiness :) this give us the room to define the specific value to indicate “unreachability”.And, to Ketan again, until now, you don’t explain clearly that if we can’t define specific value for “unreachability” why can we define the specific value for “LS-Infinity”?KT> For LS-Infinity - please read RFC2328.Thanks,Ketan Aijun WangChina TelecomOn Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) 40cisco@dmarc.ietf.org> wrote:







Ketan –
 
I am very happy to be wrong in this case. 

We are in full agreement.
 
    Les
 
 



From: Lsr <lsr-boun...@ietf.org> On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>
Cc: John Drake 40yahoo@dmarc.ietf.org>; Peter Psenak (ppsenak) <ppse...@cisco.com>; Aijun Wang <wangai...@tsinghua.org.cn>; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Les,

 


I disagree with your reading of RFC9084 (OSPF Prefix Originator).


 


Sec 1


This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These
 extensions do not change the core OSPF route computation functionality.


 


Sec 2.1



For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be
 considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.¶

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be
 considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged
 as an error (subject to rate limiting).

As editor of this document, it is absolutely clear to me that we are referring to the sub-TLV and not the prefix advertisement. So, when the value is set to 0, the sub-TLV is invalid and ignored
 - the prefix reachability is not at all affected.


This is the reason why I am firmly opposed to using Prefix Originator value 0 for UPA or any other indication.


 


I hope I am able to convince you :-)


 


Thanks,


Ketan


 


 


 


On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote:





To add to what Ketan has stated…
 
draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0
 to indicate unreachability.
For OSPF, this might be considered compatible with RFC 9084 where it is stated that advertisements with “Router ID field set to 0 MUST be considered invalid and ignored” - though
 Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times over the years, but my feedback was ignored.
 
Which is an example of why I would like to echo Ketan’s sentiments – let’s please put an end to this non-constructive discussion.
 
The authors of draft-wang have had many opportunities over the years to respond in a more constructive way to feedback. They were also – as Peter has indicated – given an opportunity
 to co-author draft-ietf-lsr-igp-ureach-prefix-announce out of respect for 

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan and Les:There are two sub-TLVs to indicate the source information of the prefix within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t such statements, this is also true for IS-IS,  as Les pointed out. So, contrary to your happiness :) this give us the room to define the specific value to indicate “unreachability”.And, to Ketan again, until now, you don’t explain clearly that if we can’t define specific value for “unreachability” why can we define the specific value for “LS-Infinity”?Aijun WangChina TelecomOn Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg)  wrote:







Ketan –
 
I am very happy to be wrong in this case. 

We are in full agreement.
 
    Les
 
 



From: Lsr  On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) 
Cc: John Drake ; Peter Psenak (ppsenak) ; Aijun Wang ; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Les,

 


I disagree with your reading of RFC9084 (OSPF Prefix Originator).


 


Sec 1


This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These
 extensions do not change the core OSPF route computation functionality.


 


Sec 2.1



For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be
 considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.¶

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be
 considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged
 as an error (subject to rate limiting).

As editor of this document, it is absolutely clear to me that we are referring to the sub-TLV and not the prefix advertisement. So, when the value is set to 0, the sub-TLV is invalid and ignored
 - the prefix reachability is not at all affected.


This is the reason why I am firmly opposed to using Prefix Originator value 0 for UPA or any other indication.


 


I hope I am able to convince you :-)


 


Thanks,


Ketan


 


 


 


On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote:





To add to what Ketan has stated…
 
draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0
 to indicate unreachability.
For OSPF, this might be considered compatible with RFC 9084 where it is stated that advertisements with “Router ID field set to 0 MUST be considered invalid and ignored” - though
 Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times over the years, but my feedback was ignored.
 
Which is an example of why I would like to echo Ketan’s sentiments – let’s please put an end to this non-constructive discussion.
 
The authors of draft-wang have had many opportunities over the years to respond in a more constructive way to feedback. They were also – as Peter has indicated – given an opportunity
 to co-author draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing the problem space to the attention of the WG. They declined – which of course is their right. But they do not have the right to endlessly oppose the consensus of the WG.
 
Let’s please move on.
 
   Les
 
 



From: Lsr <lsr-boun...@ietf.org>
On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 3:01 PM
To: John Drake 40yahoo@dmarc.ietf.org>
Cc: Peter Psenak (ppsenak) <ppse...@cisco.com>; Aijun Wang <wangai...@tsinghua.org.cn>;
lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Aijun,

 


As your co-author on the OSPF Prefix Originator RFC, I have stated many times (e.g. [1]) that overloading semantics of Prefix Originator is not a good or clean protocol encoding.
 Semantically, it is wrong and a very bad protocol design in my opinion. Going by this logic, tomorrow, someone would want to encode some different meaning for all 1's value in the originator address. We cannot be doing such (IMHO) HACKS in the protocol encodings.


 


It is better to signal the semantics/meaning explicitly using specific flags that are meaningful.


 


The authors of draft-ppsenak (now a WG document) agreed to this feedback from WG members and incorporated the U/UP flags in their draft. However, the authors of draft-wang seem
 to continue to refuse to accept feedback. It is per

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Peter:

Let’s focus on the technical analysis/comparison for the mentioned issues, and 
don’t repeat the subjective comments that without any solid analysis.

Detail replies inline below.

Aijun Wang
China Telecom

> On Nov 6, 2023, at 14:53, Peter Psenak  wrote:
> 
> Aijun,
> 
> please see inline:
> 
>> On 06/11/2023 13:23, Aijun Wang wrote:
>> Hi, all:
>> 
>> Here are some technical questions for the hurry adopted draft about 
>> unreachable prefixes announcement:
>> 
>> 1) There exists already “prefix originator” sub-TLV to indicate the 
>> associated prefix is unreachable, what’s the advantage of using other 
>> undefined, to-be-standardized, to-be-implemented sub-TLV?
> 
> many people have already commented on why overloading the “prefix originator” 
> sub-TLV to signal unreachability is a bad idea. Please accept that feedback.

[WAJ] No one gives the technical analysis. Can you explain technically in 
detail? 

You can set the prefix metric to LS-infinity to indicate the unreachability, 
why can’t we the prefix originator to NULL to indicate the 
unreachability?———The key idea for using “prefix originator” is here: if there 
is no router originate the associated prefix, then it is certainly unreachable. 
It is more straightforward than the LS_Infinity, and is also more easily 
implemented, deployed than the to-be-defined, to-be-standardized sub-TLV.

> 
>> 
>> 2) It is unnecessary to define the “UP” flag——if the operator know the 
>> unreachable event in advance, they can also schedule the switchover of the 
>> related services in advance. Why bother IGP to transfer such information?
> 
> looks like there are folks that see the value in it. I let them to comment 
> more, but I don't necessarily see a problem in an extra bit. If you don't 
> like it, don't use it.
> 
> 
>> 
>> 3) There is very limited usage of LS_Infinity in current network. From the 
>> operator’s viewpoint, we will decrease its usage also in future. Then the 
>> solution should try their best to avoid their usages——Current solutions 
>> instead enhance its usage——It is unacceptable. Let’s keep the network simple.
>> 
> the reasons for using the LSInfinity for unreachability has been discussed at 
> great length a;ready. It's the backward compatibility for routers not 
> supporting the new signalling - we need to avoid them interpreting the 
> unreachability as reachability.

[WAJ] My emphasis is that we shouldn’t enhance the usage of LS-Infinity(you 
propose that the LS-Infinity metric must be carried) Instead, we should try to 
fade them out:
1) If all routers within one area/domain all support the new capabilities, we 
need not require the summary LSA to carry LS-infinity metric.

2) The Maxage of LSA can also be used to achieve the similar effects of legacy 
node bypassing.

> 
> 
>> 4) We can’t ignore the partitions scenarios or let’s it go.
> 
> if you feel like the partition is the problem, you can write a separate draft 
> and address it there. We are NOT trying to solve it with UPA draft. And for a 
> reason.

[WAJ] They are coupled. If you don’t consider it now, you need to update your 
proposal later.

> 
> 
>> 
>> 5) There should be some mechanisms to control the volume of advertised 
>> unreachable information, when compared with reachable information, as done 
>> in 
>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.
> 
> 
> please look at the section 6 of the UPA draft.

[WAJ] I am referring to the balance advertisement of reachable information, as 
did in the above link, not the simple statement as the following: “It is also 
recommended that implementations limit the number of UPA advertisements which 
can be originated at a given time. “

Actually, even for your above statement, 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#name-deployment-considerations-4
 gives more guidelines, I think you can refer to it again.

> 
> thanks,
> Peter
> 
> 
>> 
>> Please consider the above technical issues carefully before evaluating and 
>> adopted any proposal.
>> 
>> If the above issues can’t be solved, we request the WG to adopt also the 
>> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which
>>  cover and solve all of the above issues.
>> 
>> Aijun Wang
>> China Telecom
> 
> 
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, all:

Here are some technical questions for the hurry adopted draft about unreachable 
prefixes announcement:

1) There exists already “prefix originator” sub-TLV to indicate the associated 
prefix is unreachable, what’s the advantage of using other undefined, 
to-be-standardized, to-be-implemented sub-TLV?

2) It is unnecessary to define the “UP” flag——if the operator know the 
unreachable event in advance, they can also schedule the switchover of the 
related services in advance. Why bother IGP to transfer such information?

3) There is very limited usage of LS_Infinity in current network. From the 
operator’s viewpoint, we will decrease its usage also in future. Then the 
solution should try their best to avoid their usages——Current solutions instead 
enhance its usage——It is unacceptable. Let’s keep the network simple.

4) We can’t ignore the partitions scenarios or let’s it go.

5) There should be some mechanisms to control the volume of advertised 
unreachable information, when compared with reachable information, as done in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.

Please consider the above technical issues carefully before evaluating and 
adopted any proposal.

If the above issues can’t be solved, we request the WG to adopt also the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which
 cover and solve all of the above issues.

Aijun Wang
China Telecom___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, John:

Thanks for your reply.
The key concerns for the issue is that although 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement 
has several advantages, it hasn't been given the adoption call until now. This 
is unfair and also our main appeal reason.

Considering there are two different approaches to solve some overlapping 
scenarios, I think we can consider to adopt both of them as WG documents, 
similar with actions of other WGs.
We can let the industry to select the final solution to implement and deploy 
within their networks.

We have enough energies to accomplish the final implementation and deployment.

Some detail responses are inline below.


Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 John 
Scudder
发送时间: 2023年11月1日 6:02
收件人: Aijun Wang 
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Hi Aijun,

I apologize for the length of time it’s taken me to respond to your request. 

Having now taken the time to study the question properly, including a review of 
both drafts in question, the WG adoption call, and the subsequent email, here’s 
my take.

In large part, your position appears to be based on historical precedence — 
your draft was published first. (This is your “follower solution… initiator” in 
the email I’m responding to, as well as the first three “which draft is the 
first” points in your follow-up.) This is true of course. Furthermore, although 
our formal process does not take into account such questions as “who came 
first?” I think it would be safe for me to say that people generally do try to 
do not just what’s required, but what’s right, in terms of acknowledging prior 
work. For this reason, I was a little surprised to see no acknowledgment of the 
contributions of your draft in draft-ppsenak. But I think such an 
acknowledgment — which is a norm, not a requirement — is the most you can 
expect for having published the first draft that covers the same general 
subject area as draft-ppsenak. This might also be a good time to remind you 
that draft-wang-lsr-prefix-unreachable-annoucement-00 includes the statement,

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

I encourage you to review BCP 78 if you haven’t recently.
【WAJ】In contrast, we include the above statement from the version 00: 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00,
 and also acknowledge the comments from Peter Psenak, Les Ginsberg, Bruno 
Decraene, Acee Lindem, Shraddha Hegde, Robert Raszuk, Tony Li, Jeff Tantsura 
and Tony Przygienda for their suggestions and comments on draft-wang.

In short, I’m not persuaded by the first-to-publish argument.
【WAJ】We are not advocating the fist-to-publish argument, but the first should 
be considered first for adoption call, or else, there must be reasonable 
explanations for not doing so.

The other major point made by you, and others advocating for the consideration 
of draft-wang as the WG solution and against draft-ppsenak, is that draft-wang 
is said to cover more cases. (This is “cover more scenarios” in your email, as 
well as point five, “cover more scenarios” in your follow-up.) There was some 
spirited debate about whether the draft does so successfully, or not, but I 
don’t want to take a position on that in this email. Rather, what I observe is 
that since these points were made clearly, and repeatedly, in the WG adoption 
email thread as well as at other times previously, it can’t be argued that the 
WG didn’t know that draft-wang claims to address (for example) area partition, 
and that draft-ppsenak explicitly doesn’t. So, this suggests those who 
supported the adoption of draft-ppsenak either implicitly, or explicitly, 
believed that the additional use cases draft-wang claims to address are not 
important. At least, not important to address in this draft, at this time, as 
part of this adopted WG work.
【WAJ】Prefix unreachable announcement is one general mechanism, the solution 
shouldn't be limited only on some narrow scopes. For standardization work, we 
should look further.

In your follow-up, you also proposed that “which explicit signaling mechanism 
is simpler” should be a criterion (point four). In my experience, this kind of 
question seldom leads to a useful outcome since it’s so subjective. I will say 
however that many of the people who responded to the WG adoption call made it 
clear they had such considerations in mind, so I think there is good reason to 
think the WG has taken this question into account.
【WAJ】The adoption call is issued only for one approach, not both of them, then 
how can we get the above conclusions?

I also want to speak to the questions of whet

Re: [Lsr] 答复: 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, John:

What’s your responses to this issue and my proposal then?

We need your guidances.

Aijun Wang
China Telecom

> On Sep 20, 2023, at 17:22, Aijun Wang  wrote:
> 
> Hi, Acee, John:
> 
> My proposal to solve the issue is that we can discuss the merge possibility 
> for the contents and author list of WG document at the IETF 118 on-site 
> meeting.
> I think you (also LSR experts within the list) can't deny draft-ppsenk was 
> inspired by our draft. 
> It's unfair to ignore the adoption call of 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
>  
> 
> Detail replies are inline below. 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -邮件原件-
> 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年9月16日 1:16
> 收件人: Aijun Wang 
> 抄送: John Scudder ; Christian Hopps 
> ; lsr ; 
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; tom petch 
> 
> 主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
> Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
> 
> Aijun, John, 
> 
> Technical comments as WG member: 
> 
> See inline. 
> 
>> On Sep 15, 2023, at 3:08 AM, Aijun Wang  wrote:
>> 
>> Hi,John:
>> 
>> Thanks in advance for your review for the discussion within the mail list.
>> 
>> Normally, the WG adoption call decisions will be coordinated between the 
>> Chairs. That’s the reason that I sort the judgement directly from the AD.
>> 
>> If the previous results represents only Acee’s preference, we would like to 
>> ask Chris to review also all the discussions and expect Chris to solve my 
>> concerns that Acee didn’t convince me. 
>> 
>> The IETF community should respect the initiative idea and adoption decision 
>> should be made based on the facts.
>> 
>> Hi, Chris:
>> 
>> I have asked Acee the following questions 
>> (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/ )and 
>> would like to hear your feedback:
>>> 
>>> 
>>> 
>>> For the adoption call or merge efforts, I think the WG should consider the 
>>> following facts:
>>> 1) Which draft is the first to provide the use cases? 
> 
> Given that the WG agreed to solve a specific use case, this is irrelevant. 
> [WAJ] The specific use case is also first provided by 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 
>>> 2) Which draft is the first to propose explicit signaling for 
>>> unreachable information?
> 
> Since the mechanism in your draft use an assumption about the value of 
> prefix-originator, one could argue that it is not strictly explicit. 
> [WAJ] The meaning of newly defined special value of prefix-originator is 
> similar as the meaning of the newly defined flag. 
> 
> However, the first to provide backward-compatible notification focused on the 
> short-lived notification use case was the WG document. 
> [WAJ] I think you have noticed that there was one big conversion from the 
> first version of draft-ppsenk(implicit signaling only) to its latest 
> version(including explicit signaling also). The reason for the conversion is 
> that we insisted that the explicit signaling was the direction.
> 
>>> 3) Which draft is the first to propose short lived notification?
> 
> I believe Robert Raszuk was the first to bring up the use case on the LSR 
> list - well before it was included in any draft.  
> [WAJ] Would you or Robert Raszuk like to provide the link within the LSR list 
> to prove the above imagination? 
> 
>>> 4) Which explicit signaling mechanism is simpler?
> 
> The draft which the WG rallied behind is much cleaner and based on the WG 
> request for explicit unreachable flags. As I mentioned before, it is 
> backward-compatible. Your document also requires a capabilities advertisement 
> and different behavior depending on whether or not all routers in the area 
> support the mechanism (section 5). The WG document is clearly simpler. 
> [WAJ]There is already field to carry such information, it is redundancy to 
> define the flag again. And, the most important thing is that using the 
> existing field can provide the uniform explicit signaling methods for all the 
> IGP protocols, we needn't find different places to set and parse the flags in 
> different protocol. Which is simpler?
> The reason that we keep capabilities advertisement, as I explained in 
> https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48/ in 
> detail, is that we want to fade out the usage of LS

[Lsr] 答复: 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Tom:

My appeal is that it's unfair to ignore the draft that was put forward THREE 
years earlier than the follower, and we devote intense discussions for this 
topic along the process, but there is no adoption call. 


Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tom petch
发送时间: 2023年9月15日 18:41
收件人: Aijun Wang ; John Scudder 
; cho...@chopps.org
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

From: Aijun Wang 
Sent: 15 September 2023 08:08

Hi,John:

Thanks in advance for your review for the discussion within the mail list.

Normally, the WG adoption call decisions will be coordinated between the 
Chairs. That’s the reason that I sort the judgement directly from the AD.

If the previous results represents only Acee’s preference, we would like to ask 
Chris to review also all the discussions and expect Chris to solve my concerns 
that Acee didn’t convince me.

The IETF community should respect the initiative idea and adoption decision 
should be made based on the facts.

Aijun
The IETF community works on 'rough consensus and running code' to a greater or 
lesser extent.  The descriptions of our processes do not give hard and fast 
rules about what constitutes consensus and that flexibility is one of the 
strengths of the IETF.  Consensus is judged, by WG Chairs, AD, IESG, IAB, based 
on what the mailing lists contain.  The judgement can be  appealed.  The result 
can be one I-D going forward or two or none.  Here we currently have consensus 
declared for one I-D to go forward.

I hear you protest and see that as an implicit appeal but I am unclear what you 
are appealing. The appeal could be that consensus does not reflect what  
appeared on the list, that the consensus call was not properly made, that there 
should have been additional consensus calls and so on. 

You list facts and that is fine but they are only input to my and others' 
judgement which we then express in response to a consensus call.  The facts may 
persuade some, they may not persuade others but it is the summation of views 
expressed on the list  that determines the consensus, not facts.

Tom Petch

Hi, Chris:

I have asked Acee the following questions 
(https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/<https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/>
 )and would like to hear your feedback:

For the adoption call or merge efforts, I think the WG should consider the 
following facts:
1) Which draft is the first to provide the use cases?
2) Which draft is the first to propose explicit signaling for unreachable 
information?
3) Which draft is the first to propose short lived notification?
4) Which explicit signaling mechanism is simpler?
5) Which draft provides more mechanisms to cover more scenarios?

The base document should be selected based on the answers of the above 
questions.

John can also refer the above questions when reviewing the past discussions 
within the list.

Aijun Wang
China Telecom

On Sep 15, 2023, at 04:02, John Scudder  
wrote:

Tom is right of course, and thank you for pointing it out. (The specific 
section in RFC 2026 to look at is 6.5.1.)

In the meantime, I’ll review the mailing list discussion. However, the most 
desirable outcome would be to settle things at the WG level without further 
escalation.

—John

On Sep 14, 2023, at 12:25 PM, tom petch  wrote:

From: Lsr  on behalf of Aijun Wang 

Sent: 14 September 2023 11:38

Hi, Acee:

I admire your efforts for the LSR WG, but for the adoption call of this draft, 
you have not convinced me, although I gave you large amount of solid facts.
Then, it's time to let our AD to step in, to make the non-biased judgement, 
based on our discussions along the adoption call.



I think that what you have in mind is an appeal, as per RFC2026.

The first stage therein is to involve the Chairs, and while Acee is one, he is 
not the only one.

Have you involved the other Chair, on or off list? That would seem to me to be 
next step.

Tom Petch


We request the WG document be based on the 
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$
 , because it is the first document to initiate the use case, provide the 
explicit signaling mechanism, and cover more scenarios.

It’s unreasonable to adopt the follower solution and ignore the initiator. We 
started and lead the discussions THREE years earlier than the current proposal.

Aijun Wang
China Telecom

On Sep 8, 2023, at 23:16, Acee Lindem  wrote:

The WG adoption call has completed and there is more than sufficient support 
for adoption.
What

[Lsr] 答复: 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee, John:

My proposal to solve the issue is that we can discuss the merge possibility for 
the contents and author list of WG document at the IETF 118 on-site meeting.
I think you (also LSR experts within the list) can't deny draft-ppsenk was 
inspired by our draft. 
It's unfair to ignore the adoption call of 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
 

Detail replies are inline below. 

Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月16日 1:16
收件人: Aijun Wang 
抄送: John Scudder ; Christian Hopps 
; lsr ; 
draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; tom petch 

主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Aijun, John, 

Technical comments as WG member: 

See inline. 

> On Sep 15, 2023, at 3:08 AM, Aijun Wang  wrote:
> 
> Hi,John:
> 
> Thanks in advance for your review for the discussion within the mail list.
> 
> Normally, the WG adoption call decisions will be coordinated between the 
> Chairs. That’s the reason that I sort the judgement directly from the AD.
> 
> If the previous results represents only Acee’s preference, we would like to 
> ask Chris to review also all the discussions and expect Chris to solve my 
> concerns that Acee didn’t convince me. 
> 
> The IETF community should respect the initiative idea and adoption decision 
> should be made based on the facts.
> 
> Hi, Chris:
> 
> I have asked Acee the following questions 
> (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/ )and 
> would like to hear your feedback:
>> 
>> 
>> 
>> For the adoption call or merge efforts, I think the WG should consider the 
>> following facts:
>> 1) Which draft is the first to provide the use cases? 

Given that the WG agreed to solve a specific use case, this is irrelevant. 
[WAJ] The specific use case is also first provided by 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/

>> 2) Which draft is the first to propose explicit signaling for 
>> unreachable information?

Since the mechanism in your draft use an assumption about the value of 
prefix-originator, one could argue that it is not strictly explicit. 
[WAJ] The meaning of newly defined special value of prefix-originator is 
similar as the meaning of the newly defined flag. 

However, the first to provide backward-compatible notification focused on the 
short-lived notification use case was the WG document. 
[WAJ] I think you have noticed that there was one big conversion from the first 
version of draft-ppsenk(implicit signaling only) to its latest 
version(including explicit signaling also). The reason for the conversion is 
that we insisted that the explicit signaling was the direction.

>> 3) Which draft is the first to propose short lived notification?

I believe Robert Raszuk was the first to bring up the use case on the LSR list 
- well before it was included in any draft.  
[WAJ] Would you or Robert Raszuk like to provide the link within the LSR list 
to prove the above imagination? 

>> 4) Which explicit signaling mechanism is simpler?

The draft which the WG rallied behind is much cleaner and based on the WG 
request for explicit unreachable flags. As I mentioned before, it is 
backward-compatible. Your document also requires a capabilities advertisement 
and different behavior depending on whether or not all routers in the area 
support the mechanism (section 5). The WG document is clearly simpler. 
[WAJ]There is already field to carry such information, it is redundancy to 
define the flag again. And, the most important thing is that using the existing 
field can provide the uniform explicit signaling methods for all the IGP 
protocols, we needn't find different places to set and parse the flags in 
different protocol. Which is simpler?
The reason that we keep capabilities advertisement, as I explained in 
https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48/ in 
detail, is that we want to fade out the usage of LSInfinity in future. We 
should keep and put forward the deployment of such mechanism in simple format 
or direction, don't make the network operation more complex.

>> 5) Which draft provides more mechanisms to cover more scenarios?

While you purport to support multiple use cases, they conflict with one 
another. For example, the use cases which require a change in OSPF 
advertisement by the other ABR(s) would require knowledge as long as the prefix 
is unreachable. You also have section 7 which is relevant to persistent 
notification and not the short-lived notification agreed upon by the WG. 
[WAJ] It is not enough to consider only the sender mechani

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi,John:Thanks in advance for your review for the discussion within the mail list.Normally, the WG adoption call decisions will be coordinated between the Chairs. That’s the reason that I sort the judgement directly from the AD.If the previous results represents only Acee’s preference, we would like to ask Chris to review also all the discussions and expect Chris to solve my concerns that Acee didn’t convince me. The IETF community should respect the initiative idea and adoption decision should be made based on the facts.Hi, Chris:I have asked Acee the following questions (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/ )and would like to hear your feedback:For the adoption call or merge efforts, I think the WG should consider the following facts:1) Which draft is the first to provide the use cases? 2) Which draft is the first to propose explicit signaling for unreachable information?3) Which draft is the first to propose short lived notification?4) Which explicit signaling mechanism is simpler?5) Which draft provides more mechanisms to cover more scenarios?The base document should be selected based on the answers of the above questions. John can also refer the above questions when reviewing the past discussions within the list.Aijun WangChina TelecomOn Sep 15, 2023, at 04:02, John Scudder  wrote:Tom is right of course, and thank you for pointing it out. (The specific section in RFC 2026 to look at is 6.5.1.)In the meantime, I’ll review the mailing list discussion. However, the most desirable outcome would be to settle things at the WG level without further escalation.—JohnOn Sep 14, 2023, at 12:25 PM, tom petch  wrote:From: Lsr  on behalf of Aijun Wang Sent: 14 September 2023 11:38Hi, Acee:I admire your efforts for the LSR WG, but for the adoption call of this draft, you have not convinced me, although I gave you large amount of solid facts.Then, it's time to let our AD to step in, to make the non-biased judgement, based on our discussions along the adoption call.I think that what you have in mind is an appeal, as per RFC2026.The first stage therein is to involve the Chairs, and while Acee is one, he is not the only one.Have you involved the other Chair, on or off list? That would seem to me to be next step.Tom PetchWe request the WG document be based on the https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$ , because it is the first document to initiate the use case, provide the explicit signaling mechanism, and cover more scenarios.It’s unreasonable to adopt the follower solution and ignore the initiator. We started and lead the discussions THREE years earlier than the current proposal.Aijun WangChina TelecomOn Sep 8, 2023, at 23:16, Acee Lindem  wrote:The WG adoption call has completed and there is more than sufficient support for adoption.What’s more, vendors are implementing and operators are planning of deploying the extensions.Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00.A couple of WG members, while acknowledging the use case, thought that it would be better satisfied outside of the IGPs.In fact, they both offered other viable alternatives. However, with the overwhelming support and commitment to implementationand deployment, we are going forward with WG adoption of this document. As the Co-Chair managing the adoption, I don’t seethis optional mechanism as fundamentally changing the IGPs.There was also quite vehement opposition from the authors of draft-wang-lsr-prefix-unreachable-annoucement. This draftpurports to support the same use case as well as others (the archives can be consulted for the discussion). Further discussionof this other draft and the use cases it addresses should be in the context of draft-wang-lsr-prefix-unreachable-annoucementand not the WG draft.Thanks,AceeOn Aug 23, 2023, at 3:58 PM, Acee Lindem  wrote:LSR Working Group,This begins the working group adoption call for “IGP Unreachable Prefix Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.Please indicate your support or objection on this list prior to September 7th, 2023.Thanks,Acee___Lsr mailing listLsr@ietf.orghttps://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$___Lsr mailing listLsr@ietf.orghttps://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:

I admire your efforts for the LSR WG, but for the adoption call of this draft, 
you have not convinced me, although I gave you large amount of solid facts.
Then, it's time to let our AD to step in, to make the non-biased judgement, 
based on our discussions along the adoption call.

We request the WG document be based on the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
 because it is the first document to initiate the use case, provide the 
explicit signaling mechanism, and cover more scenarios.

It’s unreasonable to adopt the follower solution and ignore the initiator. We 
started and lead the discussions THREE years earlier than the current proposal.

Aijun Wang
China Telecom

> On Sep 8, 2023, at 23:16, Acee Lindem  wrote:
> 
> The WG adoption call has completed and there is more than sufficient support 
> for adoption. 
> What’s more, vendors are implementing and operators are planning of deploying 
> the extensions. 
> Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00. 
> 
> A couple of WG members, while acknowledging the use case, thought that it 
> would be better satisfied outside of the IGPs. 
> In fact, they both offered other viable alternatives. However, with the 
> overwhelming support and commitment to implementation
> and deployment, we are going forward with WG adoption of this document. As 
> the Co-Chair managing the adoption, I don’t see
> this optional mechanism as fundamentally changing the IGPs. 
> 
> There was also quite vehement opposition from the authors of 
> draft-wang-lsr-prefix-unreachable-annoucement. This draft
> purports to support the same use case as well as others (the archives can be 
> consulted for the discussion). Further discussion
> of this other draft and the use cases it addresses should be in the context 
> of draft-wang-lsr-prefix-unreachable-annoucement
> and not the WG draft.
> 
> Thanks,
> Acee 
> 
>> On Aug 23, 2023, at 3:58 PM, Acee Lindem  wrote:
>> 
>> LSR Working Group,
>> 
>> This begins the working group adoption call for “IGP Unreachable Prefix 
>> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
>> Please indicate your support or objection on this list prior to September 
>> 7th, 2023. 
>> 
>> Thanks,
>> Acee
> 
> 
> ___
> 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] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:

 

It‘s you that repeat the FALSE statements. What I can do is to give you the 
FACT again.

Please see inline below for the response to your FALSE statements.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: Acee Lindem [mailto:acee.i...@gmail.com] 
发送时间: 2023年9月6日 20:44
收件人: Aijun Wang 
抄送: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04

 

Hi Aijun, 

 

I think we are repeating ourselves here. However, let me add a couple points. 
The fact that you added the BGP PIC use case to your draft when the WG 
indicated that was the problem to be solved doesn’t make you the owner of the 
use case. 

[WAJ] FALSE Statement.

I have replied you for such FALSE assertions at 
https://mailarchive.ietf.org/arch/msg/lsr/I1Hb28F1Fg8GrPTynJa1ZYqtY0Y/ (Aug.25 
2023) , but you raised it again. 

Please provide the fact that “WG indicated that was the problem to be solved” 
before our proposal.  For your convenience, I replied again in detail below:

 

Please read carefully the description in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00#section-3
 (Proposed in Oct.24, 2019)

"In another situation, assume the BGP session is built between Node S2

   and T2, via Ps2 and Pt2 respectively.  If Node S2 within area 1

   become unreachable, the unreachable information can't be advertised

   to Node T2 because the summary behaviour on border router R1/R3.  The

   BGP session between S1 and T2 will be kept until the BGP keepalive

   timeout or other detection mechanism takes effect.  During this

   period, the BGP traffic to Node S2 will be in black hole."

 

Additionally, the fact that you were offered authorship on the draft under 
adoption is a recognition that you did have a draft the addressed IGP 
unreachability. However, you declined.

[WAJ] We provide first the use cases, insist that the explicit signaling 
solution is the direction and lead the discussions within LSR WG, the adoption 
draft should be based on 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement,
 not the follower.

 

Finally, even after appropriating some of the elements of the draft under 
adoption (e.g., unreachable metrics and configuration of LSA life) your draft 
is now a superset of the former draft and, IMO, unimplementable.

 

[WAJ] FALSE Statement. 

For the configuration of LSA Life, I have replied you at 
https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/, please 
do not repeat it again. For your convenience, let me emphasize the FACT again:

1) The description about the short lived notification in  
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>
 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 was on March 26, 2021

2) The similar description, even the 00 version of  
<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was 
submitted on July 5, 2021

Then, which draft appropriates which draft?

 

For the unreachable metrics, the usages of the two drafts are different: 
draft-ppsenak used such information as implicit signaling(“This functionality 
can be used to advertise a prefix (IPv4 or IPv6) in a manner which indicates 
that reachability has been lost”), we used it to solve the interoperable issue 
with the legacy router(“the prefix advertised with such metric value will not 
be considered during the normal SPF computation)” which is the original usage 
that defined in relevant RFCs)

It is after our insists and intense discussions, draft-ppsenak switched to the 
explicit signaling(by defining new flags, which is still arguable). It is now 
the superset of the implicit signaling and explicit signaling, which is 
unnecessary.

 

Thanks,

Acee 

 





On Sep 6, 2023, at 01:56, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi, Acee:

 

AGAIN, before making some assertions, please check the following fact:

Have you noticed the 00 version of  
<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was 
submitted on July 5, 2021?

But the description about the short lived notification in  
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7>
 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 was on March 26, 2021.

Then, which draft was the first?

 

For the adoption call or merge efforts, I think the WG should consider the 
following facts:

1) Which draft is the first to provide the use c

Re: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Peter:Aijun WangChina TelecomOn Sep 6, 2023, at 15:57, Peter Psenak  wrote:Aijun,WG adoption should be done based on the draft content, the quality of the solution it describes and not based on the draft age or order.[WAJ] Not exactly. We should also respect the original contributions.Multiple people have pointed out over the years that the solution that you propose in your draft - e.g. using router-id of 0 to indicate the unreachability is broken and lacks the backward compatibility aspect. Your original draft did NOT include the unreachable metric and even though you added it later (way after it was proposed in the other draft), your draft still uses the original router-id 0 idea. The fact that you need the PUAM Capabilities Announcement in your draft speaks for itself.[WAJ] The reason that we keep the “PUAM Capabilities Announcement” is that we want to fade-out the usage of “LSInfinity” Metric within the network,  as described in the draft:If not all of nodes within one area support the PUAM capabilities, the PUAM message should be advertised with the associated prefix cost set to LSInfinity. According to the description in [RFC2328], [RFC5305] and [RFC5308], the prefix advertised with such metric value will not be considered during the normal SPF computation, then such additional information will avoid the misbehavior of the nodes when they don't recognize the PUAM message.If all of nodes within one area support the PUAM capabilities, the PUAM message can be safely advertised without the additional LSInfinity metric information.In the latest version of your draft, you have stated also that there maybe other cases to use such metrics:Even though in all cases the treatment of such metric, or NU-bit, is specified for IS-IS, OSPF and OSPFv3, having an explicit way to signal that the prefix was advertised in order to signal unreachability is required to distinguish it from other cases where the prefix with such metric is advertised.In your proposal, the LSInfinity metric must be set even all the nodes within the area have the capabilities to understand the explicit signaling mechanism. There will be more confusions when other cases of LSInfinity usage proposed.As explained previously, set the existing original router id to NULL is one simple, uniform way to express unreachable information for OSPFv2/v3 and IS-IS. We needn’t find the different places to define and flag it for different protocol. Isn’t it more easier for the implementation?It’s also straightforward to understand.Though you may have been the first one to try to solve the problem in the IETF draft, your solution is still incorrect. As a result of your inability to listen to the comments an alternative draft was written that is technically superior, backward compatible, has wide support from vendors as well as operators, including ones that were originally co-authors on your draft and decided to join the alternate draft based on its technical advantages, has been implemented and deployed in the field.[WAJ]There are other reasons for the switch over of co-author, I think we needn’t expand or refer to it. The standard is not the technical implementation of one company. The standard should look forward further the scenarios, deployment considerations and solutions coverages.As a matter of fact, I have invited you to join our draft several times, but you refused. You insisted on pushing your draft.[WAJ] I have proposed several times the merger of two drafts, we can discuss the contents and structure of the converged document. It’s pity that we missed the IETF117 on-site meeting. But it’s also hurry to put forward only your draft when we consider the history, contributions and similarities of two proposals.My proposal is that we postpone the adoption of this draft, and discuss offline the merger document on the coming IETF118 meeting. Then, we can submit the merged document to the LSR WG for adoption call.my 2c,PeterOn 06/09/2023 07:56, Aijun Wang wrote:Hi, Acee:AGAIN, before making some assertions, please check the following fact:Have you noticed the 00 version of https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/  was submitted on July 5, 2021?But the description about the short lived notification in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7  was on March 26, 2021.Then, which draft was the first?For the adoption call or merge efforts, I think the WG should consider the following facts:1)Which draft is the first to provide the use cases?2)Which draft is the first to propose explicit signaling for unreachable information?3)Which draft is the first to propose short lived notification?4)Which explicit signaling mechanism is simpler?5)Which draft provides more mechanisms to cover more scenarios?The base document should be selected based on the answers of the above questions.Select the base document doesn’t mean that it can’t be changed before the adoption(I haven’t said

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:

 

AGAIN, before making some assertions, please check the following fact:

Have you noticed the 00 version of 
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was 
submitted on July 5, 2021?

But the description about the short lived notification in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7
 was on March 26, 2021.

Then, which draft was the first?

 

For the adoption call or merge efforts, I think the WG should consider the 
following facts:

1) Which draft is the first to provide the use cases? 

2) Which draft is the first to propose explicit signaling for unreachable 
information?

3) Which draft is the first to propose short lived notification?

4) Which explicit signaling mechanism is simpler?

5) Which draft provides more mechanisms to cover more scenarios?

 

The base document should be selected based on the answers of the above 
questions. 

Select the base document doesn’t mean that it can’t be changed before the 
adoption(I haven’t said “Without Change” is the merge condition). 

Actually, we welcome more authors to join us to finalize the document and 
solution.

 

As one of the most important WG within IETF, I think LSR WG should respect the 
original contributions to the WG.

It is too hurry to consider or adopt only the draft that you prefer, especially 
the follower draft.

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月6日 0:56
收件人: Aijun Wang 
抄送: Robert Raszuk ; Les Ginsberg (ginsberg) 
; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04

 

 

Hi Aijun, 

 

When the WG discussion first indicated that this was a use case that needed to 
be addressed, I don’t dispute that you immediately added it to your draft. 

I have no doubt you would have purported support of any use case under 
discussion. 

 

However, the first draft to address this use case with a short-lived 
notification was  
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/

Based on WG feedback and collaboration of multiple vendors, this draft evolved 
to draft-ppsenak-lsr-igp-ureach-prefix-announce. 

 

While you’ve incorporated elements of the draft under discussion, your draft 
still includes pieces (sometimes conflicting) from previous use cases.

 

There was an effort to merge the drafts but you declined unless your draft was 
used (without change) as the base. I’m not sure your motivation. 

 

Thanks,

Acee

 

 





On Sep 1, 2023, at 20:25, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi, Acee:

 

Act as LSR chair, I think you should be more responsible to make any unfounded 
assertions:

 

We have described the previous statements in

https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7,
 March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)

 

Then, which draft copy or incorporate which draft?

 

Aijun Wang

China Telecom





On Sep 1, 2023, at 20:05, Acee Lindem mailto:acee.i...@gmail.com> > wrote:

Hi Aijun, 





On Aug 31, 2023, at 23:36, Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

 

Hi，Acee:

 

Please read  
<https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7>
 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
 before making misguide assertions:

 

“The advertisement of PUAM message should only last one configurable period to 
allow the services that run on the failure prefixes are switchovered.”

 

 

I guess I haven’t kept up with all the elements of the draft under adoption 
that you continue to incorporate into your draft. This has been a continuing 
theme since initial discussed of the application signaling use case. While I 
have no interest in improving your draft, making the LSP/LSA short-lived 
conflicts with the other scenarios your draft purports to address. 

 

Acee

 





 

Best Regards

 

Aijun Wang

China Telecom

 

发件人:  <mailto:lsr-boun...@ietf.org> lsr-boun...@ietf.org [ 
<mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月1日 0:50
收件人: Robert Raszuk < <mailto:rob...@raszuk.net> rob...@raszuk.net>
抄送: Les Ginsberg (ginsberg) < <mailto:ginsberg=40cisco@dmarc.ietf.org> 
ginsberg=40cisco@dmarc.ietf.org>; Huzhibo < 
<mailto:huzhibo=40huawei@dmarc.ietf.org> 
huzhibo=40huawei@dmarc.ietf.org>; Peter Psenak < <mailto:ppse...@cisco.com> 
ppse...@cisco.com>; linchangwang < <mailto:linchangwang.04...@h3c.com> 
linchangwang.04...@h3c.com>; lsr < <mailto:lsr@ietf.org> lsr@ietf.org>
主题: Re:

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi, Acee:Act as LSR chair, I think you should be more responsible to make any unfounded assertions:We have described the previous statements inhttps://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7, March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022)Then, which draft copy or incorporate which draft?Aijun WangChina TelecomOn Sep 1, 2023, at 20:05, Acee Lindem  wrote:Hi Aijun, On Aug 31, 2023, at 23:36, Aijun Wang  wrote:Hi，Acee: Please read https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7 before making misguide assertions: “The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered.”I guess I haven’t kept up with all the elements of the draft under adoption that you continue to incorporate into your draft. This has been a continuing theme since initial discussed of the application signaling use case. While I have no interest in improving your draft, making the LSP/LSA short-lived conflicts with the other scenarios your draft purports to address. Acee Best Regards Aijun WangChina Telecom 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem发送时间: 2023年9月1日 0:50收件人: Robert Raszuk <rob...@raszuk.net>抄送: Les Ginsberg (ginsberg) <ginsberg=40cisco@dmarc.ietf.org>; Huzhibo <huzhibo=40huawei@dmarc.ietf.org>; Peter Psenak <ppse...@cisco.com>; linchangwang <linchangwang.04...@h3c.com>; lsr <lsr@ietf.org>主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04  On Aug 31, 2023, at 12:32, Robert Raszuk <rob...@raszuk.net> wrote: Hi Acee, In any case, one will need to update the signaling routers and the routers acting on the signal.  I guess this is clear to all.  Additionally, your request for the adoption was that the draft have a stronger statement about the mechanism being used for solely for signaling for applications (e.g., BGP PIC). As to the applicability my comment was that either draft should state in strong normative language that this is applicable only to applications which data plane uses encapsulation to the next hop.  Said this draft-wang introduces the additional signalling, sort of trying to assure that all nodes in an area understand the new messages - but I am not sure if even advertising PUAM capability means that it will be actually used for all destinations ?  No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral signal which the WG agreed was a valid use case, in the other draft, the LSAs are long-lived and are also may be used for other purposed than signaling (e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting with a whole different use case but selectively added mechanisms from ppsenak-lsr…  I seem to recall you were a strong proponent of limiting the scope.   By responding to this Email inline, some may believe you support the assertion that we should start the adoption of both drafts. Please be clarify this. Well the way I see this is that adoption call is a bit more formal opportunity for WG members to express their opinion on any document. But maybe LSR (for good reasons) have different internal rules to decide which document should be subject to WG adoption and does sort of pre-filtering.  If adoption call proves document has negative comments or lacks cross vendor support it simply does not get adopted.  Maybe I am just spoiled looking at how IDR WG process works :-)  You replied to an Email inline suggesting adoption of both drafts. That is what I think could have been misconstrued - especially by those who didn’t follow the discussion until now who think you are agreeing with this recommendation.    As for your other comment that this could be accomplished with BGP or an out-of-bound mechanism, that is true but that could be true of many problem. However, the solution under adoption has running code and wide vendor support.  Right ... As I wrote to Peter - perhaps this is just a pragmatic approach and flooding is what link state uses so be it.  As you know I did try in the past to propose BGP Aggregate withdraw but then feedback of the community was that PEs do not go down that often to justify the extension.  Hmm… We seem to have broad support for the LSR application signaling use case.  Thanks,Acee  Best,Robert  ___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

Hi，Acee:

 

Please read 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7
 before making misguide assertions:

 

“The advertisement of PUAM message should only last one configurable period to 
allow the services that run on the failure prefixes are switchovered.”

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年9月1日 0:50
收件人: Robert Raszuk 
抄送: Les Ginsberg (ginsberg) ; Huzhibo 
; Peter Psenak ; 
linchangwang ; lsr 
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04

 

 





On Aug 31, 2023, at 12:32, Robert Raszuk mailto:rob...@raszuk.net> > wrote:

 

Hi Acee,

 

In any case, one will need to update the signaling routers and the routers 
acting on the signal. 

 

I guess this is clear to all. 

 

Additionally, your request for the adoption was that the draft have a stronger 
statement about the mechanism being used for solely for signaling for 
applications (e.g., BGP PIC).

 

As to the applicability my comment was that either draft should state in strong 
normative language that this is applicable only to applications which data 
plane uses encapsulation to the next hop. 

 

Said this draft-wang introduces the additional signalling, sort of trying to 
assure that all nodes in an area understand the new messages - but I am not 
sure if even advertising PUAM capability means that it will be actually used 
for all destinations ? 

 

No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral 
signal which the WG agreed was a valid use case, in the other draft, the LSAs 
are long-lived and are also may be used for other purposed than signaling 
(e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting 
with a whole different use case but selectively added mechanisms from 
ppsenak-lsr… 

 

I seem to recall you were a strong proponent of limiting the scope. 

 





 

By responding to this Email inline, some may believe you support the assertion 
that we should start the adoption of both drafts. Please be clarify this.

 

Well the way I see this is that adoption call is a bit more formal opportunity 
for WG members to express their opinion on any document. But maybe LSR (for 
good reasons) have different internal rules to decide which document should be 
subject to WG adoption and does sort of pre-filtering. 

 

If adoption call proves document has negative comments or lacks cross vendor 
support it simply does not get adopted. 

 

Maybe I am just spoiled looking at how IDR WG process works :-) 

 

You replied to an Email inline suggesting adoption of both drafts. That is what 
I think could have been misconstrued - especially by those who didn’t follow 
the discussion until now who think you are agreeing with this recommendation.  

 





 

As for your other comment that this could be accomplished with BGP or an 
out-of-bound mechanism, that is true but that could be true of many problem. 
However, the solution under adoption has running code and wide vendor support.

 

 Right ... As I wrote to Peter - perhaps this is just a pragmatic approach and 
flooding is what link state uses so be it. 

 

As you know I did try in the past to propose BGP Aggregate withdraw but then 
feedback of the community was that PEs do not go down that often to justify the 
extension. 

 

Hmm… We seem to have broad support for the LSR application signaling use case. 

 

Thanks,

Acee

 





 

Best,

Robert

 

 

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

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Aijun Wang]

Hi, Les:

 

Please do not mislead the experts within the LSR.

Detail replies are inline below.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg 
(ginsberg)
发送时间: 2023年8月31日 22:49
收件人: Huzhibo ; Peter Psenak (ppsenak) 
; linchangwang ; Acee Lindem 
; lsr 
抄送: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-unreach-prefix-announce-04

 

Zhibo –

 

[Zhibo:] draft-wang-lsr-prefix-unreachable-annoucement doesn`t use “Router ID = 
0” to implement backward compatibility. It only provides two options: 
capability negotiation and MAX metric. When capability negotiation changes, 
there is no requirement to update the MAX metric value. It can be retained.

 

[LES:] Indeed. What you are saying is that max-metric is sufficient.

[WAJ-1]: max-metric is used to let the legacy router ignore the LSA that with 
“Router ID==0”. 

Which means there is no need for “Router ID == 0”.

[WAJ]: “Router ID==0” is the explicit signaling that the associated prefix is 
unreachable

Which also means there is no need for advertising the new Router Capability.

[WAJ]: The advertising of new router capability can optimize the advertising of 
unreachable information. If all the routers within the area can understand the 
meaning of “Router ID==0”, it is unnecessary to associate it with the 
“max-metric”. 

 

Which means that the solution defined in draft-ppsenak is all that is needed – 
there is no need for any of the protocol extensions defined in draft-wang.

Which means there is no need for draft-wang..

[WAJ] The core part of solution defined in draft-ppsenak is explicit 
unreachable signaling, which is first initiated by draft-wang---From the 
current version of the draft-ppsenak, we can also observe its evolution history:

 
<https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-04#section-2>
 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-04#section-2
 and

 
<https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-04#section-3>
 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-04#section-3

describes the max-metric is enough(implicit signaling ), but  
<https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-04#section-5>
 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-04#section-5

overthrow it, indicate that the explicit signaling is necessary.

 

If the above section 2 and section 3 are correct, then according to your logic, 
no new protocol extension, no need for draft-ppsenakI want to remind you 
that the first version of draft-ppsenak aimed to informational track.( 
<https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00>
 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00)

If the above section 5 is correct, then section 2 and section 3 is not 
necessary. We should focus on comparing which explicit signaling method is 
optimal, although explicit signaling mechanism is initiated first by draft-wang.

 

> Both two draft used The 0xFE00 metric indicates that the prefix is not

> reachable. Doesn't make a difference at this point.

 

[LES:] The solution defined in draft-ppsenak-lsr-igp-unreach-prefix-announce 
does not introduce any interoperability issues with existing routers, does not 
require multiple encoding formats, and does not require a router to regenerate 
advertisements in a different form based on the state of support by all routers 
in the network.

I think this makes a big difference. 

[Zhibo:] The same applies to draft-wang-lsr-prefix-unreachable-annoucement, 
which is not the main difference between the two documents.

 

[LES:] This is hardly true.

Draft-wang does introduce interoperability issue w legacy routers – which is 
why you had to introduce the new Router Capability advertisement.

Draft-wang does define multiple encoding formats.

Draft-wang does require routers to generate the unreachable advertisement in a 
format based upon the current state of support for PUAM in the network (read 
your own text in Section 5).

 

[WAJ]: please see the above 3rd inline explanation. 

 

   Les

 

Thanks

Zhibo

 

   Les

 

> 

> Thanks

> 

> Zhibo Hu

> 

> > -Original Message-

> > From: Lsr [ <mailto:lsr-boun...@ietf.org> mailto:lsr-boun...@ietf.org] On 
> > Behalf Of Les Ginsberg

> > (ginsberg)

> > Sent: Thursday, August 31, 2023 12:31 AM

> > To: Peter Psenak < <mailto:ppsenak=40cisco@dmarc.ietf.org> 
> > ppsenak=40cisco@dmarc.ietf.org>; linchangwang

> > < <mailto:linchangwang.04...@h3c.com> linch

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Aijun Wang]

Hi，Les:

 

The use of the max-metric is only to the let the legacy routers to ignore the 
PUAM message(the LSA that is advertised with the prefix originator set to 
NULL), to assure the interoperability with existing routers. It is same for 
both solutions.

The main difference for the explicit unreachability indication of the prefix, 
as Chang Wang summarized, is that one defined newly the prefix flag, another 
utilized the existing prefix originator field.

 

If the ABR finds the prefix is unreachable, then there will be no router 
advertise this prefix within the associated area, it is straightforward to 
label the “prefix originator” as NULL to indicate such information, then is it 
redundancy to define again the flag?  

 

Besides the above difference, we should consider also other scenarios that 
draft-ppsenak lacks but draft-wang has covered, as Zhibo indiciated in 
https://mailarchive.ietf.org/arch/msg/lsr/r-qLlA2JW-JOLVf_LBlEXwE01jE/

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg 
(ginsberg)
发送时间: 2023年8月31日 10:57
收件人: Huzhibo ; Peter Psenak (ppsenak) 
; linchangwang ; Acee Lindem 
; lsr 
抄送: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-unreach-prefix-announce-04

 

Zhibo -

 

Please see inline.

 

> -Original Message-

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

> Sent: Wednesday, August 30, 2023 6:33 PM

> To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com> 
> >; Peter Psenak (ppsenak)

> mailto:ppse...@cisco.com> >; linchangwang 
> mailto:linchangwang.04...@h3c.com> >;

> Acee Lindem mailto:acee.i...@gmail.com> >; lsr 
> mailto:lsr@ietf.org> >

> Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org 
> <mailto:draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org> 

> Subject: RE: [Lsr] Working Group Adoption of "IGP Unreachable Prefix

> Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

> 

> Hi Les:

> 

> I think you may have connected something. Existing routers, on receiving a

> prefix reachability advertisement with a

> U-Flag described in  
> <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
>  https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-

 
<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>
 > ureach-prefix-announce/ also will interpret that prefix as being reachable.

 

[LES:] This statement is incorrect.

RFC 5305 states:

 



If a prefix is advertised with a metric larger then MAX_PATH_METRIC

   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered

   during the normal SPF computation.  This allows advertisement of a

   prefix for purposes other than building the normal IP routing table.



 

(Equivalent statement in RFC 5308 for IPv6)

 

Existing implementations will ignore the advertisement purely on the basis of 
the metric value - this does not depend upon understanding the U bit.

 

But existing implementations will NOT ignore a prefix reachability 
advertisement just because it has a source Router ID set to 0 as 
draft-wang-lsr-prefix-unreachable-annoucement defines.

 

It is worth noting that AFTER the publication of 
draft-ppsenak-lsr-igp-pfx-reach-loss-00 in March 2022 (subsequently renamed as 
draft-ppsenak-lsr-igp-ureach-prefix-announce), the authors of 
draft-wang-lsr-prefix-unreachable-annoucement apparently realized they had  an 
interoperability problem with existing routers (something many of us had been 
highlighting for years) and in V10 (published in Jul 2022) an option was added 
to advertise using maximum metric (the solution already proposed by 
draft-ppsenak). But because the authors apparently didn’t want to abandon the 
use of "Router ID = 0", the new version of the draft proposed a dependency on 
how the unreachable prefix should be advertised. If all routers in the network 
indicated support for the new extension (indicated by yet another protocol 
extension - a new Router Capability sub-TLV for IS-IS) then the use of Router 
ID = 0 could be used, but if any router in the network did not advertise the 
new capability, then the use of max-metric is required. Which means the 
solution requires routers advertising unreachability to potentially regenerate 
the advertisement in a different form whenever the state of support by all 
routers in the network for the extension changes.

 

> Both two draft used The 0xFE00 metric indicates that the prefix is not

> reachable. Doesn't make a difference at this point.

 

[LES:] The solution defined in draft-ppsenak-lsr-igp-unreach-prefix-announce 
does not introduce any interoperability issues with existing rout

Re: [Lsr] Regd draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]

Hi, Ketan:You said that “there is still not workable… …” , should we refer to the latest version?https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ has evolved 13 versions to reflect the discussions on the list, then I am eager to know which part let you make the previous assertions?If there is no left issue, should we compare the current two proposals and select the simpler, more comprehensive and first initiated solution?Aijun WangChina TelecomOn Aug 29, 2023, at 22:45, Ketan Talaulikar  wrote:< changing subject so as not to hijack the ongoing WG adoption poll thread >Hi Aijun,One only needs to search the LSR WG archives for the discussions, comments and feedback given on draft-wang-lsr-prefix-unreachable-annoucement by many participants (including me) over the past many years to understand the problems with the solution in draft-wang. Checking the diffs across the 13 versions illustrate the history and evolution.I am unable to explain in ways other than what has been already done in the past threads.Thanks,KetanOn Tue, Aug 29, 2023 at 1:33 PM Aijun Wang <wangai...@tsinghua.org.cn> wrote:Hi, Ketan:Which part in https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ is not workable?I want to remind you again that it is the above draft initiates the problem first, insists that the explicit signaling was the direction, covers more scenarios that draft-ppsenak lacks stillSo, what’s the reason to adopt the follower, sub-optimal solution?Aijun WangChina TelecomOn Aug 28, 2023, at 20:20, Ketan Talaulikar <ketant.i...@gmail.com> wrote:Hi Acee/All,I support the adoption of this document by the WG. Several WG members have been actively involved in the development of this document for over a year now. The authors have included the feedback and as a result the solution has evolved very well.While there is another document [1] that tries to address the same problem statement, the solution in there is still not workable despite the feedback provided to its authors over the years. We need a workable IGP based solution.Overall, I find that the solution in draft-ppsenak:- is an IGP based solution and therefore in the charter or LSR WG- is a backward compatible solution that does not break existing IGP deployments running older software versions; it allows for incremental deployment/rollout- includes explicit indication of UPA which is more robust and more appropriate semanticallyGiven that the problem scenario is well acknowledged, there is running code for this solution, and we have feedback from operators who are interested in deploying this solution, I believe it is the time for the WG to adopt this document.Thanks,Ketan [1] https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/On Thu, Aug 24, 2023 at 1:37 AM Acee Lindem <acee.i...@gmail.com> wrote:LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 2023. 

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

___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr
___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Aijun Wang]

Hi, Ketan:Which part in https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ is not workable?I want to remind you again that it is the above draft initiates the problem first, insists that the explicit signaling was the direction, covers more scenarios that draft-ppsenak lacks stillSo, what’s the reason to adopt the follower, sub-optimal solution?Aijun WangChina TelecomOn Aug 28, 2023, at 20:20, Ketan Talaulikar  wrote:Hi Acee/All,I support the adoption of this document by the WG. Several WG members have been actively involved in the development of this document for over a year now. The authors have included the feedback and as a result the solution has evolved very well.While there is another document [1] that tries to address the same problem statement, the solution in there is still not workable despite the feedback provided to its authors over the years. We need a workable IGP based solution.Overall, I find that the solution in draft-ppsenak:- is an IGP based solution and therefore in the charter or LSR WG- is a backward compatible solution that does not break existing IGP deployments running older software versions; it allows for incremental deployment/rollout- includes explicit indication of UPA which is more robust and more appropriate semanticallyGiven that the problem scenario is well acknowledged, there is running code for this solution, and we have feedback from operators who are interested in deploying this solution, I believe it is the time for the WG to adopt this document.Thanks,Ketan [1] https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/On Thu, Aug 24, 2023 at 1:37 AM Acee Lindem  wrote:LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 2023. 

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

___Lsr mailing listLsr@ietf.orghttps://www.ietf.org/mailman/listinfo/lsr___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Aijun Wang]

Hi, Acee:

Please read carefully the description in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00#section-3:

"In another situation, assume the BGP session is built between Node S2
   and T2, via Ps2 and Pt2 respectively.  If Node S2 within area 1
   become unreachable, the unreachable information can't be advertised
   to Node T2 because the summary behaviour on border router R1/R3.  The
   BGP session between S1 and T2 will be kept until the BGP keepalive
   timeout or other detection mechanism takes effect.  During this
   period, the BGP traffic to Node S2 will be in black hole."

Considering the usage of "infinite metric", version 00 of the 
https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00
 took the implicit signaling approach, it wants to redefine the meaning of 
"infinite metric".  Only after the intense discussions, it switched to the 
explicit signaling approach(version 02, March 2023), which is the direction 
that 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
took from the beginning(version 00, October, 2019).

>From the above foundation information, I would like to hear why you can't 
>admit that draft 
>https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> is the first document that provide the problem and the explicit signaling 
>mechanism. 

Best Regards

Aijun Wang
China Telecom


-邮件原件-
发件人: Acee Lindem [mailto:acee.i...@gmail.com] 
发送时间: 2023年8月24日 23:46
收件人: Aijun Wang 
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

Speaking as WG member: 

> On Aug 24, 2023, at 04:59, Aijun Wang  wrote:
> 
> Object its adoption.
> 
> The reasons are the followings:
> 1) It is not the initial draft to describe the problem and provide the 
> solution. 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 2) The problem and the explicit signaling mechanism is firstly provided by in 
> its 00 version(October,2019), far earlier than the current proposal and its 
> 00 version(March, 2022).

Let me help you refresh your memory - the -00 version of this draft solved a 
completely different problem. The unreachability signaling to other 
applications (e.g., BGP PIC) was only added after publication of the draft 
under adoption. Over revisions, other aspects of the draft under adoption were 
also appropriated (e.g., using infinite metrics). So, your claims of being 
“first" are unfounded. Let’s stick to the technical differences between the 
drafts. 

Thanks,
Acee



> 3) Even after the proposed draft adopt the explicit signaling mechanism, it 
> still lacks other mechanisms that can cover more prefixes unreachable 
> scenarios, as stated in the 
> https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
> 
> The LSR WG should consider to adopt the more comprehensive and simple 
> solution, not the partial and complex design. 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> 
> -邮件原件-
> 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
> 发送时间: 2023年8月24日 4:07
> 收件人: lsr 
> 抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
> 主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
> draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)
> 
> LSR Working Group,
> 
> This begins the working group adoption call for “IGP Unreachable Prefix 
> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
> Please indicate your support or objection on this list prior to September 
> 7th, 2023. 
> 
> Thanks,
> Acee
> ___
> 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] 答复: Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

[Aijun Wang]

Object its adoption.

The reasons are the followings:
1) It is not the initial draft to describe the problem and provide the solution.
2) The problem and the explicit signaling mechanism is firstly provided by 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ 
in its 00 version(October,2019), far earlier than the current proposal and its 
00 version(March, 2022).
3) Even after the proposed draft adopt the explicit signaling mechanism, it 
still lacks other mechanisms that can cover more prefixes unreachable 
scenarios, as stated in the 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/

The LSR WG should consider to adopt the more comprehensive and simple solution, 
not the partial and complex design. 

Best Regards

Aijun Wang
China Telecom


-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem
发送时间: 2023年8月24日 4:07
收件人: lsr 
抄送: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - 
draft-ppsenak-lsr-igp-ureach-prefix-announce-04 (Fixed draft name)

LSR Working Group,

This begins the working group adoption call for “IGP Unreachable Prefix 
Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04.
Please indicate your support or objection on this list prior to September 7th, 
2023. 

Thanks,
Acee
___
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] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt

[Aijun Wang]

Hi, All Experts:

The main updates of this version is that we put the newly defined "OSPF
Stub-Link TLV" back into the Inter-AS-TE-v2 LSA and Inter-AS-TE-v3 LSA for
OSPFv2/v3 respectively.
Your comments are welcome.
We think it is ready for the WG adoption call then.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of
internet-dra...@ietf.org
Sent: Monday, June 5, 2023 9:32 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Link State Routing
(LSR) WG of the IETF.

   Title   : Advertisement of Stub Link Attributes
   Authors     : Aijun Wang
 Zhibo Hu
 Acee Lindem
 Gyan S. Mishra
 Jinsong Sun
   Filename: draft-wang-lsr-stub-link-attributes-07.txt
   Pages   : 13
   Date: 2023-06-04

Abstract:
   This document describes the mechanism that can be used to advertise
   the stub link attributes within the IS-IS or OSPF domain.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-07

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-wang-lsr-stub-link-attribute
s-07

Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts


___
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] PUA Converge Efforts(LSInfinity or MaxAge)

[Aijun Wang]

Hi, All:As discussed within the list, we have noticed there will be confusion for the usage/implementation/deployment of LSInfinity. Because the main motivation for this field is to let the legacy nodes bypass the PUA/UPA message, we propose use the MaxAge of the LSA to accomplish such task. The reasons are the following:1) RFC2328 has described the similar results for these two fields:   (1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.2) The PUA/UPA message is one PULSE message, it should not exist within the network long time. Exploitable this value is straightforward to be implemented/deployed.Aijun WangChina TelecomOn Mar 27, 2023, at 15:02, Aijun Wang  wrote:Hi, Bruno:Let me answer some questions from you based on the current PUA solution. From the inline replies, we think the converged draft should be based on PUA draft.Aijun WangChina TelecomOn Mar 27, 2023, at 14:00, bruno.decra...@orange.com wrote:









Hi
authors,
 
Please find below some questions.
 

Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1 with MAX metric.
 Is this prefix reachable or unreachable (or both)?[WAJ] This is the network partition scenario that we mentioned in the meeting, and also in the document.(UPA has no similar solution now)According to our considerations, the prefixes IP1 will be reachable via ABR1. This is the right answer for such situation.The contents for such situations are described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-11#section-4“When only some of the ABRs can't reach the failure node/link, as that described in Section 3.2, along with the PUAM message for the associated prefixe from these ABRs, the ABR that can reach the PUAM prefix should advertise the specific route to this prefix. The internal routers within another area can then bypass the ABRs that can't reach the PUAM prefix, to reach the prefix that advertised in PUAM message.”¶Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2 advertises
 IP1 with MAX metric does this count as UPA? (i.e. may a router advertise unreachability for a prefix advertised by another router?)[WAJ] In principle, the ABR that doesn’t send the summary address shouldn’t send the PUA/UPA message. So, normally, the ABR2 will not send such message with the MAX metric set.If it is sent out by ABR2 by any way, but not by ABR1, then it belongs to again the partition scenario(the receiver will know that it can reach such prefix via ABR1, not ABR2)Can you clarify the scope of the UPA signaling? E.g. if TLV 135 advertises prefix
 IP1 with MAX metric
does this signal UPA for all
FlexAlgo?If IS-IS Flexible Algorithm Prefix Metric is advertised, is MAX metric to be advertised
 in the main TLV, or per FAPM sub-TLV, or both? Can you specify the behavior in case on “inconsistencies”?Does this signal UPA If the summary address (aka the less specific prefix) is advertised
 in a different IS-IS instance or in a different protocol (e.g. OSPF, BGP…)?[WAJ] I think Peter can explain the above questions more clearly. Anyway, this is the reason that we mentioned during the meeting that we shouldn’t design the solution that relying heavily on the LSInfinity exploration.The less to depend on it, the better. That is the reason that we introduce the capabilities negotiation procedure(UPA based solution cannot be deployed without the dependency on the LSInfinity in future, this is unacceptable. The rely on the LSInfinity, or other bypass method should be only temporary)——once all the routers within the area support such capabilities, such feature will have no relation with the LSInfinity which may be used in other scenarios.
Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will trigger BGP PIC edge
 for 255 /32)[WAJ] In principle, the ABR send only the PUA information for /32 prefix. As stated in the PUA draft:Prefix Unreachable Announcementdatatracker.ietf.orgBased on such information, the ABR will only advertise the PUAM message when the tracked prefixes(for example, the loopback addresses of PEs that run BGP) that within the summary address is missing.For UPA of SRv6 locators for algo 0 or 1, is the MAX METRIC to be advertised for
 TLV 27 or 236 or both? Can you specify the behavior in case on “inconsistencies”?“a summary address which covers the prefix is being advertised by the ABR/ASBR”.
 For IS-IS, does the Attached bit count as a summary address or is it needed to advertise a summary address in IP reachability?[WAJ] The ABR should advertise a summary address. It’s the pre-condition to advertise the PUA/UPA message.
 
Ideally it would be good if the draft were updated to answer the above questions.[WAJ] We want to express again that the PUA solution is more thorough solution—covering more aspects than UPA solution, and is also earlier solution for this problem and should be the base for the future converge.There is also

Re: [Lsr] Interdomain UPA & UP Flag

[Aijun Wang]

The following sentence should be:
> If it is planned, why the overlay service being switched over as scheduled?

If it is planned, why doesn’t the overlay service be switched over as scheduled?




Aijun Wang
China Telecom

> On Mar 28, 2023, at 19:53, Aijun Wang  wrote:
> 
> There is no significant benefits to use the prefix unreachable announcement 
> mechanism to transfer the planned maintenance information.
> 
> If it is planned, why the overlay service being switched over as scheduled?
> 
> The PUA/UPA mechanism is mainly for the fast switchover of overlay services 
> upon the accident network failures.
> 
> Please pay more attentions to other aspects of such mechanism.
> 
> Aijun Wang
> China Telecom
> 
>>> On Mar 28, 2023, at 18:51, Peter Psenak 
>>>  wrote:
>>> 
>>> On 28/03/2023 11:41, Aijun Wang wrote:
>>> There is already overload bit to accomplish the maintenance purposes,
>>> Why do you guys repeat such work again?
>> 
>> OL-bit is only propagated inside the area. We are solving 
>> inter-area/inter-domain routing convergence here.
>> 
>> Peter
>> 
>>> Aijun Wang
>>> China Telecom
>>>>> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>>>>>  wrote:
>>>> 
>>>> Hi Robert,
>>>> 
>>>>> Second, if you say this is needed for BGP free deployments then I 
>>>>> question the merit on the basis that UPA is >ephemeral and expires say in 
>>>>> 120 sec which will not be enough for most planned maintenance work. So if 
>>>>> someone >insists to add UP Flag it should be not just a bit but also a 
>>>>> time or time delta from set UTC where it is expected that >provided 
>>>>> prefix will be down,
>>>> 
>>>> That is a good point that there should be a max-time associated with 
>>>> maintenance.
>>>> 
>>>> I do not think that this needs to be signaled in IGP. It can be a local 
>>>> configuration.
>>>> 
>>>> Rgds
>>>> 
>>>> Shraddha
>>>> 
>>>> Juniper Business Use Only
>>>> 
>>>> *From:* Lsr  *On Behalf Of *Robert Raszuk
>>>> *Sent:* Monday, March 27, 2023 1:36 PM
>>>> *To:* lsr 
>>>> *Subject:* [Lsr] Interdomain UPA & UP Flag
>>>> 
>>>> *[External Email. Be cautious of content]*
>>>> 
>>>> Hi,
>>>> 
>>>> I would like to get more clarification in respect to extending External 
>>>> LSAs for UPA. Area summary use case is pretty clear - but in case of 
>>>> redistribution (typical src of external LSAs) IMO we are going way too far 
>>>> with this. Let's all keep in mind that this is a pulse designed to trigger 
>>>> upper protocol switchover.
>>>> 
>>>> Needless to say that would work only via one hop by design as 
>>>> redistribution happens via RIB and by definition of UPA unreachable routes 
>>>> are not being installed in RIB in the first place.
>>>> 
>>>> On the apparently relative terms I do not see a need for the UP Flag. 
>>>> First planned maintenance should be solved by BGP protocol and there are 
>>>> already a number of tools in BGP allowing one to do it.
>>>> 
>>>> Second, if you say this is needed for BGP free deployments then I question 
>>>> the merit on the basis that UPA is ephemeral and expires say in 120 sec 
>>>> which will not be enough for most planned maintenance work. So if someone 
>>>> insists to add UP Flag it should be not just a bit but also a time or time 
>>>> delta from set UTC where it is expected that provided prefix will be down,
>>>> 
>>>> Kind regards,
>>>> 
>>>> R.
>>>> 
>>>> ___
>>>> 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] Interdomain UPA & UP Flag

[Aijun Wang]

There is no significant benefits to use the prefix unreachable announcement 
mechanism to transfer the planned maintenance information.

If it is planned, why the overlay service being switched over as scheduled?

The PUA/UPA mechanism is mainly for the fast switchover of overlay services 
upon the accident network failures.

Please pay more attentions to other aspects of such mechanism.

Aijun Wang
China Telecom

> On Mar 28, 2023, at 18:51, Peter Psenak  
> wrote:
> 
> On 28/03/2023 11:41, Aijun Wang wrote:
>> There is already overload bit to accomplish the maintenance purposes,
>> Why do you guys repeat such work again?
> 
> OL-bit is only propagated inside the area. We are solving 
> inter-area/inter-domain routing convergence here.
> 
> Peter
> 
>> Aijun Wang
>> China Telecom
>>>> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>>>>  wrote:
>>> 
>>> Hi Robert,
>>> 
>>> > Second, if you say this is needed for BGP free deployments then I 
>>> > question the merit on the basis that UPA is >ephemeral and expires say in 
>>> > 120 sec which will not be enough for most planned maintenance work. So if 
>>> > someone >insists to add UP Flag it should be not just a bit but also a 
>>> > time or time delta from set UTC where it is expected that >provided 
>>> > prefix will be down,
>>> 
>>> That is a good point that there should be a max-time associated with 
>>> maintenance.
>>> 
>>> I do not think that this needs to be signaled in IGP. It can be a local 
>>> configuration.
>>> 
>>> Rgds
>>> 
>>> Shraddha
>>> 
>>> Juniper Business Use Only
>>> 
>>> *From:* Lsr  *On Behalf Of *Robert Raszuk
>>> *Sent:* Monday, March 27, 2023 1:36 PM
>>> *To:* lsr 
>>> *Subject:* [Lsr] Interdomain UPA & UP Flag
>>> 
>>> *[External Email. Be cautious of content]*
>>> 
>>> Hi,
>>> 
>>> I would like to get more clarification in respect to extending External 
>>> LSAs for UPA. Area summary use case is pretty clear - but in case of 
>>> redistribution (typical src of external LSAs) IMO we are going way too far 
>>> with this. Let's all keep in mind that this is a pulse designed to trigger 
>>> upper protocol switchover.
>>> 
>>> Needless to say that would work only via one hop by design as 
>>> redistribution happens via RIB and by definition of UPA unreachable routes 
>>> are not being installed in RIB in the first place.
>>> 
>>> On the apparently relative terms I do not see a need for the UP Flag. First 
>>> planned maintenance should be solved by BGP protocol and there are already 
>>> a number of tools in BGP allowing one to do it.
>>> 
>>> Second, if you say this is needed for BGP free deployments then I question 
>>> the merit on the basis that UPA is ephemeral and expires say in 120 sec 
>>> which will not be enough for most planned maintenance work. So if someone 
>>> insists to add UP Flag it should be not just a bit but also a time or time 
>>> delta from set UTC where it is expected that provided prefix will be down,
>>> 
>>> Kind regards,
>>> 
>>> R.
>>> 
>>> ___
>>> 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] Interdomain UPA & UP Flag

[Aijun Wang]

There is already overload bit to accomplish the maintenance purposes,

Why do you guys repeat such work again?


Aijun Wang
China Telecom

> On Mar 28, 2023, at 18:00, Shraddha Hegde 
>  wrote:
> 
> 
> Hi Robert,
>  
> > Second, if you say this is needed for BGP free deployments then I question 
> > the merit on the basis that UPA is >ephemeral and expires say in 120 sec 
> > which will not be enough for most planned maintenance work. So if someone 
> > >insists to add UP Flag it should be not just a bit but also a time or time 
> > delta from set UTC where it is expected that >provided prefix will be down, 
>  
> That is a good point that there should be a max-time associated with 
> maintenance.
> I do not think that this needs to be signaled in IGP. It can be a local 
> configuration.
>  
> Rgds
> Shraddha
>  
>  
>  
> Juniper Business Use Only
> From: Lsr  On Behalf Of Robert Raszuk
> Sent: Monday, March 27, 2023 1:36 PM
> To: lsr 
> Subject: [Lsr] Interdomain UPA & UP Flag
>  
> [External Email. Be cautious of content]
>  
> Hi,
>  
> I would like to get more clarification in respect to extending External LSAs 
> for UPA. Area summary use case is pretty clear - but in case of 
> redistribution (typical src of external LSAs) IMO we are going way too far 
> with this. Let's all keep in mind that this is a pulse designed to trigger 
> upper protocol switchover. 
>  
> Needless to say that would work only via one hop by design as redistribution 
> happens via RIB and by definition of UPA unreachable routes are not being 
> installed in RIB in the first place. 
>  
> On the apparently relative terms I do not see a need for the UP Flag. First 
> planned maintenance should be solved by BGP protocol and there are already a 
> number of tools in BGP allowing one to do it. 
>  
> Second, if you say this is needed for BGP free deployments then I question 
> the merit on the basis that UPA is ephemeral and expires say in 120 sec which 
> will not be enough for most planned maintenance work. So if someone insists 
> to add UP Flag it should be not just a bit but also a time or time delta from 
> set UTC where it is expected that provided prefix will be down, 
>  
> Kind regards,
> R.
> ___
> 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] Interdomain UPA & UP Flag

[Aijun Wang]

Agree.

The possible scenario for UP flag is not the original intention of our 
discussion. 
We should abandon it and focus mainly on the other aspects of the solution.

Aijun Wang
China Telecom

> On Mar 27, 2023, at 17:06, Robert Raszuk  wrote:
> 
> 
> Hi,
> 
> I would like to get more clarification in respect to extending External LSAs 
> for UPA. Area summary use case is pretty clear - but in case of 
> redistribution (typical src of external LSAs) IMO we are going way too far 
> with this. Let's all keep in mind that this is a pulse designed to trigger 
> upper protocol switchover. 
> 
> Needless to say that would work only via one hop by design as redistribution 
> happens via RIB and by definition of UPA unreachable routes are not being 
> installed in RIB in the first place. 
> 
> On the apparently relative terms I do not see a need for the UP Flag. First 
> planned maintenance should be solved by BGP protocol and there are already a 
> number of tools in BGP allowing one to do it. 
> 
> Second, if you say this is needed for BGP free deployments then I question 
> the merit on the basis that UPA is ephemeral and expires say in 120 sec which 
> will not be enough for most planned maintenance work. So if someone insists 
> to add UP Flag it should be not just a bit but also a time or time delta from 
> set UTC where it is expected that provided prefix will be down, 
> 
> Kind regards,
> R.
> ___
> 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] PUA Converge Efforts—-Re: draft-ppsenak-lsr-igp-ureach-prefix-announce

[Aijun Wang]

Hi, Bruno:Let me answer some questions from you based on the current PUA solution. From the inline replies, we think the converged draft should be based on PUA draft.Aijun WangChina TelecomOn Mar 27, 2023, at 14:00, bruno.decra...@orange.com wrote:









Hi
authors,
 
Please find below some questions.
 

Assuming ABR1 advertises IP1 with metric 10 while ABR2 advertises IP1 with MAX metric.
 Is this prefix reachable or unreachable (or both)?[WAJ] This is the network partition scenario that we mentioned in the meeting, and also in the document.(UPA has no similar solution now)According to our considerations, the prefixes IP1 will be reachable via ABR1. This is the right answer for such situation.The contents for such situations are described in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-11#section-4“When only some of the ABRs can't reach the failure node/link, as that described in Section 3.2, along with the PUAM message for the associated prefixe from these ABRs, the ABR that can reach the PUAM prefix should advertise the specific route to this prefix. The internal routers within another area can then bypass the ABRs that can't reach the PUAM prefix, to reach the prefix that advertised in PUAM message.”¶Assuming ABR1 advertises a summary address but ABR2 does not. If ABR2 advertises
 IP1 with MAX metric does this count as UPA? (i.e. may a router advertise unreachability for a prefix advertised by another router?)[WAJ] In principle, the ABR that doesn’t send the summary address shouldn’t send the PUA/UPA message. So, normally, the ABR2 will not send such message with the MAX metric set.If it is sent out by ABR2 by any way, but not by ABR1, then it belongs to again the partition scenario(the receiver will know that it can reach such prefix via ABR1, not ABR2)Can you clarify the scope of the UPA signaling? E.g. if TLV 135 advertises prefix
 IP1 with MAX metric
does this signal UPA for all
FlexAlgo?If IS-IS Flexible Algorithm Prefix Metric is advertised, is MAX metric to be advertised
 in the main TLV, or per FAPM sub-TLV, or both? Can you specify the behavior in case on “inconsistencies”?Does this signal UPA If the summary address (aka the less specific prefix) is advertised
 in a different IS-IS instance or in a different protocol (e.g. OSPF, BGP…)?[WAJ] I think Peter can explain the above questions more clearly. Anyway, this is the reason that we mentioned during the meeting that we shouldn’t design the solution that relying heavily on the LSInfinity exploration.The less to depend on it, the better. That is the reason that we introduce the capabilities negotiation procedure(UPA based solution cannot be deployed without the dependency on the LSInfinity in future, this is unacceptable. The rely on the LSInfinity, or other bypass method should be only temporary)——once all the routers within the area support such capabilities, such feature will have no relation with the LSInfinity which may be used in other scenarios.
Is an UPA for a /24 equivalent to 255 UPA for /32? (i.e. will trigger BGP PIC edge
 for 255 /32)[WAJ] In principle, the ABR send only the PUA information for /32 prefix. As stated in the PUA draft:Prefix Unreachable Announcementdatatracker.ietf.orgBased on such information, the ABR will only advertise the PUAM message when the tracked prefixes(for example, the loopback addresses of PEs that run BGP) that within the summary address is missing.For UPA of SRv6 locators for algo 0 or 1, is the MAX METRIC to be advertised for
 TLV 27 or 236 or both? Can you specify the behavior in case on “inconsistencies”?“a summary address which covers the prefix is being advertised by the ABR/ASBR”.
 For IS-IS, does the Attached bit count as a summary address or is it needed to advertise a summary address in IP reachability?[WAJ] The ABR should advertise a summary address. It’s the pre-condition to advertise the PUA/UPA message.
 
Ideally it would be good if the draft were updated to answer the above questions.[WAJ] We want to express again that the PUA solution is more thorough solution—covering more aspects than UPA solution, and is also earlier solution for this problem and should be the base for the future converge.There is also other methods that let unsupported nodes to bypass the LSA that carry the unreachable signaling information, for example, set the MAX-AGE of the LSA. The specific in RFC2328 has the following description:   (1) If the cost specified by the LSA is LSInfinity, or if the LSA's LS age is equal to MaxAge, then examine the the next LSA.Using the MaxAge field can avoid the confusions with the usages of LSInfinity in FlexAlgo.If the above solution is acceptable, we can update the draft accordingly. Such bypass method may be more clearer than LSInfinity. 
 
Thanks,
Regards,
--Bruno

_

Ce message et ses pieces jointes peuvent contenir 

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Aijun Wang]

Hi, Les:As I remembered, https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/  will not be forwarded, and the proposed hierarchy within ISIS is not practical.Then, it seems that we can still treat area same as the level 1.  It’s the time to reduce the confusion?Aijun WangChina TelecomOn Feb 15, 2023, at 00:32, Les Ginsberg (ginsberg)  wrote:







Chris –
 
Indeed – welcome to the forum.
The concept of area address in IS-IS has confused many – including folks with a much longer history than you.
 
Please see inline.
 



From: Chris Parker  
Sent: Tuesday, February 14, 2023 2:16 AM
To: Shraddha Hegde 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem ; lsr@ietf.org
Subject: Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo


 

Thank you to all who replied for your consideration, and thank you to Acee for the kind welcome!

In regards the idea to change the wording to "The IS-IS FAD Sub-TLV has an area/level scope", I personally think that any mention of the word "area" in regards to IS-IS flooding could still be a source of confusion.


I'll expand the example in my previous mail, in case it's helpful. Imagine a theoretical level 2 topology which contains a few hundred routers.

- Some routers are in area 49.0001
- Some routers are in area 49.0002
- Some routers are in area 49.0003
- Some routers are in area 49.0004

(I know "49" is not strictly speaking part of the area identifier, but I've included it in the example just for clarity.)
[LES:] For the purposes of IS-IS, everything to “the left” of the system-id should be considered part of the area address. So “49” is indeed part of the area address in your examples.

If a router in area 49.0002 were to generate the IS-IS FAD Sub-TLV, I believe the intended delivery scope is "all routers in the same level as the original sender", regardless of the area the router is in. It's the level that defines the
 flooding scope, not the area. So for example, L2 routers in area 49.0004 should receive this sub-TLV,
[LES:] The scope is determined by the state of the “S-bit” in the enclosing Router Capability TLV. It is up to the router who originates the advertisement to set the scope as desired and up to the L1L2 routers who receive it to honor
 the scope request and perform leaking as appropriate.
An L1 router can originate an advertisement and specify that it should be flooded domain-wide (S-bit set). It is then the responsibility of the L1L2 routers in the same area to leak the advertisement into the L2 sub-domain (still
 with S-bit set) and up to L1L2 routers in other areas to leak the advertisement downwards into their L1 areas (with S-bit and D-bit set).


 


Even if we were to talk about level 1, it is possible for an L1 router to be in two IS-IS areas at once, which is a way of creating a single L1 topology, a single LSP flooding domain.
[LES:] No – this is not possible. A router can be in one – and only one – L1 area.
IS-IS does have the concept of “synonymous areas”. For example, consider the simple topology:
 
AB
 
On A we have the following area addresses configured: 49.0001
On B, we have the following area addresses configured: 49.0001 49.0002
 
On the link A—B, the adjacency formed can support Level 1 because ISO 10589 requires only that there be at least one area address in common.
The area then has two synonymous area addresses – it is NOT two different areas.
 
If B were an L1L2 router connected to C – who has area address 49.0003 configured, - B and C would form an L2 only adjacency (no area address in common) and B would announce the set of “computed area addresses” as (49.0001, 49.0002)
 in its L2 LSPs, indicating that there are two synonyms for its L1 area.
 
In the context of IP/IPv6 routing, synonymous area addresses are only useful when one is preparing to collapse two areas into one or preparing to split one area into two.


 


With all that in mind, hopefully it's a bit clearer why I worry about any mention of the word "area" in IS-IS when it comes to describing flooding scope, and why I feel that the wording "has an area/level scope" still has the potential
 to cause confusion. As a reader, I would wonder whether the implementer has a choice in the scope. The intention would not be explicitly clear to me. The word "area" has a slightly different meaning in IS-IS than it does in OSPF.
[LES:] There are three meaningful flooding scopes in base IS-IS (let’s not worry about additional scopes introduced by other protocol extensions – such as RFC 7356 - in this discussion):
 
1)Area scope
2)L2 sub-domain scope
3)Domain-wide scope (All areas and the L2 sub-domain)
 
Area can be thought of equivalent to level 1 in base IS-IS, but if one extends the protocol to greater levels of hierarchy (e.g., as proposed in

https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/ ) then area is no longer equivalent to level-1. So, I think it is still quite useful to retain the notion of area.
 
Hope this 

Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[Aijun Wang]

What’s the reason to keep area in the description? Is there any flooding activities that based on area?I suggest also remove the mention of area in these descriptions.Aijun WangChina TelecomOn Feb 14, 2023, at 18:16, Chris Parker  wrote:Thank you to all who replied for your consideration, and thank you to Acee for the kind welcome!In regards the idea to change the wording to "The IS-IS FAD Sub-TLV has an area/level scope", I personally think that any mention of the word "area" in regards to IS-IS flooding could still be a source of confusion. I'll expand the example in my previous mail, in case it's helpful. Imagine a theoretical level 2 topology which contains a few hundred routers.- Some routers are in area 49.0001- Some routers are in area 49.0002- Some routers are in area 49.0003- Some routers are in area 49.0004(I know "49" is not strictly speaking part of the area identifier, but I've included it in the example just for clarity.)If a router in area 49.0002 were to generate the IS-IS FAD Sub-TLV, I believe the intended delivery scope is "all routers in the same level as the original sender", regardless of the area the router is in. It's the level that defines the flooding scope, not the area. So for example, L2 routers in area 49.0004 should receive this sub-TLV,Even if we were to talk about level 1, it is possible for an L1 router to be in two IS-IS areas at once, which is a way of creating a single L1 topology, a single LSP flooding domain.With all that in mind, hopefully it's a bit clearer why I worry about any mention of the word "area" in IS-IS when it comes to describing flooding scope, and why I feel that the wording "has an area/level scope" still has the potential to cause confusion. As a reader, I would wonder whether the implementer has a choice in the scope. The intention would not be explicitly clear to me. The word "area" has a slightly different meaning in IS-IS than it does in OSPF.Hopefully that explanation is helpful. I'm very aware that I'm a newcomer talking to people far more knowledgeable than me about things like this, so I hope you'll forgive me if it turns out I'm mistaken.All the bestChrisOn Tue, Feb 14, 2023 at 4:00 AM Shraddha Hegde  wrote:I prefer changing the sentence to
" The IS-IS FAD Sub-TLV has an area/level scope"

Rgds
Shraddha


Juniper Business Use Only

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, February 14, 2023 2:26 AM
To: Acee Lindem ; Chris Parker 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Two small potential typing errors in draft-ietf-lsr-flex-algo

[External Email. Be cautious of content]


Disclaimer: I am not an author of the flex-algo draft.

However, the text regarding "scope" of the FAD sub-TLV is in the context of the flooding scope of the containing Router Capability TLV (as defined in RFC 7981).
There we have two scopes defined:

1)Area/level scope (S-bit clear)

Such information MUST NOT be leaked between levels

2)Domain-wide scope (S-bit set)

Such information MUST be flooded across the entire IS-IS flooding domain - which means it is leaked between levels (UP and DOWN as appropriate)

Both "area/level" and "domain-wide" are terms used in RFC 7981.

The full paragraph from the flex-algo draft reads:

"The IS-IS FAD Sub-TLV has an area scope. The Router Capability TLV in which the FAD Sub-TLV is present MUST have the S-bit clear."

I think this is correct - but if the authors wanted to update this to "area/level" I would not object.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, February 13, 2023 12:15 PM
> To: Chris Parker 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] Two small potential typing errors in 
> draft-ietf-lsr-flex-algo
>
> Hi Chris,
>
> > On Feb 13, 2023, at 2:56 PM, Chris Parker 
> > 
> wrote:
> >
> > Hi all,
> >
> > First time poster here. Sincere apologies if I make any mistakes in
> etiquette. I work at Juniper, and am mailing on suggestion of Shraddha 
> Hegde, after a conversation about draft-ietf-lsr-flex-algo.
> >
> > Having read the draft, I think I've found two tiny things to fix.
> >
> > The first is a typo: In the text "The following values area 
> > allocated by IANA
> from this registry for Flex-Algorithms", I think it should say "are", not "area”.
>
> This is definitely a typo.
>
> >
> > The second is a point of clarification in the text "The IS-IS FAD 
> > Sub-TLV has
> an area scope". I think perhaps this should be "level scope", not 
> "area scope".
>
> I can’t seem to find similar IS-IS terminology. I’ll defer to the authors.
> However, you’d be correct for OSPF.
>
> >
> > For example, imagine a level 2 backbone that contains four areas. I 
> > would
> imagine the intended behavior is actually to flood this sub-TLV 
> through the entire level 2 backbone, rather than 

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Robert:

>  "other than building the normal IP routing table" 

There may be different purposes, so advertise the “unreachable within the 
summary address” should be signed explicitly.

Aijun Wang
China Telecom

> On Nov 12, 2022, at 11:59, Robert Raszuk  wrote:
> 
> 
> Chris,
> 
> > unreachable routes in the IP routing table
> 
> I don't see anywhere in the UPA spec even a hint that those unreachable 
> pulses would be installed in the IP routing table. It seems to be a local 
> implementation choice how ISIS or OSPF would inform other protocols about 
> them. 
> 
> In fact the quote you provided specifically "other than building the normal 
> IP routing table" IMO endorses quite verbatim what Peter claims. They can be 
> used for other purposes then building a reachability table. 
> 
> Thx,
> R.
> 
> 
> 
> 
> 
> 
>> On Sat, Nov 12, 2022 at 6:47 AM Christian Hopps  wrote:
>> 
>> 
>> > On Nov 9, 2022, at 2:13 PM, Peter Psenak 
>> >  wrote:
>> > 
>> > On 09/11/2022 14:56, David Lamparter wrote:
>> >> On Wed, Nov 09, 2022 at 01:27:41PM +, Acee Lindem (acee) wrote:
>> >>> I guess I'd like to understand what one would accomplish with further
>> >>> specification of prefix reachable? What requirement would this
>> >>> satisfy? For the use case UPA is designed to handle (triggering BGP
>> >>> PIC or other local action) , I can't see that there would be any case
>> >>> where you wouldn’t want to take this action for an unreachable prefix.
>> >> The problem is that a prefix with metric > 0xfe00 isn't actually an
>> >> unreachable prefix, it's a prefix that doesn't have specific routing
>> >> information associated with it, which in turn allows sticking other data
>> >> into it that might be routing-related but not quite a reachability.
>> > 
>> > well, that is your interpretation. For me a prefix with metric > 
>> > 0xfe00 is unreachable. Implementations use the max-metric today to 
>> > signal the prefix unreachability - to avoid reaching 
>> > local/leaked/redistributed prefixes in cases where OL-bit is set on the 
>> > originator. So we are not doing anything new here really.
>> 
>> [as wg-member]
>> 
>> But his interpretation seems correct. RFC5305 says specifically that the 
>> prefix is not to be used for building the normal IP routing table, that 
>> would include not creating/installing blackhole/reject routes in the normal 
>> IP routing table.
>> 
>>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>>during the normal SPF computation.  This allows advertisement of a
>>prefix for purposes other than building the normal IP routing table.
>> 
>> Do the implementations you’re referring to install unreachable routes in the 
>> IP routing table, seemingly in violation of this?
>> 
>> Thanks,
>> Chris.
>> 
>> 
>> >> I vaguely remember several years back we did indeed implement something
>> >> (seriously no memory on details) that resulted in the creation of a new
>> >> prefix reachability TLV with some experimental/local sub-TLVs.  These
>> >> prefixes did not exist in the IS-IS domain beforehand.  I have no idea
>> >> what the operational reality is on the existence of such things, but I
>> >> know that /some/ code exists that does this.
>> >> To boil this down into the core of the essence and be explicit,
>> >> - you can create an IS-IS prefix reachability for some arbitrary prefix,
>> >>   and stick > 0xfe00 into the metric, and that won't have any effect
>> >>   on the existing IS-IS domain
>> >> - this has in fact been done to carry custom bits of information that
>> >>   for one reason or another were decided to be routing-related and thus
>> >>   make sense to put there
>> >> - the assumption for the use case is that there are indeed less specific
>> >>   covering prefixes around, providing actual reachability
>> >> - any setup doing that would now suddenly have fresh "unreachable"
>> >>   semantics attached to something that didn't have them before, which
>> >>   breaks things (or rather: prevents enabling/deployment of the UPA
>> >>   feature)
>> > 
>> > and why that would be a problem? Such prefix would never be used to for 
>> > resolution of the BGP pr

Re: [Lsr] OSPF-GT

[Aijun Wang]

Agree.

It is simple to put different application information onto different planes, 
but it brings the complex for operator to manage such planes, and the inter 
communication among different planes.

Lacks of deployments for Geninfo in IS-IS can also predict the future fate of 
such approaches in some sense.


Aijun Wang
China Telecom

> On Nov 10, 2022, at 10:48, Robert Raszuk  wrote:
> 
> 
> Thx Acee ... 
> 
> Since you mentioned "sparse" and since you highlighted that OSPF is better 
> then ISIS for this as it runs over IP I took a risk if not using flooding is 
> an option. 
> 
> Well ... apparently not. 
> 
> Of course you could build lots of parallel GT planes and still flood in each 
> across interested parties for a given type of info present in such a plane, 
> but this comes with much more overhead then pub-sub. 
> 
> Cheers,
> R.
> 
> 
>> On Thu, Nov 10, 2022 at 11:34 AM Acee Lindem (acee)  wrote:
>> Hi Robert,
>> 
>>  
>> 
>> From: Robert Raszuk 
>> Date: Wednesday, November 9, 2022 at 10:37 AM
>> To: Acee Lindem , lsr 
>> Subject: OSPF-GT
>> 
>>  
>> 
>> Hi Acee,
>> 
>>  
>> 
>> The point of sparse GT makes it much more attractive. 
>> 
>>  
>> 
>> With that I have two questions/suggestions to make it even more useful.
>> 
>>  
>> 
>> #1 Would you consider adding reflection function to spares mode GT ?
>> 
>>  
>> 
>> Within a flooding scope (e.g., area) , reflection is inherent in the 
>> flooding algorithm. One thing that applications will need to specify is 
>> whether or not information is re-originated outside the flooding scope 
>> (e.g., does the ABR re-originate application LSAs into other areas).
>> 
>>  
>> 
>>  
>> 
>> #2 If you do #1 would you considet pub-sub model ?
>> 
>>  
>> 
>> I wouldn’t change basic OSPF flooding. So, one could support pub-sub but 
>> everyone in the OSPF application routing domain would receive a superset of 
>> subscribed information (or the application would have to do something 
>> unnatural from an OSPF standpoint to limit the neighbors receiving the 
>> information, e.g., dynamically assign areas for unique subscriptions). I 
>> think other protocols are better suited to pub-sub.
>> 
>>  
>> 
>> Thanks,
>> Acee
>> 
>>  
>> 
>> Then this could be used for lot's of current use cases ... some of them even 
>> discussed today :)
>> 
>>  
>> 
>> Thx
>> 
>> R 
>> 
> ___
> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Peter:

I suggest that you consider such problems and the solutions from the broader 
viewpoint, not just the behavior of one single device, or only from the vendor 
side.
To deploy the mechanism into the network, the operator must assure it will not 
conflict with other possible usages, and no more constrained for the network 
planning, network operations.

There are already amounts of solutions cannot be deployed widespread in the 
network.

Let’s take the explicit signaling approaches. 



Aijun Wang
China Telecom

> On Nov 10, 2022, at 10:41, Peter Psenak  
> wrote:
> 
> On 09/11/2022 22:51, Aijun Wang wrote:
>> Hi, Peter:
>> Actually, the “unreachable” meaning of LSInfinity in current standard is not 
>> the same as the “unreachable” meaning that we are supposed to act:
>> 1) In current standard, the “unreachable” is meant that the related prefix 
>> will not be in the FIB.(you can read again and again 
>> https://www.rfc-editor.org/rfc/rfc2328.html#page-157 
>> <https://www.rfc-editor.org/rfc/rfc2328.html#page-157>)
>> 2) What we aim to solve is that although the specific prefixes is not in the 
>> FIB, there is another summary address that cover it is in the FIB. Even in 
>> such situations, the specific prefixes is still unreachable.
>> Then, depend solely on 1) is not enough.
>> We must need one explicit information to signal 2).
>> There are so many experts within LSR state that your solution is not 
>> appropriate,  will bring much chaos into the network, you still insist your 
>> approach. Is this productive?
> 
> interesting that you, who hardly listen to these experts at all, are saying 
> that.
> 
> Peter
> 
> 
>> The final solution should be definitely in “Standard Track”, but not your 
>> approach.
>> The explicit signaling is the right direction.
>> Even the experts in LSR are confusing on your multiplex usage of 
>> “LSInfinity”, how to deploy it in the large scale network?
>> Please don’t let the operator struggle to explain such vague usages to its 
>> Network OPS, Network Planning team.
>> Aijun Wang
>> China Telecom
>>> 
>>>> I wasn't clear on that in the first mail but Bruno clarified
>>>> that this would still be inside a high-metric prefix reachability TLV.
>>>> The only difference is that there is a flag/sub-TLV inside that triggers
>>>> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>>>> the UPA indicator MUST be ignored as they were before and MUST NOT
>>>> trigger UPA/PIC.
>>> 
>>> for me flagging something that is unreachable with a unreachable flag is 
>>> redundant. But I let the WG to decide. That would obviously push the draft 
>>> to standard track trajectory.
>>> 
>>> Peter
>>> 
>>> 
>>>> Cheers,
>>>> -David
>>> 
>>> ___
>>> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Peter:

Actually, the “unreachable” meaning of LSInfinity in current standard is not 
the same as the “unreachable” meaning that we are supposed to act:
1) In current standard, the “unreachable” is meant that the related prefix will 
not be in the FIB.(you can read again and again 
https://www.rfc-editor.org/rfc/rfc2328.html#page-157)

2) What we aim to solve is that although the specific prefixes is not in the 
FIB, there is another summary address that cover it is in the FIB. Even in such 
situations, the specific prefixes is still unreachable.

Then, depend solely on 1) is not enough.
We must need one explicit information to signal 2).

There are so many experts within LSR state that your solution is not 
appropriate,  will bring much chaos into the network, you still insist your 
approach. Is this productive?

The final solution should be definitely in “Standard Track”, but not your 
approach.
The explicit signaling is the right direction.

Even the experts in LSR are confusing on your multiplex usage of “LSInfinity”, 
how to deploy it in the large scale network?

Please don’t let the operator struggle to explain such vague usages to its 
Network OPS, Network Planning team.

Aijun Wang
China Telecom
> 
>> I wasn't clear on that in the first mail but Bruno clarified
>> that this would still be inside a high-metric prefix reachability TLV.
>> The only difference is that there is a flag/sub-TLV inside that triggers
>> UPA behavior.  However, prefixes with > 0xfe00 metric *without*
>> the UPA indicator MUST be ignored as they were before and MUST NOT
>> trigger UPA/PIC.
> 
> for me flagging something that is unreachable with a unreachable flag is 
> redundant. But I let the WG to decide. That would obviously push the draft to 
> standard track trajectory.
> 
> Peter
> 
> 
>> Cheers,
>> -David
> 
> ___
> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

One more information:

The explicit solution, 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10
 does not require all the nodes be upgraded simultaneously.

Aijun Wang
China Telecom

> On Nov 9, 2022, at 12:06, Peter Psenak  
> Using a new Sub-TLV to signal unreachability makes the solution non backward 
> compatible, and harder to deploy, for no good reason IMHO.
> 
> thanks,
> Peter
> 
> 
>> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
>> the only one to read it that way and that's a pretty important
>> errata?!?)
>> Cheers,
>> -David
> 
> ___
> 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] draft-ppsenak-lsr-igp-ureach-prefix-announce / UPA IS-IS semantics

[Aijun Wang]

Hi, Peter:

I think you over explain the meaning of “LSInfinity”. I concur with David:

>> A less specific prefix may cover it

Then, you conclusion that:

> when a prefix is "not considered during the normal Shortest Path First (SPF) 
> computation", the result will be that the prefix will become unreachable. I 
> guess we can agree on that

Is NOT correct.

“the result will be that the specific prefix isn’t existing within the FIB, but 
not unreachable——-because there may be one less specific prefix covers it.”

Then, let’s stick on the original statements about the meaning of “LSInfinity”, 
no more explanations, no more confusion then.

Aijun Wang
China Telecom

> On Nov 9, 2022, at 12:06, Peter Psenak  
> wrote:
> 
> Hi David,
> 
>> On 09/11/2022 11:44, David Lamparter wrote:
>> Hi Peter, hi all,
>> to iterate on the comment I made on the mic a few minutes ago, I
>> apparently have a rather different understanding of existing IS-IS
>> behaviour.  Reading 5305/5308,
>> ... "if a prefix is advertised with a metric larger
>>than MAX_V6_PATH_METRIC (0xFE00), this prefix MUST not be
>>considered during the normal Shortest Path First (SPF)
>>computation."
>> A prefix that is "not considered" is not an unreachable prefix.  It's a
>> prefix that is in the DB but ignored entirely, as if it wasn't there at
>> all.  A less specific prefix may cover it, and I would expect that to
>> work normally.
> 
> when a prefix is "not considered during the normal Shortest Path First (SPF) 
> computation", the result will be that the prefix will become unreachable. I 
> guess we can agree on that.
> 
> And I'm not sure what do you mean by "in the DB but ignored entirely". It 
> will not be ignored, it will be maintained similarly in the DB as any other 
> reachable prefix.
> 
>> The UPA draft is changing this such that now some values may mean that
>> the prefix is in fact unreachable.  I'd rather not do that and just add
>> a sub-TLV for it.
> 
> We are not changing anything in terms of meaning of the prefix metric higher 
> than 0xFE00 - and that is why this is backward compatible. If we would be 
> changing the meaning of the metric it would not be.
> 
> Using a new Sub-TLV to signal unreachability makes the solution non backward 
> compatible, and harder to deploy, for no good reason IMHO.
> 
> thanks,
> Peter
> 
> 
>> (Alternatively, if I misunderstood 5305/5308 - I'm pretty sure I'm not
>> the only one to read it that way and that's a pretty important
>> errata?!?)
>> Cheers,
>> -David
> 
> ___
> 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] 【Object the update of LSInfinity usage in RFC8362 】Re: I-D Action: draft-ietf-lsr-ip-flexalgo-07.txt

[Aijun Wang]

So, the discussion will be back to the origin?

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
Sent: Wednesday, November 2, 2022 4:20 PM
To: Aijun Wang 
Cc: Acee Lindem (acee) ; lsr@ietf.org
Subject: Re: [Lsr] 【Object the update of LSInfinity usage in RFC8362 】Re: I-D 
Action: draft-ietf-lsr-ip-flexalgo-07.txt

On 29/10/2022 02:08, Aijun Wang wrote:
> Hi, Peter:
> 
> You needn’t repeat, just provide the hyperlink for your reasonable 
> explanations is enough.

please look at the email I sent on Oct 5th with the subject "RFC 8362 and 
LSInfinity".

Peter


> 
> What I see are just only the some asserts, for example: “Incorrect”, “No 
> problem”. etc.
> 
> If you have no examples for explanations, please following the scenarios that 
> we provides.
> 
> There are also several folks, include myself, aren’t  convinced yet for such 
> approaches.
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 28, 2022, at 22:34, Peter Psenak  
>> wrote:
>>
>> Aijun,
>>
>> several folks, including myself, has explained to you previously that your 
>> claims regarding LSInfinity metric are incorrect. I'm not going to repeat 
>> that here again.
>>
>> Regards,
>> Peter
>>
>>
>>
>>
>>> On 22/10/2022 01:18, Aijun Wang wrote:
>>> Object!
>>> I have summarized the reason at 
>>> https://mailarchive.ietf.org/arch/msg/lsr/iqcgBvMIPcVxWpfK-AW9MUhpKes/ 
>>> <https://mailarchive.ietf.org/arch/msg/lsr/iqcgBvMIPcVxWpfK-AW9MUhpKes/>.
>>> Please give the reasonable responses before making any unsound attempts.
>>> Such updates, implementation and deployment will introduce chaos within the 
>>> network.
>>> Aijun Wang
>>> China Telecom
>>>>> On Oct 22, 2022, at 04:05, Acee Lindem (acee) 
>>>>>  wrote:
>>>>
>>>> All,
>>>>
>>>> Based on the WG Last Call discussion, section 6.4 has been added to 
>>>> clarify base algorithm exclusion in OSPFv3 E-Intra-Area-Prefix-LSAs. 
>>>> Please provide any additional comment before Nov 5, 2022.
>>>>
>>>> Thanks,
>>>> Acee
>>>>
>>>>> On 10/21/22, 4:20 AM, "Lsr on behalf of internet-dra...@ietf.org" 
>>>>>  wrote:
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>>> directories.
>>>> This draft is a work item of the Link State Routing WG of the IETF.
>>>>
>>>> Title   : IGP Flexible Algorithms (Flex-Algorithm) In 
>>>> IP Networks
>>>> Authors : William Britto
>>>>   Shraddha Hegde
>>>>   Parag Kaneriya
>>>>   Rejesh Shetty
>>>>   Ron Bonica
>>>>   Peter Psenak
>>>>   Filename: draft-ietf-lsr-ip-flexalgo-07.txt
>>>>   Pages   : 21
>>>>   Date: 2022-10-21
>>>>
>>>> Abstract:
>>>>An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
>>>>constraint-based paths.  The base IGP Flex-Algorithm specification
>>>>describes how it is used with Segment Routing (SR) data planes - SR
>>>>MPLS and SRv6.
>>>>
>>>>This document extends IGP Flex-Algorithm, so that it can be used 
>>>> with
>>>>regular IPv4 and IPv6 forwarding.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>>>>
>>>> There is also an htmlized version available at:
>>>> 
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-07
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ip-flexalgo-07
>>>>
>>>>
>>>> Internet-Drafts are also available by rsync at 
>>>> rsync.ietf.org::internet-drafts
>>>>
>>>>
>>>> ___
>>>> 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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Object the update of LSInfinity usage in RFC8362 】Re: I-D Action: draft-ietf-lsr-ip-flexalgo-07.txt

[Aijun Wang]

Hi, Peter:

You needn’t repeat, just provide the hyperlink for your reasonable explanations 
is enough.

What I see are just only the some asserts, for example: “Incorrect”, “No 
problem”. etc.

If you have no examples for explanations, please following the scenarios that 
we provides.

There are also several folks, include myself, aren’t  convinced yet for such 
approaches.

Aijun Wang
China Telecom

> On Oct 28, 2022, at 22:34, Peter Psenak  
> wrote:
> 
> Aijun,
> 
> several folks, including myself, has explained to you previously that your 
> claims regarding LSInfinity metric are incorrect. I'm not going to repeat 
> that here again.
> 
> Regards,
> Peter
> 
> 
> 
> 
>> On 22/10/2022 01:18, Aijun Wang wrote:
>> Object!
>> I have summarized the reason at 
>> https://mailarchive.ietf.org/arch/msg/lsr/iqcgBvMIPcVxWpfK-AW9MUhpKes/ 
>> <https://mailarchive.ietf.org/arch/msg/lsr/iqcgBvMIPcVxWpfK-AW9MUhpKes/>.
>> Please give the reasonable responses before making any unsound attempts.
>> Such updates, implementation and deployment will introduce chaos within the 
>> network.
>> Aijun Wang
>> China Telecom
>>>> On Oct 22, 2022, at 04:05, Acee Lindem (acee) 
>>>>  wrote:
>>> 
>>> All,
>>> 
>>> Based on the WG Last Call discussion, section 6.4 has been added to clarify 
>>> base algorithm exclusion in OSPFv3 E-Intra-Area-Prefix-LSAs. Please provide 
>>> any additional comment before Nov 5, 2022.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>>> On 10/21/22, 4:20 AM, "Lsr on behalf of internet-dra...@ietf.org" 
>>>>  wrote:
>>> 
>>> 
>>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>>This draft is a work item of the Link State Routing WG of the IETF.
>>> 
>>>Title   : IGP Flexible Algorithms (Flex-Algorithm) In IP 
>>> Networks
>>>Authors : William Britto
>>>  Shraddha Hegde
>>>  Parag Kaneriya
>>>  Rejesh Shetty
>>>  Ron Bonica
>>>  Peter Psenak
>>>  Filename: draft-ietf-lsr-ip-flexalgo-07.txt
>>>  Pages   : 21
>>>  Date: 2022-10-21
>>> 
>>>Abstract:
>>>   An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
>>>   constraint-based paths.  The base IGP Flex-Algorithm specification
>>>   describes how it is used with Segment Routing (SR) data planes - SR
>>>   MPLS and SRv6.
>>> 
>>>   This document extends IGP Flex-Algorithm, so that it can be used with
>>>   regular IPv4 and IPv6 forwarding.
>>> 
>>> 
>>>The IETF datatracker status page for this draft is:
>>>https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
>>> 
>>>There is also an htmlized version available at:
>>>https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-07
>>> 
>>>A diff from the previous version is available at:
>>>https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ip-flexalgo-07
>>> 
>>> 
>>>Internet-Drafts are also available by rsync at 
>>> rsync.ietf.org::internet-drafts
>>> 
>>> 
>>>___
>>>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] 【Object the update of LSInfinity usage in RFC8362 】Re: I-D Action: draft-ietf-lsr-ip-flexalgo-07.txt

[Aijun Wang]

Object!

I have summarized the reason at 
https://mailarchive.ietf.org/arch/msg/lsr/iqcgBvMIPcVxWpfK-AW9MUhpKes/.

Please give the reasonable responses before making any unsound attempts.

Such updates, implementation and deployment will introduce chaos within the 
network.

Aijun Wang
China Telecom

> On Oct 22, 2022, at 04:05, Acee Lindem (acee) 
>  wrote:
> 
> All,
> 
> Based on the WG Last Call discussion, section 6.4 has been added to clarify 
> base algorithm exclusion in OSPFv3 E-Intra-Area-Prefix-LSAs. Please provide 
> any additional comment before Nov 5, 2022. 
> 
> Thanks,
> Acee
> 
> On 10/21/22, 4:20 AM, "Lsr on behalf of internet-dra...@ietf.org" 
>  wrote:
> 
> 
>A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>This draft is a work item of the Link State Routing WG of the IETF.
> 
>Title   : IGP Flexible Algorithms (Flex-Algorithm) In IP 
> Networks
>Authors : William Britto
>  Shraddha Hegde
>  Parag Kaneriya
>  Rejesh Shetty
>  Ron Bonica
>  Peter Psenak
>  Filename: draft-ietf-lsr-ip-flexalgo-07.txt
>  Pages   : 21
>  Date: 2022-10-21
> 
>Abstract:
>   An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute
>   constraint-based paths.  The base IGP Flex-Algorithm specification
>   describes how it is used with Segment Routing (SR) data planes - SR
>   MPLS and SRv6.
> 
>   This document extends IGP Flex-Algorithm, so that it can be used with
>   regular IPv4 and IPv6 forwarding.
> 
> 
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
> 
>There is also an htmlized version available at:
>https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo-07
> 
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ip-flexalgo-07
> 
> 
>Internet-Drafts are also available by rsync at 
> rsync.ietf.org::internet-drafts
> 
> 
>___
>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] I-D Action: draft-wang-lsr-stub-link-attributes-05.txt

[Aijun Wang]

One correction for the hyper link of the updated draft:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-05
The number 5 is carried return in the second line in previous mail.

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Aijun Wang
Sent: Friday, October 21, 2022 11:38 AM
To: lsr@ietf.org
Subject: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-05.txt

Hi, All:

We have updated significantly the mentioned draft
(https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-0
5), wish it can address the concerns that were raised in the previous
adoption call.

The main updates contents are the followings:
1) Simplify the "Introduction" part significantly, state clearly the
intensions and applied scenarios of this draft.
2) Simplify the comparative of the existing solutions, emphasis on the
necessary on the proposed solution. (The operator can do their compare work
intensely when they select the solutions, similar with our discussions on
the list)
3) Some encoding change of the OSPF/IS-IS Stub-Link TLV.
4) Detail descriptions for the possible applied scenarios that introduced in
the IETF 114 meetings. To avoid to divert the attention, we put them in the
Appendix part to assist the discussions for further reference.

In summary, the proposed solution can be applied in broader scenarios, with
its generality characteristics.
Thanks Ketan (also Acee, and Les) for their reviews of this updated draft
offline.

We are glad to hear more fresh comments on the updated version of this
draft. 
We are also pleased/eager to get rough consensus for the forwarding of this
updated draft.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of
internet-dra...@ietf.org
Sent: Friday, October 21, 2022 11:08 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Advertisement of Stub Link Attributes
Authors     : Aijun Wang
  Zhibo Hu
  Acee Lindem
  Gyan S. Mishra
  Jinsong Sun
  Filename: draft-wang-lsr-stub-link-attributes-05.txt
  Pages   : 14
  Date: 2022-10-20

Abstract:
   This document describes the mechanism that can be used to advertise
   the stub link attributes within the IS-IS or OSPF domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-stub-link-attributes-05


Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts


___
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] I-D Action: draft-wang-lsr-stub-link-attributes-05.txt

[Aijun Wang]

Hi, All:

We have updated significantly the mentioned draft
(https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-0
5), wish it can address the concerns that were raised in the previous
adoption call.

The main updates contents are the followings:
1) Simplify the "Introduction" part significantly, state clearly the
intensions and applied scenarios of this draft.
2) Simplify the comparative of the existing solutions, emphasis on the
necessary on the proposed solution. (The operator can do their compare work
intensely when they select the solutions, similar with our discussions on
the list)
3) Some encoding change of the OSPF/IS-IS Stub-Link TLV.
4) Detail descriptions for the possible applied scenarios that introduced in
the IETF 114 meetings. To avoid to divert the attention, we put them in the
Appendix part to assist the discussions for further reference.

In summary, the proposed solution can be applied in broader scenarios, with
its generality characteristics.
Thanks Ketan (also Acee, and Les) for their reviews of this updated draft
offline.

We are glad to hear more fresh comments on the updated version of this
draft. 
We are also pleased/eager to get rough consensus for the forwarding of this
updated draft.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of
internet-dra...@ietf.org
Sent: Friday, October 21, 2022 11:08 AM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Advertisement of Stub Link Attributes
Authors     : Aijun Wang
  Zhibo Hu
  Acee Lindem
  Gyan S. Mishra
  Jinsong Sun
  Filename: draft-wang-lsr-stub-link-attributes-05.txt
  Pages   : 14
  Date: 2022-10-20

Abstract:
   This document describes the mechanism that can be used to advertise
   the stub link attributes within the IS-IS or OSPF domain.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-stub-link-attributes-05


Internet-Drafts are also available by rsync at
rsync.ietf.org::internet-drafts


___
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] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Acee:

The discussion in this thread is related to the "...the WG discussions of new 
drafts to signal unreachability outside the area... "
The discussion for the "..any usage of LSInfinity within that area.. " 
is at this thread  
https://mailarchive.ietf.org/arch/msg/lsr/Z0rlEGlIyzYAXOdl7ZQ75POIerw/

All are related to the usages of LSInfinity and its potential updates to RFC 
8362.

>From the current two threads, we can get the following conclusions:
1) The current usages of LSInfinity (introduced originally in RFC2328, 
inherited by RFC 5340, should be constrained to its actual meanings "Don't 
parse the associated LSA, or Premature the associated LSA"-, or even 
deprecated it, because of the following second conclusion:
2) It is problematic to expand/inherit such definition within RFC8362, because 
the intra- and inter- LSA use the same length of metric fields.

I think we can find other solutions for the proposals that based on the 
"LSInfinity", if not, please state them on the list, let's discuss them and 
accomplish such aims.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, October 15, 2022 1:48 AM
To: Aijun Wang 
Cc: Huzhibo ; Peter Psenak (ppsenak) ; 
lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Hi Aijun, 

On 10/13/22, 6:53 AM, "Aijun Wang"  wrote:

Hi, Acee and Peter:

I think you all misunderstood the intent of his scenario.
The correct understanding are the followings:
1) When aggregate route is configured in the ABR, the specified detail 
route should be withdrawn.
2) ABR can withdraw the advertised LSA that describes the specific detail 
route, via premature mechanism(MaxAge or LSInfinity, the former is preferred 
according to RFC2328)
3) But, withdrawn such specific LSA doesn’t mean the corresponding detail 
route unreachable——This destination can be reached via the aggregate route 
advertised by ABR instead.

This is the original usage of LSInfinity defined in RFC2327. It should be 
expanded further.

How to apply it in RFC8362 is another issue, as indicated my responses in 
another thread.

In summary, again, we should constrain or depreciate the confusion usages 
of LSInfinity.

The lack of visibility into the another area due to summarization is 
independent of any usage of LSInfinity within that area. This is also 
independent of the WG discussions of new drafts to signal unreachability 
outside the area. 

Thanks,
Acee

Aijun Wang
China Telecom

> On Oct 13, 2022, at 18:07, Acee Lindem (acee) 
 wrote:
> 
> Hi Zhibo, 
> 
> On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo"  wrote:
> 
>Hi LSR:
> 
>LSInfinity
>The metric value indicating that the destination described by an
>LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
> 
>I want to clarify the meaning of unreachable in LSifinity, 
>Assume that a node advertise specific route of 1.1.1.1/32, and an 
aggregate route 1.1.0.0/16 is configured.
>This node should premature aging of the 1.1.1.1/32 LSA.
>If this node using LSInfinity metric instead of prematuring aging, 
route 1.1.1.1/32 is still reachable.
>Therefore, the "unreachable" described by LSifinity is not really 
unreachable.
> 
> If your OSPF implementation includes unreachable LSAs in the summary cost 
computation, it is indeed broken.
> 
> Thanks,
> Acee
> 
>Thanks
>Zhibo hu
> 
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Wednesday, October 5, 2022 5:32 PM
>> To: lsr@ietf.org
>> Subject: [Lsr] RFC 8362 and LSInfinity
>> 
>> Hi Folks,
>> 
>> metric of LSInfinity (0xFF) has been defined in RFC2328:
>> 
>> LSInfinity
>> The metric value indicating that the destination described by an
>> LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
>> as
>> an alternative to premature aging (see Section 14.1). It is
>> defined to be the 24-bit binary value of all ones: 0xff.
>> 
>> RFC5340 inherited it from RFC2328:
>> 
>> Appendix B.  Architectural Constants
>> 
>>Architectural constants for the OSPF protocol are defined in
>> Appendix
>>B of [OSPFV2].  The only difference for OSPF for IPv6 is that
>>DefaultDestination is encoded as a prefix with length 0 (see
>>Appendix A.4.1).
>> 
>

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

One correction:

“It should be expanded further” should be “it shouldn’t be expanded further”

Aijun Wang
China Telecom

> On Oct 13, 2022, at 18:53, Aijun Wang  wrote:
> 
> Hi, Acee and Peter:
> 
> I think you all misunderstood the intent of his scenario.
> The correct understanding are the followings:
> 1) When aggregate route is configured in the ABR, the specified detail route 
> should be withdrawn.
> 2) ABR can withdraw the advertised LSA that describes the specific detail 
> route, via premature mechanism(MaxAge or LSInfinity, the former is preferred 
> according to RFC2328)
> 3) But, withdrawn such specific LSA doesn’t mean the corresponding detail 
> route unreachable——This destination can be reached via the aggregate route 
> advertised by ABR instead.
> 
> This is the original usage of LSInfinity defined in RFC2327. It should be 
> expanded further.
> 
> How to apply it in RFC8362 is another issue, as indicated my responses in 
> another thread.
> 
> In summary, again, we should constrain or depreciate the confusion usages of 
> LSInfinity.
> 
> Aijun Wang
> China Telecom
> 
>> On Oct 13, 2022, at 18:07, Acee Lindem (acee) 
>>  wrote:
>> 
>> Hi Zhibo, 
>> 
>> On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo" > behalf of huzhibo=40huawei@dmarc.ietf.org> wrote:
>> 
>>   Hi LSR:
>> 
>>   LSInfinity
>>   The metric value indicating that the destination described by an
>>   LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
>> 
>>   I want to clarify the meaning of unreachable in LSifinity, 
>>   Assume that a node advertise specific route of 1.1.1.1/32, and an 
>> aggregate route 1.1.0.0/16 is configured.
>>   This node should premature aging of the 1.1.1.1/32 LSA.
>>   If this node using LSInfinity metric instead of prematuring aging, route 
>> 1.1.1.1/32 is still reachable.
>>   Therefore, the "unreachable" described by LSifinity is not really 
>> unreachable.
>> 
>> If your OSPF implementation includes unreachable LSAs in the summary cost 
>> computation, it is indeed broken.
>> 
>> Thanks,
>> Acee
>> 
>>   Thanks
>>   Zhibo hu
>> 
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Wednesday, October 5, 2022 5:32 PM
>>> To: lsr@ietf.org
>>> Subject: [Lsr] RFC 8362 and LSInfinity
>>> 
>>> Hi Folks,
>>> 
>>> metric of LSInfinity (0xFF) has been defined in RFC2328:
>>> 
>>> LSInfinity
>>>The metric value indicating that the destination described by an
>>>LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
>>> as
>>>an alternative to premature aging (see Section 14.1). It is
>>>defined to be the 24-bit binary value of all ones: 0xff.
>>> 
>>> RFC5340 inherited it from RFC2328:
>>> 
>>> Appendix B.  Architectural Constants
>>> 
>>>   Architectural constants for the OSPF protocol are defined in
>>> Appendix
>>>   B of [OSPFV2].  The only difference for OSPF for IPv6 is that
>>>   DefaultDestination is encoded as a prefix with length 0 (see
>>>   Appendix A.4.1).
>>> 
>>> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix
>>> reachability, so the LSInfinity was not applicable for intra-area prefixes.
>>> 
>>> RFC8362 defines 24-bit metric for all prefix reachability TLVs -
>>> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
>>> Al
> 
> ___
> 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] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Acee and Peter:

I think you all misunderstood the intent of his scenario.
The correct understanding are the followings:
1) When aggregate route is configured in the ABR, the specified detail route 
should be withdrawn.
2) ABR can withdraw the advertised LSA that describes the specific detail 
route, via premature mechanism(MaxAge or LSInfinity, the former is preferred 
according to RFC2328)
3) But, withdrawn such specific LSA doesn’t mean the corresponding detail route 
unreachable——This destination can be reached via the aggregate route advertised 
by ABR instead.

This is the original usage of LSInfinity defined in RFC2327. It should be 
expanded further.

How to apply it in RFC8362 is another issue, as indicated my responses in 
another thread.

In summary, again, we should constrain or depreciate the confusion usages of 
LSInfinity.

Aijun Wang
China Telecom

> On Oct 13, 2022, at 18:07, Acee Lindem (acee) 
>  wrote:
> 
> Hi Zhibo, 
> 
> On 10/13/22, 2:26 AM, "Lsr on behalf of Huzhibo"  behalf of huzhibo=40huawei@dmarc.ietf.org> wrote:
> 
>Hi LSR:
> 
>LSInfinity
>The metric value indicating that the destination described by an
>LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
> 
>I want to clarify the meaning of unreachable in LSifinity, 
>Assume that a node advertise specific route of 1.1.1.1/32, and an 
> aggregate route 1.1.0.0/16 is configured.
>This node should premature aging of the 1.1.1.1/32 LSA.
>If this node using LSInfinity metric instead of prematuring aging, route 
> 1.1.1.1/32 is still reachable.
>Therefore, the "unreachable" described by LSifinity is not really 
> unreachable.
> 
> If your OSPF implementation includes unreachable LSAs in the summary cost 
> computation, it is indeed broken.
> 
> Thanks,
> Acee
> 
>Thanks
>Zhibo hu
> 
>> -Original Message-
>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>> Sent: Wednesday, October 5, 2022 5:32 PM
>> To: lsr@ietf.org
>> Subject: [Lsr] RFC 8362 and LSInfinity
>> 
>> Hi Folks,
>> 
>> metric of LSInfinity (0xFF) has been defined in RFC2328:
>> 
>> LSInfinity
>> The metric value indicating that the destination described by an
>> LSA is unreachable. Used in summary-LSAs and AS-external-LSAs
>> as
>> an alternative to premature aging (see Section 14.1). It is
>> defined to be the 24-bit binary value of all ones: 0xff.
>> 
>> RFC5340 inherited it from RFC2328:
>> 
>> Appendix B.  Architectural Constants
>> 
>>Architectural constants for the OSPF protocol are defined in
>> Appendix
>>B of [OSPFV2].  The only difference for OSPF for IPv6 is that
>>DefaultDestination is encoded as a prefix with length 0 (see
>>Appendix A.4.1).
>> 
>> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix
>> reachability, so the LSInfinity was not applicable for intra-area prefixes.
>> 
>> RFC8362 defines 24-bit metric for all prefix reachability TLVs -
>> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
>> Al

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

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

Acee:

The reason that the operator set the metric to one large enough value, is to 
let the associated route be the non-optimal selection, not let its unreachable.
Because there are normally several links away from the ABR to the advertised 
router which is connected directly the prefix that has such large value metric, 
it is easily and very possibly that the metric of the summary LSA reaches the 
so-called LSInfinity and lead to the abnormal behavior within the network.

Then, it's time to correct the misstatement within RFC2328, and remove the 
LSInfinity definition.
Such work has been done in https://www.rfc-editor.org/rfc/rfc6987#appendix-A

"In addition to editorial updates, this document defines a new
   architectural constant (MaxLinkMetric in Section 3) to eliminate any
   confusion about the interpretation of LSInfinity.  It also
   incorporates and explains the use of the R-bit [RFC5340] as a
   solution to the problem addressed in the text."


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Wednesday, October 12, 2022 10:07 PM
To: Aijun Wang 
Cc: Peter Psenak (ppsenak) ; Ketan Talaulikar 
; lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Hi Aijun, 

On 10/12/22, 9:58 AM, "Aijun Wang"  wrote:

Hi, Acee:

Let me give you one more concrete example:

The metric of one prefix P is set to 0xFE(not LSInfinity, it can also 
be other large value), and this prefix is attached at one router that has the 
link cost 1 to ABR, what the value for the ABR to advertise for this Prefixes P 
into other attached area as one summary prefix?

It's obvious you wouldn’t configure metrics that large unless you were trying 
to accomplish some prefix reachability scoping (which I wouldn't recommend by 
the way).
 
Acee

Aijun Wang
China Telecom

> On Oct 12, 2022, at 18:22, Acee Lindem (acee) 
 wrote:
> 
> 
> 
> On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang"  wrote:
> 
>Hi, Acee:
> 
>Let me state some points more clearly:
>1) The LSInfinity is defined almost 30 years, but it is not 
applied/deployed within the network about 30 years, why to deprecate it?
>2) RFC8362 say nothing about LSInifinity, only RFC5340 says it 
inherits the definition from RFC2328.
>3) It is problematic to define again the LSInifinity within RFC8362, 
as the value of 0xff, because the metric of the normal summary prefixes 
advertised by ABR may reach this predefined value.
> 
> This is not problematic. Only unreachable prefixes for an algorithm will 
have a metric of LSInfinity and will, hence, be unreachable and will not 
contribute to the cost of any summary prefixes. 
> 
> Thanks,
> Acee 
> 
>The most important point is that there is reasonable/sound reason to 
define such value for its special handling.
> 
>Best Regards
> 
>Aijun Wang
>China Telecom
> 
> 
>-Original Message-
>From: lsr-boun...@ietf.org  On Behalf Of Acee 
Lindem (acee)
>Sent: Tuesday, October 11, 2022 11:20 PM
>To: Peter Psenak (ppsenak) ; Aijun Wang 
; 'Ketan Talaulikar' 
>Cc: lsr@ietf.org
>Subject: Re: [Lsr] RFC 8362 and LSInfinity
> 
>Hi Aijun,
> 
>After almost 30 years, we're not going to deprecate OSPF LSInfinity 
based on your opinion. 
> 
>Please be specific as to what you feel is problematic with usage in 
the 24-bit metric in the E-Intra-Area-Prefix LSA.
> 
>Thanks,
    >Acee
> 
>On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:
> 
>Aijun,
> 
>>On 11/10/2022 05:44, Aijun Wang wrote:
>> Hi, Peter:
>> 
>> Let's focus on OSPF itself then.
>> 
>> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link 
or intra-area prefix is 16 bit; but the metric length for the summary 
LSA/inter-area is 24bit.
>> There will be no problem to define the LSInfinity for the summary LSA as 
0xFF( although the usages of such definition is doubtful and should be 
revaluatedfor example, is there any real deployment for the mentioned 
possible usages?)
>> 
>> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, 
there is possible the cost to some prefixes advertised by the ABR reach this 
value, it is unreasonable to consider such prefixes are unreachable.  Then, 
rely on such value of the metric to determine the reachability is problematic.
> 
>again, there is no problem. For RFC8362 0xFF already means 
>LSInfinity for inter/external 

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

And, in https://www.rfc-editor.org/rfc/rfc2328.html#page-135 (Section
12.4.3. Summary-LSAs), it states clearly:

"If a router advertises a summary-LSA for a destination which
then becomes unreachable, the router must then flush the LSA
from the routing domain by setting its age to MaxAge and
reflooding (see Section 14.1)."Section 14.1 is about how to
"Premature aging of LSAs"

Then, if you want to invalidate one of your advertised LSA, you should use
MaxAge, not LSInfinity.
The LSInfinity, should be limited it's the original meaningthe last
resort of the route to the prefixes.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Huzhibo
Sent: Thursday, October 13, 2022 2:26 PM
To: Peter Psenak ; lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Hi LSR:

LSInfinity
The metric value indicating that the destination described by an LSA is
unreachable. Used in summary-LSAs and AS-external-LSAs

I want to clarify the meaning of unreachable in LSifinity, Assume that a
node advertise specific route of 1.1.1.1/32, and an aggregate route
1.1.0.0/16 is configured.
This node should premature aging of the 1.1.1.1/32 LSA.
If this node using LSInfinity metric instead of prematuring aging, route
1.1.1.1/32 is still reachable.
Therefore, the "unreachable" described by LSifinity is not really
unreachable.

Thanks
Zhibo hu

> -Original Message-
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
> Sent: Wednesday, October 5, 2022 5:32 PM
> To: lsr@ietf.org
> Subject: [Lsr] RFC 8362 and LSInfinity
> 
> Hi Folks,
> 
> metric of LSInfinity (0xFF) has been defined in RFC2328:
> 
> LSInfinity
>  The metric value indicating that the destination described by an
>  LSA is unreachable. Used in summary-LSAs and AS-external-LSAs 
> as
>  an alternative to premature aging (see Section 14.1). It is
>  defined to be the 24-bit binary value of all ones: 0xff.
> 
> RFC5340 inherited it from RFC2328:
> 
> Appendix B.  Architectural Constants
> 
> Architectural constants for the OSPF protocol are defined in 
> Appendix
> B of [OSPFV2].  The only difference for OSPF for IPv6 is that
> DefaultDestination is encoded as a prefix with length 0 (see
> Appendix A.4.1).
> 
> Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix 
> reachability, so the LSInfinity was not applicable for intra-area
prefixes.
> 
> RFC8362 defines 24-bit metric for all prefix reachability TLVs - 
> Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
> Although it is silent about the LSInfinity as such, it is assumed that 
> such metric means unreachability for Inter-Area-Prefix TLV and 
> External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits 
> metric as well, it would make sense to define the LSInfinity as 
> unreachable for Intra-Area-Prefix TLV as well.
> 
> Would anyone object such a clarification in RFC8362?
> 
> thanks,
> Peter
> 
> ___
> 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] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Acee:

Let me give you one more concrete example:

The metric of one prefix P is set to 0xFE(not LSInfinity, it can also be 
other large value), and this prefix is attached at one router that has the link 
cost 1 to ABR, what the value for the ABR to advertise for this Prefixes P into 
other attached area as one summary prefix?

Aijun Wang
China Telecom

> On Oct 12, 2022, at 18:22, Acee Lindem (acee) 
>  wrote:
> 
> 
> 
> On 10/12/22, 2:31 AM, "Lsr on behalf of Aijun Wang"  behalf of wangai...@tsinghua.org.cn> wrote:
> 
>Hi, Acee:
> 
>Let me state some points more clearly:
>1) The LSInfinity is defined almost 30 years, but it is not 
> applied/deployed within the network about 30 years, why to deprecate it?
>2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits 
> the definition from RFC2328.
>3) It is problematic to define again the LSInifinity within RFC8362, as 
> the value of 0xff, because the metric of the normal summary prefixes 
> advertised by ABR may reach this predefined value.
> 
> This is not problematic. Only unreachable prefixes for an algorithm will have 
> a metric of LSInfinity and will, hence, be unreachable and will not 
> contribute to the cost of any summary prefixes. 
> 
> Thanks,
> Acee 
> 
>The most important point is that there is reasonable/sound reason to 
> define such value for its special handling.
> 
>Best Regards
> 
>Aijun Wang
>China Telecom
> 
> 
>-Original Message-
>From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
> (acee)
>Sent: Tuesday, October 11, 2022 11:20 PM
>To: Peter Psenak (ppsenak) ; Aijun Wang 
> ; 'Ketan Talaulikar' 
>Cc: lsr@ietf.org
>Subject: Re: [Lsr] RFC 8362 and LSInfinity
> 
>Hi Aijun,
> 
>After almost 30 years, we're not going to deprecate OSPF LSInfinity based 
> on your opinion. 
> 
>Please be specific as to what you feel is problematic with usage in the 
> 24-bit metric in the E-Intra-Area-Prefix LSA.
> 
>Thanks,
>Acee
> 
>On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:
> 
>Aijun,
> 
>>On 11/10/2022 05:44, Aijun Wang wrote:
>> Hi, Peter:
>> 
>> Let's focus on OSPF itself then.
>> 
>> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or 
>> intra-area prefix is 16 bit; but the metric length for the summary 
>> LSA/inter-area is 24bit.
>> There will be no problem to define the LSInfinity for the summary LSA as 
>> 0xFF( although the usages of such definition is doubtful and should be 
>> revaluatedfor example, is there any real deployment for the mentioned 
>> possible usages?)
>> 
>> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, 
>> there is possible the cost to some prefixes advertised by the ABR reach this 
>> value, it is unreasonable to consider such prefixes are unreachable.  Then, 
>> rely on such value of the metric to determine the reachability is 
>> problematic.
> 
>again, there is no problem. For RFC8362 0xFF already means 
>LSInfinity for inter/external prefixes. All we propose is to define 
> the 
>same meaning for that metric for intra-area prefixes as it is 24 bits 
> as 
>well.
> 
>Peter
> 
>> 
>> We should decrease or abandon such unsound reliance.
>> 
>> It is easy for the device to implement such special treatment, it is 
>> difficult and complex for the operator to run the network based on such 
>> special treatment.
>> 
>> 
>> Best Regards
>> 
>> Aijun Wang
>> China Telecom
>> 
>> -Original Message-
>> From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
>> Sent: Monday, October 10, 2022 3:56 PM
>> To: Aijun Wang ; 'Acee Lindem (acee)' 
>> ; 'Ketan Talaulikar' 
>> ; 'Peter Psenak' 
>> Cc: lsr@ietf.org
>> Subject: Re: [Lsr] RFC 8362 and LSInfinity
>> 
>> Aijun,
>> 
>>> On 09/10/2022 07:44, Aijun Wang wrote:
>>> Hi, Acee, Peter and Ketan:
>>> 
>>> I propose we limit the usage of LSInfinity within the network. That is
>>> to say, we should depreciate its usages, not enhance it.
>>> 
>>> As defined in RFC2328, the sole purpose of LSInfinity is to let the
>>> receiver bypass the SPF calculation for the associated LSA:
>>> 
>>> a)In case the advertisement of LSA for some special aim.
>>> 
>>> b)Another is for the premature aging the LSA (which is not encouraged).
>>> 
>>> There is few applica

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Robert:

 

What I mean is that using LSInfinity as other special purpose. 

I have stated in previous 
mail(https://mailarchive.ietf.org/arch/msg/lsr/YqGg3Qhwm17FOmh7bky8jzOJAH4/), 
that the LSInifinity should be used only as the last resort of routing 
decision, no other more meanings.

Then, LSInifinity is just the maximum value of the prefix metric.  

The above usage is same as the other value of the metric, then define them or 
not is trival-The operator can use any other large enough value to divert 
the traffic in your mentioned scenarios.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Robert Raszuk  
Sent: Wednesday, October 12, 2022 2:50 PM
To: Aijun Wang 
Cc: Acee Lindem (acee) ; Peter Psenak 
(ppsenak) ; Ketan Talaulikar ; 
lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

 

 

> 1) The LSInfinity is defined almost 30 years, but it is not applied/deployed 
> within the 

> network about 30 years

 

OSPF Max Metric (LSInfinity) is commonly deployed and used in pretty much every 
decent network. 

 

As an example it is used to drain traffic from active forwarding nodes before 
planned maintenance. It is also used when wait-for-bgp is active. 

 

So sorry, but your above assertion is false. 

 

Rgs,

Robert.

 

 

On Wed, Oct 12, 2022 at 8:30 AM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Acee:

Let me state some points more clearly:
1) The LSInfinity is defined almost 30 years, but it is not applied/deployed 
within the network about 30 years, why to deprecate it?
2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits the 
definition from RFC2328.
3) It is problematic to define again the LSInifinity within RFC8362, as the 
value of 0xff, because the metric of the normal summary prefixes advertised 
by ABR may reach this predefined value.

The most important point is that there is reasonable/sound reason to define 
such value for its special handling.

Best Regards

Aijun Wang
China Telecom


-Original Message-
From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  mailto:lsr-boun...@ietf.org> > On Behalf Of Acee Lindem (acee)
Sent: Tuesday, October 11, 2022 11:20 PM
To: Peter Psenak (ppsenak) mailto:ppse...@cisco.com> >; 
Aijun Wang mailto:wangai...@tsinghua.org.cn> >; 
'Ketan Talaulikar' mailto:ketant.i...@gmail.com> >
Cc: lsr@ietf.org <mailto:lsr@ietf.org> 
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Hi Aijun,

After almost 30 years, we're not going to deprecate OSPF LSInfinity based on 
your opinion. 

Please be specific as to what you feel is problematic with usage in the 24-bit 
metric in the E-Intra-Area-Prefix LSA.

Thanks,
Acee

On 10/11/22, 12:09 AM, "Peter Psenak" mailto:ppse...@cisco.com> > wrote:

Aijun,

On 11/10/2022 05:44, Aijun Wang wrote:
> Hi, Peter:
> 
> Let's focus on OSPF itself then.
> 
> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or 
intra-area prefix is 16 bit; but the metric length for the summary 
LSA/inter-area is 24bit.
> There will be no problem to define the LSInfinity for the summary LSA as 
0xFF( although the usages of such definition is doubtful and should be 
revaluatedfor example, is there any real deployment for the mentioned 
possible usages?)
> 
> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, 
there is possible the cost to some prefixes advertised by the ABR reach this 
value, it is unreasonable to consider such prefixes are unreachable.  Then, 
rely on such value of the metric to determine the reachability is problematic.

again, there is no problem. For RFC8362 0xFF already means 
LSInfinity for inter/external prefixes. All we propose is to define the 
same meaning for that metric for intra-area prefixes as it is 24 bits as 
well.

Peter

> 
> We should decrease or abandon such unsound reliance.
> 
> It is easy for the device to implement such special treatment, it is 
difficult and complex for the operator to run the network based on such special 
treatment.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
mailto:lsr-boun...@ietf.org> > On Behalf Of Peter Psenak
> Sent: Monday, October 10, 2022 3:56 PM
> To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >; 'Acee Lindem (acee)' 
mailto:40cisco@dmarc.ietf.org> >; 'Ketan 
Talaulikar' mailto:ketant.i...@gmail.com> >; 'Peter 
Psenak' mailto:40cisco@dmarc.ietf.org> 
>
> Cc: lsr@ietf.org <mailto:lsr@ietf.org> 
> Subject: Re: [Lsr] RFC 8362 and LSInfinity
> 
> Aijun,
> 
> On 09/10/2022 07:44, Aijun Wang wrote:
>>

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Acee:

Let me state some points more clearly:
1) The LSInfinity is defined almost 30 years, but it is not applied/deployed 
within the network about 30 years, why to deprecate it?
2) RFC8362 say nothing about LSInifinity, only RFC5340 says it inherits the 
definition from RFC2328.
3) It is problematic to define again the LSInifinity within RFC8362, as the 
value of 0xff, because the metric of the normal summary prefixes advertised 
by ABR may reach this predefined value.

The most important point is that there is reasonable/sound reason to define 
such value for its special handling.

Best Regards

Aijun Wang
China Telecom


-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Tuesday, October 11, 2022 11:20 PM
To: Peter Psenak (ppsenak) ; Aijun Wang 
; 'Ketan Talaulikar' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Hi Aijun,

After almost 30 years, we're not going to deprecate OSPF LSInfinity based on 
your opinion. 

Please be specific as to what you feel is problematic with usage in the 24-bit 
metric in the E-Intra-Area-Prefix LSA.

Thanks,
Acee

On 10/11/22, 12:09 AM, "Peter Psenak"  wrote:

Aijun,

On 11/10/2022 05:44, Aijun Wang wrote:
> Hi, Peter:
> 
> Let's focus on OSPF itself then.
> 
> In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or 
intra-area prefix is 16 bit; but the metric length for the summary 
LSA/inter-area is 24bit.
> There will be no problem to define the LSInfinity for the summary LSA as 
0xFF( although the usages of such definition is doubtful and should be 
revaluatedfor example, is there any real deployment for the mentioned 
possible usages?)
> 
> But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, 
there is possible the cost to some prefixes advertised by the ABR reach this 
value, it is unreasonable to consider such prefixes are unreachable.  Then, 
rely on such value of the metric to determine the reachability is problematic.

again, there is no problem. For RFC8362 0xFF already means 
LSInfinity for inter/external prefixes. All we propose is to define the 
same meaning for that metric for intra-area prefixes as it is 24 bits as 
well.

Peter

> 
> We should decrease or abandon such unsound reliance.
> 
> It is easy for the device to implement such special treatment, it is 
difficult and complex for the operator to run the network based on such special 
treatment.
> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -Original Message-
> From: lsr-boun...@ietf.org  On Behalf Of Peter 
Psenak
> Sent: Monday, October 10, 2022 3:56 PM
> To: Aijun Wang ; 'Acee Lindem (acee)' 
; 'Ketan Talaulikar' ; 
'Peter Psenak' 
> Cc: lsr@ietf.org
> Subject: Re: [Lsr] RFC 8362 and LSInfinity
> 
> Aijun,
> 
> On 09/10/2022 07:44, Aijun Wang wrote:
>> Hi, Acee, Peter and Ketan:
>>
>> I propose we limit the usage of LSInfinity within the network. That is
>> to say, we should depreciate its usages, not enhance it.
>>
>> As defined in RFC2328, the sole purpose of LSInfinity is to let the
>> receiver bypass the SPF calculation for the associated LSA:
>>
>> a)In case the advertisement of LSA for some special aim.
>>
>> b)Another is for the premature aging the LSA (which is not encouraged).
>>
>> There is few application for the a) usage until now, same situation
>> for
>> b) usage.
> 
> definition of LSInfinity is very exact - it means unreachability.
> 
>>
>> The reason for the above situations may be the definition within the
>> RFC2328 is counterintuitivethe maximum value of the metric should
>> be used for the last resort of the reachability, no other more
>> meanings. Or else, it will complex the implementation and deployment, 
for example:
>>
>> a)For OSPFv2, the LSInfinity is defined as 0xff
>>
>> b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is
>> defined as 0xFE00
> 
> you are comparing apples to oranges. These are two different protocols.
> 
>>
>> c)For OSPFv3, which value will you be defined, especially for the
>> Intra-Area-Prefix? Considering the metric for the intra-area and
>> inter-area are all 24-bit long?
> 
> OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly 
mentioned in the OSPFv3 RFC. And LSInfinity is 24 bits long.
> 
>>
>> d)And, for the metric in ”IP Algorithm Prefix Reachability” ,

Re: [Lsr] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Peter:

Let's focus on OSPF itself then. 

In OSPFv2(RFC2328) and OSPFv3(RFC5340), the metric length for the link or 
intra-area prefix is 16 bit; but the metric length for the summary 
LSA/inter-area is 24bit.
There will be no problem to define the LSInfinity for the summary LSA as 
0xFF( although the usages of such definition is doubtful and should be 
revaluatedfor example, is there any real deployment for the mentioned 
possible usages?)

But for OSPFv3(RFC8362), if you still define the LSInifiity as 0xFF, there 
is possible the cost to some prefixes advertised by the ABR reach this value, 
it is unreasonable to consider such prefixes are unreachable.  Then, rely on 
such value of the metric to determine the reachability is problematic.

We should decrease or abandon such unsound reliance.

It is easy for the device to implement such special treatment, it is difficult 
and complex for the operator to run the network based on such special treatment.


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
Sent: Monday, October 10, 2022 3:56 PM
To: Aijun Wang ; 'Acee Lindem (acee)' 
; 'Ketan Talaulikar' ; 
'Peter Psenak' 
Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

Aijun,

On 09/10/2022 07:44, Aijun Wang wrote:
> Hi, Acee, Peter and Ketan:
> 
> I propose we limit the usage of LSInfinity within the network. That is 
> to say, we should depreciate its usages, not enhance it.
> 
> As defined in RFC2328, the sole purpose of LSInfinity is to let the 
> receiver bypass the SPF calculation for the associated LSA:
> 
> a)In case the advertisement of LSA for some special aim.
> 
> b)Another is for the premature aging the LSA (which is not encouraged).
> 
> There is few application for the a) usage until now, same situation 
> for
> b) usage.

definition of LSInfinity is very exact - it means unreachability.

> 
> The reason for the above situations may be the definition within the
> RFC2328 is counterintuitivethe maximum value of the metric should 
> be used for the last resort of the reachability, no other more 
> meanings. Or else, it will complex the implementation and deployment, for 
> example:
> 
> a)For OSPFv2, the LSInfinity is defined as 0xff
> 
> b)For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is 
> defined as 0xFE00

you are comparing apples to oranges. These are two different protocols.

> 
> c)For OSPFv3, which value will you be defined, especially for the 
> Intra-Area-Prefix? Considering the metric for the intra-area and 
> inter-area are all 24-bit long?

OSPFv3 inherits all the constants defined for OSPFv2, it's explicitly mentioned 
in the OSPFv3 RFC. And LSInfinity is 24 bits long.

> 
> d)And, for the metric in ”IP Algorithm Prefix Reachability” ,
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3 
> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3>,
>  its length is again 32-bit, will you define another LSInfinity value later?

0x seems like a good candidate for the unreachable metric for the IP 
flex-algo.

> 
> Won’t you think the above special rule complex the whole situation?

not at all.

> 
> I think we should seek other methods to achieve the necessary goals.

I do not see a problem

thanks,
Peter
> 
> Best Regards
> 
> Aijun Wang
> 
> China Telecom
> 
> *From:* lsr-boun...@ietf.org  *On Behalf Of 
> *Acee Lindem (acee)
> *Sent:* Saturday, October 8, 2022 4:03 AM
> *To:* Ketan Talaulikar ; Peter Psenak 
> 
> *Cc:* lsr@ietf.org
> *Subject:* Re: [Lsr] RFC 8362 and LSInfinity
> 
> Hi Peter, Ketan,
> 
> We’ll do another WG last call on the updated IP Flex Algo document and 
> it will update RFC 8362. As you probably surmised, this is useful for
> OSPFv3 IP Flex Algorithm when you want don’t want to use the prefix 
> with the base algorithm.
> 
> *From: *Lsr mailto:lsr-boun...@ietf.org>> on 
> behalf of Ketan Talaulikar  <mailto:ketant.i...@gmail.com>>
> *Date: *Thursday, October 6, 2022 at 3:35 AM
> *To: *Peter Psenak  <mailto:ppsenak=40cisco@dmarc.ietf.org>>
> *Cc: *"lsr@ietf.org <mailto:lsr@ietf.org>"  <mailto:lsr@ietf.org>>
> *Subject: *Re: [Lsr] RFC 8362 and LSInfinity
> 
> Hi Peter,
> 
> I support this "update" - not sure if it qualifies as a "clarification". 
> Also, this obviously is doable only when the network has migrated to 
> use only Extended LSAs (i.e., legacy LSAs are removed) as indicated in
> https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1
> <https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1>
> 
> In sparse-mode, the legacy LSAs are used. So if you want a pref

Re: [Lsr] New Version Notification for draft-pkaneria-lsr-multi-tlv-01.txt

[Aijun Wang]

>From my understanding, to introduce the Multi-part TLV into the network, the
following two things should be done:
1) The capability negotiation. Unless all of nodes support such
capabilities, the advertisement of Multi-part TLV should not be initiated,
or else, lack of the correct parsing of Mult-part TLV by one of the nodes
will result in the inconsistence of LSDB, which may result in the forwarding
loop.
2) The indication of the Multi-part TLV is present, similar with the
fragment flag for IP packet encapsulation. Such indication can distinct the
Multi-part TLV from the repeated advertisements of the same TLV.

Is there any other difficult points to be solved?


Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Sunday, October 9, 2022 8:49 AM
To: Les Ginsberg (ginsberg) 
Cc: Christian Hopps ; Tony Li ; Peter
Psenak (ppsenak) ; Robert Raszuk ;
Henk Smit ; lsr@ietf.org
Subject: Re: [Lsr] New Version Notification for
draft-pkaneria-lsr-multi-tlv-01.txt


Christian Hopps  writes:
>>> I simply turned your question around and asked: should conforming
>>
>>> implementations be penalized?
>>
>> [LES:] Are you claiming that the absence of an explicit statement 
>> regarding support of MP for a given TLV  is equivalent to a 
>> prohibition against sending them (which fails basic logic)?
>
> Why did we explicitly define multi-part TLVs?
>
> I agree we appear to not making any progress here. Perhaps it would be
more productive to have a discussion in a different forum like an interim or
something similar.
>
> Thanks,
> Chris.
> [as wg-chair]

Gah, I meant "as wg-member"! However, the suggestion of a different forum
could probably come from the chair hat as well. :)

Thanks,
Chris.

___
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] RFC 8362 and LSInfinity

[Aijun Wang]

Hi, Acee, Peter and Ketan:

 

I propose we limit the usage of LSInfinity within the network. That is to say, 
we should depreciate its usages, not enhance it.

 

As defined in RFC2328, the sole purpose of LSInfinity is to let the receiver 
bypass the SPF calculation for the associated LSA:

a) In case the advertisement of LSA for some special aim.

b) Another is for the premature aging the LSA (which is not encouraged). 

There is few application for the a) usage until now, same situation for b) 
usage.

 

The reason for the above situations may be the definition within the RFC2328 is 
counterintuitivethe maximum value of the metric should be used for the last 
resort of the reachability, no other more meanings. Or else, it will complex 
the implementation and deployment, for example:

a) For OSPFv2, the LSInfinity is defined as 0xff

b) For IS-IS, the equivalent variable is MAX_PATH_METRIC, which is defined 
as 0xFE00

c) For OSPFv3, which value will you be defined, especially for the 
Intra-Area-Prefix? Considering the metric for the intra-area and inter-area are 
all 24-bit long?

d) And, for the metric in ”IP Algorithm Prefix Reachability” , 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.3, 
its length is again 32-bit, will you define another LSInfinity value later?

Won’t you think the above special rule complex the whole situation?

 

I think we should seek other methods to achieve the necessary goals.

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, October 8, 2022 4:03 AM
To: Ketan Talaulikar ; Peter Psenak 

Cc: lsr@ietf.org
Subject: Re: [Lsr] RFC 8362 and LSInfinity

 

Hi Peter, Ketan, 

 

We’ll do another WG last call on the updated IP Flex Algo document and it will 
update RFC 8362. As you probably surmised, this is useful for OSPFv3 IP Flex 
Algorithm when you want don’t want to use the prefix with the base algorithm. 

 

From: Lsr mailto:lsr-boun...@ietf.org> > on behalf of 
Ketan Talaulikar mailto:ketant.i...@gmail.com> >
Date: Thursday, October 6, 2022 at 3:35 AM
To: Peter Psenak mailto:ppsenak=40cisco@dmarc.ietf.org> >
Cc: "lsr@ietf.org <mailto:lsr@ietf.org> " mailto:lsr@ietf.org> >
Subject: Re: [Lsr] RFC 8362 and LSInfinity

 

Hi Peter,

 

I support this "update" - not sure if it qualifies as a "clarification". Also, 
this obviously is doable only when the network has migrated to use only 
Extended LSAs (i.e., legacy LSAs are removed) as indicated in 
https://www.rfc-editor.org/rfc/rfc8362.html#section-6.1

 

In sparse-mode, the legacy LSAs are used. So if you want a prefix to be 
unreachable with the base algorithm, simply omit it from the legacy 
Intra-Area-Prefix LSA. 

 

Thanks,
Acee

 

Thanks,

Ketan

 

 

On Wed, Oct 5, 2022 at 3:01 PM Peter Psenak mailto:40cisco@dmarc.ietf.org> > wrote:

Hi Folks,

metric of LSInfinity (0xFF) has been defined in RFC2328:

LSInfinity
 The metric value indicating that the destination described by an
 LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
 an alternative to premature aging (see Section 14.1). It is
 defined to be the 24-bit binary value of all ones: 0xff.

RFC5340 inherited it from RFC2328:

Appendix B.  Architectural Constants

Architectural constants for the OSPF protocol are defined in Appendix
B of [OSPFV2].  The only difference for OSPF for IPv6 is that
DefaultDestination is encoded as a prefix with length 0 (see
Appendix A.4.1).

Both RFC2328 and RFC5340 used 16 bits metric for intra-area prefix 
reachability, so the LSInfinity was not applicable for intra-area prefixes.

RFC8362 defines 24-bit metric for all prefix reachability TLVs -
Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, External-Prefix TLV.
Although it is silent about the LSInfinity as such, it is assumed that 
such metric means unreachability for Inter-Area-Prefix TLV and 
External-Prefix TLV. Given that Intra-Area-Prefix TLV now has 24 bits 
metric as well, it would make sense to define the LSInfinity as 
unreachable for Intra-Area-Prefix TLV as well.

Would anyone object such a clarification in RFC8362?

thanks,
Peter

___
Lsr mailing list
Lsr@ietf.org <mailto: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] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Aijun Wang]

Hi, Zhibo:

OK.

Regarding to the point #1, it is better to relax the description for more 
broader applications of SRv6 SID information. You can also keep it in the 
current status because it doesn’t not say “MUST only” be included in the 
mentioned TLVs.

Regarding to point #2, using the newly defined LSA may be one more clean way to 
introduce the SRv6 Locator information within the existing OSPF network, or 
else, we must exploit the LSInfinity field, which may introduce more confusions 
when different router interprets its meaning differently. 

Let’s constrain  the LSInfinity within its original purpose.


Aijun Wang
China Telecom

> On Aug 19, 2022, at 18:27, Huzhibo  
> wrote:
> 
> Hi Aijun,
>  
> Thanks for your detailed review and please check inline below for responses.
>  
>  
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Aijun Wang
> Sent: Friday, August 19, 2022 5:55 PM
> To: 'Acee Lindem (acee)' ; 'lsr' 
> 
> Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> Subject: Re: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>  
> Hi, All:
>  I have the following comments for this draft, and would like to support 
> its forwarding when the below concerns are addressed.
> 
> 1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
> advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
>   There are situations that such information can be utilized by the routers 
> within the area, as I presented at the IETF 114 meeting (the draft is pending 
> to be updated).  Then the following sentence:
>“SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
>for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
>specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-
>Router-Link TLV.”
>   
> Should be relaxed as:
>“SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except
>for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a
>specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
> Neighbor/Link related TLVs.”
>  
> Zhibo> This description does not affect the new TLVs. If a new TLV is added, 
> you can include the sub TLV in the new TLV.
>  
> 2. Support for the “SRv6 Locator TLV” to be included within the existing 
> LSA, rather than to define the new “Locator LSA”.
> Zhibo> The reason for defining new LSAs is to prevent processing errors on 
> nodes that do not support SRv6. For example, ignoring algorithm fields may 
> cause loops.
> Of course, using LSinfinity metric is one way to solve this problem, but the 
> protocol specifies the IGP does not generate the RIB/Fib for LSinfinity 
> Metric prefix.
> The LSinfinity metric does not meet this scenario. In addition, IS-IS also 
> defines a New TOP TLV. The OSPF definition is the same as that of IS-IS.
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
> (acee)
> Sent: Saturday, July 30, 2022 1:17 AM
> To: lsr 
> Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
> Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
> draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)
>  
> As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
> ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
> extra week is to account for PIST (Post-IETF Stress Syndrome). The 
> corresponding IS-IS draft is already on the RFC Queue and there are 
> implementations.
>  
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/
>  
>  
> Thanks,
> Acee & Chris
>  
>  
> ___
> 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] Working Group Last Call for "OSPFv3 Extensions for SRv6" - draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

[Aijun Wang]

Hi, All:

 I have the following comments for this draft, and would like to support 
its forwarding when the below concerns are addressed.

 

1. For SRv6 SID’s advertisement, I suggest we should also consider it is 
advertised as sub-TLVs of OSPF-Stub-Link TLV, as proposed in 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-04#section-4.1.
  There are situations that such information can be utilized by the routers 
within the area, as I presented at the IETF 114 meeting (the draft is pending 
to be updated).  Then the following sentence:

   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except

   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a

   specific Neighbor/Link and are therefore advertised as Sub-TLVs of E-

   Router-Link TLV.”

   

Should be relaxed as:

   “SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except

   for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a

   specific Neighbor/Link and are therefore advertised as Sub-TLVs of 
Neighbor/Link related TLVs.”

 

 

2. Support for the “SRv6 Locator TLV” to be included within the existing 
LSA, rather than to define the new “Locator LSA”. 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Acee Lindem 
(acee)
Sent: Saturday, July 30, 2022 1:17 AM
To: lsr 
Cc: draft-ietf-lsr-ospfv3-srv6-extensi...@ietf.org
Subject: [Lsr] Working Group Last Call for "OSPFv3 Extensions for SRv6" - 
draft-ietf-lsr-ospfv3-srv6-extensions-06.txt (Corrected Address)

 

As promised in today’s LSR WG meeting, this begins a 3 week WG Last Call, 
ending on August 19th, 2022, for draft-ietf-lsr-ospfv3-srv6-extensions. The 
extra week is to account for PIST (Post-IETF Stress Syndrome). The 
corresponding IS-IS draft is already on the RFC Queue and there are 
implementations. 

 

https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-srv6-extensions/ 

 

 

Thanks,

Acee & Chris

 

 

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

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Aijun Wang]

Hi, Chris:
If so, let’s adopt them directly then, why seek the opinions from the WG?
I would like to illustrate my opinions again:
Application specific attributes just one small part of the application based 
solution, there are other issues needed to be considered and solved. And I 
think the alternative systematic  solution will obsolete RFC8919 and RFC8920 
together.
The bis draft are just repeating its precedent, and will be replaced also 
accordingly, unless it solves the issues that I mentioned.

Aijun Wang
China Telecom

> On Aug 9, 2022, at 21:50, Christian Hopps  wrote:
> 
> 
> We were asked by the AD to process these clarifications using bis drafts, 
> rather than errata. That is what this is. There should be no controversy 
> here. Let's not create any, please.
> 
> Thanks,
> Chris.
> 
> Aijun Wang  writes:
> 
>> Hi, Acee, Peter:
>> 
>> If there is no significant updates for these two RFCs, I recommend we delay 
>> the obsolete of them, also the adoption call for these two bis drafts.
>> What we should do is to find other more scalable, extensible and systematic 
>> approaches for the application specified advertisements.
>> 
>> For example, for the multiple application scenarios, is it enough just 
>> define the application specified attributes?
>> 
>> From my understandings, different applications may build different LSDBs, run
>> different SPF algorithm, update at different frequencies, forming different
>> forwarding tables etc. It is necessary to divide/group all the above items 
>> based
>> on application, not just the attributes.
>> 
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Aug 9, 2022, at 18:31, Acee Lindem (acee)  wrote:
>>> 
>>> Hi Aijun,
>>> 
>>> And the BIS changes are more clarifications than changes to the existing 
>>> RFC 8919 and RFC 8920 RFCs.
>>> 
>>> Thanks,
>>> Acee
>>> 
>>> On 8/9/22, 5:57 AM, "Peter Psenak"  wrote:
>>> 
>>>   Aijun,
>>> 
>>>>   On 09/08/2022 05:35, Aijun Wang wrote:
>>>> Hi,
>>>> 
>>>> I am wondering why we are so hurry to obsolete RFC8919, given that only the
>>>> minor parts are  updated (mainly the zero length SABM/UABM, and other
>>>> interoperability issues).
>>>> There may be other methods to advertise the application specific 
>>>> attributes.
>>>>> From my POV, the rules, implementation of ASLA are still complex, the
>>>> deployment of them are challenging.
>>>> 
>>>> Is there any real deployment for RFC8919 until now?
>>> 
>>>   sure there are deployments of it. Flex-algo is built around RFC8919, so
>>>   any network where flex-algo is used with ISIS is using RFC8919.
>>> 
>>>   Peter
>>> 
>>>> 
>>>> Best Regards
>>>> 
>>>> Aijun Wang
>>>> China Telecom
>>>> 
>>>> -Original Message-
>>>> From: lsr-boun...@ietf.org  On Behalf Of Christian
>>>> Hopps
>>>> Sent: Monday, August 8, 2022 6:17 PM
>>>> To: lsr@ietf.org
>>>> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
>>>> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
>>>> 
>>>> 
>>>> Hi Folks,
>>>> 
>>>> This begins a 2 week WG Adoption Call for the following draft:
>>>> 
>>>>  https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
>>>> 
>>>> Please indicate your support or objections by August 22nd, 2022.
>>>> 
>>>> Authors, please respond to the list indicating whether you are aware of any
>>>> IPR that applies to these drafts.
>>>> 
>>>> Thanks,
>>>> Chris.
>>>> 
>>>> ___
>>>> Lsr mailing list
>>>> Lsr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>> 
>>> 
>>> 
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
> 


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

Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02

[Aijun Wang]

Hi, Acee, Peter:

If there is no significant updates for these two RFCs, I recommend we delay the 
obsolete of them, also the adoption call for these two bis drafts.
What we should do is to find other more scalable, extensible and systematic 
approaches for the application specified advertisements.

For example, for the multiple application scenarios, is it enough just define 
the application specified attributes? 

From my understandings, different applications may build different LSDBs, run 
different SPF algorithm, update at different frequencies, forming different 
forwarding tables etc. It is necessary to divide/group all the above items 
based on application, not just the attributes.


Aijun Wang
China Telecom

> On Aug 9, 2022, at 18:31, Acee Lindem (acee)  wrote:
> 
> Hi Aijun, 
> 
> And the BIS changes are more clarifications than changes to the existing RFC 
> 8919 and RFC 8920 RFCs. 
> 
> Thanks,
> Acee 
> 
> On 8/9/22, 5:57 AM, "Peter Psenak"  wrote:
> 
>    Aijun,
> 
>>On 09/08/2022 05:35, Aijun Wang wrote:
>> Hi,
>> 
>> I am wondering why we are so hurry to obsolete RFC8919, given that only the
>> minor parts are  updated (mainly the zero length SABM/UABM, and other
>> interoperability issues).
>> There may be other methods to advertise the application specific attributes.
>>> From my POV, the rules, implementation of ASLA are still complex, the
>> deployment of them are challenging.
>> 
>> Is there any real deployment for RFC8919 until now?
> 
>sure there are deployments of it. Flex-algo is built around RFC8919, so 
>any network where flex-algo is used with ISIS is using RFC8919.
> 
>Peter
> 
>> 
>> Best Regards
>> 
>> Aijun Wang
>> China Telecom
>> 
>> -Original Message-
>> From: lsr-boun...@ietf.org  On Behalf Of Christian
>> Hopps
>> Sent: Monday, August 8, 2022 6:17 PM
>> To: lsr@ietf.org
>> Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
>> Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
>> 
>> 
>> Hi Folks,
>> 
>> This begins a 2 week WG Adoption Call for the following draft:
>> 
>>   https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/
>> 
>> Please indicate your support or objections by August 22nd, 2022.
>> 
>> Authors, please respond to the list indicating whether you are aware of any
>> IPR that applies to these drafts.
>> 
>> Thanks,
>> Chris.
>> 
>> ___
>> Lsr mailing list
>> 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 for draft-ginsberg-lsr-rfc8919bis-02

[Aijun Wang]

Hi, 

I am wondering why we are so hurry to obsolete RFC8919, given that only the
minor parts are  updated (mainly the zero length SABM/UABM, and other
interoperability issues).
There may be other methods to advertise the application specific attributes.
>From my POV, the rules, implementation of ASLA are still complex, the
deployment of them are challenging. 

Is there any real deployment for RFC8919 until now?

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Christian
Hopps
Sent: Monday, August 8, 2022 6:17 PM
To: lsr@ietf.org
Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org
Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02


Hi Folks,

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

  https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/

Please indicate your support or objections by August 22nd, 2022.

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

Thanks,
Chris.

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

Re: [Lsr] Question about draft-ppsenak-lsr-igp-ureach-prefix-announce

[Aijun Wang]

Hi, Peter:

Extend the meaning of "LSInifinity" for indicating the unreachability will
again complex the deployment.
Comply with the original rules for "LSInifinity" in related RFCs (that is,
"bypass the SPF calculation for the prefixed that carried with this value")
will generate less back compatible issues and also enable the future usage
of "LSInfinity".
As cited in your draft:(also in RFC5305)

"If a prefix is advertised with a metric larger then MAX_PATH_METRIC
   (0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
   during the normal SPF computation.  This allows advertisement of a
   prefix for purposes other than building the normal IP routing table.
   "
The "purposes" of such prefixes should be indicated explicitly by other
means, as that proposed in the PUA draft.

Best Regards

Aijun Wang
China Telecom




-Original Message-
From: lsr-boun...@ietf.org  On Behalf Of Peter Psenak
Sent: Friday, August 5, 2022 1:55 PM
To: Huzhibo 
Cc: lsr@ietf.org
Subject: Re: [Lsr] Question about
draft-ppsenak-lsr-igp-ureach-prefix-announce

Zhibo,

On 03/08/2022 21:09, Huzhibo wrote:
> Hi Peter:
>   Please see inline.
> 
>> -Original Message-
>> From: Peter Psenak [mailto:ppse...@cisco.com]
>> Sent: Wednesday, August 3, 2022 11:20 PM
>> To: Huzhibo 
>> Cc: lsr@ietf.org
>> Subject: Re: Question about 
>> draft-ppsenak-lsr-igp-ureach-prefix-announce
>>
>> Hi Zhibo,
>>
>> On 29/07/2022 20:49, Huzhibo wrote:
>>> Hi Peter:
>>>
>>> Supplement to yesterday's online questions, If a node that does not 
>>> support IP Flexalgo, which has a default route, should the node 
>>> process the IP Flexalgo prefix as a UPA?
>>
>> - I assume you are talking about the algo 0 default route. Because IP 
>> Flex-algo default route does not make much sense really.
>>
>> - If the node does not support IP flex-algo, than it would not use 
>> any IP algo prefix as BGP service endpoint or for any other purpose.
>>
> 
> Which IP Algo prefix as BGP service endpoint is not determined by the
ingress node, Such as VXLAN and SRv6 VPN.
> When the ingress node receives an BGP Service cayyied a IP algo prefix 
> as endpoint and it has a algo 0 default route, it should be process this
BGP service. and this can not be affected by the IGP Flexalgo prefix.

sorry, but above is completely wrong.

When you want to use IP flex-algo forwarding, you must advertise the prefix
as algo prefix, relying on the algo 0 default would not give you algo
forwarding.

Advertising IP algo prefix at the egress and relying in algo 0 default at
the ingress is going to cause all sorts of problems. You CAN NOT mix/change
algos along the path through the network - if you do, you may end up in a
permanent loop.


> Therefore,
> the IGP does only not generate the RIB/Fib for LSinfinity Metric prefix,
but can not trigger BGP Service Down.
> In addition, LSinfinity Metric may be applied to other scenarios in 
> the future. We cannot guarantee that LSinfinity Metric will not conflict
with other purposes when being processed as a UPA.

no, it can not, because the LSinfinity has a very strict definition - it
means unreachable, which is exactly what the UPA is about.

Peter

> 
>> - If such node receives the IP algo prefix and even if it treats it 
>> as UPA, given that such IP algo prefix was never reachable before on 
>> this node, the UPA would result in no action.
>>
>> thanks,
>> Peter
>>>
>>> Thanks
>>>
>>> Zhibo
>>>
>>
> 
> 

___
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] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]

Hi, Peter:
I think you and all the subscribers of the LSR mail list have noticed not only 
Zhibo express the opinions that LSInfinity cannot be used to indicate the 
prefix is unreachable. There should exist other explicit indication.
Should we stop arguing this point then?

Aijun Wang
China Telecom

> On Jul 29, 2022, at 19:19, Peter Psenak  wrote:
> 
> Zhibo,
> 
>> On 28/07/2022 22:07, Huzhibo wrote:
>> Peter
>>> -Original Message-
>>> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Peter Psenak
>>> Sent: Friday, July 29, 2022 8:33 AM
>>> To: Aijun Wang ; Acee Lindem (acee)
>>> 
>>> Cc: Ketan Talaulikar ; Les Ginsberg (ginsberg)
>>> ;
>>> draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr 
>>> Subject: Re: [Lsr] Comments on
>>> draft-wang-lsr-prefix-unreachable-annoucement
>>> 
>>> Aijun,
>>> 
>>> On 28/07/2022 19:55, Aijun Wang wrote:
>>>> Hi, Acee:
>>>> 
>>>> Thanks for your comments, but most of them are indefensible,
>>>> especially the conclusion.
>>>> As you have also noticed, UPA mechanism doesn’t consider the network
>>>> partition scenarios, doesn’t consider how to control the number of
>>>> advertisement of unreachable messages, doesn’t provide the explicit
>>>> notification of unreachable statement(as also pointed out Ketan, Bruno
>>>> etc.), then how you hurry to get the conclusion that UPA is superior to 
>>>> PUA?
>>> 
>>> IETF documents are not deployment guides, nor design or implementation
>>> documents, not the source of education for the other vendors.
>>> 
>>> IETF documents are there to specify the bare minimum to achieve
>>> interoperability.
>>> 
>>> In other words, the fact that you put more content in your document, does 
>>> not
>>> make it any better. Contrary, the less you need to do to achieve the
>>> interoperability, the better it is.
>> [HZB] More content you mentioned of the documents are addresses comments on 
>> the promotion of this document.
>> It is an essential part of a complete solution.
>> RFC 5305 define that LSInfinity metric is used for other purposes other than
>> building the normal routing table. UPA uses LSInfinity metric only to 
>> identify unreachable prefixes, which is contrary to RFC 5305.
> 
> no, it is in perfect compliance with RFC 5305.
> 
>> [draft-ietf-lsr-ip-flexalgo] also uses LSInfinity metric. It may also be 
>> applied to other purposes.
> 
> which is orthogonal to our discussion here, because if the valid metric 
> exists in IP Algorithm Prefix Reachability Sub-TLV, the metric in parent TLV 
> is ignored. There is no problem here.
> 
>> Therefore, using LSInfinity metric alone is not enough.
> 
> that's what you claim, bit that is not necessary true.
> 
> Peter
> 
> 
>> In conclusion, the PUA solution is more complete and the unreachable prefix 
>> is defined in a more reasonable manner.
>> Zhibo Hu
>>> Peter
>>> 
>>> 
>>>> 
>>>> We have yet mentioned that PUA mechanism has been discussed two years
>>>> before the UPA solution.
>>>> 
>>>> More responses are inline. Anyway, I am glad that your comments have
>>>> some bases, although you misunderstood something.
>>>> 
>>>> Aijun Wang
>>>> China Telecom
>>>> 
>>>>> On Jul 29, 2022, at 02:04, Acee Lindem (acee)  wrote:
>>>>> 
>>>>> Speaking as WG Member:
>>>>> 
>>>>> Hi Ketan,
>>>>> 
>>>>> Thanks for pointing out the similarities. Even after the recent
>>>>> changes,  there are still some difference between the drafts which
>>>>> I’ll describe in the baseless comments which follow. For conciseness,
>>>>> I’ll refer to the drafts as PUA (Draft Wang) and UPA (Draft Psenak).
>>>>> 
>>>>>  1. Backward Compatibility – Now that PUA has appropriated the metric
>>>>> mechanisms from UPA, it is also backward compatible. However, PUA
>>>>> still proposes extensions the IGPs to advertise the PUA
>>>>> capabilities and says the nodes may misbehave if they don’t agree
>>>>> on these capabilities. I guess removing these was omitted when the
>>>>> UPA metric mechanisms were appropriated.
>>>> 
>>>> WAJ] No. the context in the document just describes why and when the
&

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Robert:
I think your proposal are valid. 
Option C like deployment can also use such information to select the optimized 
inter-AS link to reach the routers in other domain. 
The final effect will be like the EPE scenario.

Aijun Wang
China Telecom

> On Jul 29, 2022, at 16:44, Robert Raszuk  wrote:
> 
> 
> Hi Aijun,
> 
> How does this proposal impacts BGP path selection ? 
> 
> Note that it is common to do next hop self on the ASBRs towards the 
> intradomain. So your proposal would not require any signalling to be 
> effective on a given ASBR. Local decision. 
> 
> Originally I was under impression that you want to enhance TE for option C 
> like deployments. But if not then I see not much point of doing it. 
> 
> Thx,
> R.
> 
>> On Fri, Jul 29, 2022 at 4:09 AM Aijun Wang  wrote:
>> Hi, Ketan:
>> 
>>  
>> 
>> In the inter-AS scenario, we will not deploy BGP session on each p2p link. 
>> The BGP session exists only within the loopback address of each ASBR pair.
>> 
>> Such deployment is also same in the LAN scenario. Then there is no mesh or 
>> partial p2p link that congruent to the BGP sessions.
>> 
>> But such LAN interfaces are sharing the same prefixes.
>> 
>>  
>> 
>> And regarding to your comments on Prefix sub-TLV: yes, if we redistribute 
>> such external prefixes into the IGP, then they will be transported within 
>> the associated “External Prefixes TLV”.
>> 
>> But for these stub links, if we configure them as “passive” only( no 
>> redistributed action), then the prefixes of these stub links will not exists 
>> within the IGP LSA.
>> 
>> Attach the prefixes information with these stub links can certainly fill 
>> such gap. There will be no redundancy information.
>> 
>>  
>> 
>> And, regarding to your comments: “… …- at least let us not go overboard and 
>> repeat the same info in multiple places. ”, this is also the main reason 
>> that we don’t want to use the RFC5316/RFC5392 mechanism to accomplish the 
>> goal for the inter-as topology recovery--there will be many redundancy 
>> information being flooded within the IGP area.
>> 
>>  
>> 
>>  
>> 
>> Best Regards
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>>  
>> 
>>  
>> 
>> From: Ketan Talaulikar  
>> Sent: Thursday, July 28, 2022 4:54 PM
>> To: Aijun Wang 
>> Cc: Les Ginsberg (ginsberg) ; Acee 
>> Lindem (acee) ; lsr 
>> Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>> 
>>  
>> 
>> Hi Aijun,
>> 
>>  
>> 
>> Please check inline below.
>> 
>>  
>> 
>> On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang  wrote:
>> 
>> Hi, Ketan:
>> 
>>  
>> 
>> There are situation that such information is necessary: 
>> 
>> When several ASes are connected via the LAN interface, it is impossible to 
>> describe the inter-AS relationship with the current descriptors that 
>> provided by RFC5316 and RFC5392.
>> 
>>  
>> 
>> KT> Note that we have BGP running on these Inter-AS links. Even when there 
>> is an underlying LAN, the BGP sessions are p-t-p and maybe a full or partial 
>> mesh. Therefore, I believe representing such a LAN as a mesh of p-t-p links 
>> that are congruent to the BGP sessions is the right approach. I am happy to 
>> be corrected. In any case, I still fail to see how a prefix associated with 
>> the links helps here.
>> 
>>  
>> 
>>  
>> 
>> And another scenario is that when these stub links are used to correct 
>> servers, there is no remote-AS, remote ASBR ID information. But we can 
>> distinguish different stub link via their associated prefixes.
>> 
>>  
>> 
>> KT> I disagree - such stub links can be identified by their local interface 
>> ids along with their local IP address. Note that we already have the 
>> corresponding prefix being advertised as prefix reachability. So I don't see 
>> the need to repeat. All of this is already overloading IGPs with info that 
>> is not used by IGPs - at least let us not go overboard and repeat the same 
>> info in multiple places. 
>> 
>>  
>> 
>> Please check the new fresh thread about use-cases.
>> 
>>  
>> 
>> Thanks,
>> 
>> Ketan
>> 
>>  
>> 
>>  
>> 
>> Aijun Wang
>> 
>> China Telecom
>> 
>> 
>> 
>> 
>> On Jul 28, 2022, at 15:03, Ketan Talaulikar  wrote

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Ketan:

 

In the inter-AS scenario, we will not deploy BGP session on each p2p link. The 
BGP session exists only within the loopback address of each ASBR pair.

Such deployment is also same in the LAN scenario. Then there is no mesh or 
partial p2p link that congruent to the BGP sessions.

But such LAN interfaces are sharing the same prefixes.

 

And regarding to your comments on Prefix sub-TLV: yes, if we redistribute such 
external prefixes into the IGP, then they will be transported within the 
associated “External Prefixes TLV”.

But for these stub links, if we configure them as “passive” only( no 
redistributed action), then the prefixes of these stub links will not exists 
within the IGP LSA.

Attach the prefixes information with these stub links can certainly fill such 
gap. There will be no redundancy information.

 

And, regarding to your comments: “… …- at least let us not go overboard and 
repeat the same info in multiple places. ”, this is also the main reason that 
we don’t want to use the RFC5316/RFC5392 mechanism to accomplish the goal for 
the inter-as topology recovery--there will be many redundancy information 
being flooded within the IGP area.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

 

From: Ketan Talaulikar  
Sent: Thursday, July 28, 2022 4:54 PM
To: Aijun Wang 
Cc: Les Ginsberg (ginsberg) ; Acee Lindem 
(acee) ; lsr 
Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

 

Hi Aijun,

 

Please check inline below.

 

On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

There are situation that such information is necessary: 

When several ASes are connected via the LAN interface, it is impossible to 
describe the inter-AS relationship with the current descriptors that provided 
by RFC5316 and RFC5392.

 

KT> Note that we have BGP running on these Inter-AS links. Even when there is 
an underlying LAN, the BGP sessions are p-t-p and maybe a full or partial mesh. 
Therefore, I believe representing such a LAN as a mesh of p-t-p links that are 
congruent to the BGP sessions is the right approach. I am happy to be 
corrected. In any case, I still fail to see how a prefix associated with the 
links helps here.

 

 

And another scenario is that when these stub links are used to correct servers, 
there is no remote-AS, remote ASBR ID information. But we can distinguish 
different stub link via their associated prefixes.

 

KT> I disagree - such stub links can be identified by their local interface ids 
along with their local IP address. Note that we already have the corresponding 
prefix being advertised as prefix reachability. So I don't see the need to 
repeat. All of this is already overloading IGPs with info that is not used by 
IGPs - at least let us not go overboard and repeat the same info in multiple 
places. 

 

Please check the new fresh thread about use-cases.

 

Thanks,

Ketan

 

 

Aijun Wang

China Telecom





On Jul 28, 2022, at 15:03, Ketan Talaulikar mailto:ketant.i...@gmail.com> > wrote:



Hi Aijun,

 

Similar to Les, I disagree with you on the use of Prefix TLV as an attribute of 
the "Stub Link". The reason is that this attribute is not required for the 
identification of a link in BGP-LS (or in IGPs for that matter) that was the 
main use case. I also don't see the use of that in Inter-AS links. Please 
justify this.

 

Thanks,

Ketan

 

 

On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Les:

 

Please note the references to RFC5316/RFC5392 in 
draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what we 
are discussing are non-TE scenarios.

For prefixes sub-TLV, would you like to revisit my responses to Ketan, before 
make any comments? For your convenience, I can elaborate again to you——-“The 
prefix sub-TLV is not the link identifier, it is just one kind of link 
attributes”. Is it clear enough?

 

Based on these facts, I think it is unnecessary to response your other baseless 
comments.

 

Aijun Wang

China Telecom





On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org> > 
wrote:

 

Acee –

 

I have a somewhat different take on this draft.

 

I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is relevant 
– but I disagree that the lsr-stub-link draft is needed at all.

In fact one of the main points in the extensive discussion of this draft that 
occurred several months ago  ( see 
https://mailarchive.ietf.org/arch/msg/lsr/8pY4d21J1XOb_GfwgrROJUijLQ8/  as a 
pointer to one email in the thread) was that RFC 5316/RFC 5392 are sufficient 
to support the use case. This is reinforced by the references to those two RFCs 
in the bgpls-inter-as-topology draft.

 

The other main point (discussed in #3 below) is that the use of a prefix as a 
Link Identifier is a flawed concept and has been objected to by many WG 

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]


Hi, Acee:

Thanks for your comments, but most of them are indefensible, especially the 
conclusion.
As you have also noticed, UPA mechanism doesn’t consider the network partition 
scenarios, doesn’t consider how to control the number of advertisement of 
unreachable messages, doesn’t provide the explicit notification of unreachable 
statement(as also pointed out Ketan, Bruno etc.), then how you hurry to get the 
conclusion that UPA is superior to PUA?

We have yet mentioned that PUA mechanism has been discussed two years before 
the UPA solution.

More responses are inline. Anyway, I am glad that your comments have some 
bases, although you misunderstood something.

Aijun Wang
China Telecom

> On Jul 29, 2022, at 02:04, Acee Lindem (acee)  wrote:
> 
> Speaking as WG Member:
>  
> Hi Ketan,
>  
> Thanks for pointing out the similarities. Even after the recent changes,  
> there are still some difference between the drafts which I’ll describe in the 
> baseless comments which follow. For conciseness, I’ll refer to the drafts as 
> PUA (Draft Wang) and UPA (Draft Psenak).
>  
> Backward Compatibility – Now that PUA has appropriated the metric mechanisms 
> from UPA, it is also backward compatible. However, PUA still proposes 
> extensions the IGPs to advertise the PUA capabilities and says the nodes may 
> misbehave if they don’t agree on these capabilities. I guess removing these 
> was omitted when the UPA metric mechanisms were appropriated.

WAJ] No. the context in the document just describes why and when the LSInfinity 
is necessary. The usages of LSInfinity in two drafts are different: one(PUA) is 
to avoid the misbehavior(which is conform to the RFC rules), another(UPA) is to 
indicate the unreachable information(which is not described in the RFC rules)

> Receive Router Behavior – For UPA, the unreachable prefix notification is 
> solely for an event signal to be used by other routers in the IGP domain to 
> trigger actions, e.g., BGP PIC excluding the unreachable prefix.  PUA is used 
> for the switchover of services as well but is also used to modify persistent 
> state. In section 4, the PUA advertisement will trigger the advertisement of 
> the prefix by an ABR that does have a route to the unreachable prefix 
> advertised by another ABR.
[WAJ] Is this one evidence that PUA covers UPA?
> Advertisement Persistence – PUA is advertised like any other LSA and 
> presumably advertised as long as the prefix is unreachable. Conversely, UPA 
> is an ephemeral LSA that will be withdrawn after enough time is allowed for 
> the event notification to propagate.
[WAJ] No. if there is no network update again, the PUA will not be advertised 
“as long as the prefix is unreachable “. Actually, there is description in the 
document:

   “The advertisement of PUAM message should only last one configurable
   period to allow the services that run on the failure prefixes are
   switchovered.  If one prefix is missed before the PUAM takes effect,
   the ABR will not declare its absence via the PUAM.”

I think you may ignore them.

>  
> In my opinion, UPA is superior to PUA since it is addresses the original 
> requirement with minimal overhead and changes to the IGP. Even after many 
> revisions, PUA still contains a lot of additional unnecessary overhead and 
> complexity. I think the WG should adopt UPA and not spend any more time on 
> this discussion.  
>  
[WAJ] From the above responses, I think you should realize that UPA just cover 
very minor part of the overall PUA solution, then your conclusion should be 
reverted.
Or else, we can compare these two drafts sentences by sentences.

> Thanks,
> Acee
>  
> From: Lsr  on behalf of Ketan Talaulikar 
> 
> Date: Thursday, July 28, 2022 at 2:29 AM
> To: Aijun Wang 
> Cc: "Les Ginsberg (ginsberg)" , 
> "draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org" 
> , lsr 
> Subject: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
>  
> Hi Aijun,
>  
> Indeed, your draft has done a "pivot" in the latest version with the use of 
> LSInfinity like the UPA proposal. I hope you will do yet another "pivot" to 
> move away from the use of Prefix Originator.
>  
> IMHO that would also bring the PUA and UPA proposals much closer to each 
> other.
>  
> Thanks,
> Ketan
>  
>  
> On Thu, Jul 28, 2022 at 6:52 AM Aijun Wang  wrote:
> Hi, Les:
>  
> I admire you and your comments as usual, but the baseless comments will 
> decrease your credits within the WG. Would you like to review the update of 
> the draft more carefully, then post your comments? Doing this can avoid 
> misleading some of your followers.
>  
> To facilitate your review, I copied the related contents 
> again:(https://datatracker.ietf.org/doc/ht

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Ketan:

There are situation that such information is necessary: 
When several ASes are connected via the LAN interface, it is impossible to 
describe the inter-AS relationship with the current descriptors that provided 
by RFC5316 and RFC5392.

And another scenario is that when these stub links are used to correct servers, 
there is no remote-AS, remote ASBR ID information. But we can distinguish 
different stub link via their associated prefixes.

Aijun Wang
China Telecom

> On Jul 28, 2022, at 15:03, Ketan Talaulikar  wrote:
> 
> 
> Hi Aijun,
> 
> Similar to Les, I disagree with you on the use of Prefix TLV as an attribute 
> of the "Stub Link". The reason is that this attribute is not required for the 
> identification of a link in BGP-LS (or in IGPs for that matter) that was the 
> main use case. I also don't see the use of that in Inter-AS links. Please 
> justify this.
> 
> Thanks,
> Ketan
> 
> 
>> On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang  
>> wrote:
>> Hi, Les:
>> 
>> Please note the references to RFC5316/RFC5392 in 
>> draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what 
>> we are discussing are non-TE scenarios.
>> For prefixes sub-TLV, would you like to revisit my responses to Ketan, 
>> before make any comments? For your convenience, I can elaborate again to 
>> you——-“The prefix sub-TLV is not the link identifier, it is just one kind of 
>> link attributes”. Is it clear enough?
>> 
>> Based on these facts, I think it is unnecessary to response your other 
>> baseless comments.
>> 
>> Aijun Wang
>> China Telecom
>> 
>>>> On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg) 
>>>>  wrote:
>>>> 
>>> 
>>> Acee –
>>> 
>>>  
>>> 
>>> I have a somewhat different take on this draft.
>>> 
>>>  
>>> 
>>> I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is 
>>> relevant – but I disagree that the lsr-stub-link draft is needed at all.
>>> 
>>> In fact one of the main points in the extensive discussion of this draft 
>>> that occurred several months ago  ( see 
>>> https://mailarchive.ietf.org/arch/msg/lsr/8pY4d21J1XOb_GfwgrROJUijLQ8/  as 
>>> a pointer to one email in the thread) was that RFC 5316/RFC 5392 are 
>>> sufficient to support the use case. This is reinforced by the references to 
>>> those two RFCs in the bgpls-inter-as-topology draft.
>>> 
>>>  
>>> 
>>> The other main point (discussed in #3 below) is that the use of a prefix as 
>>> a Link Identifier is a flawed concept and has been objected to by many WG 
>>> members.
>>> 
>>>  
>>> 
>>> For these reasons I believe this draft is unnecessary and undesirable.
>>> 
>>>  
>>> 
>>> Given the extensive review of the draft by many members of the WG and the 
>>> failed WG adoption, I believe the WG should move on to other priorities. I 
>>> understand that the authors of lsr-stub-link have not been convinced and 
>>> want to continue to advocate for the draft, but at some point the WG needs 
>>> to say we have done due diligence and the WG consensus is NOT to adopt the 
>>> draft. The continued discussion of this draft consumes WG resources 
>>> (including presentation slots) and diverts WG attention from other work.
>>> 
>>>  
>>> 
>>>Les
>>> 
>>>  
>>> 
>>>  
>>> 
>>> From: Lsr  On Behalf Of Acee Lindem (acee)
>>> Sent: Wednesday, July 27, 2022 11:37 AM
>>> To: Ketan Talaulikar ; 
>>> draft-wang-lsr-stub-link-attribu...@ietf.org
>>> Cc: lsr 
>>> Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>>> 
>>>  
>>> 
>>> Hi Ketan,
>>> 
>>> I’m glad you brought this up. The primary (and AFAIK only) reason for this 
>>> draft is to get the stub-link information to a router in the IGP domain 
>>> running BGP-LS so that it can be advertised to the controller. For 
>>> reference, see 
>>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt
>>>  figure 1. So, the IGP encoding is only to get the stub-link information 
>>> from B1 and B3 to S2 and from B2 and B4 to T1. Since the IGPs and TE are 
>>> not consuming the information, the problem could be avoid by simply running 
>>> BGP-LS on B1-B4. See inline.
>>> 
>>>  
>>> 
>>>  
>>&

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Ketan:

For the mentioned scenario, not only  we need to run BGP-LS on every edge 
router, but also we need to configure every inter-AS link the following 
information: remote—AS number, remote ASBR ID. 
Regardless of the redundancy configured efforts, such information will be also 
need to imported into the TE Database unnecessary , as also pointed out by you.

And, imagining there are lots of inter-AS links between the ASBRs in real 
deployments, such approach is certainly not extensible and should be avoided.

From the POV of operator, we want to keep the network simple and easy to 
operate.

Aijun Wang
China Telecom

> On Jul 28, 2022, at 14:58, Ketan Talaulikar  wrote:
> 
> 
> Hi Acee,
> 
> Thanks for your clarifications and please check inline below for responses as 
> co-author of the referenced BGP-LS draft with Aijun.
> 
>> On Thu, Jul 28, 2022 at 12:07 AM Acee Lindem (acee)  wrote:
>> Hi Ketan,
>> 
>> I’m glad you brought this up. The primary (and AFAIK only) reason for this 
>> draft is to get the stub-link information to a router in the IGP domain 
>> running BGP-LS so that it can be advertised to the controller. For 
>> reference, see 
>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt
>>  figure 1. So, the IGP encoding is only to get the stub-link information 
>> from B1 and B3 to S2 and from B2 and B4 to T1. Since the IGPs and TE are not 
>> consuming the information, the problem could be avoid by simply running 
>> BGP-LS on B1-B4.
>> 
> 
> KT> This scenario is addressed in the BGP-LS draft that you point to - i.e., 
> direct advertisement by BGP-LS from B1 and B3. This way the information gets 
> to the controller/application and IGPs don't need to be bothered. My 
> impression is that Aijun wanted to avoid enabling BGP-LS on B1 and B3 - that 
> is the only reason why this is being pushed into the IGPs. Aijun, please 
> correct me, if I am wrong here.
>  
>> See inline.
>> 
>>  
>> 
>>  
>> 
>> From: Lsr  on behalf of Ketan Talaulikar 
>> 
>> Date: Wednesday, July 27, 2022 at 5:33 AM
>> To: "draft-wang-lsr-stub-link-attribu...@ietf.org" 
>> 
>> Cc: lsr 
>> Subject: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>> 
>>  
>> 
>> Hello Authors,
>> 
>>  
>> 
>> Please find below my comments/suggestions on this draft. I am sharing them 
>> upfront given the packed LSR agenda.
>> 
>>  
>> 
>> Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not 
>> sound in my opinion. I would say that the TE encoding may not be suitable 
>> for use in all deployments as their advertisement results in the addition of 
>> those Inter-AS links in a TE topology database and that may not be desired. 
>> So, I would suggest that the draft keeps the option of use of Inter-AS TE 
>> TLVs valid and goes ahead with the Stub Link proposal as an alternative with 
>> broader applicability (also see the next comment).
>>  
>> 
>> Agree.
>> 
>>  
>> 
>> For the proclaimed wider applicability (e.g., links to servers/hosts) in the 
>> slides, there is no such text in the draft. The draft seems focused on 
>> Inter-AS links. I hope the authors update either the draft or the slides - 
>> to be in sync with their objectives.
>>  
>> 
>> It is solely for purposes of advertisement in BGP-LS and consumption by the 
>> SDN controller as described in 
>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt.
>> 
>>  
>> 
>>  
>> 
>> The use of the prefix TLVs in this context is something that is (in my 
>> opinion) broken from day 1 of this draft. Prefixes are for reachability. For 
>> identification of links, we have the local/remote link identifiers along 
>> with the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO 
>> for the progression of this document.
>>  
>> 
>> I agree, if this draft is to persist, these should be referred to as ASBR 
>> addresses as in the IDR draft (the sole raison d’etre for this IGP draft).
>> 
>>  
>> 
>> The placement of the Stub Link TLV should be top-level (similar to 
>> other/existing links). I can share further suggestions offline, provided we 
>> reach an agreement on the above points and we converge on the main 
>> purpose/motivation for this work.
>>  
>> 
>> I feel that strongly here as this is analogous to the new BGP-LS NLRI type 
>> in  
>> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-to

Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Les:

Please note the references to RFC5316/RFC5392 in 
draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what we 
are discussing are non-TE scenarios.
For prefixes sub-TLV, would you like to revisit my responses to Ketan, before 
make any comments? For your convenience, I can elaborate again to you——-“The 
prefix sub-TLV is not the link identifier, it is just one kind of link 
attributes”. Is it clear enough?

Based on these facts, I think it is unnecessary to response your other baseless 
comments.

Aijun Wang
China Telecom

> On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> Acee –
>  
> I have a somewhat different take on this draft.
>  
> I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is 
> relevant – but I disagree that the lsr-stub-link draft is needed at all.
> In fact one of the main points in the extensive discussion of this draft that 
> occurred several months ago  ( see 
> https://mailarchive.ietf.org/arch/msg/lsr/8pY4d21J1XOb_GfwgrROJUijLQ8/  as a 
> pointer to one email in the thread) was that RFC 5316/RFC 5392 are sufficient 
> to support the use case. This is reinforced by the references to those two 
> RFCs in the bgpls-inter-as-topology draft.
>  
> The other main point (discussed in #3 below) is that the use of a prefix as a 
> Link Identifier is a flawed concept and has been objected to by many WG 
> members.
>  
> For these reasons I believe this draft is unnecessary and undesirable.
>  
> Given the extensive review of the draft by many members of the WG and the 
> failed WG adoption, I believe the WG should move on to other priorities. I 
> understand that the authors of lsr-stub-link have not been convinced and want 
> to continue to advocate for the draft, but at some point the WG needs to say 
> we have done due diligence and the WG consensus is NOT to adopt the draft. 
> The continued discussion of this draft consumes WG resources (including 
> presentation slots) and diverts WG attention from other work.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of Acee Lindem (acee)
> Sent: Wednesday, July 27, 2022 11:37 AM
> To: Ketan Talaulikar ; 
> draft-wang-lsr-stub-link-attribu...@ietf.org
> Cc: lsr 
> Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>  
> Hi Ketan,
> I’m glad you brought this up. The primary (and AFAIK only) reason for this 
> draft is to get the stub-link information to a router in the IGP domain 
> running BGP-LS so that it can be advertised to the controller. For reference, 
> see 
> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt
>  figure 1. So, the IGP encoding is only to get the stub-link information from 
> B1 and B3 to S2 and from B2 and B4 to T1. Since the IGPs and TE are not 
> consuming the information, the problem could be avoid by simply running 
> BGP-LS on B1-B4. See inline.
>  
>  
> From: Lsr  on behalf of Ketan Talaulikar 
> 
> Date: Wednesday, July 27, 2022 at 5:33 AM
> To: "draft-wang-lsr-stub-link-attribu...@ietf.org" 
> 
> Cc: lsr 
> Subject: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
>  
> Hello Authors,
>  
> Please find below my comments/suggestions on this draft. I am sharing them 
> upfront given the packed LSR agenda.
>  
> Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not 
> sound in my opinion. I would say that the TE encoding may not be suitable for 
> use in all deployments as their advertisement results in the addition of 
> those Inter-AS links in a TE topology database and that may not be desired. 
> So, I would suggest that the draft keeps the option of use of Inter-AS TE 
> TLVs valid and goes ahead with the Stub Link proposal as an alternative with 
> broader applicability (also see the next comment).
>  
> Agree.
>  
> For the proclaimed wider applicability (e.g., links to servers/hosts) in the 
> slides, there is no such text in the draft. The draft seems focused on 
> Inter-AS links. I hope the authors update either the draft or the slides - to 
> be in sync with their objectives.
>  
> It is solely for purposes of advertisement in BGP-LS and consumption by the 
> SDN controller as described in 
> https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt.
>  
>  
> The use of the prefix TLVs in this context is something that is (in my 
> opinion) broken from day 1 of this draft. Prefixes are for reachability. For 
> identification of links, we have the local/remote link identifiers along with 
> the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO for the 
> progression of this document.
>  
> I agree, if this draft is to persist, these should be re

[Lsr] 答复: Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Ketan and Acee:

 

Let me answer all your concern in the top post mode for brevity.

1) For inter-AS link that described in  
https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt,
 the AS number needn’t be configured and carried by the advertisement of every 
inter-AS link.

2) The definition and inclusion of “Prefixes sub-TLV” doesn’t preclude 
other sub-TLV (for example, the local and remote identifier of the inter-AS 
link, if they are exist and can be known in advance)being included within the 
“Stub-Link TLV” if necessary.

3) For the encoding of “Stub Link TLV”, I agree with your suggestions. We 
can put them in one more general container. 

For example, OSPFv2 related part can be put in 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-opaque-lsa-tlvs
 (defined as “OSPFv2 Extended Stub-Link TLV”, which is corresponding to “OSPFv2 
Extended Link TLV”)and OSPFv3 related part can be put in 
https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-tlvs
 (defined as “Router-Stub-Link TLV”?, which is corresponding to the 
“Router-Link TLV”).

 

For IS-IS, current version of the draft has stated that:

“Existing Sub-TLVs: Sub-TLVs that defined within "IS-IS Sub-TLVs for

   TLVs Advertising Neighbor Information " can be included if necessary.”

   Is it enough to illustrate that the newly defined TLV is one of the top TLV 
in IS-IS?

 

 

To Acee’s concerns about running BGP-LS in every border router:

We think such solution and deployment will decrease the brevity and efficiency 
of BGP-LS.  Normally, we need only one or two routers(for redundancy) within 
the domain to run BGP-LS with the controller. 

And, for other broader applications(EPE like approach to the connected server), 
such information can also be utilized by other internal routers, not only the 
controller. 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 21:35
收件人: Aijun Wang 
抄送: draft-wang-lsr-stub-link-attribu...@ietf.org; lsr 
主题: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

 

Hi Aijun,

 

Please check inline below.

 

On Wed, Jul 27, 2022 at 5:07 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

Thanks for your comments and suggestions!

Some responses are inline below.

We can update the draft accordingly after we reach consensus on these points.

 

 

Best Regards

 

Aijun Wang

China Telecom.

 

发件人: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 17:32
收件人: draft-wang-lsr-stub-link-attribu...@ietf.org 
<mailto:draft-wang-lsr-stub-link-attribu...@ietf.org> 
抄送: lsr mailto:lsr@ietf.org> >
主题: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

 

Hello Authors,

 

Please find below my comments/suggestions on this draft. I am sharing them 
upfront given the packed LSR agenda.

 

1)  Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not 
sound in my opinion. I would say that the TE encoding may not be suitable for 
use in all deployments as their advertisement results in the addition of those 
Inter-AS links in a TE topology database and that may not be desired. So, I 
would suggest that the draft keeps the option of use of Inter-AS TE TLVs valid 
and goes ahead with the Stub Link proposal as an alternative with broader 
applicability (also see the next comment).

【WAJ】Yes, in the corresponding non-TE scenario, we don’t want to add additional 
information to the TE topology database. How about to add such statements, 
together with existing descriptions?

 

KT> IMHO the existing reason (and I am paraphrasing) "I don't want to configure 
local/remote AS on the intra-AS link endpoint routers" is not a justification 
for introducing a new TLV. If it is truly an Intra-AS link, then we should have 
those AS numbers.

 

 

2)  For the proclaimed wider applicability (e.g., links to servers/hosts) in 
the slides, there is no such text in the draft. The draft seems focused on 
Inter-AS links. I hope the authors update either the draft or the slides - to 
be in sync with their objectives.

【WAJ】If the WG agree the use case of links to servers/hosts, we can add some 
description back to the draft.

KT> I think it is for the proponents to share the use case that is motivating 
them. I personally did not find the previous reference to 
draft-dunbar-lsr-5g-edge-compute to be a good use case.

 

 

3)  The use of the prefix TLVs in this context is something that is (in my 
opinion) broken from day 1 of this draft. Prefixes are for reachability. For 
identification of links, we have the local/remote link identifiers along with 
the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO for the 
pro

Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]



Hi, Les:

I admire you and your comments as usual, but the baseless comments will 
decrease your credits within the WG. Would you like to review the update of the 
draft more carefully, then post your comments? Doing this can avoid misleading 
some of your followers.

To facilitate your review, I copied the related contents 
again:(https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10#section-5)

  If not all of nodes within one area support the PUAM capabilities,
   the PUAM message should be advertised with the associated prefix cost
   set to LSInfinity.  According to the description in [RFC2328],
   [RFC5305] and [RFC5308], the prefix advertised with such metric value
   will not be considered during the normal SPF computation, then such
   additional information will avoid the misbehavior of the nodes when
   they don't recognize the PUAM message.

   If all of nodes within one area support the PUAM capabilites, the
   PUAM message can be safely advertised without the additional
   LSInfinity metric information.

Then, how can the “legacy nodes MUST interpret as meaning reachable.” ? I wish 
to hear your explanation.

Aijun Wang
China Telecom

> On Jul 28, 2022, at 06:39, Les Ginsberg (ginsberg) 
>  wrote:
> 
> (Preamble: All of what I am going to say I have said many times before – on 
> the list – off the list – in private conversations – in WG meetings…
> I don’t say this to start a discussion with the WG authors – it seems clear 
> that we don’t agree and have no path to agreement.
> My purpose in saying this is to respond to the ongoing existence of this 
> draft and offering my opinion as to what action the WG should take.)
>  
> The mechanism defined in this draft is broken. Not only is it not backwards 
> compatible – the PUA advertisements will be misinterpreted to mean the exact 
> opposite of what is intended i.e., the intent is to signal that a prefix is 
> unreachable, but you do so by using an advertisement which legacy nodes MUST 
> interpret as meaning reachable. This is simply broken and should not be done.
>  
> The authors deserve credit for bringing the attention of the WG to the 
> problem space – but the solution offered is not deployable. Given the long 
> period of time during which this draft has been published and the many times 
> it has been presented/discussed in the WG I think it is now time to say thank 
> you to the authors for their work, but the WG is not interested in adopting 
> this draft.
>  
>Les
>  
>  
> From: Lsr  On Behalf Of Ketan Talaulikar
> Sent: Wednesday, July 27, 2022 1:36 AM
> To: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org
> Cc: lsr 
> Subject: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement
>  
> Hello Authors,
>  
> I am sharing some comments on the latest version of this document since we 
> seem to have a packed agenda in LSR this time.
>  
> 1) I notice that in the latest update of the draft, there is a big change to 
> start using LSInfinity for indicating prefix unreachability (similar to 
> draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a 
> degree of convergence between the two drafts.
>  
> 2) However, I then question the motivation of the authors to continue with 
> the bad design of overloading Prefix Originator and the added capability 
> stuff on top. I don't wish to repeat why that design was an absolute NO-GO 
> for me and I am glad to see the authors acknowledge the problem with 
> misrouting by implementations not supporting this specification. So I don't 
> see the point of still retaining all that. 
>  
> Thanks,
> Ketan
>  
> ___
> 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] 答复: Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang]

Hi, Ketan:

 

Thanks for your comments and suggestions!

Some responses are inline below.

We can update the draft accordingly after we reach consensus on these points.

 

 

Best Regards

 

Aijun Wang

China Telecom.

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 17:32
收件人: draft-wang-lsr-stub-link-attribu...@ietf.org
抄送: lsr 
主题: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

 

Hello Authors,

 

Please find below my comments/suggestions on this draft. I am sharing them 
upfront given the packed LSR agenda.

 

1)  Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not 
sound in my opinion. I would say that the TE encoding may not be suitable for 
use in all deployments as their advertisement results in the addition of those 
Inter-AS links in a TE topology database and that may not be desired. So, I 
would suggest that the draft keeps the option of use of Inter-AS TE TLVs valid 
and goes ahead with the Stub Link proposal as an alternative with broader 
applicability (also see the next comment).

【WAJ】Yes, in the corresponding non-TE scenario, we don’t want to add additional 
information to the TE topology database. How about to add such statements, 
together with existing descriptions?

 

2)  For the proclaimed wider applicability (e.g., links to servers/hosts) in 
the slides, there is no such text in the draft. The draft seems focused on 
Inter-AS links. I hope the authors update either the draft or the slides - to 
be in sync with their objectives.

【WAJ】If the WG agree the use case of links to servers/hosts, we can add some 
description back to the draft. 

 

3)  The use of the prefix TLVs in this context is something that is (in my 
opinion) broken from day 1 of this draft. Prefixes are for reachability. For 
identification of links, we have the local/remote link identifiers along with 
the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO for the 
progression of this document.

【WAJ】We consider “prefix TLV” is one kind of link attributes, which is same as 
other link attributes, not the identification of links.

Can you accept such explanations? 

 

4)  The placement of the Stub Link TLV should be top-level (similar to 
other/existing links). I can share further suggestions offline, provided we 
reach an agreement on the above points and we converge on the main 
purpose/motivation for this work.

【WAJ】In the current draft, the IANA codepoint for the Stub Link TLV is 
allocated from 
https://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level,
 which is already top-level(same as Link TLV). For IS-IS, it is also allocated 
from the 
top-level(https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints).
 Are they reasonable? Anyway, we are welcome your further suggestions.

 

Thanks,

Ketan

 

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

[Lsr] 答复: Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]

Hi, Ketan:

 

We have discussed with Bruno offline for the possibilities of defining new flag 
to indicate the unreachable status explicitly. 

It’s possible, but the challenge is that for OSPFv3, currently, there only one 
bit unassigned 
(https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#ospfv3-parameters-4).
  It may need more works to expand the flag bits for OSPFv3.

And, I can’t see there is significant differences between using the originator 
field and the flag bits to accomplish such aim.

 

Would you like to state more clearly why the NULL value of originator can’t be 
used to indicate the unreachability explicitly?  From my POV, if the prefix 
became unreachable, there is no originator advertise it, isn’t it?

 

Anyway, this can be discussed further later after the adoption.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: Ketan Talaulikar [mailto:ketant.i...@gmail.com] 
发送时间: 2022年7月27日 17:45
收件人: Aijun Wang 
抄送: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org; lsr 
主题: Re: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

 

Hi Aijun,

 

Please check inline below for a quick response.

 

On Wed, Jul 27, 2022 at 2:55 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Hi, Ketan:

 

Thanks for your comments.  But I should correct some of them:

1) In the updated version, the indication of prefix unreachability is still 
the “NULL” value of prefix originator, not the LSInfinity.

KT> Right and I am suggesting you go one step further and remove all that 
prefix originator "business" :-)

 

2) The LSInfinity is used only for avoiding the misrouting by 
implementation not support this implementation, as you have also pointed out.  
As pointed out also in the draft, when all the nodes within the area support 
such capabilities, the LSInfinity value can be ignored:

 

KT> Well, as indicated, the use of the prefix originator for this purpose is 
broken in my view. The use of LSInfinity is helpful to navigate through 
backward compatibility issues. With prefix originator aspects removed, we don't 
need the capability anymore. What comes out at the other end of this "pivot" 
for draft-wang is much similar to the other proposal ... and this IMHO is good.

 

 

“If not all of nodes within one area support the PUAM capabilities,
   the PUAM message should be advertised with the associated prefix cost
   set to LSInfinity.  According to the description in [RFC2328 
<https://datatracker.ietf.org/doc/html/rfc2328> ],
   [RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305> ] and [RFC5308 
<https://datatracker.ietf.org/doc/html/rfc5308> ], the prefix advertised with 
such metric value
   will not be considered during the normal SPF computation, then such
   additional information will avoid the misbehavior of the nodes when
   they don't recognize the PUAM message.
 
   If all of nodes within one area support the PUAM capabilites, the
   PUAM message can be safely advertised without the additional
   LSInfinity metric information.”

 

 

We are glad to cooperate with Peter to forward the solution, but want to say 
LSInfinity only can’t be used to indicate the unreachable information, we need 
some explicit indication method.

 

KT> There is some value in having an explicit indication in addition to the use 
of LSInfinity in draft-ppsenak. Perhaps a prefix attribute flag as was already 
suggested to the authors of draft-ppsenak 
(https://mailarchive.ietf.org/arch/msg/lsr/Q9wU3Bo1uzhPd5C7bT_WE7k_3JI/). But 
certainly not the prefix originator as proposed by draft-wang.

 

Thanks,

Ketan

 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  
[mailto:lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org> ] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 16:36
收件人: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org 
<mailto:draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org> 
抄送: lsr mailto:lsr@ietf.org> >
主题: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

 

Hello Authors,

 

I am sharing some comments on the latest version of this document since we seem 
to have a packed agenda in LSR this time.

 

1) I notice that in the latest update of the draft, there is a big change to 
start using LSInfinity for indicating prefix unreachability (similar to 
draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree 
of convergence between the two drafts.

 

2) However, I then question the motivation of the authors to continue with the 
bad design of overloading Prefix Originator and the added capability stuff on 
top. I don't wish to repeat why that design was an absolute NO-GO for me and I 
am glad to see the authors acknowledge the problem with misrouting by 
implementations not supporting this specification. So I don't see the point of 
still retaining all that

[Lsr] 答复: Comments on draft-wang-lsr-prefix-unreachable-annoucement

[Aijun Wang]

Hi, Ketan:

 

Thanks for your comments.  But I should correct some of them:

1) In the updated version, the indication of prefix unreachability is still 
the “NULL” value of prefix originator, not the LSInfinity.

2) The LSInfinity is used only for avoiding the misrouting by 
implementation not support this implementation, as you have also pointed out.  
As pointed out also in the draft, when all the nodes within the area support 
such capabilities, the LSInfinity value can be ignored:

 

“If not all of nodes within one area support the PUAM capabilities,
   the PUAM message should be advertised with the associated prefix cost
   set to LSInfinity.  According to the description in [RFC2328 
<https://datatracker.ietf.org/doc/html/rfc2328> ],
   [RFC5305 <https://datatracker.ietf.org/doc/html/rfc5305> ] and [RFC5308 
<https://datatracker.ietf.org/doc/html/rfc5308> ], the prefix advertised with 
such metric value
   will not be considered during the normal SPF computation, then such
   additional information will avoid the misbehavior of the nodes when
   they don't recognize the PUAM message.
 
   If all of nodes within one area support the PUAM capabilites, the
   PUAM message can be safely advertised without the additional
   LSInfinity metric information.”

 

 

We are glad to cooperate with Peter to forward the solution, but want to say 
LSInfinity only can’t be used to indicate the unreachable information, we need 
some explicit indication method.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 16:36
收件人: draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org
抄送: lsr 
主题: [Lsr] Comments on draft-wang-lsr-prefix-unreachable-annoucement

 

Hello Authors,

 

I am sharing some comments on the latest version of this document since we seem 
to have a packed agenda in LSR this time.

 

1) I notice that in the latest update of the draft, there is a big change to 
start using LSInfinity for indicating prefix unreachability (similar to 
draft-ppsenak-lsr-igp-ureach-prefix-announce). I see this as a sign of a degree 
of convergence between the two drafts.

 

2) However, I then question the motivation of the authors to continue with the 
bad design of overloading Prefix Originator and the added capability stuff on 
top. I don't wish to repeat why that design was an absolute NO-GO for me and I 
am glad to see the authors acknowledge the problem with misrouting by 
implementations not supporting this specification. So I don't see the point of 
still retaining all that. 

 

Thanks,

Ketan

 

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

Re: [Lsr] UPA/PUA

[Aijun Wang]

Hi, Greg:

 

As indicated in the update draft 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-10

 

The motivation behind this draft is for either MPLS LPM FEC binding,

   SRv6 etc. tunnel ,or BGP overlay service that are using LPM

   forwarding plane where the IGP domain has been carved up into OSPF

   areas or IS-IS levels and summarization is utilized.  In such

   scenario, a link or node failure can result in a black hole of

   traffic when the summary advertisement that covers the failure

   prefixes still exists.

 

   PUAM can track the unreachability of the important component

   prefixes to ensure traffic is not black hole sink routed for the

   above overlay services.

 

Then considering only the BFD sessions among PEs are not enough, even we put 
aside the BFD sessions overhead on each PE.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Greg Mirsky  
Sent: Monday, July 18, 2022 11:06 AM
To: Aijun Wang 
Cc: Robert Raszuk ; Christian Hopps ; 
Peter Psenak ; lsr 
Subject: Re: [Lsr] UPA/PUA

 

Hi Aijun,

I cannot figure out how you draw such a conclusion from my comments to Robert. 
You may recall that from very early in the discussion, I was not enthusiastic, 
to put it lightly, about either of the solutions. Instead, I believe that 
multi-hop BFD should be used to monitor the continuity of a path PE-PE, not 
ABR/ASBR-PE as suggested by Robert. I hope I've made my position clear.

 

Regards,

Greg

 

On Sun, Jul 17, 2022 at 7:04 PM Aijun Wang mailto:wangai...@tsinghua.org.cn> > wrote:

Then considering both the scalability and possible false negative of BFD based 
solution,  can we say that the PUA/UPA solution is more preferable?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org <mailto:lsr-boun...@ietf.org>  mailto:lsr-boun...@ietf.org> > On Behalf Of Greg Mirsky
Sent: Monday, July 18, 2022 8:39 AM
To: Robert Raszuk mailto:rob...@raszuk.net> >
Cc: Christian Hopps mailto:cho...@chopps.org> >; Peter 
Psenak mailto:ppse...@cisco.com> >; lsr mailto:lsr@ietf.org> >
Subject: Re: [Lsr] UPA

 

Hi Robert,

top-posting and then my notes in-line under the GIM>> tag:

As mentioned it is still not the same. BFDs on the link tell me that link is up 
and part of the line card responder to BFD is alive. 

GIM>> I assume you refer to BFD single-hop. Then I have a question What do you 
mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in the Down 
state may not indicate that the link is down but that the remote peer is 
operating down.

 

Multihop BFD sessions will tell me that PE is up or down and that at least one 
connection to it is still up. That is subtle but there is an important 
difference. 

GIM>> Not necessarily, depends on the implementation. I can imagine a scenario, 
depending on the Detect Multiplier and Transmission Interval values, when the 
BFD multi-hop session going down indicates that the particular path to the 
remote PE lost continuity.

 

And I repeat from the Abstract of RFC 5880:

   This document describes a protocol intended to detect faults in the

   bidirectional path between two forwarding engines, including

   interfaces, data link(s), and to the extent possible the forwarding

   engines themselves, with potentially very low latency.

I believe that BFD cannot give us a reliable indication of the operational 
state of a node that hosts the BFD session, applications, and protocols hosted 
on that node.

 

Regards,

Greg

 

 

On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk mailto:rob...@raszuk.net> > wrote:

Hi Christian,

 

> It seems you saying use multi-hop BFD for fast detection b/c you've gone and 
> configured one of those same hops along the 

> multi-hop path to an incredibly slow link-local BFD rate in comparison to the 
> BFD multi-hop rate. 

 

Yes. That is exactly the case. What is however missing in your picture is that 
UPA is not only about signalling that all links to a node went down. 

 

UPA is also about signalling node down while links are still up - continue 
responding to BFD in the line cards. 

 

See what we need here is not a signalling moment when all peers of PE see all 
links to it going down. What is really needed is to signal when such PE can not 
perform its service function any more. And that BFD to interfaces will not tell 
you. 

 

 

> Why would you do that? In fact you're defeating a fundamental scaling aspect 
> of link-state protocols here.

 

Since I have no physical alternative to use as backup other then crappy 
carrier's backup link. 

 

 

>  Now you have N multi-hop BFDs sessions (one per ABR) running over the link 
> instead of just *1* session running on that link.

 

As mentioned it is still not the same. BFDs on the link tell me that link is up 
and part of the line card responder to BFD is alive. 

 

Multihop

Re: [Lsr] UPA/PUA

[Aijun Wang]

Then considering both the scalability and possible false negative of BFD based 
solution,  can we say that the PUA/UPA solution is more preferable?

 

Best Regards

 

Aijun Wang

China Telecom

 

From: lsr-boun...@ietf.org  On Behalf Of Greg Mirsky
Sent: Monday, July 18, 2022 8:39 AM
To: Robert Raszuk 
Cc: Christian Hopps ; Peter Psenak ; lsr 

Subject: Re: [Lsr] UPA

 

Hi Robert,

top-posting and then my notes in-line under the GIM>> tag:

As mentioned it is still not the same. BFDs on the link tell me that link is up 
and part of the line card responder to BFD is alive. 

GIM>> I assume you refer to BFD single-hop. Then I have a question What do you 
mean by "link is up"? If the link is Ethernet, p2p single-hop BFD in the Down 
state may not indicate that the link is down but that the remote peer is 
operating down.

 

Multihop BFD sessions will tell me that PE is up or down and that at least one 
connection to it is still up. That is subtle but there is an important 
difference. 

GIM>> Not necessarily, depends on the implementation. I can imagine a scenario, 
depending on the Detect Multiplier and Transmission Interval values, when the 
BFD multi-hop session going down indicates that the particular path to the 
remote PE lost continuity.

 

And I repeat from the Abstract of RFC 5880:

   This document describes a protocol intended to detect faults in the

   bidirectional path between two forwarding engines, including

   interfaces, data link(s), and to the extent possible the forwarding

   engines themselves, with potentially very low latency.

I believe that BFD cannot give us a reliable indication of the operational 
state of a node that hosts the BFD session, applications, and protocols hosted 
on that node.

 

Regards,

Greg

 

 

On Sun, Jul 17, 2022 at 4:49 AM Robert Raszuk mailto:rob...@raszuk.net> > wrote:

Hi Christian,

 

> It seems you saying use multi-hop BFD for fast detection b/c you've gone and 
> configured one of those same hops along the 

> multi-hop path to an incredibly slow link-local BFD rate in comparison to the 
> BFD multi-hop rate. 

 

Yes. That is exactly the case. What is however missing in your picture is that 
UPA is not only about signalling that all links to a node went down. 

 

UPA is also about signalling node down while links are still up - continue 
responding to BFD in the line cards. 

 

See what we need here is not a signalling moment when all peers of PE see all 
links to it going down. What is really needed is to signal when such PE can not 
perform its service function any more. And that BFD to interfaces will not tell 
you. 

 

 

> Why would you do that? In fact you're defeating a fundamental scaling aspect 
> of link-state protocols here.

 

Since I have no physical alternative to use as backup other then crappy 
carrier's backup link. 

 

 

>  Now you have N multi-hop BFDs sessions (one per ABR) running over the link 
> instead of just *1* session running on that link.

 

As mentioned it is still not the same. BFDs on the link tell me that link is up 
and part of the line card responder to BFD is alive. 

 

Multihop BFD sessions will tell me that PE is up or down and that at least one 
connection to it is still up. That is subtle but there is an important 
difference. 

 

 

> If your (possible multiple sessions of) multi-hop BFD can be sent over this 
> "slow link" at fast rate X then why not do it just once using a link local 
> BFD session at the same rate instead?

 

As described, BFD over a link is not the same as BFD to the node. 

 

 

And to project a bigger picture why I asked this ... 

 

If I would do the fast signalling of PE going down in BGP RRs would likely have 
some form of detecting PE liveness anyway. Multihop BFD could be one such 
option. So I was thinking 

if the same can be done with IGP detection wise. 

 

Note also that there are folks who do recommend PE to PE full mesh of BFD. That 
orders of magnitude more BFD sessions then within an area. 

 

Many thx,

R.

 

 

 

 

On Sun, Jul 17, 2022 at 8:48 AM Christian Hopps mailto:cho...@chopps.org> > wrote:


Robert Raszuk mailto:rob...@raszuk.net> > writes:

> Peter,
>
> In the scenario described there is really nothing to be tuned as you
> are limited by the quality of local telco carriers. 
>
> Apparently you are not willing to consider it. Thank you. 

First, I don't like any of these unreachable things, and so I don't want my 
comment to reflect in any way on them one way or the other.

On a more fundamental level though, I don't see why Peter's answers are not 
sufficient here. In particular, unless I am misunderstanding your scenario it 
seems ... unrealistic -- but maybe I've missed something.

It seems you saying use multi-hop BFD for fast detection b/c you've gone and 
configured one of those same hops along the multi-hop path to an in

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-10.txt

[Aijun Wang]

Hi, All:

We have submitted the update version about "Prefix Unreachable Announcement" 
draft, which contains signification simplification for its contents and the 
clarification of some key points of the mechanism, based on the discussion on 
the list and off the list with LSR experts.
We will try to make some summarizations on the coming IETF meetings. 
Please feel free to comments on the updated contents, or the overall solution.

Best Regards

Aijun Wang
China Telecom

-Original Message-
From: internet-dra...@ietf.org  
Sent: Monday, July 11, 2022 8:50 AM
To: Aijun Wang ; Gyan Mishra 
; Yaqun Xiao ; Zhibo Hu 

Subject: New Version Notification for 
draft-wang-lsr-prefix-unreachable-annoucement-10.txt


A new version of I-D, draft-wang-lsr-prefix-unreachable-annoucement-10.txt
has been successfully submitted by Aijun Wang and posted to the IETF repository.

Name:   draft-wang-lsr-prefix-unreachable-annoucement
Revision:   10
Title:  Prefix Unreachable Announcement
Document date:  2022-07-11
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annoucement-10.txt
Status: 
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-wang-lsr-prefix-unreachable-annoucement-10

Abstract:
   This document describes a mechanism that can trigger the switchover
   of the services which rely on the reachability of the peer endpoints,
   for example the BGP or the tunnel services.  It is mainly used in the
   scenarios that the summary prefixes are advertised at the border
   routers whereas the services endpoints are located in different IGP
   areas or levels, whose reachabilities are covered by the summary
   prefixes.

   It introduces a new signaling mechanism using a negative prefix
   announcement called Prefix Unreachable Announcement Mechanism(PUAM),
   utilized to detect a link or node down event and signal the overlay
   services that the event has occurred to force immediate switchover.


  


The IETF Secretariat



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

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Gunter:

Thanks for your deep considerations for the partition scenarios although it is 
one rarely event I the network.
Regarding to your statements, one point I want to correct is that in the 
mentioned scenario, R2 is also detached from R4 in area 2. This is the reason 
that only R2 sends out the PUA message, or else, if R2 can reach Pt2 via R4, it 
shouldn’t send out the PUA for Pt2.
So, in this scenario, R4 and R2 can only exchange the LSA in area 0. When R2 
receive the specific detail prefix for Pt2 from R4, it just install this 
specific route into its routing table as usual behavior——The PUA messages that 
it advertised has already stopped—-as noted in the draft, the PUA message only 
last one short time to assist the service convergence.
Regarding to your churn concerns, as discussed before on the list, not every 
link failure will cause the PUA advertisement, this can be configured on the 
ABR. Currently, we interest mainly the node’s reachability(that is, the 
loopback addresses of the routers).

Aijun Wang
China Telecom

> On Jun 21, 2022, at 20:40, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>  wrote:
> 
> 
> wrt partitioned area’s and UPA’s. The wang PUA draft has an interesting 
> proposal for assuring that even with UPAs and partitioned area’s 
> non-conflicting information exist.
> The solution proposal does come at cost of increased ISIS churn. This could 
> be an acceptable cost, especially considering that UPAs will only appear by 
> exception and even more rare in combination with area partitioning.
>  
> Lets consider the following (based upon section “3.2 from 
> draft-wang-lsr-prefix-unreachable”):
>  
> For ISIS,  R2 L1/L2 would advertise the PUA for Pt2.
> R4 L1/L2 router receives the L2 PUA route for Pt2 and because it is also 
> summarizing Pt2 from L1, it now decides to advertise a specific route to Pt2.
> R2 now sees that R4 advertises a specific route for Pt2 and programs Pt2 next 
> hop to R4. This will stop the PUA advertisement on R2 immediately.
>  
> Although this enhancement as described is in the 
> draft-wang-lsr-prefix-unreachable draft it should work with 
> draft-ppsenak-lsr-igp-ureach-prefix. A side effect is more churn.
> This setup where R2 and R4 only see each other in L2 causes a lot of churn as 
> a PUA needs to be advertised for Pt2 and all downstream routes of T2.
> On top , R4 now advertises specific route for each of the PUA’s and a bit 
> later R2 floods the same LSPs again but without the PUA’s.
>  
>  
> ***
>  +-+--++-+--+
>  | +--++--+   ++-+   ++-++-++   + -++--+|
>  | |S1++S2+---+R1+---|R0++R2+---+T1++T2||
>  | +-++Ps1 +-++   ++-+   +--++-++   Pt2 +-++|
>  |   |   | |   | ||   | |
>  |   |   | |   | ||   | |
>  |   |   | |  L2 ||   | |
>  |   |   | |   | ||   | |
>  | +-++Ps4 +-++   ++-+   +-++    Pt4+-++|
>  | |S4++S3+---+R3+---+R4+---+T3++T4||
>  | +--++--+   ++-+   +-++   ++-++--+|
>  | |   ||
>  | |   ||
>  | | ISIS L2   |  ISIS L1   |
>  +-+---++
>  
> Inter-Area Prefix Unreachable Announcement Scenario
>  
>  
> 3.2.  Inter-Area Links Failure Scenario
>  
>In a link failure scenario, if the link between T1/T2 and T1/T3 are
>down, R2 will not be able to reach node T2.  But as R2 and R4 do the
>summary announcement, and the summary address covers the bgp next hop
>prefix of Pt2, other nodes in area 0 area 1 will still send traffic
>to T2 bgp next hop prefix Pt2 via the border router R2, thus black
>hole sink routing the traffic.
>  
>In such a situation, the border router R2 should notify other routers
>that it can't reach the prefix Pt2, and lets the other ABRs(R4) that
>can reach prefix Pt2 advertise one specific route to Pt2, then the
>internal routers will select R4 as the bypass router to reach prefix
>Pt2.
> ***
>  
> G/
>  
>  
> -Original Message-
> From: Peter Psenak  
> Sent: Thursday, June 16, 2022 12:04 PM
> To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
> ; Gyan Mishra ; Voyer, 
> Daniel 
> Cc: draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
> draft-wang-lsr-prefix-unreachable-annoucement 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
&g

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Anup:

The advantage of PUA over BFD is that the operator needs not deploy o(n^2) BFD 
sessions for the services that rely on the IGP reachablity. 
Such comparisons have been discussed on the list.

Aijun Wang
China Telecom

> On Jun 18, 2022, at 12:55, Anup MalenaaDu  wrote:
> 
> 
> Hi,
> 
> BGP uses BFD to track the remote PEs. 
> So, how does PUA really help?
> 
> To be precise, 
> 1. what are the advantages of having PUAs for IGPs 
> 2. what are the advantages for services like BGP, Tunnels, LSPs etc going 
> over IGPs
> 
> Thanks,
> Anup
> 
>> On Thu, Jun 16, 2022 at 7:41 PM Voyer, Daniel 
>>  wrote:
>> Hi Gunter, see [DV]
>> 
>>  
>> 
>> From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
>> 
>> Date: Thursday, June 16, 2022 at 6:38 AM
>> To: Robert Raszuk 
>> Cc: Gyan Mishra , Dan Voyer , 
>> "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" 
>> , 
>> draft-wang-lsr-prefix-unreachable-annoucement 
>> , "lsr@ietf.org" 
>> 
>> Subject: [EXT]RE: [Lsr] Thoughts about PUAs - are we not over-engineering?
>> 
>>  
>> 
>> Hi Robert, Peter, Bruno
>> 
>>  
>> 
>> You wrote:
>> 
>> “Aas there is no association between node_id (perhaps loopback) and SIDs 
>> (note that egress can use many SIDs) UPA really does not signal anything 
>> about SIDs reachability or liveness. “
>> 
>>  
>> 
>> Sure, but UPA signals that a locator is unreachable, would that not result 
>> for the SRv6 SID to become unreachable as well?
>> 
>>  
>> 
>> I understood that UPA have increased value add benefit when using with SRv6. 
>> If suddenly a locator becomes unreachable, then it I guess the associated 
>> 128 bit SIDs become unreachable too, causing an event for something to 
>> happen in the transport network to fix the problem.
>> 
>>  
>> 
>> That being said, Peter makes a good point stating that UPA is not solving 
>> the problem of partitioning areas, and hence, maybe my use-case is not 
>> overly relevant.
>> 
>>  
>> 
>> So progressing, an operator using ABR based summarization then there are few 
>> options:
>> 
>> No summarization at all at ABRs
>> Summarize on ABR all prefixes that can be summarized
>> Summarize all prefixes that are not associated with PEs and remain 
>> advertising individual PE addresses
>> Summarize all prefixes and use UPA’s to advertise unreachability of 
>> protected prefixes
>>  
>> 
>> [DV] if “an operator using ABR based summarization” then option 1 is out, 
>> right ? Also, option 4 is the point of this draft – but furthermore, if an 
>> aggregation device, inside a domain, is also being summarized – as the 
>> entire domain get summarized – but this agg device doesn’t have any 
>> services, because it’s an aggregation device, “then it’s up to the operator 
>> designing the network to implement” a form of policy/filter. So if that agg 
>> device reload, due to a maintenance, we don’t care about the unreachability 
>> advertisement (adding unnecessary LSP in the LSDB).
>> 
>>  
>> 
>> We all know that option 1 -3 work well and has been working well for long 
>> time. Behavior is very well understood
>> 
>>  
>> 
>> With the new option 4, to add value, applications need to get what is being 
>> referenced as ‘vendor secret sauce’ … I can already see the fun caused by 
>> inconsistent behavior and interop issues due to under specification.
>> 
>> [DV] not sure I am following your “secret sauce” point here. Following the 
>> RFC5305/RFC5308 should be clear.
>> 
>>  
>> 
>> The question I remain to have is if the UPA provide higher benefit as the 
>> tax it introduces. I can see operators suffer due to under specification, 
>> causing interop and inconsistent behaviors.
>> 
>>  
>> 
>> I agree with Bruno’s statement “If you believe that all you need is 
>> RFC5305/RFC5308 I guess this means that we don't need 
>> draft-ppsenak-lsr-igp-ureach-prefix-announce”
>> 
>>  
>> 
>> [DV] well, “draft-ppsenak-lsr-igp-ureach-prefix-announce”, is describing a 
>> use case/architecture and what you can do w/ RFC5305/RFC5308 – its 
>> “informational” 
>> 
>>  
>> 
>> G/
>> 
>>  
>> 
>>  
>> 
>> From: Robert Raszuk  
>> Sent: Thursday, June 16, 2022 11:54 AM
>> To: Van De Velde, Gunter (Nokia - BE/Antwerp) 
>> Cc: Gyan Mishra ; Voyer, Daniel 
>&g

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Gunter:

Thanks for your through thoughts.
For your mentioned case 1), the PUA draft has already the considerations: 
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4

“If the nodes in the area receive the PUAM flood from all of its ABR
   routers, they will start BGP convergence process if there exist BGP
   session on this PUAM prefix.  The PUAM creates a forced fail over
   action to initiate immediate control plane convergence switchover to
   alternate egress PE.  Without the PUAM forced convergence the down
   prefix will yield black hole routing resulting in loss of
   connectivity.

   When only some of the ABRs can't reach the failure node/link, as that
   described in Section 3.2, the ABR that can reach the PUAM prefix
   should advertise one specific route to this PUAM prefix.  The
   internal routers within another area can then bypass the ABRs that
   can't reach the PUAM prefix, to reach the PUAM prefix.”

For your mentioned case 2), we think the transit receiver should do the local 
bypass if there is PLR configured, or the ingress router/PCE should switch the 
traffic to other path that can avoid the failure node. These are all 
applications of the PUA/UPA messages, and we can add some statements if 
necessary on the deployment considerations parts.

Aijun Wang
China Telecom

> On Jun 16, 2022, at 16:10, Van De Velde, Gunter (Nokia - BE/Antwerp) 
>  wrote:
> 
> 
> Hi Gyan, Daniel, Peter, All,
>  
> Thanks for sharing your insights and I agree mostly with your feedback
>  
> I agree and understand that summarization is needed to reduce the size of the 
> LSDB. I also agree summarization good design practice, especially with IPv6 
> and SRv6 in mind. There never has been doubt about that.
> I am not sure I agree that UAP/UPA is ‘optimal-design’. Maybe it is the best 
> we can do, however I have a healthy worry we could be suffering tunnel vision 
> and that proposed solution may not be good enough.
> We should not be blind and believe that advertising UPA/PUA does not come 
> without a cost. The architectural PUA/UPA usage complexity cost may not be 
> worth the effort (none of the integration of using a PUA/UPA event triggers 
> come for free). Do we really believe that PUA/UPA solve all the SID 
> reachability problems for all IGP network design and SR use-cases elegantly? 
> Maybe some use-case design constraints and assumptions should be documented 
> to clarify architecturally where PUA/UPA is most beneficial for operators? 
> Just stating “outside scope of the draft” seems unfair to operators 
> interested in PUA/UPAs
>  
> Let me give two examples where PUA/UPA benefit is unclear:
>  
> (1) Multiple-ABRs
>  
> I was wondering for example if a ingress router receives a PUA signaling that 
> a given locator becomes unreachable, does that actually really signals that 
> the SID ‘really’ is unreachable for a router?
>  
> For example (simple design to illustrate the corner-case):
>  
> ingressPE#1---area#1---ABR#1---area---ABR#2---area#3---egressPE#2
>  |  |
>  |  |
>  +area#1---ABR#3---area---ABR#4---area#3+
>  
> What if ABR#4 would loose connectivity to egressPE#2 and ABR#2 does not?
> In that case ABR#4 will originate a UPA/PUA and ABR#2 does not originate a 
> PUA/UPA.
> How is ingressPE#1 supposed to handle this situation? The only thing 
> ingressPE#1 see is that suddenly there is a PUA/UPA but reachability may not 
> have changed at all and remains perfectly reacheable.
>  
>  
> (2) with sr-policy or SRv6 SRTE
> What if we have an inter-area/domain/level SRTE or sr-policy and suddenly 
> there is a PUA/UPA for one of the SIDs in the sid-list of the path.
> will this impact the srte or sr-policy in any way? Will transit routers do 
> anything with the UPA/PUA and drop packets. Will transit routers trigger 
> fast-restoration?
> Can PCEs/controllers use the SID for crafting paths? Will all SRTE/sr-policy 
> using the locator be pruned or re-signaled?
> Will ingress router do something with the PUA information? Should PUA/UPA 
> draft give guidelines around this?
>  
> Be well,
> G/
>  
>  
>  
>  
>  
>  
>  
> If there is an SRTE or sr-policy using a given SID somewhere in the SID list… 
> and suddenly
>  
>  
>  
> From: Gyan Mishra  
> Sent: Thursday, June 16, 2022 6:12 AM
> To: Voyer, Daniel 
> Cc: Van De Velde, Gunter (Nokia - BE/Antwerp) 
> ; 
> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
> draft-wang-lsr-prefix-unreachable-annoucement 
> ; lsr@ietf.org
> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>  
>

Re: [Lsr] draft-ppsenak-lsr-igp-ureach-prefix-announce

[Aijun Wang]

Hi, Bruno:

I agree with your thoughts on the solutions to this questions.

Actually, this is the reason that we brought up the thread “Convergence of 
Prefixes Unreachable Announcement Proposal” and I think you can review the 
discussion of this thread again.

And, in the mail 
https://mailarchive.ietf.org/arch/msg/lsr/qZ87Kjc9RdSsNpXzpOu31g1dSR0/, we have 
the following statements:
“ Anyway, to make the UPA mechanism take effect, you will also require the 
router be upgraded. And the “Max-Value” solution doesn’t necessarily indicate 
the prefix is lost. We should announce such information explicitly.”

Whether defining a new flag or use the prefix originator information(as adopt 
by  
https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-09#section-4)
  to indicate explicitly the prefix is unreachable can be further discussed.

Aijun Wang
China Telecom

> On Jun 15, 2022, at 22:09, bruno.decra...@orange.com wrote:
> 
> 
> Hi Peter, authors, all
>  
> Thanks for the draft. I find it a useful contribution to the problem space.
>  
> IMHO the use of MAX_PATH_METRIC is a good idea in particular since it can be 
> made backward compatible and provides incremental benefits with incremental 
> deployment.
>  
> I also have two disagreements on the current draft. Both are minor IMO, but 
> authors may have a different opinion.
>  
> This draft defines a new signaling from an egress ABR to all ingress ABR/PE. 
> As such, this require all these nodes to agree on this signaling. So I’d call 
> for a STD track document.
> IMO, the behavior defined in this draft is not backward compatible with the 
> specification of MAX_PATH_METRIC in an IP prefix.
>  
> RFC5305 says:
>If a prefix is advertised with a metric larger then MAX_PATH_METRIC
>(0xFE00, see paragraph 3.0), this prefix MUST NOT be considered
>during the normal SPF computation.  This allows advertisement of a
>prefix for purposes other than building the normal IP routing table.
>  
> As per the above, one (ABR) may (is allowed and free to do so) already 
> advertise both an aggregate prefix IP1/N with a regular metric and a more 
> specific prefix IP2/32 with MAX_PATH_METRIC.
> With the above advertisement, all nodes compliant with RFC 5305 will install 
> IP1/N in their FIB and not consider IP2/32 during their SPF and as a 
> consequence not install it in their FIB.
> In term of reachability, all nodes have IP reachability to all IP @ in IP1 
> including IP2.
>  
> If one node now implements the draft, it will remove reachability for IP2. 
> And hence all my BGP routes using IPv2 for next-hop will be removed.
> This looks clearly like a change in behavior to me, plus one which introduce 
> loss of reachability in an existing network.
>  
> 3) The solution that I would suggest is:
> - advertise the “unreachable prefix” with metric MAX_PATH_METRIC
> - define a new  “Extended Reachability Attribute Flags” ([RFC 7794]) 
> explicitly signaling that the reachability to this prefix has been lost:
> Unreachable Flag (U_flag). Set if this prefix is to be considered 
> unreachable.
>  
> This would allow for explicit signaling of the reachability (vs implicit 
> currently) and would be backward compatible with existing specification and 
> deployments.
>  
> Regards,
> --Bruno
>  
> _
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> ___
> 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] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Peter:

Please review your document carefully:

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00#section-2.1:(UPA
 in IS-IS)

As per the definitions referenced in the preceding section, any
   prefix advertisement with a metric value greater than 0xFE00 can
   be used for purposes other than normal routing calculations.  Such an
   advertisement can be interpreted by the receiver as a UPA.

https://datatracker.ietf.org/doc/html/draft-ppsenak-lsr-igp-ureach-prefix-announce-00#section-3.1(UPA
 in OSPF)

Using the existing mechanism already defined in the standards, as
   described in previous section, an advertisement of the inter-area or
   external prefix inside OSPF or OSPFv3 LSA that has the age set to
   value lower than MaxAge and metic set to LSInfinity can be
   interpreted by the receiver as a UPA.

Aijun Wang
China Telecom

> On Jun 15, 2022, at 20:09, Peter Psenak  
> wrote:
> 
> On 15/06/2022 13:39, Aijun Wang wrote:
>> Hi, Peter:
>> What’s my meaning is that if you redefine or reuse the meaning of 
>> LSInfinity, there will be issues for other scenario that want to utilize 
>> this field.
>> In the mentioned example, the prefixes associated with the LSInfinity is 
>> certainly reachable, which is contradicted with your assumption.
> 
> not at all, you are interpreting it that way.
> 
> Peter
> 
> 
>> Aijun Wang
>> China Telecom
>>>> On Jun 15, 2022, at 19:18, Peter Psenak 
>>>>  wrote:
>>> 
>>> Aijun,
>>> 
>>>> On 15/06/2022 12:12, Aijun Wang wrote:
>>>> Hi, Peter:
>>>> If you use LSInfinity as the indicator of the prefixes unreachable, then 
>>>> how about you solve the situations that described in 
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.4
>>>>  
>>>> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.4>,
>>>>  in which the the metric in parent TLV MUST be set to LSInfinity?
>>> 
>>> if the IP Algorithm Prefix Reachability Sub-TLV is present the metric from 
>>> that Sub-TLV is used instead. There is no problem.
>>> 
>>>> Will you consider all such prefixes unreachable? This is certainly not the 
>>>> aim of the IP FlexAlgo document.
>>>> In conclusion, the prefixes unreachable information should be indicated 
>>>> explicitly by other means, as that introduced in the PUA draft.
>>> 
>>> the meaning of LSInfinity has been defined decades ago. No matter how much 
>>> you may not like it, but it means unreachable.
>>> 
>>> thanks,
>>> Peter
>>> 
>>>> Aijun Wang
>>>> China Telecom
>>>>>> On Jun 15, 2022, at 17:09, Peter Psenak 
>>>>>>  wrote:
>>>>> 
>>>>> Hi Gunter,
>>>>> 
>>>>> On 15/06/2022 11:02, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
>>>>>> Hi Robert,
>>>>>> I agree with you that the operator problem space is not limited to 
>>>>>> multi-area/levels with IGP summarisation.
>>>>>> With the PUA/UPA proposals I get the feeling that LSR WG is jumping into 
>>>>>> the deep-end and is re-vectoring the IGP to carry opaque information not 
>>>>>> used for SPF/cSPF.
>>>>>> I believe we should be conservative for such and if LSR WG progresses 
>>>>>> with such decision.
>>>>> 
>>>>> please note that UPA draft builds on existing protocol specification 
>>>>> defined in RFC5305 and RFC5308 that allow the metric larger then 
>>>>> MAX_PATH_METRIC to be used "for purposes other than building the normal 
>>>>> IP routing table". We are just documenting one of them.
>>>>> 
>>>>> thanks,
>>>>> Peter
>>>>> 
>>>>> 
>>>>>> It could very well be that re-vectoring is the best solution, but I 
>>>>>> guess we need to agree first on understanding the operator problem space.
>>>>>> G/
>>>>>> *From:*Robert Raszuk 
>>>>>> *Sent:* Tuesday, June 14, 2022 11:51 AM
>>>>>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
>>>>>> 
>>>>>> *Cc:* lsr ; 
>>>>>> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
>>>>>> draft-wang-lsr-prefix-unreachable-annoucement 
>>>>>> 
>>>>>> *Subject:* Re: [Lsr]

Re: [Lsr] Thoughts about PUAs - are we not over-engineering?

[Aijun Wang]

Hi, Peter:
What’s my meaning is that if you redefine or reuse the meaning of LSInfinity, 
there will be issues for other scenario that want to utilize this field.
In the mentioned example, the prefixes associated with the LSInfinity is 
certainly reachable, which is contradicted with your assumption.

Aijun Wang
China Telecom

> On Jun 15, 2022, at 19:18, Peter Psenak  
> wrote:
> 
> Aijun,
> 
>> On 15/06/2022 12:12, Aijun Wang wrote:
>> Hi, Peter:
>> If you use LSInfinity as the indicator of the prefixes unreachable, then how 
>> about you solve the situations that described in 
>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.4 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-6.4>,
>>  in which the the metric in parent TLV MUST be set to LSInfinity?
> 
> if the IP Algorithm Prefix Reachability Sub-TLV is present the metric from 
> that Sub-TLV is used instead. There is no problem.
> 
>> Will you consider all such prefixes unreachable? This is certainly not the 
>> aim of the IP FlexAlgo document.
>> In conclusion, the prefixes unreachable information should be indicated 
>> explicitly by other means, as that introduced in the PUA draft.
> 
> the meaning of LSInfinity has been defined decades ago. No matter how much 
> you may not like it, but it means unreachable.
> 
> thanks,
> Peter
> 
>> Aijun Wang
>> China Telecom
>>>> On Jun 15, 2022, at 17:09, Peter Psenak 
>>>>  wrote:
>>> 
>>> Hi Gunter,
>>> 
>>> On 15/06/2022 11:02, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
>>>> Hi Robert,
>>>> I agree with you that the operator problem space is not limited to 
>>>> multi-area/levels with IGP summarisation.
>>>> With the PUA/UPA proposals I get the feeling that LSR WG is jumping into 
>>>> the deep-end and is re-vectoring the IGP to carry opaque information not 
>>>> used for SPF/cSPF.
>>>> I believe we should be conservative for such and if LSR WG progresses with 
>>>> such decision.
>>> 
>>> please note that UPA draft builds on existing protocol specification 
>>> defined in RFC5305 and RFC5308 that allow the metric larger then 
>>> MAX_PATH_METRIC to be used "for purposes other than building the normal IP 
>>> routing table". We are just documenting one of them.
>>> 
>>> thanks,
>>> Peter
>>> 
>>> 
>>>> It could very well be that re-vectoring is the best solution, but I guess 
>>>> we need to agree first on understanding the operator problem space.
>>>> G/
>>>> *From:*Robert Raszuk 
>>>> *Sent:* Tuesday, June 14, 2022 11:51 AM
>>>> *To:* Van De Velde, Gunter (Nokia - BE/Antwerp) 
>>>> 
>>>> *Cc:* lsr ; 
>>>> draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; 
>>>> draft-wang-lsr-prefix-unreachable-annoucement 
>>>> 
>>>> *Subject:* Re: [Lsr] Thoughts about PUAs - are we not over-engineering?
>>>> Hello Gunter,
>>>> I agree with pretty much all you said except the conclusion - do nothing 
>>>> :).
>>>> To me if you need to accelerate connectivity restoration upon an unlikely 
>>>> event like a complete PE failure the right vehicle to signal this is 
>>>> within the service layer itself. Let's keep in mind that links do fail a 
>>>> lot in the networks - routers do not (or they do it is multiple orders of 
>>>> magnitude less frequent event). Especially links on the PE-CE boundaries 
>>>> do fail a lot.
>>>> Removal of next hop reachability can be done with BGP and based on BGP 
>>>> native recursion will have the exact same effect as presented ideas. 
>>>> Moreover it will be stateful for the endpoints which again to me is a 
>>>> feature not a bug.
>>>> Some suggested to define a new extension in BGP to signal it even without 
>>>> using double recursion - well one of them has been proposed in the past - 
>>>> https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt 
>>>> <https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt> At 
>>>> that time the feedback received was that native BGP withdraws are fast 
>>>> enough so no need to bother. Well those native withdrawals are working 
>>>> today as well as some claim that specific implementations can withdraw 
>>>> RD:* when PE hosting such RDs fail and RDs are allocated in a unique per 
>&