This discussion is interesting, but I still have not seen an answer to the question: what is (or is there) a difference between a VN and an CUG?
If there is no difference, that would be great, because then we can use the terms interchangably. If there are differences, we need to understand what those differences are, or there will be confusion in our discussions. Yakov Rekhter <[email protected]> writes: > There is a definition of L2-based CUG in > draft-rekhter-nvo3-vm-mobility-issues That definition appears to be: > Consider a set of VMs that (as a matter of policy) are allowed to > communicate with each other, and a collection of devices that > interconnect these VMs. If communication among any VMs in that set > could be accomplished in such a way as to preserve MAC source and > destination addresses in the Ethernet header of the packets exchanged > among these VMs (as these packets traverse from their sources to > their destinations), we will refer to such set of VMs as an Layer 2 > based Closed User Group (L2-based CUG). This defines an L2 CUG, but not a CUG generally. That said, my read of he above is that a CUG is nothing more than "a set of VMs that (as a matter of poliocy) are allowed to communicate with each other". That sure sounds like what I thought a VN is. Interesting, the draft-ietf-nvo3-framework-00.txt.p7s doesn't seem to even define VN (oops). draft-ietf-nvo3-overlay-problem-statement-00.txt says: > To end stations, a virtual network looks like a normal network > (e.g., providing an ethernet or L3 service), except that the only > end stations connected to the virtual network are those belonging > to a tenant's specific virtual network. My assumption has always been that VN is the set of machines that (by policy) are allowed to talk to each other. Communication with machins outside of a VN takes place outside of NVO3, i.e., by (at least conceptually) going outside of the VN, having policy applied (as appropriate) and then (if policy allows) forwarding to another VN. I.e., analogous to forwarding between VLANs where one has to go through L3. Kireeti Kompella <[email protected]> writes: > > In offlist discussions I've had, I've come to the conclusion that a > > CUG is the same thing as a VN. That is, it's a set of machine that are > > administratively placed into a group and are allowed to communicate > > with each other, but not with others outside of that CUG. > > > > Correct? > Almost. Entities inside a CUG may communicate to entities outside > through a policy specified by the appropriate administrator. the > default policy is as you say: no communication. I think we are in complete agreement here. Although I say that to go from one VN to another one must (conceptually) go out of the VN, one can certainly optimize that case and (if policy allows) have direct tunneling from a VM in one VN to a VM in another. But the fundamental notion of a VN (and from what I can tell, a CUG) is that it is a set of machines that are part of a single administrative group/network and that are allowed to talk to each other, and that normally do not talk to machines in other VNs. > > And, RFC 4364 says: > Essentially, RFC 4364 defined an L3 CUG, RFC 4364 has this for a definition: > Suppose it is desired to create a fully meshed closed user group, > i.e., a set of sites where each can send traffic directly to the > other, but traffic cannot be sent to or received from other > sites. > and the EVPN draft an L2 CUG. What draft would that be? Neither draft-ietf-l2vpn-evpn-req-00.txt nor draft-ietf-l2vpn-evpn-01.txt use the term "closed" or "CUG". Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
