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