Hi Robert,

>> Because many problems are identified in the current work
> Please kindly enumerate technical problems which got identified. It will be 
> actually very helpful list.
>> It's not needs/requirements, it's mostly the lack of a KISS approach
> Not all vendors are falling into the last "S" category

You clearly don't understand the concept of KISS and prefer to call people 
stupid because of that… Pathetic.

>> Please elaborate about the real deployment. Where was it deployed? In what 
>> kind of networks? On what scale? For which use cases?
> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01
>> I don't like the design of the current solution, and you seem to suggest 
>> that I have to stall work on what I would like until you have what you would 
>> like *. That doesn't work for me.
> No one is stating that. It is your network and you can deploy and develop 
> anything you like.
> But IETF mission is to make sure you have interoperable services and so far 
> for all SRv6+ related draft this is all single vendor. Sorry but linux code 
> does not count.

And Cisco is doing exactly the same. I'm just happy that finally someone is 
standing up to Cisco in this. I *know* the SRv6+ people have suggested working 
on interop. Cisco is the one who refused! So don't come to me with this "IETF 
mission is to make sure you have interoperable services" BS.

> So do you think that IETF should support and work on single vendor's wall 
> garden now ? Very interesting ....

No. And that is why I want SRv6+ to move forward, to avoid getting trapped in 
the SRv6 walled garden.

> I think Juniper reps are actually taking a very risky path ... In fact if 
> IETF would accept the work - even as experimental - they can only deploy it 
> in single Juniper shops. So those customers with dual or multi vendor will 
> have no choice but get rid of Juniper gear.

I don't care which vendor is behind which proposal. I don't want to get trapped 
into one vendor's way of thinking. Especially if I don't like that way of 
thinking. I want to have choice. If SRv6+ is successful it will be implemented 
by many vendors. A lot of them are still on the fence whether to support SRv6, 
SRv6+ or both. Let the operators decide what we like best, instead of 
manipulating the IETF to push a single solution down our throats.


Attachment: signature.asc
Description: Message signed with OpenPGP

spring mailing list

Reply via email to