> On Jul 31, 2024, at 05:56, Robert Raszuk <rob...@raszuk.net> wrote: > > 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.
I agree. Furthermore, I think it is a bad idea to try and retrofit aggregation into MPLS. Thanks, Acee > > Kind regards, > Robert > > > On Wed, Jul 31, 2024 at 11:01 AM Vasilenko Eduard > <vasilenko.eduard=40huawei....@dmarc.ietf.org > <mailto: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 <mailto:l...@pi.nu>>; spring@ietf.org >> <mailto:spring@ietf.org> >> Cc: mpls <m...@ietf.org <mailto: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 <mailto:l...@pi.nu>> >> Sent: Wednesday, July 31, 2024 11:15 >> To: Vasilenko Eduard <vasilenko.edu...@huawei.com >> <mailto:vasilenko.edu...@huawei.com>>; spring@ietf.org >> <mailto:spring@ietf.org> >> Cc: mpls <m...@ietf.org <mailto: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 <http://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 <mailto:m...@ietf.org> >> > To unsubscribe send an email to mpls-le...@ietf.org >> > <mailto:mpls-le...@ietf.org> >> >> -- >> Loa Andersson >> Senior MPLS Expert >> Bronze Dragon Consulting >> l...@pi.nu <mailto:l...@pi.nu> >> loa.pi....@gmail.com <mailto:loa.pi....@gmail.com> >> >> _______________________________________________ >> spring mailing list -- spring@ietf.org <mailto:spring@ietf.org> >> To unsubscribe send an email to spring-le...@ietf.org >> <mailto:spring-le...@ietf.org> > _______________________________________________ > mpls mailing list -- m...@ietf.org > To unsubscribe send an email to mpls-le...@ietf.org
_______________________________________________ spring mailing list -- spring@ietf.org To unsubscribe send an email to spring-le...@ietf.org
