Hi all, Yes, I did have something IP-independent in mind (that is IPv6-independent too). Actually, the additional transport header is a different data plane anyway (many would argue).
MPLS has one advantage against SRv4/SRv6: PUSH/POP/SWAP operation. SRv4/v6 would drag the whole routing header along the path and even mandate that it could not be extended in the middle. It is not flexible! IMHO: it is a big disadvantage in the functionality and overhead. I did never understand why it is prohibited in the IPv6 architecture to add Extension Headers in transit. High levels checksum (for transport headers) was not a good idea in general. It is not reasonable at all for the outer transport header (SRv6, SRv4, MPLS, whatever). The combination of PUSH/POP/SWAP with the longest much looks a very nice combination. “MPLS with the longest match forwarding” could claim some advantage against SRv6/SRv4. Just copying the SRv6 approach would not drive the market. SRv4 looks duplicate – it would not fly. Eduard From: Robert Raszuk <[email protected]> Sent: Friday, August 2, 2024 22:00 To: Jeff Tantsura <[email protected]> Cc: Vasilenko Eduard <[email protected]>; [email protected]; mpls <[email protected]> Subject: Re: [mpls] Re: SR-MPLS address space aggregation Jeff, Q1 - Where do you see in the original email any reference to IPv6 running in the underlay ? Q2 - Do you happen to have a pointer handy on how do you run TI-LFA in the underlay with SR-MPLS over native IPv6 in any topology ? Q3 - Do you have a way to select paths depending on the actual segment by segment real time measurements when running native IPv6 ? .. and we can continue like this for some time :) Sure in some type of underlays this may not be ever needed (heavy ECMPs, non blocking etc...), but the original thread Eduard has started is much more about real WAN networks, often with IGP hierarchy, often global where ability to do underlay summarization and SID aggregation would allow control and data plane size reduction. Yet no immediate plans to enable SRv6 there. Of course one could argue if this reduction is worth the hassle, but let's keep comparing apples to apples. Best, R. On Fri, 2 Aug 2024 at 19:13, Jeff Tantsura <[email protected]<mailto:[email protected]>> wrote: SR-MPLS over IPv6 works just fine and is deployed at hyperscale scale. Cheers, Jeff On Jul 31, 2024, at 23:37, Vasilenko Eduard <[email protected]<mailto:[email protected]>> wrote: Hi Jeff, Hi Tarek, Yeah, I know, the resources must be spent first, before the right to ask. Just I am not sure that it makes sense. Hi Robert, Thanks! Your comment was very interesting. You are probably right that such an initiative should be called SRv4. Then, it probably has no chance. Eduard From: Tarek Saad <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 31, 2024 21:06 To: Vasilenko Eduard <[email protected]<mailto:[email protected]>>; Loa Andersson <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; mpls <[email protected]<mailto:[email protected]>> Subject: Re: [mpls] Re: SR-MPLS address space aggregation 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 <[email protected]<mailto:[email protected]>> Date: Wednesday, July 31, 2024 at 5:01 AM To: Loa Andersson <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, mpls <[email protected]<mailto:[email protected]>> 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' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: mpls <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 31, 2024 11:15 To: Vasilenko Eduard <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: mpls <[email protected]<mailto:[email protected]>> 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<http://iana.org>) > <https://www.iana.org/assignments/mpls-label-values/mpls-label-values. <https://www.iana.org/assignments/mpls-label-values/mpls-label-values.%0b>> 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: +7(985) 910-1105 > > > _______________________________________________ > mpls mailing list -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]> -- Loa Andersson Senior MPLS Expert Bronze Dragon Consulting [email protected]<mailto:[email protected]> [email protected]<mailto:[email protected]> _______________________________________________ mpls mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ mpls mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
