Larry, I agree with your rewording proposal in the PS draft since part of the confusion comes from the fact that the PS draft uses the term "virtual network instance" as simply meaning a specific VN whereas both framework and dataplane reqs drafts define the term VNI as follows:
"A VNI is a specific VN instance on a NVE. Each VNI defines a forwarding context that contains reachability information and policies." While it seems that not everybody will agree to this definition, this term has been defined and used for the last 18 months to have the above meaning. If some words cause some confusion (e.g. "specific", "context"), I'm open to other suggestions... Marc > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Larry Kreeger (kreeger) > Sent: Monday, July 01, 2013 5:22 AM > To: Eric Gray; Lucy yong; Black, David; [email protected] > Subject: Re: [nvo3] Virtual Network - what's an instance? > > OK, I'll weigh in on this. > > The problem statement uses the non-capitalized phrase > "virtual network instance" to mean one specific virtual > network. It could just as well be replace with "a specific > virtual network". > > One way to fix to this is to change the problem statement to > either remove the word "instance" when it falls directly > after "virtual network", or replace the term "virtual network > instance" with "specific virtual network", or "instance of a > virtual network". > > > The framework is more precise in its definition of VNI. > Regardless of what the old or new definition is, let me quote > how the term is being used in the framework in a few places: > > "One or more VNIs can be instantiated on an NVE. Tenant > Systems interface with a corresponding VNI via a Virtual > Access Point (VAP)." > > "The VNI represents a set of configuration attributes > defining access and tunnel policies and (L2 and/or L3) > forwarding functions." > > "In a multi-tenant context, the tunnel aggregates frames from/to > different VNIs. Tenant identification and traffic > demultiplexing are based on the VN Context identifier (e.g., VNID)." > > This context seems consistent with the currently published > definition of term, regardless of what the new definition will be. > > Now regarding identifiers for a specific virtual network, the > framework has defined two related terms, VN Context and VNID, > defined as follows: > > "Virtual Network Context or VN Context: Field that is part of the > overlay encapsulation header which allows the > encapsulated frame to > be delivered to the appropriate virtual network endpoint by the > egress NVE. The egress NVE uses this field to determine the > appropriate virtual network context in which to > process the packet. > This field MAY be an explicit, unique (to the > administrative domain) > virtual network identifier (VNID) or MAY express the necessary > context information in other ways (e.g., a locally > significant identifier)." > > "VNID: Virtual Network Identifier. In the case where the VN context > identifier has global significance, this is the ID > value that is > carried in each data packet in the overlay > encapsulation that identifies the Virtual Network the packet > belongs to." > > So, it is the VN Context that maps within the NVE to a VNI (A > VNI is not the same as a VLAN ID, a VNID would be) and it > seems like it is up to the implementation of the NVE whether > it will allow different technologies to use the same context values. > > Also note that in draft-kreeger-nvo3-overlay-cp-04, the > following additional related terms are defined that may help > answer some of the questions I have seen raised in this thread. > > "VN Alias: A string name for a VN as used by administrators and > customers to name a specific VN. A VN Alias is a human-usable > string that can be listed in contracts, customer forms, email, > configuration files, etc. and that can be communicated easily > vocally (e.g., over the phone). A VN Alias is > independent of the > underlying technology used to implement a VN and will generally > not be carried in protocol fields of control protocols used in > virtual networks. Rather, a VN Alias will be mapped into a VN > Name where precision is required. > > "VN Name: A globally unique identifier for a VN suitable for use > within network protocols. A VN Name will usually be > paired with a > VN Alias, with the VN Alias used by humans as a shorthand way to > name and identify a specific VN. A VN Name should have > a compact > representation to minimize protocol overhead where a VN Name is > carried in a protocol field. Using a Universally Unique > Identifier (UUID) as discussed in RFC 4122 > <http://tools.ietf.org/html/rfc4122>, may work well because > it is both compact and a fixed size and can be generated locally > with a very high likelihood of global uniqueness." > > - Larry > > On 6/28/13 9:24 AM, "Eric Gray" <[email protected]> wrote: > > >Folks need to back up a bit. From the discussion, it > certainly looks > >like the definition in the framework draft has changed. In > my opinion, > >the changed version is in alignment with the usage in the problem > >statement draft. > > > >That seems to be a good thing. > > > >Folks in this thread are talking about several things: > >o What the definition was in the previous (currently > posted) version > > of the framework draft. > >o What the definition seems to be in the most up-to-date > version of > > the framework draft (soon to be posted/published?). > >o What the definition should be - according to a number > of different > > perspectives. > > > >There are a few too many variants of a definition for VNI being > >discussed for anyone to make much sense in the discussion to anyone > >else. Let's wait to see what the definition actually is, before we > >spin things out of control. > > > >By the way, IMHO, we don't really need definitions for state > maintained > >by a host in this respect. For one thing, the OS vendors > may want to > >take an exception to our telling them how to do what they > do. So it is > >unclear to me why we need a term to talk about this. > > > >Assuming we actually do need to do this (certainly > possible), I don't > >see why we cannot simply use the phrase "Host per-VNI state > >information." We could even allow that - from a host perspective - > >this may be equivalent to the term "VNI." > > > >-----Original Message----- > >From: [email protected] [mailto:[email protected]] > On Behalf Of > >Lucy yong > >Sent: Friday, June 28, 2013 11:49 AM > >To: Black, David; [email protected] > >Subject: Re: [nvo3] Virtual Network - what's an instance? > > > >So this is because that the problem statement already uses it for > >different meaning. > > > >Should the framework draft support the consistency to L2VPN/L3VPN or > >the > >nvo3 problem statement? > >L2/L3VPN documents were generated much early without the description > >issues. > > > >Regards, > >Lucy > > > >> -----Original Message----- > >> From: Black, David [mailto:[email protected]] > >> Sent: Friday, June 28, 2013 10:39 AM > >> To: Lucy yong; [email protected] > >> Cc: Black, David > >> Subject: RE: Virtual Network - what's an instance? > >> > >> HI Lucy, > >> > >> Short answer: the problem statement draft's use of > "virtual network > >> instance" > >> and much of the discussion here (including Eric's note below) does > >> not limit the scope of "virtual network instance" (VNI) to > "on a device". > >> > >> The framework draft needs a term for that concept (portion of a > >> specific virtual network that is on a specific device") and as of > >> now, "virtual network instance" has been taken by the problem > >> statement draft with a broader meaning, making VNI > problematic for that purpose. > >> > >> IMHO, We need to decide whether a "virtual network instance" is > >> limited to "on a device" or not and modify the problem > statement or > >> framework draft accordingly. > >> > >> Thanks, > >> --David > >> > >> > -----Original Message----- > >> > From: [email protected] [mailto:[email protected]] On > >> > Behalf > >> Of Lucy > >> > yong > >> > Sent: Friday, June 28, 2013 10:44 AM > >> > To: Eric Gray; smith, erik; Joe Pelissier (jopeliss); > [email protected] > >> > Subject: Re: [nvo3] Virtual Network - what's an instance? > >> > > >> > Here is my 2cent. > >> > > >> > Why do we now run into the language and term conflict > issue in nvo3? > >> > > >> > We used similar terms such as VSI, VFI, VRI etc in L2VPN > and L3VPN > >> before to > >> > present multiple xx instances on a device. There are > many documents > >> developed > >> > in L2VPN and L3VPN WGs. We did not have problem there. > >> > > >> > Regards, > >> > Lucy > >> > > >> > > >> > > >> > > >> > > -----Original Message----- > >> > > From: [email protected] [mailto:[email protected]] On > >> Behalf Of > >> > > Eric Gray > >> > > Sent: Friday, June 28, 2013 6:51 AM > >> > > To: smith, erik; Joe Pelissier (jopeliss); [email protected] > >> > > Subject: Re: [nvo3] Virtual Network - what's an instance? > >> > > > >> > > Erik, > >> > > > >> > > Well, one issue is that we would minimally need to > include "VNI" > >> > > in > >> an > >> > > acronym expansion. I believe we can all agree that > the English > >> > > language interpretation of "instance" fits the way we > are using > >> > > it. But > >> this > >> > > may > >> > > not be important enough to worry about, given how late in the > >> > > cycle > >> we > >> > > are in discussing this WRT to framework draft, and - if the > >> > > English usage is correct - then the "definition" is > also correct. > >> > > > >> > > In fact, it would have been nice if we could have used the > >> > > acronym > >> VNI > >> > > instead of spelling it out in the problem statement draft. It > >> might > >> > > have > >> > > been a whole page shorter. > >> > > > >> > > For many of us, there is a reason to distinguish a VN > from a VNI. > >> > > > >> > > For instance, in talking about the various approaches > that might > >> > > be used to implement virtual network overlays, one > might use the > >> > > phrase "specific VN" to mean a VN of a specific type, but not > >> > > necessarily a specific > >> VNI. > >> > > > >> > > A specific VN might - for instance - be a VLAN, or an > IP subnet, > >> > > without being a specific instance of either. Therefore, it is > >> > > possible to distinguish a "specific VN" from a "specific VNI." > >> > > > >> > > Either a VN, or a VNI may be implemented using BGP/MPLS VPNs, > >> > > VPLS, NVGRE, etc. In the VN case, we may talk about the > >> technology/approach > >> > > used while in the VNI case, were talking about a specific VN > >> instance. > >> > > > >> > > Your reference to "VNID" below doesn't help and may be an > >> illustrative > >> > > example of why the distinction is needed. For some approaches > >> > > that > >> may > >> > > be used, the technology provides its own "VNID" while > for others, > >> > > either the way that the VN would otherwise be > identified is more > >> complicated > >> > > than desired (hence a numerical identifier that maps to a more > >> complex > >> > > real identification may be useful), or there isn't a way to > >> identify a > >> > > VN of > >> > > that type at present (so we invent one). > >> > > > >> > > A VN of a certain type may be identified by a VNID of a certain > >> type. > >> > > A VNI > >> > > is identified by a specific VNID for its associated type. > >> > > > >> > > -- > >> > > Eric > >> > > > >> > > -----Original Message----- > >> > > From: smith, erik [mailto:[email protected]] > >> > > Sent: Thursday, June 27, 2013 6:49 PM > >> > > To: Eric Gray; Joe Pelissier (jopeliss); [email protected] > >> > > Subject: RE: Virtual Network - what's an instance? > >> > > Importance: High > >> > > > >> > > Ha..that's funny... I was going to complement you on your > >> > > correct spelling (because it's the way the everyone spells my > >> > > name by default)! :-) > >> > > > >> > > To borrow your format: > >> > > > >> > > Specific VNs (i.e. - VN instances) are identified by a VNID > >> (Virtual > >> > > Network ID) > >> > > > >> > > My point is, if the statement "VLAN 41 may be an > instance of the > >> VLAN > >> > > concept" is technically correct (and I believe it is), > then why > >> > > wouldn't "VN 41 may be an instance of the VN concept", "the > >> tenant's > >> > > VN" or "there's a problem with VN 41" also be acceptable? Why > >> should > >> > > we have to append "I" to "VN" in each case? If the > answer is "we > >> > > don't", then can anyone provide a specific scenario where VNI > >> > > must > >> be > >> > > used? > >> > > > >> > > Regards, Erik > >> > > > >> > > > >> > > -----Original Message----- > >> > > From: Eric Gray [mailto:[email protected]] > >> > > Sent: Thursday, June 27, 2013 4:28 PM > >> > > To: smith, erik; Joe Pelissier (jopeliss); [email protected] > >> > > Subject: RE: Virtual Network - what's an instance? > >> > > > >> > > Erik, > >> > > > >> > > Weird talking to someone whose name is > "correctly spelled" > >> > > according to most of my Ericsson colleagues - which is already > >> strange > >> > > enough. :-) > >> > > > >> > > Specific VLANs (i.e. - VLAN instances) are > identified by a VID > >> > > (VLAN ID). > >> > > Specific IP subnets (i.e. - IP Subnet instances) are > identified > >> > > in > >> a > >> > > somewhat more complicated way. > >> > > > >> > > If we need to talk about generic concepts, we need to > >> > > differentiate the generic concept of a virtual network from the > >> equally > >> > > generic concept of a specific instance of a virtual network. > >> > > > >> > > -- > >> > > Eric > >> > > > >> > > -----Original Message----- > >> > > From: smith, erik [mailto:[email protected]] > >> > > Sent: Thursday, June 27, 2013 4:11 PM > >> > > To: Eric Gray; Joe Pelissier (jopeliss); [email protected] > >> > > Subject: RE: Virtual Network - what's an instance? > >> > > Importance: High > >> > > > >> > > Eric, if VNI is required to describe an instance of a VN, why > >> > > isn't VLANI required to describe an instance of a VLAN? > >> > > > >> > > Regards, Erik > >> > > > >> > > -----Original Message----- > >> > > From: [email protected] [mailto:[email protected]] On > >> Behalf Of > >> > > Eric Gray > >> > > Sent: Thursday, June 27, 2013 3:51 PM > >> > > To: Joe Pelissier (jopeliss); [email protected] > >> > > Subject: Re: [nvo3] Virtual Network - what's an instance? > >> > > > >> > > Joe, > >> > > > >> > > At the end of the day, every definition is > either a tautology, > >> > > or it is wrong. > >> > > > >> > > As one of my colleagues has put it, a VN is a > concept and a VNI > >> > > is a realization of the concept. > >> > > > >> > > VLAN 41 may be an instance of the VLAN concept. > >> > > > >> > > The subnet associated with a router interface > IP address and its > >> > > associated net-mask is an instance of the IP subnet concept. > >> > > > >> > > A VN is intended to be a generic concept that > includes multiple > >> > > virtual-network types. A VNI is an instance (or > realization?) of > >> > > a > >> VN. > >> > > > >> > > -- > >> > > Eric > >> > > > >> > > -----Original Message----- > >> > > From: [email protected] [mailto:[email protected]] On > >> Behalf Of > >> > > Joe Pelissier (jopeliss) > >> > > Sent: Wednesday, June 19, 2013 6: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:marc.lasserre@alcatel- > >> lucent.com] > >> > > > 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 > >_______________________________________________ > >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
