[spring] SR-MPLS address space aggregation

Vasilenko Eduard <vasilenko.eduard@huawei.com> Wed, 31 July 2024 07:36 UTC

Return-Path: <vasilenko.eduard@huawei.com>
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 <vasilenko.eduard@huawei.com>
To: "spring@ietf.org" <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 <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [spring] SR-MPLS address space aggregation
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Zxy8hwpj2GWglZEnsxdSbCTLuWY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

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 loopback node addresses.
The smallest byte of the MPLS label SHOULD be left for functions reserved by IANA: Special-Purpose Multiprotocol Label Switching (MPLS) Label Values (iana.org)<https://www.iana.org/assignments/mpls-label-values/mpls-label-values.xhtml>.
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 the help of a management system, the last byte should be still reserved for other 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 signaled 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 scale - 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