Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6ADC14F6B5; Wed, 31 Jul 2024 00:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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_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 BgfPiD0GqMLi; Wed, 31 Jul 2024 00:36:34 -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 31C6AC14F6F7; Wed, 31 Jul 2024 00:36:34 -0700 (PDT) Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WYkP24Vm2z6K6T7; Wed, 31 Jul 2024 15:33:58 +0800 (CST) Received: from mscpeml500004.china.huawei.com (unknown [7.188.26.250]) by mail.maildlp.com (Postfix) with ESMTPS id 21B0B140B55; Wed, 31 Jul 2024 15:36:30 +0800 (CST) Received: from mscpeml500004.china.huawei.com (7.188.26.250) by mscpeml500004.china.huawei.com (7.188.26.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.34; Wed, 31 Jul 2024 10:36:29 +0300 Received: from mscpeml500004.china.huawei.com ([7.188.26.250]) by mscpeml500004.china.huawei.com ([7.188.26.250]) with mapi id 15.02.1258.034; Wed, 31 Jul 2024 10:36:29 +0300 From: Vasilenko Eduard To: "spring@ietf.org" Thread-Topic: SR-MPLS address space aggregation Thread-Index: AdrjFf+lX0dGjqG2Spu3hZkJH5bLJg== Date: Wed, 31 Jul 2024 07:36:29 +0000 Message-ID: <3595aa0167da4c7a8b3fe6a26fd4175e@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.199.59.222] Content-Type: multipart/alternative; boundary="_000_3595aa0167da4c7a8b3fe6a26fd4175ehuaweicom_" MIME-Version: 1.0 Message-ID-Hash: FVGOLKEOCIFV4KZLJESF46R2SM7MIVPU X-Message-ID-Hash: FVGOLKEOCIFV4KZLJESF46R2SM7MIVPU X-MailFrom: vasilenko.eduard@huawei.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: mpls X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bspring=5D_SR-MPLS_address_space_aggregation?= List-Id: "Source Packet Routing in NetworkinG (SPRING)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_3595aa0167da4c7a8b3fe6a26fd4175ehuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, SRv6 has an advantage in address space aggregation. What if to add the same= functionality to SR-MPLS? Something like: SR-MPLS SID MAY be constructed hierarchically from the IPv4 or IPv6 loopbac= k node addresses. The smallest byte of the MPLS label SHOULD be left for functions reserved b= y IANA: Special-Purpose Multiprotocol Label Switching (MPLS) Label Values (= iana.org). Any number of bits between X and Y from the IP address MAY be copied to the= Node SID bits from 32-8-(X-Y) to 8. Alternatively, Node SIDs MAY be hierarchically assigned manually or with th= e help of a management system, the last byte should be still reserved for o= ther MPLS functions. It makes sense to do it only for global SIDs, local SIDs may continue to be= random/consecutive/whatever. The global and local SIDs separation may be s= ignaled by bit 7 of the SID. 24 bits (16,777,216) would be probably enough for any infrastructure domain= . SRv6 is often pushed with 16-bit compressed labels. 24 bits is a bigger sca= le - it has a higher probability of being enough. Then Metro could signal only aggregated SID to the Backbone and vice versa. Of course, the longest match MPLS forwarding should be enabled in this case= , i.e. IPv4 machinery should be reused for MPLS labels. Hence, it is a major MPLS upgrade, comparable to the MNA initiative. Best Regards Eduard Vasilenko Senior Architect Network Algorithm Laboratory Tel: +7(985) 910-1105 --_000_3595aa0167da4c7a8b3fe6a26fd4175ehuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

SRv6 has an advantage in address space aggregation. = What if to add the same functionality to SR-MPLS? Something like:

 

SR-MPLS SID MAY be constructed hierarchically fro= m the IPv4 or IPv6 loopback node addresses.

The smallest byte of the MPLS label SHOULD be lef= t for functions reserved by IANA: Special-Purpose Multiprotocol Label Switching (MPLS) Label Values (iana.org= ).

Any number of bits between X and Y from the IP ad= dress MAY be copied to the Node SID bits from 32-8-(X-Y) to 8.

Alternatively, Node SIDs MAY be hierarchically as= signed manually or with the help of a management system, the last byte shou= ld be still reserved for other MPLS functions.

It makes sense to do it only for global SIDs, loc= al SIDs may continue to be random/consecutive/whatever. The global and loca= l SIDs separation may be signaled by bit 7 of the SID.

 

24 bits (16,777,216) would be probably enough for an= y infrastructure domain.

SRv6 is often pushed with 16-bit compressed labels. = 24 bits is a bigger scale – it has a higher probability of being enou= gh.

 

Then Metro could signal only aggregated SID to the B= ackbone and vice versa.

 

Of course, the longest match MPLS forwarding should = be enabled in this case, i.e. IPv4 machinery should be reused for MPLS labe= ls.

Hence, it is a major MPLS upgrade, comparable to the= MNA initiative.

 

Best Regards

Eduard Vasilenko

Senior Architect

Network Algorithm Laboratory

Tel: +7(985) 910-1105

 

--_000_3595aa0167da4c7a8b3fe6a26fd4175ehuaweicom_--