Thomas,
> > > > 3) Whether the underlying network can be assumed to support > > > > broadcast/multicast services. > > > > > > It cannot. At least, this is what everyone I've asked has said. > I.e., > > > use it if available and makes sense, but one cannot assume it's > > > present. There are numerous DCs where multicast is not supported. > > > Does this mean that a solution such as proposed in > > http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-01 is > > out of scope of nvo3? > > That's a pretty broadly worded question... :-) > > That document does assume that IP multicast is enabled in the > underlay, and to send traffic to all members of a given VNI, you would > would send to a corresponding IP multicast address on the underlay. > > Obviously, that part can't be counted on if the underlay doesn't > support multicast. > > So yes, that solution (IMO) cannot be assumed to be sufficient for > NVO3. Thanks for clarifying. The section 4.7 would have to be updated accordingly. I think it is important to state the assumptions about the properties (e.g., multicast support or, better, its lack of) of the underlying network in the problem statement draft. Maria _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
