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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 0xFE000000 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:[e-mail]] On Behalf Of Les Ginsberg

> > (ginsberg)

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

> > To: Peter Psenak <ppsenak=[e-mail]<mailto:ppsenak=[e-mail]>>; linchangwang

> > <[e-mail]<mailto:[e-mail]>>; Acee Lindem <[e-mail]<mailto:[e-mail]>>;

> > lsr <[e-mail]<mailto:[e-mail]>>

> > Cc: [e-mail]<mailto:[e-mail]>

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

> >

> > <snip>

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

> > > > [RFC9084] to

> > > indicate reachability by checking whether the originator information

> > > is

> > > >    NULL.

> > <end snip>

> >

> > 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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Peter Psenak

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

> > > To: linchangwang <[e-mail]<mailto:[e-mail]>>; Acee Lindem

> > > <[e-mail]<mailto:[e-mail]>>; lsr <[e-mail]<mailto:[e-mail]>>

> > > Cc: [e-mail]<mailto:[e-mail]>

> > > 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:[e-mail]] On Behalf Of Acee Lindem

> > > > Sent: Thursday, August 24, 2023 3:58 AM

> > > > To: lsr

> > > > Cc: [e-mail]<mailto:[e-mail]>

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

> > > > [e-mail]<mailto:[e-mail]>

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

> > > > [e-mail]<mailto:[e-mail]>

> > > > https://www.ietf.org/mailman/listinfo/lsr

> > > >

> > >

> > > _______________________________________________

> > > Lsr mailing list

> > > [e-mail]<mailto:[e-mail]>

> > > https://www.ietf.org/mailman/listinfo/lsr

> > _______________________________________________

> > Lsr mailing list

> > [e-mail]<mailto:[e-mail]>

> > https://www.ietf.org/mailman/listinfo/lsr