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

[Loa Andersson <[e-mail]>]

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]