Aijun – You either have not understood the points I have made, or you have not read what I wrote closely enough.
As I have done my best to be as clear as possible, I can only ask that you read my responses to both Changwang and Zhibo again – as well as reread Peter’s response to Changwang. If rereading is of no help – please ask someone else to explain it to you – I do not know how to state things more clearly than I have. Respectfully, Les From: Lsr <lsr-boun...@ietf.org> On Behalf Of Aijun Wang Sent: Wednesday, August 30, 2023 8:37 PM To: 'Les Ginsberg (ginsberg)' <ginsberg=40cisco....@dmarc.ietf.org>; 'Huzhibo' <huzhibo=40huawei....@dmarc.ietf.org>; Peter Psenak (ppsenak) <ppse...@cisco.com>; 'linchangwang' <linchangwang.04...@h3c.com>; 'Acee Lindem' <acee.i...@gmail.com>; 'lsr' <lsr@ietf.org> 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 Hi，Les: The use of the max-metric is only to the let the legacy routers to ignore the PUAM message(the LSA that is advertised with the prefix originator set to NULL), to assure the interoperability with existing routers. It is same for both solutions. The main difference for the explicit unreachability indication of the prefix, as Chang Wang summarized, is that one defined newly the prefix flag, another utilized the existing prefix originator field. If the ABR finds the prefix is unreachable, then there will be no router advertise this prefix within the associated area, it is straightforward to label the “prefix originator” as NULL to indicate such information, then is it redundancy to define again the flag? Besides the above difference, we should consider also other scenarios that draft-ppsenak lacks but draft-wang has covered, as Zhibo indiciated in https://mailarchive.ietf.org/arch/msg/lsr/r-qLlA2JW-JOLVf_LBlEXwE01jE/ Best Regards Aijun Wang China Telecom 发件人: lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org> [mailto:lsr-boun...@ietf.org] 代表 Les Ginsberg (ginsberg) 发送时间: 2023年8月31日 10:57 收件人: Huzhibo <huzhibo=40huawei....@dmarc.ietf.org<mailto:huzhibo=40huawei....@dmarc.ietf.org>>; Peter Psenak (ppsenak) <ppse...@cisco.com<mailto:ppse...@cisco.com>>; 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>> 抄送: draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org<mailto:draft-ppsenak-lsr-igp-unreach-prefix-annou...@ietf.org> 主题: 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 > <huzhibo=40huawei....@dmarc.ietf.org<mailto:huzhibo=40huawei....@dmarc.ietf.org>> > Sent: Wednesday, August 30, 2023 6:33 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; > Peter Psenak (ppsenak) > <ppse...@cisco.com<mailto:ppse...@cisco.com>>; 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 > > 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: <snip> If a prefix is advertised with a metric larger then MAX_PATH_METRIC (0xFE000000, 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. <end snip> (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 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. 😊 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
