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 <jefftant.i...@gmail.com> 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 <vasilenko.edu...@huawei.com> > 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 <tsaad....@gmail.com> > *Sent:* Wednesday, July 31, 2024 21:06 > *To:* Vasilenko Eduard <vasilenko.edu...@huawei.com>; Loa Andersson < > l...@pi.nu>; spring@ietf.org; mpls <m...@ietf.org> > *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 <vasilenko.eduard=40huawei....@dmarc.ietf.org> > *Date: *Wednesday, July 31, 2024 at 5:01 AM > *To: *Loa Andersson <l...@pi.nu>, spring@ietf.org <spring@ietf.org>, mpls < > m...@ietf.org> > *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' <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. > <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 -- 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 > > _______________________________________________ > 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
