Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 30 September 2022 22:22 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B731C14F74E for <idr@ietfa.amsl.com>; Fri, 30 Sep 2022 15:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ham 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 bOjVHWGc_lFz for <idr@ietfa.amsl.com>; Fri, 30 Sep 2022 15:22:11 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16D67C14F74A for <idr@ietf.org>; Fri, 30 Sep 2022 15:22:09 -0700 (PDT)
Received: from smtpclient.apple (unknown [106.121.187.75]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id B1C82800084; Sat, 1 Oct 2022 06:22:06 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-F8768696-818B-43BD-8139-FFC077F20108"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 01 Oct 2022 06:22:06 +0800
Message-Id: <64E9038A-77DD-4C18-8351-68DC849D9363@tsinghua.org.cn>
References: <20220930215902.D389590007B@hmail-m121149.qiye.163.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, idr@ietf.org
In-Reply-To: <20220930215902.D389590007B@hmail-m121149.qiye.163.com>
To: Susan Hares <shares@ndzh.com>
X-Mailer: iPhone Mail (19G82)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaQkMZVh5JHkJNTksfSEgaQ1UTARMWGhIXJB QOD1lXWRgSC1lBWUpLTVVKSUpVSkNMVUxOWVdZFhoPEhUdFFlBWU9LSFVKSktITUpVSktLVUtZBg ++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6OBg6MQw*Ej0qTVYVMT8#HFYq Ng5PCytVSlVKTU1PTkxNTklMSU5OVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpDTFVMTllXWQgBWUFJSkNNTTcG
X-HM-Tid: 0a83907e198bb03akuuub1c82800084
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/H7t1whf_vIHQHwyO7SF87HV7t4Y>
Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2022 22:22:15 -0000

Hi, Sue:

Thanks for your reply.

What puzzling me for the current approach is that there is no one illustrate the reason that why we can’t meet the requirements based on the existing WG document, given the authors of [I-D.ietf-idr-next-hop-capability has described the potential changes/updates , and it has also several other advantages over  document of draft-scudder-idr-entropy-label-01.

 I would like to get the answers from your write up of this adoption, or from the discussions of the coming interim meeting.

There is one direct route to reach the destination, why did we select the detour one?

Aijun Wang
China Telecom

> On Sep 30, 2022, at 21:59, Susan Hares <shares@ndzh.com> wrote:
> 
> 
> Acee:
>  
> Agreed.   I and the other WG chairs need technical input on the progression of these drafts.  If you can think of someone (like MPLS chairs) who should be asked to attend, let me know.
>  
> Sue
>  
> From: Acee Lindem (acee) <acee@cisco.com> 
> Sent: Friday, September 30, 2022 9:54 AM
> To: Susan Hares <shares@ndzh.com>; Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: idr@ietf.org
> Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
>  
>  
> Hi Sue,
>  
> We should discuss this progression at the Interim. I believe that 3) may be an “updates” and 4) may leave the existing attribute in place while allowing for extendible next-hop capabilities (if and when it is pubublished).
>  
> Thanks,
> Acee
>  
> From: Idr <idr-bounces@ietf.org> on behalf of Susan Hares <shares@ndzh.com>
> Date: Friday, September 30, 2022 at 9:44 AM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: IDR List <idr@ietf.org>
> Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
>  
> Aijun:
>  
> Thank you for your patience with my delay in responding.   I have been on travel.   This working group adoption call has closed and the chairs have decided to adopt draft-scudder-idr-entropy-label-01.txt.
>  
> The purpose of draft-scudder-idr-entropy-label-01.txt is to fix an existing problem with IDR specification.  It is possible that the sequence you listed in your emails could occur:  
>  
> 1) RFC6790
> 2) RFC 7447(deprecate RFC6790)
> 3) RFC****(deprecate RFC7447 again, based on the final document of draft-scudder-idr-entropy-label-01)
> 4) RFC####(depeciated RFC**** again, based on the final document of [I-D.ietf-idr-next-hop-capability]
>  
> I have received requests from the IDR mail list and from private email from implementers and operators.  As you know from our conversations, the IDR care deeply about standardizing BGP additions (fixes or enhancements) needed by network operators.  
>  
> Whether this “fix” should be replaced by draft-ietf-idr-next-hop-capability or some combination of other drafts (draft-ietf-idr-attribute-announcement) is something the IDR chairs need feedback on.   We decided to hold an interim on 10/13 with 1 hour devoted to this topic.   
>  
> Since you asked about my thought processes, I will post my write-up on this call on the IDR wiki by Monday.  I continued on with adoption calls on Tuesday to address your second concern – keeping the IDR Working Group working on other drafts.
>  
> If you would like to chat with me after you read my adoption call write-up, I would be happy to chat with you.
>  
> Cheerily,  Sue
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> One of the challenges of a WG chair is to make a call based on input from the working group.   This
>  
> From: Aijun Wang <wangaijun@tsinghua.org.cn> 
> Sent: Tuesday, September 27, 2022 8:24 PM
> To: Susan Hares <shares@ndzh.com>
> Cc: idr@ietf.org
> Subject: Re: [Idr] WG adoption call for draft-scudder-idr-entropy-label-01 (9/6/2022 to 9/20/2022)
>  
>  
> Hi, Sue:
>  
> Want to ask where are the consensus on the list for this draft? Given this draft has contradicted with the existing WG draft which has been pointed out by several several service providers?
> As also mentioned in your list questions, there is necessary to discuss the short term and long term improvements of BGP next hop in the coming interim meeting, then what’s the reason to adopt this document in hurry?
>  
> Aijun Wang
> China Telecom
>  
> 
> On Sep 28, 2022, at 01:14, Susan Hares <shares@ndzh.com> wrote:
> 
>  
> The chairs have reviewed the IDR WG discussion and feedback from implementers on draft-ietf-idr-entropy-label-01.txt.
>                                              
> The consensus from this review is that we should:
> 1) adopt draft-scudder-idr-entropy-label-01 as
> draft-ietf-idr-entropy-label-01  
>  
>  
> 2) Hold a discussion of BGP Next-Hop technology to discuss
> the needs for current and future standards on BGP Next Hop.
>  
> During this interim we will discuss the open proposals for
> BGP Next HOPS to determine what technology goes forward
> toward standardization.
>  
> IDR needs the feedback from implementers and operators
> about the short term and long-term improvements to
> BGP Next hop.
>  
> Cheerily, Sue  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr