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. Cheers, Sander
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
