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

 

 
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

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)

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] On 
> > Behalf Of Les Ginsberg

> > (ginsberg)

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

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

> > <  linchangwang.04...@h3c.com>; Acee 
> > Lindem <  acee.i...@gmail.com>;

> > lsr <  lsr@ie

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

[Les Ginsberg (ginsberg)]

Aijun –

You either have not understood the points I have made, or you have not read 
what I wrote closely enough.

As I have done my best to be as clear as possible, I can only ask that you read 
my responses to both Changwang and Zhibo again – as well as reread Peter’s 
response to Changwang.
If rereading is of no help – please ask someone else to explain it to you – I 
do not know how to state things more clearly than I have.

Respectfully,

   Les


From: Lsr  On Behalf Of Aijun Wang
Sent: Wednesday, August 30, 2023 8:37 PM
To: 'Les Ginsberg (ginsberg)' ; 'Huzhibo' 
; Peter Psenak (ppsenak) 
; 'linchangwang' ; 'Acee Lindem' 
; 'lsr' 
Cc: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org
Subject: [Lsr] 答复: Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

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> 
[mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg)
发送时间: 2023年8月31日 10:57
收件人: Huzhibo 
mailto:huzhibo=40huawei@dmarc.ietf.org>>;
 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>>
抄送: 
draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org<mailto: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-<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/>

> ureach-prefix-announce/<https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-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 

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

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

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