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

Aijun Wang <wangaijun@tsinghua.org.cn> Wed, 20 September 2023 09:28 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 267CBC151083; Wed, 20 Sep 2023 02:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 n4xoEU0E3XHP; Wed, 20 Sep 2023 02:28:37 -0700 (PDT)
Received: from mail-m49197.qiye.163.com (mail-m49197.qiye.163.com [45.254.49.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2247EC14CE44; Wed, 20 Sep 2023 02:28:36 -0700 (PDT)
Received: from LAPTOP09T7970K (unknown [219.142.69.75]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 3D71580008D; Wed, 20 Sep 2023 17:28:26 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'tom petch' <ietfc@btconnect.com>, 'John Scudder' <jgs=40juniper.net@dmarc.ietf.org>, chopps@chopps.org
Cc: 'lsr' <lsr@ietf.org>, draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org
References: <1E442048-D5CA-4E53-AAE0-7A4BF993DE70@tsinghua.org.cn> <GVXPR07MB97286A47667A85F3FADD9B1FA0F6A@GVXPR07MB9728.eurprd07.prod.outlook.com>
In-Reply-To: <GVXPR07MB97286A47667A85F3FADD9B1FA0F6A@GVXPR07MB9728.eurprd07.prod.outlook.com>
Date: Wed, 20 Sep 2023 17:28:26 +0800
Message-ID: <002901d9eba4$cf9a7370$6ecf5a50$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQMlLgwqsQCESN2z5Y1vbSPdwDx8sQHNR1y/rX6BlnA=
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVlDThhNVhpNS0MYGBlDQx9KQlUTARMWGhIXJB QOD1lXWRgSC1lBWUlKQlVKT0lVTUJVTE5ZV1kWGg8SFR0UWUFZT0tIVUpKS0NISFVKS0tVS1kG
X-HM-Tid: 0a8ab1eb5c40b03akuuu3d71580008d
X-HM-MType: 10
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MlE6TBw5HD0MHUweSEswLw4I ChcKCxhVSlVKTUJOSUtJSktMSUlOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUJMTUM3Bg++
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Wb-quBHxTvAm7wau7e9TNQbefJA>
Subject: [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: Wed, 20 Sep 2023 09:28:42 -0000

Hi, Tom:

My appeal is that it's unfair to ignore the draft that was put forward THREE years earlier than the follower, and we devote intense discussions for this topic along the process, but there is no adoption call. 


Best Regards

Aijun Wang
China Telecom

-----邮件原件-----
发件人: lsr-bounces@ietf.org [mailto:lsr-bounces@ietf.org] 代表 tom petch
发送时间: 2023年9月15日 18:41
收件人: Aijun Wang <wangaijun@tsinghua.org.cn>; John Scudder <jgs=40juniper.net@dmarc.ietf.org>; chopps@chopps.org
抄送: lsr <lsr@ietf.org>; draft-ppsenak-lsr-igp-ureach-prefix-announce@ietf.org
主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Sent: 15 September 2023 08:08

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.
<tp>
Aijun
The IETF community works on 'rough consensus and running code' to a greater or lesser extent.  The descriptions of our processes do not give hard and fast rules about what constitutes consensus and that flexibility is one of the strengths of the IETF.  Consensus is judged, by WG Chairs, AD, IESG, IAB, based on what the mailing lists contain.  The judgement can be  appealed.  The result can be one I-D going forward or two or none.  Here we currently have consensus declared for one I-D to go forward.

I hear you protest and see that as an implicit appeal but I am unclear what you are appealing. The appeal could be that consensus does not reflect what  appeared on the list, that the consensus call was not properly made, that there should have been additional consensus calls and so on. 

You list facts and that is fine but they are only input to my and others' judgement which we then express in response to a consensus call.  The facts may persuade some, they may not persuade others but it is the summation of views expressed on the list  that determines the consensus, not facts.

Tom Petch

Hi, Chris:

I have asked Acee the following questions (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/<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?
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.

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.net@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 <ietfc@btconnect.com> wrote:

From: Lsr <lsr-bounces@ietf.org> on behalf of Aijun Wang <wangaijun@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.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!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr