Hi Zafar, >> In the vast majority of the deployments (single SP domain), one can deploy >> MPLS. >> In a minority of cases where some MPLS discontinuity in the domain could >> exist, SR-MPLS over IP/UDP is an adopted and deployed solution. For an operator who has used MPLS, don’t you think SRv6+ will appeal more to them in this case? Given all the arguments that are being made that it does resemble MPLS in its mapping prefixes to short labels?
Regards, Tarek From: "Zafar Ali (zali)" <z...@cisco.com> Date: Friday, September 6, 2019 at 4:28 AM To: Robert Raszuk <rob...@raszuk.net>, Andrew Alston <andrew.als...@liquidtelecom.com> Cc: Ron Bonica <rbon...@juniper.net>, Srihari Sangli <ssan...@juniper.net>, Tarek Saad <tsaad....@gmail.com>, Rob Shakir <ro...@google.com>, SPRING WG List <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com> Subject: Re: [spring] Beyond SRv6. Hi Andrew, I agree with Robert. CRH is nothing else than IPv6 over SR-MPLS. In the vast majority of the deployments (single SP domain), one can deploy MPLS. In a minority of cases where some MPLS discontinuity in the domain could exist, SR-MPLS over IP/UDP is an adopted and deployed solution. As you stated in your original response” “Now – in that case SR-MPLS would have been just fine and frankly speaking – we were entirely happy with pure SR-MPLS and I’m on record saying that I didn’t see much of a use case for SRv6 at all.” I can see why you liked CRH. Thanks Regards … Zafar From: Robert Raszuk <rob...@raszuk.net> Date: Friday, September 6, 2019 at 4:01 AM To: Andrew Alston <andrew.als...@liquidtelecom.com> Cc: "Zafar Ali (zali)" <z...@cisco.com>, Ron Bonica <rbon...@juniper.net>, Srihari Sangli <ssan...@juniper.net>, Tarek Saad <tsaad....@gmail.com>, Rob Shakir <ro...@google.com>, SPRING WG List <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org> Subject: Re: [spring] Beyond SRv6. Hi Andrew, I can say that I may even agree with some of your points. But one question I asked which no one responded still stands ... SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. Both require mapping, both require changes to OAM, both require IGP extensions, both can use the same forwarding hardware and logic, both require almost identical operation etc .... As you know even main author of SRv6+ agrees with all of this in the notes sent to the list. So please help me to understand why entire industry who wants to be good IETF citizen and Industry player should now invest a lot of resources in development, testing, shipping and support of a solution which is just a poor mirror of something which is already available ? Yes some folks were allergic to MPLS in the past and some are still allergic to MPLS. But as someone who have worked since Tag Switching early days on that piece of technology let me tell you that vast majority of those folks do not even understand the difference between MPLS used for transport and MPLS used as forwarding demux for the applications. They just treat it the very same way like an evil or devil protocol which does nothing else other then demonstrate their complete ignorance of the subject. Yes MPLS to be used as a transport is a mistake. It was not a mistake in the past as when we rolled out services which required encapsulation most platforms in the field just could not do line rate IP encapsulation. But those days are gone. If in 1998 time frame routers could do IPv4 in IPv4 encap MPLS as a transport would have never succeeded. Then of course there was more mistakes TDP later by IETF collaboration became LDP was a mapping protocol - yes another mistake instead of making up front domain wide labels and extended IGPs and BGP for that. Well the thought was that working on single protocol will be easier then extending ISIS, OSPFv2 (and v3 on the radar), RIPv2, EIGRP. But this is MPLS transport which in spite of little group of folks still selling it around believe it or not it is going away. But nothing is wrong about using 20 bit labels as demux for applications and services. Packet carry bits. Nowhere in the packet even if you decode it carefully it says "I am MPLS" ... forwarding on the boxes also uses bit lookup and if you ask your vendor they can paint it and abstract all the MPLS legacy in the CLI for you so you never see it. Bottom line is that I see no reason at all to adopt a solution which walks like a duck, quacks like a duck and only carries a label "I am not a duck" Best, R. <snip>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
