Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Jeff Tantsura <jefftant.ietf@gmail.com>
In-Reply-To: <dfa76c313b1046b1b7e7e67155b84f19@huawei.com>
Date: Wed, 31 Jul 2024 09:28:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F787E94-F809-4789-ABC4-9376C7EE3BA5@gmail.com>
References: <3595aa0167da4c7a8b3fe6a26fd4175e@huawei.com>
 <94d80db1-79b8-4359-80fc-92423b12c6b5@pi.nu>
 <dafe98a17dd44da88df4292d741a0663@huawei.com>
 <dfa76c313b1046b1b7e7e67155b84f19@huawei.com>
To: Vasilenko Eduard <vasilenko.eduard=40huawei.com@dmarc.ietf.org>
Message-ID-Hash: HOL2EALGDPZNEA6WDUUA62TGO7MH7I4O
CC: Loa Andersson <loa@pi.nu>, spring <spring@ietf.org>, mpls <mpls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bspring=5D_Re=3A_=5Bmpls=5D_SR-MPLS_address_space_aggregation?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/spring/wX88SRxx_vbWsEfq0hBKpu2Qif0>

Eduard,

What is the problem you are trying to solve?
Where are the analysis of cost/complexity of implementation vs potential =
gains? What would be the vote for/against?


Cheers,
Jeff

> On Jul 31, 2024, at 01:59, Vasilenko Eduard =
<vasilenko.eduard=3D40huawei.com@dmarc.ietf.org> wrote:
>=20
> Dear MPLS chairs,
> It is for sure possible to do what I proposed but is it really needed?
> We have heard very loud complaints that "aggregation is a big value".
> I propose to vote on this topic (after long enough discussion): "Does =
it make sense to do a major MPLS upgrade to support aggregation? The =
primary challenge is the upgrade of the data plane engine to support the =
longest match"
> I do not have a clue how the vote finished. The loud people may not be =
the majority.
> Eduard
> -----Original Message-----
> From: Vasilenko Eduard=20
> Sent: Wednesday, July 31, 2024 11:24
> To: 'Loa Andersson' <loa@pi.nu>; spring@ietf.org
> Cc: mpls <mpls@ietf.org>
> Subject: RE: [mpls] SR-MPLS address space aggregation
>=20
> ESPL is after XL. XL is in the smallest byte.
> Hence, not affected.
>=20
> I am sure, there could be other problems after careful investigation.
> But if aggregation and hierarchy are a value, then the MPLS label has =
enough bits for it.
> Ed/
> -----Original Message-----
> From: Loa Andersson <loa@pi.nu>
> Sent: Wednesday, July 31, 2024 11:15
> To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; spring@ietf.org
> Cc: mpls <mpls@ietf.org>
> Subject: Re: [mpls] SR-MPLS address space aggregation
>=20
> Eduard,
>=20
> Have you considered if RFC 7274 and RFC 9017 has any impact on this?
>=20
> /Loa
>=20
> Den 2024-07-31 kl. 09:36, skrev Vasilenko Eduard:
>>=20
>> Hi all,
>>=20
>> SRv6 has an advantage in address space aggregation. What if to add =
the=20
>> same functionality to SR-MPLS? Something like:
>>=20
>> /SR-MPLS SID MAY be constructed hierarchically from the IPv4 or IPv6=20=

>> loopback node addresses./
>>=20
>> /The smallest byte of the MPLS label SHOULD be left for functions=20
>> reserved by IANA: Special-Purpose Multiprotocol Label Switching =
(MPLS)=20
>> Label Values (iana.org)=20
>> =
<https://www.iana.org/assignments/mpls-label-values/mpls-label-values.
>> xhtml>./
>>=20
>> /Any number of bits between X and Y from the IP address MAY be copied=20=

>> to the Node SID bits from 32-8-(X-Y) to 8./
>>=20
>> /Alternatively, Node SIDs MAY be hierarchically assigned manually or=20=

>> with the help of a management system, the last byte should be still=20=

>> reserved for other MPLS functions./
>>=20
>> /It makes sense to do it only for global SIDs, local SIDs may =
continue=20
>> to be random/consecutive/whatever. The global and local SIDs=20
>> separation may be signaled by bit 7 of the SID./
>>=20
>> //
>>=20
>> 24 bits (16,777,216) would be probably enough for any infrastructure=20=

>> domain.
>>=20
>> SRv6 is often pushed with 16-bit compressed labels. 24 bits is a=20
>> bigger scale =E2=80=93 it has a higher probability of being enough.
>>=20
>> Then Metro could signal only aggregated SID to the Backbone and vice=20=

>> versa.
>>=20
>> Of course, the longest match MPLS forwarding should be enabled in =
this=20
>> case, i.e. IPv4 machinery should be reused for MPLS labels.
>>=20
>> Hence, it is a major MPLS upgrade, comparable to the MNA initiative.
>>=20
>> Best Regards
>>=20
>> Eduard Vasilenko
>>=20
>> Senior Architect
>>=20
>> Network Algorithm Laboratory
>>=20
>> Tel: +7(985) 910-1105
>>=20
>>=20
>> _______________________________________________
>> mpls mailing list -- mpls@ietf.org
>> To unsubscribe send an email to mpls-leave@ietf.org
>=20
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> loa@pi.nu
> loa.pi.nu.@gmail.com
>=20
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org