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
