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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 70094C1516E3 for <>; Sun, 5 Mar 2023 23:45:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DL9Uc0vGsTZb for <>; Sun, 5 Mar 2023 23:44:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A381C1516F3 for <>; Sun, 5 Mar 2023 23:44:26 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (FangMail) with ESMTPS id 4PVVvn5MjGz8RSdK; Mon, 6 Mar 2023 15:44:21 +0800 (CST)
Received: from ([]) by with SMTP id 3267iCiT058124; Mon, 6 Mar 2023 15:44:12 +0800 (+08) (envelope-from
Received: from mapi (njy2app03[null]) by mapi (Zmail) with MAPI id mid203; Mon, 6 Mar 2023 15:44:14 +0800 (CST)
Date: Mon, 06 Mar 2023 15:44:14 +0800
X-Zmail-TransId: 2afb640599ce1cb523c2
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 3267iCiT058124
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04- with ID 640599D5.000 by FangMail milter!
X-FangMail-Envelope: 1678088661/4PVVvn5MjGz8RSdK/640599D5.000/[]/<>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 640599D5.000/4PVVvn5MjGz8RSdK
Archived-At: <>
Subject: Re: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Mar 2023 07:45:03 -0000

Hi Jie,

Thanks for your comments. Please see the replies inline with Yao>>.




From: Dongjie(Jimmy) <>
To: Ketan Talaulikar <>;刘尧00165286;
Cc: <>; <>;
Date: 2023年03月03日 17:11
Subject: RE: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3

Hi Yao and Ketan,


I agree with Ketan that the flags in segment sub-TLV are mainly for the functions which are generic and applicable to all of the segment types, and they are used to indicate the attributes of the segment itself. Thus it may not be a good fit for indicating the position of ELI/EL insertion.

Yao>>Following Ketan's  and your suggestions, in the 07 version of draft-zhou-idr-bgp-srmpls-elp, the ELP-sub-TLV is defined under the Segment List sub-TLV instead of using the flags. 


Another point I am concerned is that the insertion of multiple ELI/ELs would change the length and the encoding efficiency of the segment list, this may makes one candidate path without ELI/EL insertion no longer valid after ELI/EL insertion, due to the constraints of the nodes’ MSD, ERLD, etc. This means the set of valid segment lists with entropy label insertion enabled can be very different from the set of segment lists without entropy label insertion. This document may want to provide some considerations about that impact. And perhaps some indication about whether entropy label insertion is enabled or not at the segment list level would be needed.


Yao>> How the MSD infects the placement and insertion of ELI/EL in SR network with the external controller has been already considered in section5 and section 7 of RFC8662. And it's mentioned in draft-zhou that these considerations are still followed. We could add more text to emphasize that in next revision.

As for whether to insert the ELI/EL, it's based on the headend's decision just like RFC8662 . The controller is only responsible for computing the ELP as mentioned in section 3 of draft-zhou . So the indication in the segment list is not needed in this case in my opinion.

It would be good if the above comments could be considered before the adoption of this document. Thanks.


Best regards,



From: Idr [] On Behalf Of Ketan Talaulikar
 Sent: Friday, March 3, 2023 3:47 PM
 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.






On Thu, Mar 2, 2023 at 7:37 AM <> 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,
 From: KetanTalaulikar <>
 To: Susan Hares <>;
 Cc: <>;
 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
 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.
 On Wed, Mar 1, 2023 at 9:38 AM Susan Hares <> wrote:
 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.
 The text of the initial call is included below.
 Cheerily, Sue
 his adoption begins a two week WG Adoption call for
 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  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