Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency
"Chengli (Cheng Li)" <c.l@huawei.com> Mon, 07 June 2021 07:27 UTC
Return-Path: <c.l@huawei.com>
X-Original-To: srcomp@ietfa.amsl.com
Delivered-To: srcomp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB72F3A3A89 for <srcomp@ietfa.amsl.com>; Mon, 7 Jun 2021 00:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku4AhqhCBnJS for <srcomp@ietfa.amsl.com>; Mon, 7 Jun 2021 00:26:58 -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 9096C3A3A88 for <srcomp@ietf.org>; Mon, 7 Jun 2021 00:26:57 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Fz4X01lp3z6F8KV for <srcomp@ietf.org>; Mon, 7 Jun 2021 15:20:16 +0800 (CST)
Received: from dggpemm500006.china.huawei.com (7.185.36.236) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 7 Jun 2021 09:26:53 +0200
Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500006.china.huawei.com (7.185.36.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 7 Jun 2021 15:26:51 +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.2176.012; Mon, 7 Jun 2021 15:26:51 +0800
From: "Chengli (Cheng Li)" <c.l@huawei.com>
To: Ron Bonica <rbonica@juniper.net>, "Darren Dukes (ddukes)" <ddukes@cisco.com>, "srcomp@ietf.org" <srcomp@ietf.org>
Thread-Topic: Questions of CRH Appendix B. RE: 2.3 State Efficiency
Thread-Index: AddYGmGrkKKpJWn5RoaWBwMv27PDAAADhlfQAAAuQpAAUi09wAB/AT7w
Date: Mon, 07 Jun 2021 07:26:51 +0000
Message-ID: <5df0c3f47011479e95b2ca0129c5ceec@huawei.com>
References: <09ae8eaf77a244a5a6ccdb760aa8c658@huawei.com> <BL0PR05MB53162F115E83A76ADC5225F5AE3C9@BL0PR05MB5316.namprd05.prod.outlook.com> <5dd8d320693a4fb994f44099e4c6294b@huawei.com> <BL0PR05MB5316DA13146DBFC61E8985D4AE3B9@BL0PR05MB5316.namprd05.prod.outlook.com>
In-Reply-To: <BL0PR05MB5316DA13146DBFC61E8985D4AE3B9@BL0PR05MB5316.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.130]
Content-Type: multipart/alternative; boundary="_000_5df0c3f47011479e95b2ca0129c5ceechuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/srcomp/QISzYdum2AEFcwmBNIZ6KLAjMHA>
Subject: Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency
X-BeenThere: srcomp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <srcomp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/srcomp>, <mailto:srcomp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/srcomp/>
List-Post: <mailto:srcomp@ietf.org>
List-Help: <mailto:srcomp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/srcomp>, <mailto:srcomp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jun 2021 07:27:03 -0000
Hi Ron, I guess it is clear that we need P to maintain END SID for each Dn, or maybe we should add text to describe that it is a common case that a node will maintain the received SID for SPF. The Adj SIDs are allocated by the node P triggered by received prefix SIDs of Dn, so the Prefix SIDs MUST be counted. Thanks, Cheng From: Ron Bonica [mailto:rbonica@juniper.net] Sent: Saturday, June 5, 2021 2:50 AM To: Chengli (Cheng Li) <c.l@huawei.com>; Darren Dukes (ddukes) <ddukes@cisco.com>; srcomp@ietf.org Subject: RE: Questions of CRH Appendix B. RE: 2.3 State Efficiency Hi Cheng, OK. Now I can find the text to which you refer 😉 It is not clear that P maintains an END SID for each Dn. If it already has 2 END.X SIDs for each Dn, the path computation element (whether it is a controller or the SR ingress node) can load balance between those. Ron Juniper Business Use Only From: Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>> Sent: Wednesday, June 2, 2021 11:35 PM To: Ron Bonica <rbonica@juniper.net<mailto:rbonica@juniper.net>>; Darren Dukes (ddukes) <ddukes@cisco.com<mailto:ddukes@cisco.com>>; srcomp@ietf.org<mailto:srcomp@ietf.org> Subject: RE: Questions of CRH Appendix B. RE: 2.3 State Efficiency [External Email. Be cautious of content] Hi Ron, I am not really sure about that. I mean the Appendix B in your draft[1]. I reread CRH draft yesterday and learned a lot, appreciated! Thanks, Cheng [1].https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr-26#appendix-B From: Srcomp [mailto:srcomp-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, June 3, 2021 11:30 AM To: Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>; Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:ddukes=40cisco.com@dmarc.ietf.org>>; srcomp@ietf.org<mailto:srcomp@ietf.org> Subject: Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency Chengli, I don’t see Appendix B in version 01-6 or 01-7. Didn’t we agree to drop it from the document? Ron Juniper Business Use Only From: Srcomp <srcomp-bounces@ietf.org<mailto:srcomp-bounces@ietf.org>> On Behalf Of Chengli (Cheng Li) Sent: Wednesday, June 2, 2021 10:02 PM To: Chengli (Cheng Li) <c.l@huawei.com<mailto:c.l@huawei.com>>; Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:ddukes=40cisco.com@dmarc.ietf.org>>; srcomp@ietf.org<mailto:srcomp@ietf.org> Subject: [Srcomp] Questions of CRH Appendix B. RE: 2.3 State Efficiency [External Email. Be cautious of content] Hi Ron, I get confused of the analysis in CRH appendix B[1], hope to discuss with you. CRH compressed SRv6 can encode this SR Path in two or three segments. When it encodes the path in two segments, one segment instantiated on P and the other on the destination. [It seems like something wrong here?]To support this strategy, P instantiates 2*N SIDs (one per network per destination). First of all, the node P maintains a N FIB for Dn for SPF forwarding, correct? For forwarding the packet to a specific interface, 2N FIB entries are maintained? Furthermore, 1 prefix CRH SID for node P is maintained as well? So the sum should be N+2N+1 =3N+1? When CRH compressed SRv6 encodes the path in three segments, two segments are instantiated on P and the other on the destination. The first segment on P updates the IPv6 Destination address without forwarding the packet, while the other segment on P forwards the packet without updating the IPv6 destination address. To support this strategy, P instantiates 2+N SIDs (one per network and one per destination). For this, it should be 1 Prefix + 2 adj + N =3+N? Thanks, Cheng [1].https://datatracker.ietf.org/doc/html/draft-bonica-6man-comp-rtg-hdr-26#appendix-B From: Srcomp [mailto:srcomp-bounces@ietf.org] On Behalf Of Chengli (Cheng Li) Sent: Wednesday, June 2, 2021 3:01 PM To: Darren Dukes (ddukes) <ddukes=40cisco.com@dmarc.ietf.org<mailto:ddukes=40cisco.com@dmarc.ietf.org>>; srcomp@ietf.org<mailto:srcomp@ietf.org> Subject: Re: [Srcomp] 2.3 State Efficiency Sorry for my late reply. I agree with the text in this section, at least for C-SID, VSID part. I guess it is ready to be added to the draft. Cheng From: Srcomp [mailto:srcomp-bounces@ietf.org] On Behalf Of Darren Dukes (ddukes) Sent: Tuesday, May 25, 2021 10:26 AM To: srcomp@ietf.org<mailto:srcomp@ietf.org> Subject: [Srcomp] 2.3 State Efficiency Below is the proposed text for section 2.3 for review. 2.3. State Efficiency The compression proposal SHOULD minimize the amount of additional forwarding state stored at a node. State efficiency is analyzed at an edge node and in a single sub- domain of the SR domain, where three parameters are considered: o N: the number of SRv6 nodes in the sub-domain o I: the number of IGP algorithms [I-D.ietf-lsr-flex-algo] configured o A: the number of local adjacency SIDs o D: the number of attached SR sub-domains at a border node o V: the number of VPN services at edge nodes For a sub-domain consisting of 1000 SRv6 nodes (N=1000) and some number of non-SRv6 nodes, two IGP algorithms (I=2), 100 adjacencies per SRv6 node (A=100), up to 10 attached sub-domains per border node (D=10), and up to 1000 VPN service segments per edge. o N=1000, I=2, A=100, D=10 o V=1000 UIDSR, CSID and VSID require the following entries: o a FIB entry for the local prefix segment, one per algorithm (I=2). o a FIB entry per local adjacency SID (A=100) **Note1 o At border nodes either: * A.1) a FIB entry per domain (D=10) to swap the IPv6 destination address prefix. * A.2) a 128-bit SID in the segment list of a packet, requiring no additional FIB entries. o At edge nodes, a FIB entry per VPN segment CRH requires: o a CFIB entry per CRH node per IGP algorithm for local and remote prefix segments (N*I=2000) * One FIB entry per node (N=1000) per IGP algorithm greater than 1 (per I>1) (N=1000) + IP Flex Algo requires a loopback address per algorithm per node - CRH assigns a CFIB entry per loopback o a CFIB entry per local adjacency segment (A=100) **Note1 * When non-CRH adjacent nodes are present, additional state is required for CRH as per CRH appendix B. + B.1) Up to one CFIB entry per node (N=1000) per local adjacency segment (A=100) per algorithm (I=2) to support non-CRH adjacent nodes in the sub-domain (N*A*I=200000). + B.2) Up to one CFIB entry per next endpoint if attached to non-SR domains and an additional CFIB entry per adjacency to support non-CRH adjacent endpoints ((N+A)*I=2200). o At border nodes, assuming two inter-domain links per adjacent domain for redundancy, (as per CRH Appendix B) either: * C.1) a CFIB entry per unique endpoint (N*D*I), per inter-domain adjacency (2) (N*D*I*2=40000) * C.2) a CFIB entry per unique endpoint (N*D*I), plus inter- domain adjacency (2) (N*D*I+2=20002) o At edge nodes, an SRv6 SID FIB entry per VPN segment and a CFIB or TPF FIB entry per VPN segment (V*2=2000) **Note1: there may be additional adjacency SIDs for protected, unprotected, and per algorithm adjacencies, resulting in some multiple of A. This is common for all proposals. +----------------------+----------+-----------+----------+----------+ | 16-bit and 32-bit | CSID | CRH | VSID | UIDSR | +----------------------+----------+-----------+----------+----------+ | S(N1000,I2,A100,D10) | *102* | 2100 | *102* | *102* | | | A.1: 112 | | A.1: 112 | A.1: 112 | | | A.2: 102 | | A.2: 102 | A.2: 102 | | | | B.1: | | | | | | 202100 | | | | | | B.2: 4500 | | | | | | C.1: | | | | | | 40000 | | | | | | C.2: | | | | | | 20002 | | | | S(V1000) | *1000* | 2000 | *1000* | *1000* | +----------------------+----------+-----------+----------+----------+ Table 8: Forwarding State Conclusion: CSID, VSID and UIDSR minimize forwarding state stored at a node.
- [Srcomp] Questions of CRH Appendix B. RE: 2.3 Sta… Chengli (Cheng Li)
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Ron Bonica
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Chengli (Cheng Li)
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Ron Bonica
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Chengli (Cheng Li)
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Ron Bonica
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Chengli (Cheng Li)
- Re: [Srcomp] Questions of CRH Appendix B. RE: 2.3… Ron Bonica