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

[Gyan Mishra]

I support adoption.

Thanks

Gyan

On Wed, 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

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

[Satoru Matsushima]

Hi, I support this adoption.

Best regards,
--satoru

> 2023/08/24 4:58、Acee Lindem のメール:
> 
> 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] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[Thomas.Graf]

Dear LSR Working Group,

I have read the document. Swisscom is one of the operators deploying “IGP 
Unreachable Prefix Announcement” in their SRv6 network. The document addresses 
the challenge of fast convergance in a SRv6 aggregated IGP domain. I therfore 
support the adoption in LSR.

Best wishes
Thomas Graf


On 2023-08-23, 3:58 PM, "Lsr on behalf of Acee Lindem" mailto:lsr-boun...@ietf.org> on behalf of 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 

--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints





smime.p7s
Description: S/MIME Cryptographic Signature
___
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-unreach-prefix-announce-04

[Robert Raszuk]

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 ?

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


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

Best,
Robert
___
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-unreach-prefix-announce-04

[Acee Lindem]

Hi Robert, 

> On Aug 31, 2023, at 4:18 AM, Robert Raszuk  wrote:
> 
> Hi Les,
> 
> > 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.
> 
> True, but let's do not forget the bigger picture here. The dst is already 
> covered by summary so for the 
> app it really does not matter ... It is reachable anyway. 
> 
> Bottom line is that both solutions need to have upgraded code to use the new 
> trigger. 

In any case, one will need to update the signaling routers and the routers 
acting on the signal. In the draft under adoption, this is done in a backward 
compatible manner so the other routers do not need to be upgraded.  




> 
> 
> Dear LSR chairs,
> 
> I am not sure what harm would it make to start WG adoption call on both 
> drafts and see the results. 
> 
> So far I am not seeing strong and uniform adoption support for either one :) 
> 
> Not sure why some authors feel like their work was rejected. 
> 
> Cheers,
> R.

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). 
The other draft doesn’t restrict the mechanisms to application signaling even 
though that was added. 
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. 

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.

Thanks,
Acee 



> 
> 
> On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
>  wrote:
> Zhibo -
>  Please see inline.
>  > -Original Message-
> > From: Huzhibo 
> > Sent: Wednesday, August 30, 2023 6:33 PM
> > To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
> > ; linchangwang ;
> > Acee Lindem ; lsr 
> > 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 u

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

[Les Ginsberg (ginsberg)]

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.

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

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

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



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



   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 
> > mailto:ppsenak=40cisco@dmarc.ietf.org>>;
> >  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

> >

> > Changwang -

> >

> > It is very important to note ...

> >

> > 

> > > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and

> > > > [RFC9084] to

> > > indicate reachability by checking whether the originator information

> > > is

> > > >NULL.

> > 

> >

> > This statement is incorrect. There is no existing mechanism defined in the

> > protocol that states that a prefix reachability advertisement sent with a

> > source router ID == 0 implies unreachability.

> > Please see https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2

> >

> > Existing routers, on receiving a prefix reachability advertisement with a

> > Source Router ID == 0 will interpret that prefix as being reachable - which

> > is exactly the opposite of the intent defined in

> > https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annouc

> > ement-12.txt

> > This is one of the things which is broken in this draft.

> > This fact has been pointed out to the authors many times over the years -

> > but they have consistently ignored it.

> >

> > On the other hand,

> > https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-annou

> > nce-04.txt uses an existing mechanism defined in RFC 5305 to insure that

> > legacy routers who do not understand the new use case or the new flags

> > will ignore the prefix reachability advertisement. This has been verified by

> > testing against multiple implementations.

> >

> > Please be accurate in the statements that you make.

> >

> >Les

> >

> >

> > > -Original Message-

> > > From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf 
> > > Of Peter Psenak

> > > Sent: Wednesday, August 30, 2023 8:43 AM

> > > To: 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-l

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

[Robert Raszuk]

