Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

Peter Psenak <ppsenak@cisco.com> Fri, 03 November 2023 14:02 UTC

Return-Path: <ppsenak@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1605C1516E1; Fri, 3 Nov 2023 07:02:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.699
X-Spam-Level:
X-Spam-Status: No, score=-14.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBwJvOuGNFZx; Fri, 3 Nov 2023 07:01:58 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70B0C14CF15; Fri, 3 Nov 2023 07:01:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11994; q=dns/txt; s=iport; t=1699020118; x=1700229718; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=Jri3JZiCCaUSSUG5ShTrj/sMVejt9Tqq2DRniG+th7Y=; b=SVVL/MELxRJ4AQx3eIUuTSqFK7VYmsc+wcl+t0mGojpP5XBC0znJ86t3 iSf/xNvt4cUIJon6Uo3l2wwDErDHQvN+3pvecvEDDbfNawJZnEAjr1J/J UPUULTBFcV/dWEXZB/ceI2AfogJ4CYolnJkQ8qbsbOGouDWQv1bLFqvEN M=;
X-CSE-ConnectionGUID: 4b8AB0EVStqw7jXhvJerkQ==
X-CSE-MsgGUID: HlMriaKiTECbzj1M/ARVxQ==
X-IPAS-Result: A0BdAACl/ERl/xbLJq1aHAEBAQEBAQcBARIBAQQEAQFAgT0FAQELAYMyVUBIBIROiHyINS0Di1ySIhSBag8BAQEPLggOBAEBhQYCFocMJzYHDgECBAEBAQEDAgMBAQEBAQEBAgEBBQEBAQIBBwSBChOFOwYnDYZNAQEBAwEBGwYRBDYLEAsOCgICEQ4HAgICHwYlCwYBDAYCAQEXgmMBgioDMQMRqx96gTKBAYNoQa4HDWqBYgaBGi4Bh2seAYUUJRiENRcrgUlEgTyCAUo4PmsaAYEZQgEBA4EWEgESASEXKIMcgmgEhl+CAxUuBzKBCgwJgQODKymBE4trVggiBUJwGwMHA4EAECsHBDAbBwYJFBgVIwZRBC0kCRMSPgSBY4FRCoECPw8OEYI9IgIHNjYZSIJVCRUMNEp2ECoEFBeBEQRqHRUeNxESFw0DCHYdAhEjOgIDBQMENAoSDQshBRRDA0IGSQsDAhoFAwMEgTYFDR4CEBoGDScDAxNNAhAUAzsDAwYDCzEDMFVEDFADbx82CRIqDwwfAhseDScqAjVIAxUFEgIFBA4DGSsdQAIBC209FCEJCxsGPgInnhptQoFBAWsaKiYEIg0UEAQQBBcsBgUaETwNBAENGAEECgEpOpIlsQRIb4QWhGeHGo8Vgm2DCwYPBC+EAYxzhkCRaGREhUmBWosJhU4gjUWDdZEzBBiFKDWBNQgtaXAzGggbFTuCZ1IZD4t0gjgLCxaDQIUUimZDMgI5AgcBCgEBAwkBaopfAQE
IronPort-Data: A9a23:zeOT56LyRlRHYuavFE+Rq5QlxSXFcZb7ZxGr2PjKsXjdYENShTBTz 2sdC2iBP/zfMWCmLtp3ad+0o0gD65XUy4NgHQYd+CA2RRqmiyZq6fd1j6vUF3nPRiEWZBs/t 63yUvGZcYZpCCea/k/9WlTYhSEU/bmSQbbhA/LzNCl0RAt1IA8skhsLd9QR2uaEuvDnRVvW0 T/Oi5eHYgT8gmYvajl8B5+r8XuDgtyj4Fv0gXRmDRx7lAe2v2UYCpsZOZawIxPQKmWDNrfnL wpr5OjRElLxp3/BOPv8+lrIWhFirorpAOS7oiE+t55OLfR1jndaPq4TbJLwYKrM4tmDt4gZJ N5l7fRcReq1V0HBsLx1bvVWL81xFfFMqJbteVWBitCK0BLEQ3vy4fh0D3hjaOX0+s4vaY1P3 fUVMnUGaQqOwr7wy7OgQe4qjcMmRCXpFNpA4Tc7nXeDVa1gG8qrr6bivbe02B8onttDG//dT 8EYcjFoKh/HZnWjP39GU8llw77z7pX5Wx1cjUiUrIk230X4xh5ziZ2qGeDrauXfEK25mW7d/ Aoq5V/RDgsTOsDa0SKe/3SlharLhjm+WY0KUaCi+/dhgBiL3GEdCQ1TXF29puS/gUOWWt9DJ QoT4CVGhawp7mSqQ8XzGRqirxasoRcaVNNREfA8wB2Wy6zb4xuQQG8eQXhKbrQOtsAtbT430 F6RksmvAzFz2IB5UlqU+63RrCu1IzRQK2YeIyQFVgACpdLkpenfky7yczqqK4bt5vWdJN066 2niQPQW71nLsfM26g==
IronPort-HdrOrdr: A9a23:+luoA63+OKCyOdGGkwclqgqjBIMkLtp133Aq2lEZdPWaSL36qy ncppUmPHjP+VAssRAb6Le90ca7LE80maQFhLX5eI3SODUO21HFEGgB1+HfKlTbckWUygce79 YDT0EUMrPN5DZB7foSrDPWLz7lq+P3iJxBQozlvg5QcT0=
X-Talos-CUID: 9a23:IF/JW2/dhgpEa3a1OumVvxIeSukPKlDj92vJPBC6OWZ3arCPSmbFrQ==
X-Talos-MUID: 9a23:C6PRsQjVHbwsR6PsueHIPMMpFMNN+aWnK0ExvL4MqcvdEGtZAQmNtWHi
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="6.03,273,1694736000"; d="scan'208";a="9333713"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Nov 2023 14:01:53 +0000
Received: from [10.147.24.54] ([10.147.24.54]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 3A3E1qZm011084; Fri, 3 Nov 2023 14:01:52 GMT
Message-ID: <e7f5732c-b6ea-71b5-8eec-bd6c0771defe@cisco.com>
Date: Fri, 03 Nov 2023 15:01:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
Content-Language: en-US
To: John Scudder <jgs@juniper.net>, Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: lsr <lsr@ietf.org>, "draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org" <draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org>
References: <28D58B1F-527C-4F8A-BD18-B74D5965FD14@gmail.com> <AE20A7EE-FA6F-4F19-93CA-1EE495025066@tsinghua.org.cn> <1442C0E5-20B3-41CC-8F84-BD83B783E970@juniper.net>
From: Peter Psenak <ppsenak@cisco.com>
In-Reply-To: <1442C0E5-20B3-41CC-8F84-BD83B783E970@juniper.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
X-Outbound-SMTP-Client: 10.147.24.54, [10.147.24.54]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/5QxXbwbP_MA4R0rqCpLvo0YfDAQ>
Subject: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2023 14:02:03 -0000

Hi John,

On 31/10/2023 23:01, John Scudder wrote:
> Hi Aijun,
> 
> I apologize for the length of time it’s taken me to respond to your request.
> 
> Having now taken the time to study the question properly, including a review of both drafts in question, the WG adoption call, and the subsequent email, here’s my take.
> 
> In large part, your position appears to be based on historical precedence — your draft was published first. (This is your “follower solution… initiator” in the email I’m responding to, as well as the first three “which draft is the first” points in your follow-up.) This is true of course. Furthermore, although our formal process does not take into account such questions as “who came first?” I think it would be safe for me to say that people generally do try to do not just what’s required, but what’s right, in terms of acknowledging prior work. For this reason, I was a little surprised to see no acknowledgment of the contributions of your draft in draft-ppsenak. But I think such an acknowledgment — which is a norm, not a requirement — is the most you can expect for having published the first 

for the record, I have offered co-authorship to Aijun and rest of the 
authors of his draft numerous times. They decided to pursue their draft 
instead.

thanks,
Peter


draft that covers the same general subject area as draft-ppsenak. This 
might also be a good time to remind you that 
draft-wang-lsr-prefix-unreachable-annoucement-00 includes the statement,
> 
>     This Internet-Draft is submitted in full conformance with the
>     provisions of BCP 78 and BCP 79.
> 
> I encourage you to review BCP 78 if you haven’t recently.
> 
> In short, I’m not persuaded by the first-to-publish argument.
> 
> The other major point made by you, and others advocating for the consideration of draft-wang as the WG solution and against draft-ppsenak, is that draft-wang is said to cover more cases. (This is “cover more scenarios” in your email, as well as point five, “cover more scenarios” in your follow-up.) There was some spirited debate about whether the draft does so successfully, or not, but I don’t want to take a position on that in this email. Rather, what I observe is that since these points were made clearly, and repeatedly, in the WG adoption email thread as well as at other times previously, it can’t be argued that the WG didn’t know that draft-wang claims to address (for example) area partition, and that draft-ppsenak explicitly doesn’t. So, this suggests those who supported the adoption of draft-ppsenak either implicitly, or explicitly, believed that the additional use cases draft-wang claims to address are not important. At least, not important to address in this draft, at this time, as part of this adopted WG work.
> 
> In your follow-up, you also proposed that “which explicit signaling mechanism is simpler” should be a criterion (point four). In my experience, this kind of question seldom leads to a useful outcome since it’s so subjective. I will say however that many of the people who responded to the WG adoption call made it clear they had such considerations in mind, so I think there is good reason to think the WG has taken this question into account.
> 
> I also want to speak to the questions of whether the WG adoption decision was too hasty, whether there should be more deliberation in the WG, and whether there should have been a separate adoption call for draft-wang, which are points you’ve made emails other than the one I’m replying to. Regarding whether it was too hasty — as you say in this email, this work has been in progress since 2019. The merits of the solutions have been debated extensively. A considerable amount of valuable WG meeting time has been devoted to these discussions, as well as a great many emails. It’s hard for me to see the WG adoption decision as being made without due deliberation — the opposite if anything. Regarding whether there should have been an adoption call for draft-wang — our process allows considerable latitude to WG chairs in how they choose to run these things. In reviewing this adoption call, it seems to me that all participants were clear that in practice and regardless of what the subject line was, they were really addressing a multi-part question: should the WG work on this area? If so, should the base document be draft-ppsenak, or draft-wang? These questions received a full airing, as far as I can tell.
> 
> As you know, the IETF runs on “rough consensus”. This is true for WG adoptions just as for anything else, and it sometimes requires WG chairs to make hard decisions to call a consensus where some WG contributors are “in the rough”. After reviewing the WG adoption call, drafts, and history, it appears to me that the WG chairs have listened to all the positions put forward and considered them, and judged the rough consensus to favor the adoption of draft-ppsenak. I don’t see sufficient evidence to make me believe I should overrule the WG chairs’ judgment.
> 
> Finally, I will point out that you have many options still open to you if you strongly feel that the scenarios that are not covered by the adopted document are crucial.
> 
> Thanks for your patience as I investigated this matter,
> 
> —John
> 
> P.S.: As I’ve reviewed the adoption call and subsequent discussion, I’ve noticed that tempers have grown a little heated at times. I’d like to remind all participants that BCP 54, Guidelines for Conduct, cautions us among other things that "IETF participants extend respect and courtesy to their colleagues at all times” and "IETF participants have impersonal discussions”, and ask that we keep these guidelines in mind.
> 
>> On Sep 14, 2023, at 6:38 AM, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>>
>> 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.
>>
>> 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!EzMeDOJ2CKQMN5BjyxXnXhjJdOHPCa5wJqBo4AHwGRRhiwl1lIneQoxBdHDm1d58PO0NM7tu7IQ4ULrpAq_7Zw$ , 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.ietf@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.ietf@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/lsr__;!!NEt6yMaO-gk!EzMeDOJ2CKQMN5BjyxXnXhjJdOHPCa5wJqBo4AHwGRRhiwl1lIneQoxBdHDm1d58PO0NM7tu7IQ4ULpTBQ5vgw$
>>
> 
>