Re: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3

liu.yao71@zte.com.cn Fri, 03 March 2023 09:09 UTC

Return-Path: <liu.yao71@zte.com.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 009CEC14F737 for <idr@ietfa.amsl.com>; Fri, 3 Mar 2023 01:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.894
X-Spam-Level:
X-Spam-Status: No, score=-6.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, 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 wxhcJ5ZSurqi for <idr@ietfa.amsl.com>; Fri, 3 Mar 2023 01:09:53 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C948C151B06 for <idr@ietf.org>; Fri, 3 Mar 2023 01:09:52 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4PShxk1HQQz6FK2R for <idr@ietf.org>; Fri, 3 Mar 2023 17:09:46 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4PShx80hBZz501SZ; Fri, 3 Mar 2023 17:09:16 +0800 (CST)
Received: from njy2app04.zte.com.cn ([10.40.12.64]) by mse-fl2.zte.com.cn with SMTP id 323993ng066136; Fri, 3 Mar 2023 17:09:03 +0800 (+08) (envelope-from liu.yao71@zte.com.cn)
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid203; Fri, 3 Mar 2023 17:09:05 +0800 (CST)
Date: Fri, 03 Mar 2023 17:09:05 +0800
X-Zmail-TransId: 2afb6401b931ffffffffa908e039
X-Mailer: Zmail v1.0
Message-ID: <202303031709055015503@zte.com.cn>
In-Reply-To: <CAH6gdPwzQNDgwU86Yn9KvssD2jdzUDmTCPkz=E5POk0eh3qMww@mail.gmail.com>
References: CAH6gdPwTC54sWE1VDaxmcoxr=f2shXPND7SBTpqQGqHCcLkGnQ@mail.gmail.com, 202303021007278411889@zte.com.cn, CAH6gdPwzQNDgwU86Yn9KvssD2jdzUDmTCPkz=E5POk0eh3qMww@mail.gmail.com
Mime-Version: 1.0
From: liu.yao71@zte.com.cn
To: ketant.ietf@gmail.com
Cc: shares@ndzh.com, idr@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 323993ng066136
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.138.novalocal with ID 6401B95A.000 by FangMail milter!
X-FangMail-Envelope: 1677834586/4PShxk1HQQz6FK2R/6401B95A.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/<liu.yao71@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 6401B95A.000/4PShxk1HQQz6FK2R
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fMXETyUnS2TcmC-yPn47TAt3p5E>
Subject: Re: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3
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, 03 Mar 2023 09:09:58 -0000

Hi Ketan,




A new version of draft-zhou-idr-bgp-srmpls-elp is updated to address your comments.

https://datatracker.ietf.org/doc/html/draft-zhou-idr-bgp-srmpls-elp 

The ELP-sub-TLV is defined under the Segment List sub-TLV instead of using the flag field of segment sub-TLV.




Regards,

Yao













Original



From: KetanTalaulikar <ketant.ietf@gmail.com>
To: 刘尧00165286;
Cc: shares@ndzh.com <shares@ndzh.com>;idr@ietf.org <idr@ietf.org>;
Date: 2023年03月03日 15:47
Subject: Re: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3



Hi Liu,
Thanks for your response. 

We should look to conserve these remaining 4 flags for something that is applicable more generically to all types of Segments and their encoding. For the very specific use-case where we want to indicate insertion of ELI/EL, it is better to define a new sub-TLV or a similar alternative encoding approach. 

A change on this line by the authors would address my concerns with the proposal in this document.

Thanks,
Ketan





On Thu, Mar 2, 2023 at 7:37 AM <liu.yao71@zte.com.cn> wrote:

Hi Ketan,
 
 Thanks for your support and valuable comments.
 If opinions from the WG tend to conserve the remaining segment flags, the authors would choose to define a new ELP-sub-TLV under the Segment List sub-TLV instead.
 
 Best Regards,
 Yao
 
 
 
 
 
 ------------------Original------------------
 From: KetanTalaulikar <ketant.ietf@gmail.com>
 To: Susan Hares <shares@ndzh.com>;
 Cc: idr@ietf.org <idr@ietf.org>;
 Date: 2023年03月01日 20:19
 Subject: Re: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3
 _______________________________________________
 Idr mailing list
 Idr@ietf.org
 https://www.ietf.org/mailman/listinfo/idr
 
 Hi Sue,
 I support the adoption of this document since it attempts to address an existing technical gap with the signaling of SR Policies.
 
 However, I have a concern with the proposal using one of the 4 remaining per-segment flags. There are multiple alternatives including using a new sub-TLV of the Segment List sub-TLV to indicate the position or even the use of a new Segment Type for indicating the placement of an EL.
 
 I understand that there is an equivalent proposal for PCEP where the authors introduced extended flags for the purpose of introducing the "E" flag. Since the same might not be possible in BGP SR Policy SAFI encoding, we should conserve the existing flags and instead go for an alternative encoding proposal.
 
 Thanks,
 Ketan
 
 On Wed, Mar 1, 2023 at 9:38 AM Susan Hares <shares@ndzh.com> wrote:
 Greetings:
 
 The support for draft-zhou-idr-bgp-srmpls-elp-06 is positive, but light.
 I am extending the original call to 3/3 to see if we can obtain additional support.
 
 https://mailarchive.ietf.org/arch/msg/idr/vVpUpFP_0QqY4tzGAoeEyLM7Brc/
 
 The text of the initial call is included below.
 
 Cheerily, Sue
 
 ===========
 his adoption begins a two week WG Adoption call for
 draft-zhou-idr-bgp-srmpls-elp-06.txt
 https://datatracker.ietf.org/doc/draft-zhou-idr-bgp-srmpls-elp/
 The authors should respond to this message with
 Email that indicates whether they know of any IPR
 related to this draft.
 In your discussions please consider if this WG
 should approve an  extension to Segment flags defined in the
 draft-ietf-idr-segment-routing-te-policy-20.txt .
 The existing flags are the following
 2.4.4.2.12.  Segment Flags
 The Segment Types sub-TLVs described above may contain the following
 flags in the "Flags" field defined in Section 6.8:
 0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |V|A|S|B|       |
 +-+-+-+-+-+-+-+-+
 Figure 22: Segment Flags
 The changes proposed by this draft are the addition
 Of an "E" flag to those bits.
 0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 |V|A|S|B|E|     |
 +-+-+-+-+-+-+-+-+
 E-Flag: This flag, when set, indicates that presence of < ELI, EL>
 label pairs which are inserted after this segment.  E-Flag is
 applicable to Segment Types A, C, D, E, F, G and H.  If E-Flag
 appears with Segment Types B, I, J and K, it MUST be ignored.
 Cheerily, Sue
 _______________________________________________
 Idr mailing list
 Idr@ietf.org
 https://www.ietf.org/mailman/listinfo/idr