Peter,


> > I am not sure what harm would it make to start WG adoption call on both
> > drafts and see the results.
> >
> > So far I am not seeing strong and uniform adoption support for either
> > one :)
>
> I hope you are not serious. Having two different ways of signalling the
> same thing in a protocol is hardy something you would want.



This is WC adoption call not WG last call.

Once documents are in WG, WG owns them and can merge them or improve them.
I hope LSR's mission is not just to rubber stamp the accepted drafts.

And actually I do not see sufficient and uniform support for either of them
as of today to get even to the WG doc status.

Cheers,
R.
___
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-unreach-prefix-announce-04

[Peter Psenak]

Robert,

On 31/08/2023 01:18, Robert Raszuk wrote:

*Hi Les,*

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.


True, but let's do not forget the bigger picture here. The dst is 
already covered by summary so for the

app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the 
new trigger.



*Dear LSR chairs,*

I am not sure what harm would it make to start WG adoption call on both 
drafts and see the results.


So far I am not seeing strong and uniform adoption support for either 
one :)


I hope you are not serious. Having two different ways of signalling the 
same thing in a protocol is hardy something you would want.


thanks,
Peter



Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
<mailto:40cisco@dmarc.ietf.org>> wrote:


Zhibo -

__ __

Please see inline.

__ __

 > -Original Message-

 > From: Huzhibo mailto: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 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 ro

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

[Dongjie (Jimmy)]

Robert,

We are on the same page. What I said was “summarize the common parts, and 
highlight their differences”.

-Jie

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Thursday, August 31, 2023 5:36 PM
To: Dongjie (Jimmy) 
Cc: Les Ginsberg (ginsberg) ; Huzhibo 
; Peter Psenak (ppsenak) ; linchangwang 
; Acee Lindem ; lsr 
; 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

>  it would be helpful to summarize the common parts of the two solutions,

Actually IMO it would be much more helpful to summarise differences of both 
solutions not common parts.

Thx,
r.



On Thu, Aug 31, 2023 at 11:23 AM Dongjie (Jimmy) 
mailto:jie.d...@huawei.com>> wrote:
Hi Les and Robert,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>] On Behalf 
Of Robert Raszuk
Sent: Thursday, August 31, 2023 4:19 PM
To: Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>>
Cc: Huzhibo 
mailto: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>
Subject: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix 
Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

Hi Les,

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

True, but let's do not forget the bigger picture here. The dst is already 
covered by summary so for the
app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the new 
trigger.

[Jie] Agreed. Consider the existence of the summary route, advertising 
Max_Metric for a prefix covered by the summary route will not make it 
unreachable. A router needs to either understand the new flags as defined in 
draft-ppsenak, or understand the semantic of the NULL originator as specified 
in draft-wang to behave accordingly. This make me wonder whether it is still 
necessary to set the metric of that prefix to Max?

After several rounds of update, to me the two solutions becomes similar in 
principle , just choose different ways to encode the trigger information.


Dear LSR chairs,

I am not sure what harm would it make to start WG adoption call on both drafts 
and see the results.

[Jie] This sounds like a reasonable suggestion.

And since the WG has been discussing this problem and the two solution drafts 
for a while, it would be helpful to summarize the common parts of the two 
solutions, and highlight their difference, so that people can understand the 
current state and make their decision.

Best regards,
Jie

So far I am not seeing strong and uniform adoption support for either one :)

Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Zhibo -



Please see inline.



> -Original Message-

> From: Huzhibo 
> mailto: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 rou

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

[Peter Psenak]

Robert,

On 31/08/2023 02:36, Robert Raszuk wrote:

  it would be helpful to summarize the common parts of the two solutions,


Actually IMO it would be much more helpful to summarise differences of 
both solutions not common parts.


please read both drafts and you would easily get the difference. If you 
are not in favor of doing that, please read Les's response to Zhibo, it 
has the most important parts.


thanks,
Peter



Thx,
r.



On Thu, Aug 31, 2023 at 11:23 AM Dongjie (Jimmy) > wrote:


Hi Les and Robert,

__ __

Please see some comments inline:

__ __

*From:*Lsr [mailto:lsr-boun...@ietf.org
] *On Behalf Of *Robert Raszuk
*Sent:* Thursday, August 31, 2023 4:19 PM
*To:* Les Ginsberg (ginsberg) mailto:40cisco@dmarc.ietf.org>>
*Cc:* Huzhibo mailto: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

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

__ __

*Hi Les,*

__ __

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

__ __

True, but let's do not forget the bigger picture here. The dst is
already covered by summary so for the 

app it really does not matter ... It is reachable anyway. 

__ __

Bottom line is that both solutions need to have upgraded code to use
the new trigger. 

__ __

[Jie] Agreed. Consider the existence of the summary route,
advertising Max_Metric for a prefix covered by the summary route
will not make it unreachable. A router needs to either understand
the new flags as defined in draft-ppsenak, or understand the
semantic of the NULL originator as specified in draft-wang to behave
accordingly. This make me wonder whether it is still necessary to
set the metric of that prefix to Max?

__ __

After several rounds of update, to me the two solutions becomes
similar in principle , just choose different ways to encode the
trigger information. 

__ __

__ __

*Dear LSR chairs,*

__ __

I am not sure what harm would it make to start WG adoption call on
both drafts and see the results. 

__ __

[Jie] This sounds like a reasonable suggestion. 

__ __

And since the WG has been discussing this problem and the two
solution drafts for a while, it would be helpful to summarize the
common parts of the two solutions, and highlight their difference,
so that people can understand the current state and make their
decision. 

__ __

Best regards,

Jie



So far I am not seeing strong and uniform adoption support for
either one :) 

__ __

Not sure why some authors feel like their work was rejected. 

__ __

Cheers,

R.

__ __

__ __

On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg)
mailto:40cisco@dmarc.ietf.org>> wrote:

Zhibo -



Please see inline.



> -Original Message-

> From: Huzhibo mailto: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


> 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 

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

[Robert Raszuk]

>  it would be helpful to summarize the common parts of the two solutions,

Actually IMO it would be much more helpful to summarise differences of both
solutions not common parts.

Thx,
r.



On Thu, Aug 31, 2023 at 11:23 AM Dongjie (Jimmy) 
wrote:

> Hi Les and Robert,
>
>
>
> Please see some comments inline:
>
>
>
> *From:* Lsr [mailto:lsr-boun...@ietf.org] *On Behalf Of *Robert Raszuk
> *Sent:* Thursday, August 31, 2023 4:19 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* Huzhibo ; Peter Psenak
> (ppsenak) ; linchangwang ;
> Acee Lindem ; lsr ;
> 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,*
>
>
>
> > 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.
>
>
>
> True, but let's do not forget the bigger picture here. The dst is already
> covered by summary so for the
>
> app it really does not matter ... It is reachable anyway.
>
>
>
> Bottom line is that both solutions need to have upgraded code to use the
> new trigger.
>
>
>
> [Jie] Agreed. Consider the existence of the summary route, advertising
> Max_Metric for a prefix covered by the summary route will not make it
> unreachable. A router needs to either understand the new flags as defined
> in draft-ppsenak, or understand the semantic of the NULL originator as
> specified in draft-wang to behave accordingly. This make me wonder whether
> it is still necessary to set the metric of that prefix to Max?
>
>
>
> After several rounds of update, to me the two solutions becomes similar in
> principle , just choose different ways to encode the trigger information.
>
>
>
>
>
> *Dear LSR chairs,*
>
>
>
> I am not sure what harm would it make to start WG adoption call on both
> drafts and see the results.
>
>
>
> [Jie] This sounds like a reasonable suggestion.
>
>
>
> And since the WG has been discussing this problem and the two solution
> drafts for a while, it would be helpful to summarize the common parts of
> the two solutions, and highlight their difference, so that people can
> understand the current state and make their decision.
>
>
>
> Best regards,
>
> Jie
>
>
>
>
> So far I am not seeing strong and uniform adoption support for either one
> :)
>
>
>
> Not sure why some authors feel like their work was rejected.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> Zhibo -
>
>
>
> Please see inline.
>
>
>
> > -Original Message-----
>
> > From: Huzhibo 
>
> > Sent: Wednesday, August 30, 2023 6:33 PM
>
> > To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
>
> > ; linchangwang ;
>
> > Acee Lindem ; lsr 
>
> > 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-
> <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-unr

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

