Re: [spring] Beyond SRv6.

[Ca By <[e-mail]>]

On Fri, Sep 6, 2019 at 1:40 AM Andrew Alston <
[e-mail]> 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.
>
>
Eh, i am also an operator of a non-trivial size network.  The above
statements make me concerned about your business.

1.   I consider SR to be a bit of flashy marketing push by vendors to do
things with no unique merit. One looks at a 1/2 page author list of these
SR draft and must note something here is fishy. Folks from my company who
have no idea what SRv6 is have been asked to add their names to the author
list of SPRING drafts.  It is a mirage, and poor form by the SR pushers to
engage in this fake grass roots movement.

2. IMO, SR is like lisp and nsh. Overly complicated protocols driven by
vendors, with plenty of astro turf, to make networks more complicated and
expensive.  Oh, and it is so simple ans great, but only runs on the newest
kit ...

3.  You are very confused. You give vendors requirements and they comply.
You pay them, they do stuff. They will even put your name on an I-D you
have not read.

4. SR is not coming to anyone who does not have the religion of SR. SR is
no more of a solid bet than LISP or OpenFlow or NSH or “SDN” or PCF ....

My bet is MPLS will not die, it is 20 years mature and not going anywhere.
Let’s see a vendor launch a serious carrier router without MPLS....


>
> 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) <[e-mail]>
> *Sent:* Friday, 6 September 2019 11:28
> *To:* Robert Raszuk <[e-mail]>; Andrew Alston <
> [e-mail]>
> *Cc:* Ron Bonica <[e-mail]>; Srihari Sangli <
> [e-mail]>; Tarek Saad <[e-mail]>; Rob Shakir <
> [e-mail]>; SPRING WG List <[e-mail]>; [e-mail]; Zafar
> Ali (zali) <[e-mail]>
> *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 <[e-mail]>
> *Date: *Friday, September 6, 2019 at 4:01 AM
> *To: *Andrew Alston <[e-mail]>
> *Cc: *"Zafar Ali (zali)" <[e-mail]>, Ron Bonica <[e-mail]>,
> Srihari Sangli <[e-mail]>, Tarek Saad <[e-mail]>,
> Rob Shakir <[e-mail]>, SPRING WG List <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>