Re: [spring] Beyond SRv6.

[Robert Raszuk <[e-mail]>]

> 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 <
[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.
>
>
>
> 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
> --------------------------------------------------------------------
>