[Huzhibo]

From: Les Ginsberg (ginsberg) [mailto:ginsberg=40cisco@dmarc.ietf.org]
Sent: Thursday, August 31, 2023 10:57 AM
To: Huzhibo ; Peter Psenak (ppsenak) ; 
linchangwang ; Acee Lindem ; 
lsr 
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


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



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



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



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 
> > mailto:ppsenak=40cisco@dmarc.ietf.org

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

[Dongjie (Jimmy)]

Hi Les and Robert,

Please see some comments inline:

From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, August 31, 2023 4:19 PM
To: Les Ginsberg (ginsberg) 
Cc: Huzhibo ; Peter Psenak (ppsenak) 
; linchangwang ; Acee Lindem 
; lsr ; 
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,

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

True, but let's do not forget the bigger picture here. The dst is already 
covered by summary so for the
app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the new 
trigger.

[Jie] Agreed. Consider the existence of the summary route, advertising 
Max_Metric for a prefix covered by the summary route will not make it 
unreachable. A router needs to either understand the new flags as defined in 
draft-ppsenak, or understand the semantic of the NULL originator as specified 
in draft-wang to behave accordingly. This make me wonder whether it is still 
necessary to set the metric of that prefix to Max?

After several rounds of update, to me the two solutions becomes similar in 
principle , just choose different ways to encode the trigger information.


Dear LSR chairs,

I am not sure what harm would it make to start WG adoption call on both drafts 
and see the results.

[Jie] This sounds like a reasonable suggestion.

And since the WG has been discussing this problem and the two solution drafts 
for a while, it would be helpful to summarize the common parts of the two 
solutions, and highlight their difference, so that people can understand the 
current state and make their decision.

Best regards,
Jie

So far I am not seeing strong and uniform adoption support for either one :)

Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg) 
mailto:40cisco@dmarc.ietf.org>> wrote:

Zhibo -



Please see inline.



> -Original Message-

> From: Huzhibo 
> mailto: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 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

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

[Robert Raszuk]

*Hi Les,*

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

True, but let's do not forget the bigger picture here. The dst is already
covered by summary so for the
app it really does not matter ... It is reachable anyway.

Bottom line is that both solutions need to have upgraded code to use the
new trigger.


*Dear LSR chairs,*

I am not sure what harm would it make to start WG adoption call on both
drafts and see the results.

So far I am not seeing strong and uniform adoption support for either one
:)

Not sure why some authors feel like their work was rejected.

Cheers,
R.


On Thu, Aug 31, 2023 at 4:57 AM Les Ginsberg (ginsberg)  wrote:

> Zhibo -
>
>
>
> Please see inline.
>
>
>
> > -Original Message-
>
> > From: Huzhibo 
>
> > Sent: Wednesday, August 30, 2023 6:33 PM
>
> > To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)
>
> > ; linchangwang ;
>
> > Acee Lindem ; lsr 
>
> > 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-
> <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 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 by all
> routers in the network.
>
> I think this makes a big difference. 
>
>
>
>Les
>
>
>
> >
>
> > Thanks
>
> >
>
> > Zhibo Hu
>
> >
>
> > > -Original Message-
>
> > > Fr

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

[Les Ginsberg (ginsberg)]

