> > If, as you suggest, multicast is already within scope because we haven't > explicitly excluded it, then I'm fine with the charter text.
Of course multicast is already within scope for the WG. I find myself scratching my head a bit that anyone thinks that it might not be, and that wording needs to be in the charter on this point. I can't recall anyone suggesting that suport for tenant multicast should be out-of-scope. IMO, there is no need to specifically mention multicast in the charter. There is no way the WG or the IESG would allow us to produce solutions that didn't support multicast. Such a solution would be pretty deficient. Does anyone seriously think otherwise? Thomas In that sense, > even the milestones can be broadly interpreted as containing solutions for > multicast. At the very least we will have this thread to point to, should any > questions arise at some point in the future with regard to scope of the > charter. Hopefully, all folks that would approve the charter (WG, ADs, IESG, > etc.) would be on the same page. > > The main reason why I'm bringing this up is that there are existing > implementations that do not support multicast, so in that sense, offering a > solution does not automatically mean that the problem is solved for both > unicast and multicast. Of course, those are not IETF solutions. > > Anoop > > On Mon, Sep 1, 2014 at 12:15 PM, Benson Schliesser <[email protected]> > wrote: > > Hi, Anoop, Linda, Ramki, and other contributors - > > First, just to be clear, I should remind you that we aren't voting here. > With that in mind, the important thing for you to do is help me resolve > the issue that I asked about. > > So, let me ask the question in a slightly different way. You are proposing > that we expand the current text to explicitly identify multicast and > unicast traffic. Does that mean that you intend for the WG to exclude > broadcast traffic? > > The current text of the proposed charter is meant to be open to all sorts > of common network traffic. It is nonspecific about what those types of > traffic may be, to avoid giving anybody the impression that we are > limiting the WG work etc. What is the purpose of changing that? > > Thanks, > -Benson > > On Aug 30, 2014 5:22 PM, "ramki Krishnan" <[email protected]> wrote: > > Hi Benson, > > [ag] "The NVO3 WG will develop solutions for network virtualization > covering both unicast and multicast traffic handling based on the > following architectural tenets:” > > I agree with Linda’s observation and support Anoop’s suggestion for > the modified charter text. > > Thanks, > > Ramki > > From: nvo3 [mailto:[email protected]] On Behalf Of Benson > Schliesser > Sent: Friday, August 29, 2014 7:56 PM > To: [email protected] > Subject: [nvo3] Multicast issues draft > > Hi, Linda and Anoop - > > (I’ve changed the message Subject to more accurately describe this > topic.) > > On Aug 29, 2014, at 6:06 PM, Anoop Ghanwani <[email protected]> > wrote: > > [Linda] The entire charter didn't even mention application > initiated multicast. It is wrong. NVA can eliminate (or reduce) > ARP/ND related broadcast/multicast, but not application initiated > multicast. > > The current proposed MILESTONES have separate deliverables for WG > adoption and FOR IESG review, and very detailed categories being > explicitly spelled out. Therefore, at minimum, should have one > line on the protocols to handle hosts/applications initiated > multicast. > > [ag] I agree with Linda here. While it sounds like there is agreement > that the problem needs to be addressed by the working group, it would > be useful to at least have an explicit mention of multicast somewhere > in the charter. Perhaps we could change the following line from: > > "The NVO3 WG will develop solutions for network virtualization based > on the > > following architectural tenets:" > > to: > > "The NVO3 WG will develop solutions for network virtualization > covering both unicast and multicast traffic handling based on the > > following architectural tenets:” > > I’m not opposed to mentioning multicast in the charter, but t wouldn’t > be my preferred choice. > > The way that I think about it, multicast support is an appropriate > topic for the requirements drafts. And it should be discussed in the > architecture draft, as well as any solutions drafts where it might be > applicable. But it would be sub-optimal to load the charter with a > discussion of the various types of traffic that might be found in the > overlay: broadcast, known and unknown unicast, multicast supporting > network protocols (such as address resolution etc), multicast on > behalf of applications (“application specific multicast”), etc. > > The current charter text does not exclude work on multicast, which is > good. And I don’t see any reason to explicitly call it out as a unique > topic separate from the architecture, control plane, data plane, and > use cases. If I’m missing something please help me understand. > Otherwise I’d prefer to leave the proposed charter text as-is. > > Cheers, > > -Benson > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > > > [2 <text/plain; us-ascii (7bit)>] > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
