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=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 > > _______________________________________________ > 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
