Hi Andrew, check out the Milestones section for SPRING in Datatracker.
Darren > On Nov 20, 2019, at 12:31 AM, Andrew Alston <[email protected]> > wrote: > > 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