Zhibo -



Please see inline.



> -Original Message-

> From: Huzhibo 

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

> To: Les Ginsberg (ginsberg) ; Peter Psenak (ppsenak)

> ; linchangwang ;

> Acee Lindem ; lsr 

> 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-<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 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 by all routers 
in the network.

I think this makes a big difference. 



   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 
> > mailto:ppsenak=40cisco@dmarc.ietf.org>>;
> >  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

> >

> > Changwang -

> >

> > It is very important to note ...

> >

> > 

> > > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and

> > > > [RFC9084] to

> > > indicate reachability by checking whether the originator information

> > > is

> > > >NULL.

> > 

> >

> > This statement is incorrect. There is no existing mechanism defined in the

> > protocol that states that a prefix reachability advertisement sent with a

> > source router ID == 0 implies unreachability.

> > Please see https://www.rfc-editor.org/rfc

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

[Huzhibo]

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.
Both two draft used The 0xFE00 metric indicates that the prefix is not 
reachable. Doesn't make a difference at this point.

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 ; linchangwang
> ; Acee Lindem ;
> lsr 
> 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
> 
> Changwang -
> 
> It is very important to note ...
> 
> 
> > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and
> > > [RFC9084] to
> > indicate reachability by checking whether the originator information
> > is
> > >NULL.
> 
> 
> This statement is incorrect. There is no existing mechanism defined in the
> protocol that states that a prefix reachability advertisement sent with a
> source router ID == 0 implies unreachability.
> Please see https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2
> 
> Existing routers, on receiving a prefix reachability advertisement with a
> Source Router ID == 0 will interpret that prefix as being reachable - which
> is exactly the opposite of the intent defined in
> https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annouc
> ement-12.txt
> This is one of the things which is broken in this draft.
> This fact has been pointed out to the authors many times over the years -
> but they have consistently ignored it.
> 
> On the other hand,
> https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-annou
> nce-04.txt uses an existing mechanism defined in RFC 5305 to insure that
> legacy routers who do not understand the new use case or the new flags
> will ignore the prefix reachability advertisement. This has been verified by
> testing against multiple implementations.
> 
> Please be accurate in the statements that you make.
> 
>Les
> 
> 
> > -Original Message-
> > From: Lsr  On Behalf Of Peter Psenak
> > Sent: Wednesday, August 30, 2023 8:43 AM
> > To: linchangwang ; Acee Lindem
> > ; lsr 
> > 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
> >
> > Changwang,
> >
> > On 30/08/2023 08:15, linchangwang wrote:
> > > Hi WG,
> > >
> > > When considering adoption, it's important to take into account the
> > > following
> > drafts as well.
> > >
> > > Draft #1 link：https://www.ietf.org/archive/id/draft-wang-lsr-prefix-
> > unreachable-annoucement-12.txt
> > > Draft #2 link：https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-
> > ureach-prefix-announce-04.txt
> > >
> > > Reasons are as follows:
> > >
> > > 1. The two drafts mentioned above are similar in nature.
> > >The draft #1 covers more scenarios than the draft #2 as mentioned
> > > by
> > Zhibo Hu mail.
> > >Therefore, a more in-depth discussion and technical comparison
> > > should
> > take place before any adoption decision is made.
> > >
> > > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and
> > > [RFC9084] to
> > indicate reachability by checking whether the originator information
> > is
> > >NULL. On the other hand, the draft #2 introduces a new flag to
> > > indicate
> > reachability.
> > >From an implementation perspective, it would be easier to
> develop
> > > using
> > the existing RFC mechanisms.
> > >
> > > 3. The Draft #1 covers more scenarios and can address the
> > > aggregation issues
> > of multiple ABRs.
> > >However, the Draft #2 explicitly states in Chapter 6 that it does
> > > not support
> > this scenario.
> >
> > to be more precise, draft #1 talks about more scenarios, it does not
> > solves any of them, as these scenarios can not be solved by what the
> > draft #1 introduces.
> >
> > draft#2 clearly states the fact that these scenarios are not addressed.
> >
> > thanks,
> > Peter
> >
> > >
> > >

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

