Benson, I've got a bit of experience when it comes to drafting WG charters. :-) Especially when working on the milestones, it helps to envision the expectations for the documents that will be produced by the WG, as there tends to be a direct correspondence between documents and milestones, so that milestones can be ticked off as documents are published. There are currently a couple of multicast-related individual drafts intended for the WG, however In the current draft charter, there are no specific milestones related to multicast. If there is a reasonable expectation that at least one of these drafts will be adopted by the WG and be published as a stand-alone document, then there should probably be a corresponding milestone in the charter to track that work.
Thanks, Andy On Mon, Sep 1, 2014 at 6:42 PM, Anoop Ghanwani <[email protected]> wrote: > 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 > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
