What's wrong with (which I sent before): A virtual network (VN) behaves as a "Closed User Group" (CUG) of machines that are allowed to exchange traffic freely, while traffic between virtual networks is subject to access controls.
Maria > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Thomas Narten > Sent: Friday, September 28, 2012 9:09 AM > To: [email protected] > Subject: Re: [nvo3] What is CUG model was RE: Push or pull? > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
