Hi, Acee, John: My proposal to solve the issue is that we can discuss the merge possibility for the contents and author list of WG document at the IETF 118 on-site meeting. I think you (also LSR experts within the list) can't deny draft-ppsenk was inspired by our draft. It's unfair to ignore the adoption call of https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
Detail replies are inline below. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 Acee Lindem 发送时间: 2023年9月16日 1:16 收件人: Aijun Wang <wangai...@tsinghua.org.cn> 抄送: John Scudder <jgs=40juniper....@dmarc.ietf.org>; Christian Hopps <cho...@chopps.org>; lsr <lsr@ietf.org>; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org; tom petch <ie...@btconnect.com> 主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04 Aijun, John, Technical comments as WG member: See inline. > On Sep 15, 2023, at 3:08 AM, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > Hi,John: > > Thanks in advance for your review for the discussion within the mail list. > > Normally, the WG adoption call decisions will be coordinated between the > Chairs. That’s the reason that I sort the judgement directly from the AD. > > If the previous results represents only Acee’s preference, we would like to > ask Chris to review also all the discussions and expect Chris to solve my > concerns that Acee didn’t convince me. > > The IETF community should respect the initiative idea and adoption decision > should be made based on the facts. > > Hi, Chris: > > I have asked Acee the following questions > (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/ )and > would like to hear your feedback: >> >> >> >> 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? Given that the WG agreed to solve a specific use case, this is irrelevant. [WAJ] The specific use case is also first provided by https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ >> 2) Which draft is the first to propose explicit signaling for >> unreachable information? Since the mechanism in your draft use an assumption about the value of prefix-originator, one could argue that it is not strictly explicit. [WAJ] The meaning of newly defined special value of prefix-originator is similar as the meaning of the newly defined flag. However, the first to provide backward-compatible notification focused on the short-lived notification use case was the WG document. [WAJ] I think you have noticed that there was one big conversion from the first version of draft-ppsenk(implicit signaling only) to its latest version(including explicit signaling also). The reason for the conversion is that we insisted that the explicit signaling was the direction. >> 3) Which draft is the first to propose short lived notification? I believe Robert Raszuk was the first to bring up the use case on the LSR list - well before it was included in any draft. [WAJ] Would you or Robert Raszuk like to provide the link within the LSR list to prove the above imagination? >> 4) Which explicit signaling mechanism is simpler? The draft which the WG rallied behind is much cleaner and based on the WG request for explicit unreachable flags. As I mentioned before, it is backward-compatible. Your document also requires a capabilities advertisement and different behavior depending on whether or not all routers in the area support the mechanism (section 5). The WG document is clearly simpler. [WAJ]There is already field to carry such information, it is redundancy to define the flag again. And, the most important thing is that using the existing field can provide the uniform explicit signaling methods for all the IGP protocols, we needn't find different places to set and parse the flags in different protocol. Which is simpler? The reason that we keep capabilities advertisement, as I explained in https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48/ in detail, is that we want to fade out the usage of LSInfinity in future. We should keep and put forward the deployment of such mechanism in simple format or direction, don't make the network operation more complex. >> 5) Which draft provides more mechanisms to cover more scenarios? While you purport to support multiple use cases, they conflict with one another. For example, the use cases which require a change in OSPF advertisement by the other ABR(s) would require knowledge as long as the prefix is unreachable. You also have section 7 which is relevant to persistent notification and not the short-lived notification agreed upon by the WG. [WAJ] It is not enough to consider only the sender mechanism and doesn't consider its usage in more complex situations. Even in partition scenario, the advertisement of PUAM message need not last forever. And, which sentences in section 7 is relevant to persistent notification? Aijun - now that I have answered your questions again, I have one for you that you have never answered. Why have you rejected attempts to merge the drafts unless they adopted your mechanisms??? Why wouldn’t you join the WG draft which has adapted to the feedback on the LSR llst and garnered the WG support??? [WAJ] It's reasonable that initiator lead the merge work----we have put forward such work THREE years earlier than draft-ppsenk. I have express the merge proposal at https://mailarchive.ietf.org/arch/msg/lsr/E6Pg6kDppFfrPWJ0h03XivUHB48/, but it is rejected. Since your draft claims to support many use cases, you could still attempt to bring it forward as well. However, this should be independent of the WG document. [WAJ] It is impracticable. The solution to the scenarios are coupled with the notification mechanism. We should consider them together. Thanks, Acee >> >> The base document should be selected based on the answers of the above >> questions. > > John can also refer the above questions when reviewing the past discussions > within the list. > > Aijun Wang > China Telecom > >> On Sep 15, 2023, at 04:02, John Scudder <jgs=40juniper....@dmarc.ietf.org> >> wrote: >> >> Tom is right of course, and thank you for pointing it out. (The >> specific section in RFC 2026 to look at is 6.5.1.) >> >> In the meantime, I’ll review the mailing list discussion. However, the most >> desirable outcome would be to settle things at the WG level without further >> escalation. >> >> —John >> >>> On Sep 14, 2023, at 12:25 PM, tom petch <ie...@btconnect.com> wrote: >>> >>> From: Lsr <lsr-boun...@ietf.org> on behalf of Aijun Wang >>> <wangai...@tsinghua.org.cn> >>> Sent: 14 September 2023 11:38 >>> >>> Hi, Acee: >>> >>> I admire your efforts for the LSR WG, but for the adoption call of this >>> draft, you have not convinced me, although I gave you large amount of solid >>> facts. >>> Then, it's time to let our AD to step in, to make the non-biased judgement, >>> based on our discussions along the adoption call. >>> >>> <tp> >>> >>> I think that what you have in mind is an appeal, as per RFC2026. >>> >>> The first stage therein is to involve the Chairs, and while Acee is one, he >>> is not the only one. >>> >>> Have you involved the other Chair, on or off list? That would seem to me to >>> be next step. >>> >>> Tom Petch >>> >>> >>> We request the WG document be based on the >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$ >>> , because it is the first document to initiate the use case, provide the >>> explicit signaling mechanism, and cover more scenarios. >>> >>> It’s unreasonable to adopt the follower solution and ignore the initiator. >>> We started and lead the discussions THREE years earlier than the current >>> proposal. >>> >>> Aijun Wang >>> China Telecom >>> >>>> On Sep 8, 2023, at 23:16, Acee Lindem <acee.i...@gmail.com> wrote: >>>> >>>> The WG adoption call has completed and there is more than sufficient >>>> support for adoption. >>>> What’s more, vendors are implementing and operators are planning of >>>> deploying the extensions. >>>> Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00. >>>> >>>> A couple of WG members, while acknowledging the use case, thought that it >>>> would be better satisfied outside of the IGPs. >>>> In fact, they both offered other viable alternatives. However, with >>>> the overwhelming support and commitment to implementation and >>>> deployment, we are going forward with WG adoption of this document. As the >>>> Co-Chair managing the adoption, I don’t see this optional mechanism as >>>> fundamentally changing the IGPs. >>>> >>>> There was also quite vehement opposition from the authors of >>>> draft-wang-lsr-prefix-unreachable-annoucement. This draft purports >>>> to support the same use case as well as others (the archives can be >>>> consulted for the discussion). Further discussion of this other >>>> draft and the use cases it addresses should be in the context of >>>> draft-wang-lsr-prefix-unreachable-annoucement >>>> and not the WG draft. >>>> >>>> Thanks, >>>> Acee >>>> >>>>> On Aug 23, 2023, at 3:58 PM, Acee Lindem <acee.i...@gmail.com> wrote: >>>>> >>>>> 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 >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>> sr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeB >>>> kYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$ >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ls >>> r__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkY >>> kjEH4eFsk7HxvaaacJE5IDNwDbvQ$ >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
