Hi, Don. Thanks for your comment. It is actually a very good question and a difficult one to answer, which is why I took and extra day to respond...
On Aug 26, 2014, at 10:32 AM, Fedyk, Don <[email protected]> wrote: > This statement strikes me as too terse: >> >> BGP-based solutions to network virtualization within a data center >> environment >> will be developed in the BGP-Enabled Services (BESS) WG. Those words actually came from our ADs. So we should probably get their input on this topic. Notwithstanding that, here are my thoughts: > It almost sounds as if BGP solutions are out of scope for NVO3. Yes, that is the idea. BGP solutions are out of scope. But it is probably worth expanding on what that word “scope” means in this case, because it’s slightly ambiguous. See my next comment. > What I think is important is: > If an NVO3 solution specifies an existing protocol developed in another IETF > WG, any specific extensions to that protocol should be coordinated with and > may be developed within the respective WG. For example any BGP-based > extensions for NVO3 BGP-based solutions will be developed in the BGP-Enabled > Services (BESS) WG. > > I see BGP solutions as in scope for NVO3 but the BESS WG has the oversight on > the extensions. The difficult question is how to apply the idea of scope to “solutions”. It’s somewhat easier to decide where specific protocol work should happen, based on the text of the proposed charter. So let’s assume that as a starting point - we know where protocols will be developed. (And if we don’t, then we’ll figure it out when examples arise.) But if a solution is a combination of multiple protocols (e.g. data and control plane), and some of those protocols were developed by different WG(s), then it might be less clear where the solution belongs. Before we can figure out the right answer, I suppose we ought to define what a “solution” actually is in this context: I posit that it is a document describing how to use one or more protocols to solve the problem. In other words, it is an Applicability Statement (AS) document. If an AS describes how to solve for the issues outlined in the NVO3 Problem Statement in a manner consistent with the Architecture, then arguably that AS document should be developed in the NVO3 WG. If the AS solves for a different problem and/or is inconsistent with our Architecture, then it probably belongs to a different WG. Alternatively (and perhaps very likely), if the AS crosses WG boundaries and isn’t clear, then it’s up to the WG management (chairs and ADs) to make sure it gets cross-WG review and ultimately decide which WG should develop it. In the case of BGP-based solutions, we are agreeing up-front that AS documents with BGP-based control planes will be developed in the BESS WG. This is being called out explicitly because it is possible to imagine BGP used in a centralized fashion (such as a route-reflector NVA model), and we intend for that work to happen in BESS even though it resembles the NVO3 architecture. All that being said, if we develop a solution that leverages BGP protocol extensions but also has a significant non-BGP NVA control plane, then we will evaluate where it belongs - and it may very well belong in NVO3. However it isn’t a good idea to pre-judge where such work would belong until we have a real example… I’m just explaining my thought process, in case it helps you (and others) understand how it might evolve. Of course, I’d welcome any additional feedback on this. But at this time I’m going to leave the referenced charter text as-is. Cheers, -Benson _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
