[spring] Re: [mpls] SR-MPLS address space aggregation

[Vasilenko Eduard <[e-mail]>]

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 
Sent: Wednesday, July 31, 2024 11:24
To: 'Loa Andersson' <[e-mail]>; [e-mail]
Cc: mpls <[e-mail]>
Subject: RE: [mpls] SR-MPLS address space aggregation

ESPL is after XL. XL is in the smallest byte.
Hence, not affected.

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 <[e-mail]>
Sent: Wednesday, July 31, 2024 11:15
To: Vasilenko Eduard <[e-mail]>; [e-mail]
Cc: mpls <[e-mail]>
Subject: Re: [mpls] SR-MPLS address space aggregation

Eduard,

Have you considered if RFC 7274 and RFC 9017 has any impact on this?

/Loa

Den 2024-07-31 kl. 09:36, skrev Vasilenko Eduard:
>
> 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: [phone]
>
>
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

--
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
[e-mail]
[e-mail]