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

"Dongjie (Jimmy)" <> Fri, 03 March 2023 09:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 003BAC151B06 for <>; Fri, 3 Mar 2023 01:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ABLeaeTMccEk for <>; Fri, 3 Mar 2023 01:11:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D86D9C14F737 for <>; Fri, 3 Mar 2023 01:11:07 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4PShyx54Ksz6J7Hy for <>; Fri, 3 Mar 2023 17:10:49 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Fri, 3 Mar 2023 09:11:04 +0000
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.21; Fri, 3 Mar 2023 17:11:02 +0800
Received: from ([]) by ([]) with mapi id 15.01.2507.021; Fri, 3 Mar 2023 17:11:02 +0800
From: "Dongjie (Jimmy)" <>
To: Ketan Talaulikar <>, "" <>
CC: "" <>, "" <>
Thread-Topic: [Idr] draft-zhou-idr-bgp-srmpls-elp-06 - Adoption call (1/27/2023 to 2/10/2023) - extended to 3/3
Thread-Index: AQHZTaSi32OVY3wdmEObqs6JBERIxq7ovCGQ
Date: Fri, 03 Mar 2023 09:11:01 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_d5bf721344494776a376a800d92c0d38huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Fri, 03 Mar 2023 09:11:12 -0000

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.

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.

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<>