Re: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-10.txt
Chengli <c.l@huawei.com> Fri, 30 September 2022 11:27 UTC
Return-Path: <c.l@huawei.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 DB352C1594BC for <idr@ietfa.amsl.com>; Fri, 30 Sep 2022 04:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 H0fPUZNjaP7e for <idr@ietfa.amsl.com>; Fri, 30 Sep 2022 04:27:35 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BAFC1594BA for <idr@ietf.org>; Fri, 30 Sep 2022 04:27:34 -0700 (PDT)
Received: from fraeml706-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Mf7FC5BH0z67LRs for <idr@ietf.org>; Fri, 30 Sep 2022 19:25:19 +0800 (CST)
Received: from dggpemm100002.china.huawei.com (7.185.36.179) by fraeml706-chm.china.huawei.com (10.206.15.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.31; Fri, 30 Sep 2022 13:27:31 +0200
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm100002.china.huawei.com (7.185.36.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 30 Sep 2022 19:27:29 +0800
Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2375.031; Fri, 30 Sep 2022 19:27:29 +0800
From: Chengli <c.l@huawei.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-10.txt
Thread-Index: AQHY1DnBKjH7IqUGykaLxN/r+FSgm633zpAQ
Date: Fri, 30 Sep 2022 11:27:29 +0000
Message-ID: <b9c8ffc2b08c4bda94cc51db913c2621@huawei.com>
References: <166447970209.563.7960682004005552067@ietfa.amsl.com>
In-Reply-To: <166447970209.563.7960682004005552067@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.81]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/1JM14HM4aFMDXMG2umf8VSgc-Mc>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-10.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2022 11:27:38 -0000
Hi IDRers and Authors, When read the draft, I find out an issue. At the beginning, we defined the SRv6 SID as an 128-bit value. In that time, a 128-bit value is the key of the SID in control plane protocol, like IGP/BGP/BGP-LS. Also, a EM lookup can be performed in FIB when forwarding. But as the development of SRv6, the definition of SRv6 SID has been changed: a SID length may be shorter than 128 bits while the rest bits are padding as zero. And a SID is presented as a FIB entry which should be hit by a LPM lookup. """ This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT) and A bits of arguments (ARG). L, the locator length, is flexible, and an operator is free to use the locator length of their choice. F and A may be any value as long as L+F+A <= 128. When L+F+A is less than 128, then the remaining bits of the SID MUST be zero. """ Therefore, the key of the SID in control plane protocols is the prefix with mask not the 128-bit value, and the lookup method should be LPM. Otherwise, errors may come. For example, 2001:DB8:1:1::/64, and 2001:DB8:1:1:0::/80 can be treated as a single value or the same SID if the receiver identifies a SID by the 128-bit value(same 2001:DB8:1:1::) only without considering the information of the SID structure. But actually, they are two different prefixes that can be allocated to two different SIDs as they are different two prefixes (with two different masks) in the FIB. Considering the SID structure, the same value 2001:DB8:1:1:: with different mask can be treated correctly as two different SIDs. Therefore, we need to add a mask information/SID structure information to the NLRI. Similar text is needed in IGP/BGP/PCEP drafts to specify the receiving processing: using the SID value with mask as a key instead of the 128-bit value. Thanks, Cheng -----Original Message----- From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, September 30, 2022 3:28 AM To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP Link State Extensions for SRv6 Authors : Gaurav Dawra Clarence Filsfils Ketan Talaulikar Mach Chen Daniel Bernier Bruno Decraene Filename : draft-ietf-idr-bgpls-srv6-ext-10.txt Pages : 24 Date : 2022-09-29 Abstract: Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by various protocols such as BGP, IS-IS and OSPFv3. This document defines extensions to BGP Link-state (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data-plane defined in a separate document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgpls-srv6-ext/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-srv6-ext-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgpls-srv6-ext-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
- [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-ext-1… internet-drafts
- Re: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-e… Chengli
- Re: [Idr] I-D Action: draft-ietf-idr-bgpls-srv6-e… Ketan Talaulikar