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

[Aijun Wang <[e-mail]>]

Hi, Les:

 

Please do not mislead the experts within the LSR.

Detail replies are inline below.

 

 

Best Regards

 

Aijun Wang

China Telecom

 

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

 

Zhibo –

 

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

overthrow it, indicate that the explicit signaling is necessary.

 

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

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

 

> Both two draft used The 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).

 

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

 

   Les

 

Thanks

Zhibo

 

   Les

 

> 

> Thanks

> 

> Zhibo Hu

> 

> > -----Original Message-----

> > From: Lsr [ <mailto:[e-mail]> mailto:[e-mail]] On Behalf Of Les Ginsberg

> > (ginsberg)

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

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

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

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

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

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

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

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

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

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

> > > > To: lsr

> > > > Cc:  <mailto:[e-mail]> [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

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

> > > >  <https://www.ietf.org/mailman/listinfo/lsr> 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

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

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

> > > >

> > >

> > > _______________________________________________

> > > Lsr mailing list

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

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

> > _______________________________________________

> > Lsr mailing list

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

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