> between those who want MPLS to die Again you are putting an equal sign between MPLS used for transport and MPLS used for application and services. While I know and agree that MPLS for transport should die - I have not met anyone who says MPLS for applications is a bad demux encoding.
> for the technical problems behind CRH I pointed the need for mapping as architectural deficiency. But this is not the point. If next week there will be three more proposals of data plane encoding (XRH, ZRH & YRH) and each asking for new IGP & BGP control plane extensions for Segment Routing over v6 should IETF adopt all of them and should all vendors work and deliver all of them ? Is this what you think is in best interest of the industry ? Many thx, R, On Fri, Sep 6, 2019 at 10:40 AM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: > 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> > *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> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > i...@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
