[Idr] RE: draft-liu-idr-srv6-segment-list-optimize-02

Yisong Liu <liuyisong@chinamobile.com> Fri, 06 September 2024 07:48 UTC

Return-Path: <liuyisong@chinamobile.com>
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 9DE17C14F711 for <idr@ietfa.amsl.com>; Fri, 6 Sep 2024 00:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.056
X-Spam-Level:
X-Spam-Status: No, score=-0.056 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HDRS_MISSP=1.85, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 EXOmaeSrevkz for <idr@ietfa.amsl.com>; Fri, 6 Sep 2024 00:48:25 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta6.chinamobile.com [111.22.67.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC17C14F6EF for <idr@ietf.org>; Fri, 6 Sep 2024 00:48:23 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee166dab3c68dc-c61de; Fri, 06 Sep 2024 15:48:22 +0800 (CST)
X-RM-TRANSID: 2ee166dab3c68dc-c61de
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-PC (unknown[10.2.51.65]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee566dab3c5a18-9d915; Fri, 06 Sep 2024 15:48:22 +0800 (CST)
X-RM-TRANSID: 2ee566dab3c5a18-9d915
MIME-Version: 1.0
x-PcFlag: 1690de8f-c4f0-4d53-97ff-887528df6cec_5_183680
X-Mailer: PC_RICHMAIL 2.9.57
Date: Fri, 06 Sep 2024 15:48:20 +0800
From: Yisong Liu <liuyisong@chinamobile.com>
To: Susan Hares <shares@ndzh.com>, idr <idr@ietf.org>
Message-ID: <202409061548202017369533@chinamobile.com>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart2017369533_=----"
Message-ID-Hash: S5YV7S6THOCUIOSSODZFGHYV4EFJZH5M
X-Message-ID-Hash: S5YV7S6THOCUIOSSODZFGHYV4EFJZH5M
X-MailFrom: liuyisong@chinamobile.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] RE: draft-liu-idr-srv6-segment-list-optimize-02
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/yBP92YzuWbmkOT0whrS4TXnkYws>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>


Hi Sue,




Thank you very much for your comments.  We'll update a new version of this draft ASAP. Please see our replies for the question you mentioned:






1. Are you implementing this technology change?

[Yisong]As far as I concerned, ZTE and New H3C are implementing the features in the draft. 

2. Have discussed this problem with the Spring WG?

[Yisong]Not yet. If necessary, we will immediately initiate a discussion on the spring mailing list.

3. Have you considered what segment types use the SRv6 SID Endpoint Behavior and Structure Sub-TLV?It appears that segment types B, I, J, and K.

[Yisong] I think the segment types should include SRv6 information, that segment types are B, I, J and K.

4. Have you considered making the E-Flag a field of flags with more bits?

[Yisong]Yes. We'll update the extension of the flags field in the next version.

5. Do you have any update you wish to present at IDR interim on 9/9/2024?



[Yisong]Yes. I hope to request a slot to present the draft. We'll update the draft in time. 




Best Regards

Yisong on behalf of co-authors





 






发件人: Susan Hares

时间: 2024/09/06(星期五)11:30

收件人: idr;

抄送人: 刘毅松;linchangwang;chen.ran;qiuyuanxiang;

主题: draft-liu-idr-srv6-segment-list-optimize-02        

 

Yisong, Changwang, Ran, and Yuanxiang:  

  

Thank you for your work on draft-liu-idr-srv6-segment-list-optimize-02.  

  

Your draft presents a problem and a solution.  

I’ve included a few things that should be considered in  

your next revision.  Please let me know if you have any questions  

regarding my comments.  

  

Would you mind answering a few questions: 

   Are you implementing this technology change? Have discussed this problem with the Spring WG? Have you considered what segment types use the  

SRv6 SID Endpoint Behavior and Structure Sub-TLV?  

  

It appears that segment types B, I, J, and K.  

   Have you considered making the E-Flag a field of flags  

with more bits?  

   Do you have any update you wish to present at  

IDR interim on 9/9/2024?  

  

Cheerily, Susan Hares  

  

  

Detailed Shepherd Review for:  

draft-liu-idr-sr-v6-segment-list-optimize-02 

  

status: individual draft,  

Status: Proposed Standard,  

version: revision needed (-03)   

implementations: unknown 

Authors: 4  

  

Shepherd Detailed review 

  

Summary: Text provides SR problem and solution.  

Needs a few refinements in -03.  

  

Issue-1: Please rename draft  

  

Please rename draft to: 

  

draft-liu-idr-sr-segment-list-optimize-00.  

  

This renaming will help the idr-chairs more easily track the draft.  

  

Issue-2:  Abstract, English text, clarity of text.  

  

Old text:/  

   This document introduces an optimization method for segment list 

   arrangement to solve the problem of the penultimate segment node 

   being unable to perform PSP behavior when the egress node has both 

   End SID and service SID and improve the forwarding efficiency of 

   data packets. 

  

New text:/  

   This document introduces an optimization method for segment list 

   arrangement the SR Policy TLV of the BGP Tunnel Encapsulation Attribute. 

   This optimization solves the problem of the Segment Routing's  

   penultimate segment node being unable to perform the  

   penultimate Segment Pop (PSP) behavior when the egress node has both 

   End SID and service SID encapsulated in Segment Routing Header's  

   segment List. This solution adds an E-Flag to the SRv6 SID  

   Endpoint Behavior sub-TLV carried in Segment List Sub-TLV of  

   the SR Policy TLV.   

    

   This optimization can improve the forwarding efficiency of data  

   packets when End SID and Service SID are present. / 

  

     

  

  

Issue-2: All sections, remove [draft-ietf-idr-segment-routing-te-policy] 

Please replace [draft-ietf-idr-segment-routing-te-policy] 

with [draft-ietf-idr-sr-policy-safi]. 

  

    

Issue-3: How does the E-Flag interact with the Segment flags  

specified in [draft-ietf-idr-sr-policy-safi] and  

[draft-ietf-idr-sr-segtypes-ext] 

  

It seems the B-Flag must be on when E-Flag is set.  

  

V-Flag - SID Verification 

B-Flag - SRv6 Endpoint Behavior exist in draft.  

A-Flag - presence of SR Algorithm  

S-Flag - presence of SR-MPLS or SRv6 SID  

  

  

From [draft-ietf-idr-sr-segtypes-ext] 

  

V-Flag applies to all Segment Types including the ones introduced by this document. 

A-Flag applies to Segment Types C, D, I, J, and K.  

 If A-Flag appears with Segment Types A, B, E, F, G, and H, it MUST be ignored. 

  

S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K.  

  If S-Flag appears with Segment Types A or B, it MUST be ignored. 

  

B-Flag applies to Segment Types B, I, J, and K.  

  If B-Flag appears with Segment Types A, C, D, E, F, G, and H, it MUST be ignored. 

  

It appears the SRv6 SID Endpoint Behavior and Structure is on segment types B, I, J, and K.  

  

  

Issue-4: E-Flag as set of Flags and IANA Section  

  

It would be wise to create E-Flag as a set of flags in the reserved section.  

As such, it would be useful to create a registry for such flags.