Benson, Broadcast is usually a special case of multicast, so by including multicast, we would have automatically included broadcast (at least that's the way I see it).
If, as you suggest, multicast is already within scope because we haven't explicitly excluded it, then I'm fine with the charter text. 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 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
