Hi, John: What’s your responses to this issue and my proposal then?
We need your guidances. Aijun Wang China Telecom > On Sep 20, 2023, at 17:22, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > 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 _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
