Hi, What is the real operational value to depart from MPLS label exact match data plane paradigm into longest match if the latter has been operating fine with IPv4 for decades ? And aggregation in IPv4 comes for free.
IPv4 encapsulation has also been around for decades and it works in line rate across most of the hardware. And 32 bits (from RFC1918) is clearly more then 20 bits of MPLS label. As example - say to get source routing one could use GRE. The original rfc1701 had space in the header to add routing hops. Sure rfc2890 removed the R bit, but to resurrect this is just one page draft and zero data plane change to accomplish IPv4 address stacking and SRv4. I understand some people may not like IPv6, but the delta between new to be introduced MPLS aggregation, and massive data plane change vs IPv4 forwarding seems IMO not worth the cost and effort. Kind regards, Robert On Wed, Jul 31, 2024 at 11:01 AM Vasilenko Eduard <vasilenko.eduard= 40huawei....@dmarc.ietf.org> 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' <l...@pi.nu>; spring@ietf.org > Cc: mpls <m...@ietf.org> > 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 <l...@pi.nu> > Sent: Wednesday, July 31, 2024 11:15 > To: Vasilenko Eduard <vasilenko.edu...@huawei.com>; spring@ietf.org > Cc: mpls <m...@ietf.org> > 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: +7(985) 910-1105 > > > > > > _______________________________________________ > > mpls mailing list -- m...@ietf.org > > To unsubscribe send an email to mpls-le...@ietf.org > > -- > Loa Andersson > Senior MPLS Expert > Bronze Dragon Consulting > l...@pi.nu > loa.pi....@gmail.com > > _______________________________________________ > spring mailing list -- spring@ietf.org > To unsubscribe send an email to spring-le...@ietf.org >
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
