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: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<mailto:ppsenak=40cisco....@dmarc.ietf.org>>; > > linchangwang > > <linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com>>; Acee > > Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>; > > lsr <lsr@ietf.org<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 ... > > > > <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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> On Behalf > > > Of Peter Psenak > > > Sent: Wednesday, August 30, 2023 8:43 AM > > > To: linchangwang > > > <linchangwang.04...@h3c.com<mailto:linchangwang.04...@h3c.com>>; Acee > > > Lindem > > > <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>; lsr > > > <lsr@ietf.org<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, > > > > > > 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<mailto: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<mailto: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<mailto:Lsr@ietf.org> > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org<mailto:Lsr@ietf.org> > > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org<mailto:Lsr@ietf.org> > > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
