Re: [spring] Beyond SRv6.

[Robert Raszuk <[e-mail]>]

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.


On Fri, Sep 6, 2019 at 9:04 AM Andrew Alston <
[e-mail]> wrote:

> Zafar,
>
> One of the things I keep seeing below is you referring to the operators
> perspective.  So - as someone who actually is from an operator - and has
> done substantial testing of the proposed solution let me give you the
> perspective of an operator.
>
> Firstly - as an operator - on the table mapping - I've seen absolutely no
> problem with this - particularly if I add bgp crh signaling which lets me
> build a mapping table that can be understood in multiple systems which do
> not necessarily need to know about the rest of the network (this is
> particularly useful on inline DPI systems and other such things)
> Secondly - as an operator - the segregation between what is an address and
> how said address is directed - rather than a constant change in the address
> to us seems far safer.  In the uSID draft, a leak of a more specific prefix
> in the network because of finger trouble - can fundamentally break routing
> - and well, that could be rather interesting to start debugging.
> Thirdly - as an operator - without retaining the uncompressed list of
> SID's in the header, I have a debugging nightmare - and zero ability to
> figure out packet pathing through the network at intermediary points - and
> you keep saying that this is addressed by retaining the full SID list - but
> - if I do that - can you explain to me what the point of the micro sid is -
> since - I was under the impression that the point was to remove the
> overhead - the moment I take this approach - how am I not back at square
> one with the same overhead?
> Forth - as an operator - I am deeply uncomfortable with the fact that the
> proposal fundamentally redefines the semantics of the address with
> potential unintended consequences - and despite the fact that multiple
> times I have raised the redefinition of the semantics of the address when
> compared against RFC4291 - I have yet to see this addressed
> Fifth - as an operator - I have concerns about the inflation of the IGP,
> and this was raised in Montreal.  I was told that this could be addressed
> by renumbering my network - sorry - I hardly view this as viable
> Sixth - as an operator that has to apply for space from the RIR's - and
> has concerns about address space utilization - a request was made in
> Montreal for an evaluation of actual address space required by this
> solution - which as of yet has not been forthcoming.  However, when looking
> closely, I'm pretty sure we can figure out how much space this is.  To this
> end, as per Nick Hilliards suggestion, perhaps we should approach the RIR's
> about allocation policies to seek the viewpoints from them as the
> allocators of space.  I am even willing to take this on, and prepared to
> put a global policy into the RIR system through all 5 RIR's to change the
> allocation policies to cater for this once I have a firmer grasp on h ow
> much address space will be utilized.  At that point we can see what the
> appetite is from that perspective. (In fact some prelim work on such a
> policy proposal has already begun)
>
> Thanks
> Andrew
>