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

[Tarek Saad <[e-mail]>]

Hi Ed,

Thanks for reaching out.
The usual IETF process starts with an individual draft that is announced to the WG on the mailing list. Depending on WG interest, the WG members may give feedback and engage on the mailing list. Authors are then also encouraged to request slots to present new drafts at interims and/or IETF WG sessions to widen the scope of engagement among the WG. Time permitting, the WG chairs will make effort to grant such requests.
The WG chairs would like to see those steps followed before jumping to discuss the need for a vote or poll.

Regards,
Tarek (for the MPLS chairs)


From: Vasilenko Eduard <vasilenko.eduard=[e-mail]>
Date: Wednesday, July 31, 2024 at 5:01 AM
To: Loa Andersson <[e-mail]>, [e-mail] <[e-mail]>, mpls <[e-mail]>
Subject: [mpls] Re: SR-MPLS address space aggregation
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]