Hi, Les:
Please do not mislead the experts within the LSR. Detail replies are inline below. Best Regards Aijun Wang China Telecom 发件人: [email protected] [mailto:[email protected]] 代表 Les Ginsberg (ginsberg) 发送时间: 2023年8月31日 22:49 收件人: Huzhibo <[email protected]>; Peter Psenak (ppsenak) <[email protected]>; linchangwang <[email protected]>; Acee Lindem <[email protected]>; lsr <[email protected]> 抄送: [email protected] 主题: 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:[email protected]> mailto:[email protected]] On > > Behalf Of Les Ginsberg > > (ginsberg) > > Sent: Thursday, August 31, 2023 12:31 AM > > To: Peter Psenak < <mailto:[email protected]> > > [email protected]>; linchangwang > > < <mailto:[email protected]> [email protected]>; Acee > > Lindem < <mailto:[email protected]> [email protected]>; > > lsr < <mailto:[email protected]> [email protected]> > > Cc: <mailto:[email protected]> > > [email protected] > > 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:[email protected]> [email protected]> On Behalf > > > Of Peter Psenak > > > Sent: Wednesday, August 30, 2023 8:43 AM > > > To: linchangwang < <mailto:[email protected]> > > > [email protected]>; Acee Lindem > > > < <mailto:[email protected]> [email protected]>; lsr < > > > <mailto:[email protected]> [email protected]> > > > Cc: <mailto:[email protected]> > > > [email protected] > > > 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:[email protected]> mailto:[email protected]] > > > > On Behalf Of Acee Lindem > > > > Sent: Thursday, August 24, 2023 3:58 AM > > > > To: lsr > > > > Cc: <mailto:[email protected]> > > > > [email protected] > > > > 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:[email protected]> [email protected] > > > > <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:[email protected]> [email protected] > > > > <https://www.ietf.org/mailman/listinfo/lsr> > > > > https://www.ietf.org/mailman/listinfo/lsr > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > <mailto:[email protected]> [email protected] > > > <https://www.ietf.org/mailman/listinfo/lsr> > > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > > Lsr mailing list > > <mailto:[email protected]> [email protected] > > <https://www.ietf.org/mailman/listinfo/lsr> > > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