[Les Ginsberg (ginsberg)]

Changwang -

It is very important to note ...


> > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and [RFC9084] to
> indicate reachability by checking whether the originator information is
> >NULL.


This statement is incorrect. There is no existing mechanism defined in the 
protocol that states that a prefix reachability advertisement sent with a 
source router ID == 0 implies unreachability.
Please see https://www.rfc-editor.org/rfc/rfc7794.html#section-2.2

Existing routers, on receiving a prefix reachability advertisement with a 
Source Router ID == 0 will interpret that prefix as being reachable - which is 
exactly the opposite of the intent defined in 
https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annoucement-12.txt
This is one of the things which is broken in this draft.
This fact has been pointed out to the authors many times over the years - but 
they have consistently ignored it.

On the other hand, 
https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-04.txt
 uses an existing mechanism defined in RFC 5305 to insure that legacy routers 
who do not understand the new use case or the new flags will ignore the prefix 
reachability advertisement. This has been verified by testing against multiple 
implementations.

Please be accurate in the statements that you make.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Peter Psenak
> Sent: Wednesday, August 30, 2023 8:43 AM
> To: linchangwang ; Acee Lindem
> ; lsr 
> 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
> 
> Changwang,
> 
> On 30/08/2023 08:15, linchangwang wrote:
> > Hi WG,
> >
> > When considering adoption, it's important to take into account the following
> drafts as well.
> >
> > Draft #1 link：https://www.ietf.org/archive/id/draft-wang-lsr-prefix-
> unreachable-annoucement-12.txt
> > Draft #2 link：https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-
> ureach-prefix-announce-04.txt
> >
> > Reasons are as follows:
> >
> > 1. The two drafts mentioned above are similar in nature.
> >The draft #1 covers more scenarios than the draft #2 as mentioned by
> Zhibo Hu mail.
> >Therefore, a more in-depth discussion and technical comparison should
> take place before any adoption decision is made.
> >
> > 2. The Draft #1 utilizes the existing mechanisms [RFC7794] and [RFC9084] to
> indicate reachability by checking whether the originator information is
> >NULL. On the other hand, the draft #2 introduces a new flag to indicate
> reachability.
> >From an implementation perspective, it would be easier to develop using
> the existing RFC mechanisms.
> >
> > 3. The Draft #1 covers more scenarios and can address the aggregation issues
> of multiple ABRs.
> >However, the Draft #2 explicitly states in Chapter 6 that it does not 
> > support
> this scenario.
> 
> to be more precise, draft #1 talks about more scenarios, it does not
> solves any of them, as these scenarios can not be solved by what the
> draft #1 introduces.
> 
> draft#2 clearly states the fact that these scenarios are not addressed.
> 
> thanks,
> Peter
> 
> >
> > 4. If we remove the additional scenarios covered in Draft #1 and compare the
> two drafts, the only remaining difference is the method of indicating
> unreachable prefixes -
> >either through a UPA flag or using the originator TLV.
> >
> >
> > Thanks,
> > Changwang
> >
> >
> > -Original Message-
> > From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
> > Sent: Thursday, August 24, 2023 3:58 AM
> > To: 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
> >
> > 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
> > 
> -
> > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址
> 中列出
> > 的

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

[Peter Psenak]

Changwang,

On 30/08/2023 08:15, linchangwang wrote:

Hi WG,

When considering adoption, it's important to take into account the following 
drafts as well.

Draft #1 
link：https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annoucement-12.txt
Draft #2 
link：https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-04.txt

Reasons are as follows:

1. The two drafts mentioned above are similar in nature.
   The draft #1 covers more scenarios than the draft #2 as mentioned by Zhibo 
Hu mail.
   Therefore, a more in-depth discussion and technical comparison should take 
