Hi Jesse, On Mon, Jul 25, 2016 at 11:52 AM, Jesse Gross <[email protected]> wrote:
> > On Jul 25, 2016, at 7:38 AM, Alia Atlas <[email protected]> wrote: > > Hi Paul, > > On Mon, Jul 25, 2016 at 10:23 AM, Paul Quinn (paulq) <[email protected]> > wrote: > >> Alia, >> >> >> On Jul 21, 2016, at 7:12 PM, Alia Atlas <[email protected]> wrote: >> >> Hi Larry, >> >> Very briefly in-line. >> >> On Jul 21, 2016 10:04 PM, "Larry Kreeger (kreeger)" <[email protected]> >> wrote: >> > >> > Hi Matthew, >> > >> > See my responses inline below. >> > >> > Thanks, Larry >> > >> > >> > >> > On 7/21/16, 7:56 AM, "nvo3 on behalf of Bocci, Matthew (Nokia - GB)" >> > <[email protected] on behalf of [email protected]> wrote: >> > >> > >WG >> > > >> > >There was a discussion in the NVO3 WG meeting in Berlin following >> strong >> > >advice from our Area Director that we need to come to a consensus on >> > >converging on a common encapsulation. Two sets of questions were asked: >> > >(1) Should the WG move forward with one standards track encap? >> > >(2) For a given encap, do you have significant technical objections? >> > > >> > >This email relates to the second of these questions. Please refer to >> the >> > >separate email titled ³Consensus call on moving forward with single >> > >encap² for discussion related to point (1). >> > >> > I am sorry I missed the meeting. Was the room polled for the option to >> > move forward with more than one encap? I am interested in knowing the >> > response to that question since on the list, that option appeared to >> have >> > much more traction. If the room was not polled for that option or for a >> > choice between the options discussed on the list, then we have >> > incomplete/misleading results for how to move forward. >> >> Yes, of course the question was asked. There was, as I recall, almost >> no one in favor. >> >> >> Thank you for the summary of the meeting for those of us who weren't >> there. Interestingly, we seem to have a different trend on the mailing >> list: option 1 appears to garner significant support. >> > > I am well aware and curious about why. It may be that in person, there > were more folks peripherally involved who just want the Standards process > to work. That doesn't really explain why none of the people expressing > opinions on the mailing list - whom I know were in the room in some cases - > didn't feel comfortable raising their hands or publicly expressing their > opinion. > > > I was in the room and didn't speak up on this point (though I did express > my support of option #1 previously on the mailing list). > > The way the question was asked was pretty abstract and therefore hard to > argue against. Asking "Who is in favor of a single encap?" is somewhat the > equivalent of saying "Who would like to eat ice cream?". In both cases, > it's something that essentially everyone likes but probably comes with some > tradeoffs. In the case of encapsulations, I think everyone would be fine if > their preferred choice was selected. However, in the absence of that > happening and without specifically linking what you would have to give up, > the question is fairly meaningless. > The first question is to determine if there's a desire to get to a single standard encap. Of course, it'd be easy if everyone wanted the same thing. I will note that I've given the working group 18 months to figure out how to get to 2 or fewer and seen no progress. The second is to figure out what the technical objections are to the different encapsulations. Once they are clear (and almost no one is commenting with technical substance there), then a couple things can happen. For each, either there is a plan and the problem is addressed or the WG decides that it has heard the technical concern but it does not need to be resolved. > When it comes to extensibility, I think the design space is pretty well > explored at this point. I don't really see that it is likely that a new > compromise choice emerges that will significantly change the objections > that have been raised to the existing protocols. To me, extensibility is a > core need-to-have component. As a result, while it would be nice to have a > single encapsulation format, if that format did not include extensibility > it would not be useful to me. Without it, it would not be possible to build > the software that I/VMware am trying to deliver and therefore the choice to > use something else would be an easy one. > I hear you completely that extensibility is really important. I do not know if the design space has been well explored yet; there has certainly been little public discussion of alternatives. I have heard ideas around using lookup tables instead of TLVs for instance - which might have a benefit in the argument about TLVs. > I believe that others are in a similar position but opposite with regards > to technical choices. The net result is that there are almost certain to be > multiple formats in the wild regardless of what is decided here. Yes, that > means letting the market decide rather than the IETF. I honestly don't > necessarily see that as a negative since it means that it will be based on > experience rather than theoretical arguments. I don't even think that it > will cause more confusion or set back the industry given that timescales of > ~5 years are being talked about for a new compromise encap if that were to > come to be. > NVO3 has been around for about 5 years. So far, solutions have been brought into the IETF but not really developed. It is rather rare that a technical solution is rubber-stamped without changes. At least we would be heading somewhere. I'm also fine with taking and tweaking an existing solution so that the technical objections are met. Regards, Alia
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
