Hi, Acee:
It‘s you that repeat the FALSE statements. What I can do is to give you the FACT again. Please see inline below for the response to your FALSE statements. Best Regards Aijun Wang China Telecom 发件人: Acee Lindem [mailto:[email protected]] 发送时间: 2023年9月6日 20:44 收件人: Aijun Wang <[email protected]> 抄送: Robert Raszuk <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Huzhibo <[email protected]>; Peter Psenak <[email protected]>; linchangwang <[email protected]>; lsr <[email protected]> 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 Hi Aijun, I think we are repeating ourselves here. However, let me add a couple points. The fact that you added the BGP PIC use case to your draft when the WG indicated that was the problem to be solved doesn’t make you the owner of the use case. [WAJ] FALSE Statement. I have replied you for such FALSE assertions at https://mailarchive.ietf.org/arch/msg/lsr/I1Hb28F1Fg8GrPTynJa1ZYqtY0Y/ (Aug.25 2023) , but you raised it again. Please provide the fact that “WG indicated that was the problem to be solved” before our proposal. For your convenience, I replied again in detail below: Please read carefully the description in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-00#section-3 (Proposed in Oct.24, 2019) "In another situation, assume the BGP session is built between Node S2 and T2, via Ps2 and Pt2 respectively. If Node S2 within area 1 become unreachable, the unreachable information can't be advertised to Node T2 because the summary behaviour on border router R1/R3. The BGP session between S1 and T2 will be kept until the BGP keepalive timeout or other detection mechanism takes effect. During this period, the BGP traffic to Node S2 will be in black hole." Additionally, the fact that you were offered authorship on the draft under adoption is a recognition that you did have a draft the addressed IGP unreachability. However, you declined. [WAJ] We provide first the use cases, insist that the explicit signaling solution is the direction and lead the discussions within LSR WG, the adoption draft should be based on https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement, not the follower. Finally, even after appropriating some of the elements of the draft under adoption (e.g., unreachable metrics and configuration of LSA life) your draft is now a superset of the former draft and, IMO, unimplementable. [WAJ] FALSE Statement. For the configuration of LSA Life, I have replied you at https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/, please do not repeat it again. For your convenience, let me emphasize the FACT again: 1) The description about the short lived notification in <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 was on March 26, 2021 2) The similar description, even the 00 version of <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was submitted on July 5, 2021 Then, which draft appropriates which draft? For the unreachable metrics, the usages of the two drafts are different: draft-ppsenak used such information as implicit signaling(“This functionality can be used to advertise a prefix (IPv4 or IPv6) in a manner which indicates that reachability has been lost”), we used it to solve the interoperable issue with the legacy router(“the prefix advertised with such metric value will not be considered during the normal SPF computation)” which is the original usage that defined in relevant RFCs) It is after our insists and intense discussions, draft-ppsenak switched to the explicit signaling(by defining new flags, which is still arguable). It is now the superset of the implicit signaling and explicit signaling, which is unnecessary. Thanks, Acee On Sep 6, 2023, at 01:56, Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Acee: AGAIN, before making some assertions, please check the following fact: Have you noticed the 00 version of <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ was submitted on July 5, 2021? But the description about the short lived notification in <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7 was on March 26, 2021. Then, which draft was the first? For the adoption call or merge efforts, I think the WG should consider the following facts: 1) Which draft is the first to provide the use cases? 2) Which draft is the first to propose explicit signaling for unreachable information? 3) Which draft is the first to propose short lived notification? 4) Which explicit signaling mechanism is simpler? 5) Which draft provides more mechanisms to cover more scenarios? The base document should be selected based on the answers of the above questions. Select the base document doesn’t mean that it can’t be changed before the adoption(I haven’t said “Without Change” is the merge condition). Actually, we welcome more authors to join us to finalize the document and solution. As one of the most important WG within IETF, I think LSR WG should respect the original contributions to the WG. It is too hurry to consider or adopt only the draft that you prefer, especially the follower draft. Best Regards Aijun Wang China Telecom 发件人: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] 代表 Acee Lindem 发送时间: 2023年9月6日 0:56 收件人: Aijun Wang < <mailto:[email protected]> [email protected]> 抄送: Robert Raszuk < <mailto:[email protected]> [email protected]>; Les Ginsberg (ginsberg) < <mailto:[email protected]> [email protected]>; Huzhibo < <mailto:[email protected]> [email protected]>; Peter Psenak < <mailto:[email protected]> [email protected]>; linchangwang < <mailto:[email protected]> [email protected]>; lsr < <mailto:[email protected]> [email protected]> 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 Hi Aijun, When the WG discussion first indicated that this was a use case that needed to be addressed, I don’t dispute that you immediately added it to your draft. I have no doubt you would have purported support of any use case under discussion. However, the first draft to address this use case with a short-lived notification was <https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/> https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-event-notification/ Based on WG feedback and collaboration of multiple vendors, this draft evolved to draft-ppsenak-lsr-igp-ureach-prefix-announce. While you’ve incorporated elements of the draft under discussion, your draft still includes pieces (sometimes conflicting) from previous use cases. There was an effort to merge the drafts but you declined unless your draft was used (without change) as the base. I’m not sure your motivation. Thanks, Acee On Sep 1, 2023, at 20:25, Aijun Wang < <mailto:[email protected]> [email protected]> wrote: Hi, Acee: Act as LSR chair, I think you should be more responsible to make any unfounded assertions: We have described the previous statements in <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-06#section-7, March 26, 2021, one year before the 00 version of draft-ppsenak(March 25,2022) Then, which draft copy or incorporate which draft? Aijun Wang China Telecom On Sep 1, 2023, at 20:05, Acee Lindem < <mailto:[email protected]> [email protected]> wrote: Hi Aijun, On Aug 31, 2023, at 23:36, Aijun Wang < <mailto:[email protected]> [email protected]> wrote: Hi，Acee: Please read <https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7> https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-7 before making misguide assertions: “The advertisement of PUAM message should only last one configurable period to allow the services that run on the failure prefixes are switchovered.” I guess I haven’t kept up with all the elements of the draft under adoption that you continue to incorporate into your draft. This has been a continuing theme since initial discussed of the application signaling use case. While I have no interest in improving your draft, making the LSP/LSA short-lived conflicts with the other scenarios your draft purports to address. Acee Best Regards Aijun Wang China Telecom 发件人: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] 代表 Acee Lindem 发送时间: 2023年9月1日 0:50 收件人: Robert Raszuk < <mailto:[email protected]> [email protected]> 抄送: Les Ginsberg (ginsberg) < <mailto:[email protected]> [email protected]>; Huzhibo < <mailto:[email protected]> [email protected]>; Peter Psenak < <mailto:[email protected]> [email protected]>; linchangwang < <mailto:[email protected]> [email protected]>; lsr < <mailto:[email protected]> [email protected]> 主题: Re: [Lsr] Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 On Aug 31, 2023, at 12:32, Robert Raszuk < <mailto:[email protected]> [email protected]> wrote: Hi Acee, In any case, one will need to update the signaling routers and the routers acting on the signal. I guess this is clear to all. Additionally, your request for the adoption was that the draft have a stronger statement about the mechanism being used for solely for signaling for applications (e.g., BGP PIC). As to the applicability my comment was that either draft should state in strong normative language that this is applicable only to applications which data plane uses encapsulation to the next hop. Said this draft-wang introduces the additional signalling, sort of trying to assure that all nodes in an area understand the new messages - but I am not sure if even advertising PUAM capability means that it will be actually used for all destinations ? No - but while the draft under adoption (ppsenak-lsr…) is for an ephemeral signal which the WG agreed was a valid use case, in the other draft, the LSAs are long-lived and are also may be used for other purposed than signaling (e.g., reread both sections 4 and 6 of draft-wang-lsr…). This draft starting with a whole different use case but selectively added mechanisms from ppsenak-lsr… I seem to recall you were a strong proponent of limiting the scope. By responding to this Email inline, some may believe you support the assertion that we should start the adoption of both drafts. Please be clarify this. Well the way I see this is that adoption call is a bit more formal opportunity for WG members to express their opinion on any document. But maybe LSR (for good reasons) have different internal rules to decide which document should be subject to WG adoption and does sort of pre-filtering. If adoption call proves document has negative comments or lacks cross vendor support it simply does not get adopted. Maybe I am just spoiled looking at how IDR WG process works :-) You replied to an Email inline suggesting adoption of both drafts. That is what I think could have been misconstrued - especially by those who didn’t follow the discussion until now who think you are agreeing with this recommendation. As for your other comment that this could be accomplished with BGP or an out-of-bound mechanism, that is true but that could be true of many problem. However, the solution under adoption has running code and wide vendor support. Right ... As I wrote to Peter - perhaps this is just a pragmatic approach and flooding is what link state uses so be it. As you know I did try in the past to propose BGP Aggregate withdraw but then feedback of the community was that PEs do not go down that often to justify the extension. Hmm… We seem to have broad support for the LSR application signaling use case. Thanks, Acee Best, Robert _______________________________________________ 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 <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
