RE: Do we really need to add state into each packet ...

[Andrew Alston <[e-mail]>]

From: ipv6 <[e-mail]> On Behalf Of Gyan Mishra
Sent: Thursday, 14 May 2020 04:27
To: Uma Chunduri <[e-mail]>
Cc: 6man <[e-mail]>
Subject: Re: Do we really need to add state into each packet ...


There are of course two perspectives and a balancing act as to what prevails and obtains WG and IETF adoption and becomes an RFC.

For operators it would be great to have many options in designers toolbox, however their is a cost incurred for every steering flavor by the vendor developers writing the code for the feature.

Of course the balancing act is the difficult one and for adoption an agreement on which ones to develop and from that respect which one based on market analysis will yield the most revenues residuals for years to come.

Some vendors may think their idea or philosophy is better then others and so then comes down to the vendors that the the so called pillars that make up that routing and switching network gear market share have to battle it out and come to a consensus on what feature or technology is best for all both the vendors revenue generation and marketability and operators end users consuming the new features or technology.

Kind regards

Gyan


Just some comments on this – as an operator – you are correct that choice is required.  Obviously, inter-op is also important – and I typically avoid running proprietary protocols.  But  here is the thing, there is ever indication that both CRH and SRH are going to be developed – with or without RFC’s.  In Montreal I raised this with one of the vendors involved more than a year ago – and in fact I went as far as to say that both parties were entrenched, there was code out there for both, because I’d seen it and used it – and in that case, perhaps it was time to start looking at a way to inter-op the two technologies.  I was told rather bluntly to my face that irrespective of what happened, there would be no inter-op, it wasn’t desired, and it was that particular vendor’s way or the highway.  On that day – all I’m going to say is that purchase orders got changed.

My take on this is pretty simple – we’re in a situation where firstly – there is no requirement for any vendor to implement any RFC – and there are MANY cases where vendors choose NOT to implement a particular RFC.  Some things move ahead post the RFC process and get properly implemented – some don’t, and then the operator chooses to run something or not, and tailors their purchasing options around those choices.  Now, while it is obviously not practical to standardize every idea – where we have a situation where there is on going development and clear indication that both systems are *GOING* to be developed – and both are asking for standardization – by refusing to do a working group call or adopt one of them – we are saying – we embrace proprietary protocols – because where there is customer demand – the development will happen.

Let us be real – do you think most operators give a damn about an RFC?  Some of the bigger ones, and myself, we like to know the rfc’s – but for most, they don’t care so long as it works.   End the day – the market is going to decide – the operators are going to decide – and in the face of lack of standardization – where two vendors are going to develop no matter what we do – what I predict happening is that you end up with two cases – one standard – one not – and then – if the non-standard one becomes popular in the market – and I’ve seen that happen as well, suddenly the vendor that went the other way will be under pressure to go ahead and implement something non-standard against the other vendors implementation – and we end up with a non-standard protocol with multiple implementations.  That – is in no one’s interests.

In the alternative case, we have two standards – vendor A and vendor B choose to implement the standard they prefer, with no obligation to implement the other.  If the market then decides the one a particular vendor chose NOT to implement is the better solution – either they convince their vendor to implement the other one, or, they get up and talk with their cheque books and walk out the door.  No harm, no foul.   The only reason I can see for one vendor actively fighting the standardization of something that they themselves are under no obligation to implement is to protect their own standard, and is a tacit acknowledgement that there is a chance the market may reject what they are doing and choose to go the other way.  That to me, is horribly reminiscent of anti-competitive protectionism – squash the competitions innovation to promote your own, rather than letting your good work win out in the free and open market, and it smacks of insecurity.  This behavior also creates a situation where once one vendor starts playing that game, the only alternative available to the other vendor is to start getting obstructive to protect their own interests, and we end up in a long and escalating battle of obstructionism to force the other vendor to back down – effectively creating a stale mate till both come to a draw.

In this particular case – and this is my personal opinion, you have two technologies – that in my view actually serve very different use cases (but that can debated).  There is clearly *some* support for both – from both vendors and operators alike.  There is clearly on going development of both.  We now choose – do we want to see one standard – one proprietary – and then risk the scenario above – or do we say – it is the enterprises, the operators, the customers who end up choosing – lets give them the choice and standardize both – and let the market decide?

To me – the latter makes far more sense – the protectionism I am seeing going on in this whole debate – and the blatant obstructionism – is nothing short of madness – and it may serve the vendors interests – but it sure as hell does not serve the operators interests, and at the end of the day, it’s the operators who are going to be buying the stuff – or not buying from the vendor that chooses not to implement it.  Let them have the choice, just as operators have the choice to implement or not implement against any RFC out there.

Thanks

Andrew