+1 Hence, to avoid such violation, but still to use shorter SIDs, SRv6+ (https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-05 <https://tools.ietf.org/html/draft-bonica-spring-srv6-plus-05>) architecture has been proposed.
Thanks, Krzysztof > On 2019-Oct-06, at 05:18, Joel M. Halpern <j...@joelhalpern.com> 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 <hayabusa...@gmail.com >> <mailto:hayabusa...@gmail.com>> wrote: >> In line possible answers >> Sent from my iPhone >> On Oct 4, 2019, at 8:22 PM, Gyan Mishra <hayabusa...@gmail.com >> <mailto:hayabusa...@gmail.com>> 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: gyan.s.mis...@verizon.com >>> <mailto:gyan.s.mis...@verizon.com>____ >>> >>> 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 >> BESS@ietf.org <mailto:BESS@ietf.org> >> https://www.ietf.org/mailman/listinfo/bess >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
