An Zafar – I told by those words – I am pragmatic though as an operator. I know that srv6 in some form or another is coming – I stated as much on various blogs. I am not fool enough to believe that I am not going to be forced into a situation where I am going to be made to run some variant of this – because I have been told very bluntly by certain vendors that mpls style development for v6 will cease at a control plane level – and we are already seeing situations where despite sr-mpls working just fine – certain vendors have actively chosen to not support this with IPv6.
That has put me in a position where I have to be pragmatic – because – as an operator with a massive network – I have to be able to continue to well, operate. That leaves me needing something that finds a common ground between those who want MPLS to die – and the MPLS usage which is present, real and necessary in the world in which I operate. That leaves me with needing a version of SRv6 which is usable, does not impose insane overhead, and does not fundamentally rewrite the IPv6 protocol. I have been extremely open and honest about this – I will however say – that the added functionality through the network programmability – all of which is catered for in CRH without the need to rewrite the IPv6 specification to do it – does have other use cases – and hence – CRH actually works for us – very very well – because it retains that which I need – while adding some really nice advantages on top of it. But again – we have asked – multiple times – for the technical problems behind CRH – and the ringing in my ears is deafening from the silence. Andrew From: Zafar Ali (zali) <z...@cisco.com> Sent: Friday, 6 September 2019 11:28 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; 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<mailto:rob...@raszuk.net>> Date: Friday, September 6, 2019 at 4:01 AM To: Andrew Alston <andrew.als...@liquidtelecom.com<mailto:andrew.als...@liquidtelecom.com>> Cc: "Zafar Ali (zali)" <z...@cisco.com<mailto:z...@cisco.com>>, Ron Bonica <rbon...@juniper.net<mailto:rbon...@juniper.net>>, Srihari Sangli <ssan...@juniper.net<mailto:ssan...@juniper.net>>, Tarek Saad <tsaad....@gmail.com<mailto:tsaad....@gmail.com>>, Rob Shakir <ro...@google.com<mailto:ro...@google.com>>, SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>>, "6...@ietf.org<mailto:6...@ietf.org>" <6...@ietf.org<mailto: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
