Aijun, John, Technical comments as WG member:
See inline. > On Sep 15, 2023, at 3:08 AM, Aijun Wang <[email protected]> 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. >> 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. However, the first to provide backward-compatible notification focused on the short-lived notification use case was the WG document. >> 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. >> 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. >> 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. 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??? 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. 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 <[email protected]> >> 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 <[email protected]> wrote: >>> >>> From: Lsr <[email protected]> on behalf of Aijun Wang >>> <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$ >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$ >> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
