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

Hi Jie,

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

Regards,

Yao

Original

From: Dongjie(Jimmy) <jie.dong@huawei.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>;刘尧00165286;
Cc: shares@ndzh.com <shares@ndzh.com>;idr@ietf.org <idr@ietf.org>;
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,

Jie

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar
 Sent: Friday, March 3, 2023 3:47 PM
 To: liu.yao71@zte.com.cn
 Cc: shares@ndzh.com; idr@ietf.org
 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