In-line
Thank you all for the response Sent from my iPhone > On Oct 6, 2019, at 11:54 AM, Joel M. Halpern <[email protected]> wrote: > > I just realized reading this note from Greg that he was arguing for something > different than I understood. To that degree, I apologize to Greg. My > comments do not reflect on Greg's Unified SID work. > > Yours, > Joel [Gyan] With regards to the SID depth issue with SRv6 one way to get around it is with jumbograms support 32 bit IPv6 mtu payload where IPv4 has 16 bit mtu theoretical maximum of which most vendors only support today up to 9216 but if the core was bumped let’s say to 64k then SRv6 would be fine as it stands with SID depth for long many hop TE paths as well as EH insertion on intermediate nodes for Ti-LFA at PLR to PQ node additional EH insertions occurring at least would not be an issue as far as overhead mpls bytes with jumbograms. With regards to SR-MPLS versus SRv6 with LDP supporting dual stack transport v4 v6 as of a few years ago and some providers have adopted so the decision tree of which direction to go is based on your core transport and if your mpls core “bgp and PIM free” is still IPv4 then you go with SR-MPLS and if dual stacked with LDP v4 v6 then you have the option to easily migrate to SRv6. As far as TE goes in terms of per vrf coloring TE with LDP is supported by most SP router vendors today but is not as seamless as a separate loopback is required for egress FEC bgp peering so then with SR-MPLS you have SR-TE and with SRv6 you have Ti-LFA 50ms fast reroute so TE is functionally and FRR is available for all options. The major gain that SRv6 has with TE capabilities is its use cases extend outside the service provider core arena to every permutation imaginable with traffic engineering natively with IPv6 dataplane from enterprise solutions for DC to Access client /server communication to IPSEC vpn net to net to internet flows can now all use Ti-LFA native traffic engineered protected paths. uSID variable length SID does provide interoperability for dual data plane v4 SR-MPLS and SRv6 IPv6 data plane interoperability with 32 bit SID and SRv6 now with uSID along with SRv6+ compressed SID can provide workaround for the SRv6 SID depth issue until vendors are able to support larger MTUs for IPv6. > > PS: Greg, just so you know waht error I made, I connected U-SID with the uSID > drafts. Again, sorry, I misread and misunderstood your note. Yes, you > referenced your draft. > >> On 10/6/2019 11:29 AM, Greg Mirsky wrote: >> Hi Joel, >> thank you for reviewing U-SID draft. I'm looking forward to reading a more >> detailed analysis. >> Regards, >> Greg >> On Sat, Oct 5, 2019 at 8:18 PM Joel M. Halpern <[email protected] >> <mailto:[email protected]>> wrote: >> No Greg, uSID does not bring all the benefits of SRv6 while using >> shorter SIDs. >> It also violates the basic IP archtiecture really abdly. >> Yours, >> Joel >> On 10/5/2019 7:44 PM, Greg Mirsky wrote: >> > Hi Gyan, >> > you're asking very good questions and your arguments are all >> correct. >> > But I think that now there are several proposals that address >> what is >> > considered the scalability issue of SRv6. Among these is the >> Unified SID >> > for SRv6 >> > <https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/>. >> > U-SID benefits from all the advantages SRH provides while adding a >> > higher density of SIDs thus allowing stricter path control. >> > >> > Regards, >> > Greg >> > >> > On Fri, Oct 4, 2019 at 10:02 PM Gyan Mishra >> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] <mailto:[email protected]>>> wrote: >> > >> > >> > In line possible answers >> > >> > Sent from my iPhone >> > >> > On Oct 4, 2019, at 8:22 PM, Gyan Mishra >> <[email protected] <mailto:[email protected]> >> > <mailto:[email protected] >> <mailto:[email protected]>>> wrote: >> > >> >> >> >> Bess, >> >> >> >> What is the benefit of SRv6 over SR-MPLS for greenfield >> >> deployments or existing mpls deployments. >> >> >> > I think I answered my own question but please chime in with your >> > thoughts.. >> > >> > This NANOG document talks about the state of TE with >> providers and >> > currently the big show stopper with SRv6 which removes it off the >> > table as a possibility is the SID depth and larger packet >> size given >> > that customers are set to 9100 and the core is 9216 so when >> adding >> > in mpls overhead vpn labels and Ti-LFA EH insertion at PLR >> node to >> > PQ node that adding in the entire SID list for long TE paths that >> > have huge SID depth makes SRv6 not viable at this point. >> > >> > >> >> https://pc.nanog.org/static/published/meetings/NANOG73/1646/20180627_Gray_The_State_Of_v1.pdf >> > >> > For existing implementations it appears from my research a no >> > brainer to go with SR-MPLS as that is a painless seamless >> migration >> > but SRv6 due to SID depth issues and given limited head room from >> > customer MTU to the backbone MTU today we are over the limit >> with >> > larger SID depth for Ti-LFA paths or non protected paths. Until >> > that is addressed SRv6 unfortunately may not get much >> traction with >> > service providers which I think due to the SRv6 issues >> ....uSID and >> > SRv6+ may tend to be more viable and more attractive. >> > >> > >> > >> > >> >> Regards, >> >> >> >> Gyan Mishra ____ >> >> >> >> IT Network Engineering & Technology ____ >> >> >> >> Verizon Communications Inc. (VZ)____ >> >> >> >> 13101 Columbia Pike >> >> >> <https://www.google..com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> >> FDC1 >> >> 3rd Floor____ >> >> >> >> Silver Spring, MD 20904____ >> >> >> >> United States____ >> >> >> >> Phone: 301 502-1347 <tel:301%20502-1347>____ >> >> >> >> Email: [email protected] >> <mailto:[email protected]> >> >> <mailto:[email protected] >> <mailto:[email protected]>>____ >> >> >> >> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT >> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT> >> >> <http://www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT> >> >> >> >> >> >> Sent from my iPhone >> > _______________________________________________ >> > BESS mailing list >> > [email protected] <mailto:[email protected]> <mailto:[email protected] >> <mailto:[email protected]>> >> > https://www.ietf.org/mailman/listinfo/bess >> > >> > >> > _______________________________________________ >> > BESS mailing list >> > [email protected] <mailto:[email protected]> >> > https://www.ietf.org/mailman/listinfo/bess >> > > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
