Here is my thought. Use "a virtual network (VN)" to describe the virtual network function and behavior. For example, create one VN or two VNs.
Use "VNI, i.e. virtual network instance" to model that one NVE is the member in multiple virtual networks. Thus, VN and VNI has one-on-one relationship. It is important to model NVE with following characteristics: TSs attached to the same NVE may belong to the same or different virtual networks. A TS attached to an NVE may participate one or more virtual networks. An NVE has the corresponding VNIs for the virtual networks that attached TSs belong to. It is also important to differentiate the virtual network and tenant network. One tenant network may contain one or more virtual networks. Lucy > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Reith, Lothar > Sent: Friday, June 21, 2013 7:39 AM > To: Joe Pelissier (jopeliss); [email protected] > Subject: Re: [nvo3] Virtual Network - what's an instance? > > My 2 cents: > > For a network centric engineer, there may not be a difference between a > virtual network and a virtual network instance. > > For a compute centric engineer (such as those creating the virtual > networks via a Quantum API in OpenStack), there may very well be a > fundamental difference as he may associate with " virtual network" a > class, and with "virtual network instance" an object. > > One key problem in IETF is, that key terms often may be loosely defined. > I am afraid, that this may be just happening again (similar and related > also with the term CUG). > > Can someone please come up with a UML cardinality diagram, which > explains the relation between VN, VNI, and CUG? > > Or tell us their view regarding which of the following statements are > true: > > 1. There is always a one to one relation between VN and VNI (therefore > the terms are actually synonymous and can be harmonized to VN) > 2. There is always a 1 to n relation between VN and VNI (like between > Class and object) > 3. There is always a one to one relation between a VN and a CUG > 4. There may be a 1:n relation between CUG and VN, i.e. the members of > one CUG may be network endpoints (devices/stations/station > interfaces/NICs/vNICs) in multiple VNs (or VNIs?) > 5. There may be a 1:n relation between VN and CUG, i.e. a VN may have > network endpoints which are members of multiple CUGs > 6. There may be an n:m relation between CUG and VN, because both 4 and > 5 are true statements. > > Lothar > > > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im Auftrag > von Joe Pelissier (jopeliss) > Gesendet: Donnerstag, 20. Juni 2013 20:00 > An: [email protected] > Betreff: Re: [nvo3] Virtual Network - what's an instance? > > Ok, that seems to make sense, but in this case, VN Instance does not > need to be a defined term. I.e., VN is defined, and "instance" has its > normal English meaning. So maybe keep the definition of "Virtual > Network", delete the definition for "Virtual Network Instance", and in > the text use "Virtual Network instance" instead of "Virtual Network > Instance". > > Still, I doubt that there is any place that the term "Virtual Network > Instance" is used that could not be replaced with "Virtual Network" > since the singular form of VN is, by definition, an instance. Adding > the extra word "instance" may make the intent more clear in some cases; > after all, we are network engineers, so we are always promoting > redundancy :-). > > Cheers, > Joe Pelissier > > > -----Original Message----- > From: Dave Hood [mailto:[email protected]] > Sent: Thursday, June 20, 2013 6:00 AM > To: Joe Pelissier (jopeliss); [email protected] > Subject: RE: Virtual Network - what's an instance? > > Right. > > The point is that, to the client, the idea of instance is irrelevant > because there is only one. > > On the other hand, the server instantiates a separate VN for each > client, a total of zero or more, depending on the number of clients, so > VN instances are an essential concept to the server. > > Dave > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Joe Pelissier (jopeliss) > Sent: Wednesday, June 19, 2013 7:55 PM > To: [email protected] > Subject: Re: [nvo3] Virtual Network - what's an instance? > > Hi Dave, > Maybe I could rephrase your last sentence: > "....From the server's point of view, there are as many VNs as there > are clients." > This appears to have the same meaning as your sentence, which seems to > indicate the terms are synonymous. > > Cheers, > Joe > > -----Original Message----- > From: Dave Hood [mailto:[email protected]] > Sent: Wednesday, June 19, 2013 4:03 PM > To: Joe Pelissier (jopeliss); [email protected] > Subject: RE: Virtual Network - what's an instance? > > IMO, a virtual network is the set of [network] resources exposed by a > server to a client. From the client's point of view, there is only one > VN. From the server's point of view, there are as many VNIs as there > are clients. > > Would that be a useful way to describe the difference? > > Dave > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Joe Pelissier (jopeliss) > Sent: Wednesday, June 19, 2013 3:29 PM > To: [email protected] > Subject: Re: [nvo3] Virtual Network - what's an instance? > > Maybe it's just me, but the definition of VNI does not seem useful: > > "Virtual Network Instance (VNI): A specific instance of a VN." > If someone did not understand what a Virtual Network Instance is, then > simply adding the word "specific" does not help much. Essentially, a > VNI is a VN - the terms appear synonymous, so it would be best to > simply eliminate the VNI term. > > My $0.02 worth... > Joe Pelissier > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Black, David > Sent: Wednesday, June 19, 2013 7:48 AM > To: LASSERRE, MARC (MARC) > Cc: [email protected] > Subject: Re: [nvo3] Virtual Network - what's an instance? > > Marc, > > Good - that'll work well, and I'm assuming that you'll bring the rest > of the draft into line, as there is usage of the VNI acronym to refer > to the NVE-local portion of a VN (what I refer to as VNLI below). > > Thanks, > --David > > > -----Original Message----- > > From: LASSERRE, MARC (MARC) [mailto:[email protected]] > > Sent: Wednesday, June 19, 2013 3:54 AM > > To: Black, David > > Cc: [email protected] > > Subject: RE: Virtual Network - what's an instance? > > > > Hi David, > > > > In the soon-to-be-published revision of the framework draft, the VN & > > VNI definitions stand as: > > > > Virtual Network (VN): A VN is a logical abstraction of a physical > > network that provides L2 or L3 network services to a set of Tenant > > Systems. A VN is also known as a Closed User Group (CUG). > > > > Virtual Network Instance (VNI): A specific instance of a VN. > > > > I think that this addresses your concern. > > > > Marc > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > > Of Black, David > > > Sent: Wednesday, June 19, 2013 1:24 AM > > > To: [email protected] > > > Subject: [nvo3] Virtual Network - what's an instance? > > > > > > In working on some control plane draft material, I've run across an > > > inconsistency in the use of the concept of a "virtual network > > > instance" > > > (or VNI) between the problem statement and framework drafts. > > > > > > The problem statement draft does not define "virtual network > instance" > > > and uses that term more or less interchangeably with "virtual > network" > > > to refer to a specific virtual network. Here's an example with > both > > > terms used in the same sentence near the top of p.5: > > > > > > A key requirement is that each > > > individual virtual network instance be isolated from other > virtual > > > network instances, with traffic crossing from one virtual > network > > > to > > > another only when allowed by policy. > > > > > > The framework draft defines Virtual Network Instance (VNI) as > > > effectively being the portion of a virtual network that is > > > instantiated in an NVE: > > > > > > VNI: Virtual Network Instance. This is one instance of a > > > virtual > > > overlay network. It refers to the state maintained for a > > > given VN on > > > a given NVE. Two Virtual Networks are isolated from one > > > another and > > > may use overlapping addresses. > > > > > > Something's wrong here. Back in February, Thomas Narten proposed > > > that we use the problem statement terminology consistently in the > > > framework draft, but there hasn't been any further discussion. > > > > > > Speaking for myself, the problem statement draft's usage seems more > > > intuitive (an "instance" of a virtual network is a virtual network, > > > not part of one, as is the case in the framework draft), but we've > > > had the VNI acronym around in the framework draft for a good long > > > time now. > > > > > > If it were ok to change the framework draft, I would prefer: > > > > > > VNLI: Virtual Network Local Instance. This is an instance > of a > > > virtual overlay network on a specific NVE. The VNLI refers to > the > > > local state and associated processing for a given VN on a > given > > > NVE. Within an NVE, VNLIs are isolated from one another and > > > may use overlapping network addresses. > > > > > > But that's just my 0.02 - what should be done about this? > > > > > > Thanks, > > > --David > > > ---------------------------------------------------- > > > David L. Black, Distinguished Engineer EMC Corporation, 176 South > > > St., Hopkinton, MA 01748 > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > [email protected] Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
