Marc, The following was the sentence in question.
"The flooding tree is equivalent with a multicast (*,G) construct where all the NVEs where the corresponding VNI is instantiated are members." "(*,G) construct" doesn't deliver any precise meaning. One could interpret it as "ASM" while another could read it as "PIM shared tree" state. Neither would sever well in this document. My point was that it is better to describe the requirement from the POV of the multicast service model. This is especially important if an NVE is considered as a host and not part of the L3 data center network. The volume of IP multicast traffic in today's data center network is not "0". Whether it would go towards 0 or away from it is a good question. I'm not sure our speculation of its moving direction will help to determine the MUST/SHOULD/MAY requirement of the service models. A detailed analysis is more useful and IETF can certainly help here. By the way, some portion of my day job is indeed related to operating DC/Cloud. But I'm commenting as an individual IETF participant, and *NOT* on behalf of my previous or current employers ;) Thanks. -- Yiqun From: LASSERRE, MARC (MARC) [mailto:[email protected]] Sent: Tuesday, May 22, 2012 1:22 AM To: Yiqun Cai; AshwoodsmithPeter; [email protected] Subject: RE: New dataplane requirements draft Yiqun, The draft does not refer specifically to (*,G) or (S,G) except for section 3.2.1 which explains that BUM traffic needs to be handled for L2 NVEs. When multicast is not enabled, ingress replication is required. As Peter asked in his mail, let's hear from DC/Cloud operators whether multicast is a MAY or a MUST. So far, it seems to be a soft requirement i.e. a MAY and not a MUST. Marc ________________________________ From: Yiqun Cai [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Monday, May 21, 2012 11:14 PM To: AshwoodsmithPeter; LASSERRE, MARC (MARC); [email protected]<mailto:[email protected]> Subject: RE: New dataplane requirements draft The document should not refer to either (*,G) or (S,G). Instead, it should specify whether an ASM or SSM multicast service model is to be desired from the point of view of an NVE, and what happens if neither multicast service model is available. -- Yiqun From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf Of AshwoodsmithPeter Sent: Friday, May 18, 2012 7:30 AM To: LASSERRE, MARC (MARC); [email protected]<mailto:[email protected]> Subject: Re: [nvo3] New dataplane requirements draft Concerning the 'SHOULD' for (*,G) in the underlay: What percentage of traffic in a DC (cloud or enterprise etc.) is actually non BUM/ARP multicast between VMs? Who has actual data that does not include BUM/ARP (which has to be solved with distributed control for these scales)? We heard from some big DC/Cloud folks that they explicitly disable multicast by applications ... so clearly for them its 0. If it is in general a very very low percentage, then should we not drop (*,G) as a requirement of the underlay? This work could set the tone for DC/Cloud based applications for years to come and perhaps the applications would be better served by a reliable distributed control mechanism. Peter P.S. As a networking person I love the challenges of (*,G) (S,G) trees so I'm biased but objectively I'd like to understand exactly where the requirement is coming from to see if it is not better addressed by distributed control. ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]]<mailto:%5bmailto:[email protected]%5d> On Behalf Of LASSERRE, MARC (MARC) Sent: Thursday, May 17, 2012 4:32 AM To: [email protected]<mailto:[email protected]> Subject: [nvo3] New dataplane requirements draft We have just posted a new draft on nvo3 data plane requirements: http://www.ietf.org/id/draft-bitar-lasserre-nvo3-dp-reqs-00.txt We welcome your feedback. Our intent is to submit a revised version by Vancouver addressing your comments and/or suggestions. Thanks, Marc
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