place before any adoption decision is made.

2. The Draft #1 utilizes the existing mechanisms [RFC7794] and [RFC9084] to 
indicate reachability by checking whether the originator information is
   NULL. On the other hand, the draft #2 introduces a new flag to indicate 
reachability.
   From an implementation perspective, it would be easier to develop using the 
existing RFC mechanisms.

3. The Draft #1 covers more scenarios and can address the aggregation issues of 
multiple ABRs.
   However, the Draft #2 explicitly states in Chapter 6 that it does not 
support this scenario.


to be more precise, draft #1 talks about more scenarios, it does not 
solves any of them, as these scenarios can not be solved by what the 
draft #1 introduces.


draft#2 clearly states the fact that these scenarios are not addressed.

thanks,
Peter



4. If we remove the additional scenarios covered in Draft #1 and compare the 
two drafts, the only remaining difference is the method of indicating 
unreachable prefixes -
   either through a UPA flag or using the originator TLV.


Thanks,
Changwang


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Thursday, August 24, 2023 3:58 AM
To: 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

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
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
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 Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-unreach-prefix-announce-04

[linchangwang]

Hi WG,

When considering adoption, it's important to take into account the following 
drafts as well.

Draft #1 
link：https://www.ietf.org/archive/id/draft-wang-lsr-prefix-unreachable-annoucement-12.txt
Draft #2 
link：https://www.ietf.org/archive/id/draft-ppsenak-lsr-igp-ureach-prefix-announce-04.txt

Reasons are as follows:

1. The two drafts mentioned above are similar in nature.
  The draft #1 covers more scenarios than the draft #2 as mentioned by Zhibo Hu 
mail.
  Therefore, a more in-depth discussion and technical comparison should take 
place before any adoption decision is made.

2. The Draft #1 utilizes the existing mechanisms [RFC7794] and [RFC9084] to 
indicate reachability by checking whether the originator information is
  NULL. On the other hand, the draft #2 introduces a new flag to indicate 
reachability.
  From an implementation perspective, it would be easier to develop using the 
existing RFC mechanisms.

3. The Draft #1 covers more scenarios and can address the aggregation issues of 
multiple ABRs.
  However, the Draft #2 explicitly states in Chapter 6 that it does not support 
this scenario.

4. If we remove the additional scenarios covered in Draft #1 and compare the 
two drafts, the only remaining difference is the method of indicating 
unreachable prefixes -
  either through a UPA flag or using the originator TLV.


Thanks,
Changwang


-Original Message-
From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Acee Lindem
Sent: Thursday, August 24, 2023 3:58 AM
To: 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

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
-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
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-unreach-prefix-announce-04

[Acee Lindem]

Speaking as WG member:

I support WG adoption. This draft solves the WG agreed upon problem of 
notification of a prefix being unreachable to other applications without 
modifying the routing table and with a fully backward compatible mechanism. 
There is running vendor code and operators who are deploying this solution. 

I think that the problem could be solved with OSPF advertisement of individual 
summary LSAs in the range of PE addresses. However, with IS-IS there is a 
limited number LSPs that can be advertised and multiple summary prefixes must 
be advertised in the same LSP. Any time there is an unreachable prefix, the 
entire monolithic LSP must be re-advertised.  Additionally, operators do not 
want to separate out the PE addresses into a separate address range as they 
haven’t done the in the past. 

Thanks,
Acee

> On Aug 23, 2023, at 15:58, 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

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

[Voyer, Daniel]

Hi wg,

I support the adoption of UPA. This solution is key when summarization is used 
for IPv6/SRv6 networks.

Thanks
Dan

On 2023-08-23, 3:58 PM, "Lsr on behalf of Acee Lindem" mailto:lsr-boun...@ietf.org> on behalf of 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 

--
External Email: Please use caution when opening links and attachments / 
Courriel externe: Soyez prudent avec les liens et documents joints



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