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> Wed, 28 September 2022 10:58 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 AD15FC1524BD for <idr@ietfa.amsl.com>; Wed, 28 Sep 2022 03:58:46 -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 9T4_zkH9olBb for <idr@ietfa.amsl.com>; Wed, 28 Sep 2022 03:58:42 -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 0CA15C1524BB for <idr@ietf.org>; Wed, 28 Sep 2022 03:58:39 -0700 (PDT)
Received: from smtpclient.apple (unknown [221.223.103.237]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 408ED80008D; Wed, 28 Sep 2022 18:58:37 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-88410660-DCB2-46CE-9E7A-958A203644B6"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Wed, 28 Sep 2022 18:58:36 +0800
Message-Id: <3ADF9E46-2BCC-469D-94C5-D62B81CCEA89@tsinghua.org.cn>
References: <CAOj+MMFcdOpxVGVzOWPaZmv2aDD_=vMuT+fxQr-pTac4c4Ykyg@mail.gmail.com>
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <CAOj+MMFcdOpxVGVzOWPaZmv2aDD_=vMuT+fxQr-pTac4c4Ykyg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19G82)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVlCGB1PVkMdTElITU1OHUgfTlUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVSktIVUlITFlXWRYaDxIVHRRZQVlPS0hVSkpLSE1KVUpLS1VLWQ Y+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NTY6FQw5Nz0iPgxOEQIILwgS HjAwFBBVSlVKTU1PSE1JTEpMTUpOVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSFVJSExZV1kIAVlBSktOT003Bg++
X-HM-Tid: 0a8383bfa054b03akuuu408ed80008d
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kVaZE6VzeQGCKEbkoNJfLr7V5Uc>
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: Wed, 28 Sep 2022 10:58:46 -0000

Hi, Robert:

Then for the advertisement of such capabilities, the journey will be: 
1) RFC6790
2) RFC 7447(depreciated RFC6790)
3) RFC****(depeciated 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]

Can the IDR experts spend their energies in more efficient manners?

Aijun Wang
China Telecom

> On Sep 28, 2022, at 17:14, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
> Hi Aijun, 
> 
> Signalling capability to process entropy labels IMO should be signalled in a transitive manner. Requirement that BGP nodes like RRs which do not modify the next hop understand the attribute is not justified. 
> 
> On that basis alone I think the proposed document should progress. The fact that it evolved with time from RFC6790 and got deployed is another factor. 
> 
> If/when next-hop-capability adds transitive option and get's deployed I guess this doc could be moved to historical however for now it attempts to address real deployments by allocating valid codepoint for it. 
> 
> Thx,
> R.
> 
>> On Wed, Sep 28, 2022 at 2:23 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>> 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
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr