Just to add to this because it’s the one thing that I am still confused about.
We are referring to finishing the work on SRv6 - what does this mean? SRH is with the editors - meaning - its pretty much completed (and it came out of 6man not spring) Network programming and CRH are entirely different things - they have entirely different functions and entirely different use cases. Yes - there is micro-sid and CRH - but you cannot make one hostage to the other - and if you are - on the basis of what is proposed here, surely first come first serve would apply - look at the publication dates. So - what do we mean finish the work - what exactly are we finishing? I view this as the equivalent of saying - lets finish the work on BGP - yet at the same time - how many flow spec extensions are out there (in fact there are even things in pipeline while flowspec v2 is coming). You have a ton of extensions for different things - no one halts the progress. So - What exactly are we "finishing" and on what premise are we holding other things hostage on these grounds? Andrew On 19/11/2019, 01:00, "Sander Steffann" <[email protected]> wrote: Hi, > Hi Ron, to follow up on what was said at the mic. > > The current community analysis, comparing existing solutions (SRv6 and SR-MPLS for IPv6) with SRm6, had the following result: > - a lot of differences (Architecture, Dataplane, Controlplane) and hence engineering cost A different architecture isn't necessarily a bad thing. I think the architecture is sound, and I prefer a strong architecture that needs some engineering work to a weaker architecture that is easier to implement any day. Build for the future etc. > - scale, performance and complexity drawbacks Not my field of expertise, so skipping this one. > - no genuine advantage These are the advantages that I see: - fits cleanly within the IPv6 standard - packet overhead comparable to SR-MPLS - but doesn't need every box on the path to cooperate (I have participated in a test running SRm6 over the open internet: no tunnels, just worked) I think SRm6 strikes the right balance between clean architecture, overhead and complexity. I my opinion this working group should pursue work on SRm6 for these reasons. I understand the need for finishing the work on SRv6, but at the same time lets work on new developments like SRm6, work on interoperability, and give operators the choice to run the protocol they prefer. There is no need for competition here (and if there is, please take it outside the IETF), only the need for cooperation and coexistence. Cheers, Sander _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
