Hi Hannes, > agreed that customers buying kit are making a call on this, not IETF - > however IETF should keep honesty in the discussion. > unfortunately the current way of promoting v6-sr is an 'oversell'. > > "look we have this new dataplane, it comes at (almost) zero cost, > and is going to be the 'holy-grail of networking' > (one protocol, one dataplane which does it all)" > > so a bit more honesty on the one-off and perpetual cost of adding dataplane #4 > on the internet would be appreciated.
Well looking from the side at this I think perhaps both parties are a bit too far. As example one side is defending LDP unicast like it's of any practical value, while the other side dismisses use of simple GRE encapsulation and proposes in place SR. Looking at the bigger picture it needs to be observed that networks are becoming simpler and are moving to carry less state while more and more services are becoming overlays. With that in mind keeping use of entire load of MPLS control plane state is not aligned with network re-architecture trend. Example: Peter's TeraStream ... look how much MPLS control plane state he is carrying in the Croatia network and draw your own conclusions ;) Of course in the case of SR shifting the state to centralized controllers responsible for inserting proper headers in the packets does not come for free and there is still a lot to be done on the management, monitoring and troubleshooting side, but if we rather then working on this will continue to argue about MPLS and it's signalling being the only multi-protocol data plane forever we may not get far I am afraid - but maybe that's the point ..... > | Nothing wrong, but those are limited to the same trust domain. While BGP > | SAFI 2/1 is a bit of much wider deployment scope. > > not sure i understand - why is 3107 limited to the same trust domain ? In theory it is not, however in practice it is sufficient to observe how many tier1s, tier2s or even tier3s ISPs and IX-es run 3107 peering sessions today to answer your dilemma. Cheers, R. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
