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

[Jeff Tantsura <[e-mail]>]

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=[e-mail]> wrote:
> 
> 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]
> 
> _______________________________________________
> mpls mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]