Hi Larry, thanx a lot for trying to pull together the root causes of this almost babylonic mess.
While discussing how to resolve it, please also consider the following additional problems: 1. Definition of the term "specific VN" appears to be ambigous, as it may mean to some a specific type of VN and to others a specific instance of a VN. 2. Definition of the term "context" appears to problematic, as it may be interpreted either as information contained in a PDU, or as state information contained in an NVE or at least as something active that can perform some mapping. 3. The statement "In a multi-tenant context, the tunnel aggregates frames from/to different VNIs" appears to suggest an assumed one to one relation between tenant or tenant system and VNI. This is of course not the case, as a single tenant usually employs multiple VNIs per tenant system, e.g. as a minimum one for management access and one for user access. So this statement seems to be misleading, because also in a single tenant context, the tunnel may aggregate frames from/to different VNIs. 4. The term "locally significant" is being used in definitions, but not defined. Does it mean - local to an NVE? Local to an AS? Local to an administrative domain? Local to the medium/virtual network segment between the VAP in the NVE and the tenant system interface? Please see also my comments inline below, which I have indented with >> Lothar -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Larry Kreeger (kreeger) Gesendet: Montag, 1. Juli 2013 05:22 An: Eric Gray; Lucy yong; Black, David; [email protected] Betreff: 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". >>Lothar: relocating the problem from the word "instance" to the word >>"specific" does not really help, because some ambiguity remains about whether >>"specific" VN >>refers to a specific type of VN or to a specific instance of >>a VN. 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)." >>Lothar: Problem is, that there no separate term introduced for a portion of a >>VNI, that is instantiated on an NVE. Second problem is, that the formulation >>>>suggests a one to one relation between Tenant System and VNI, usually one >>tenant system is attached to multiple VNIs, e.g. as a minimum different VNIs >>for >>management traffic and user traffic "The VNI represents a set of configuration attributes defining access and tunnel policies and (L2 and/or L3) forwarding functions." >>Lothar: problem is, that this definition does not say, if the set is >>comprising the configuration attributes and tunnels policies on all NVEs >>belonging to the VN, >>or if it refers only to the subset of configuration >>attributes defining access and tunnel policies on a specific NVE - but then a >>new term such as the term VNLI >>should have been introduced "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)." >>Lothar: First problem is, that the word "context" and "Context" refer to >>different things, and that the author apparently may have erroneously >>assumed, that >>there is a one to one relation between tenant and VN. Second >>problem is, that a new "VN Context identifier" gets introduced but not >>defined, but an example given >>that is yet again another term. Third >>problem is, that the statement suggests that a single method may be available >>for tenant identification and for traffic >>demultiplexing - perhaps again >>because the author may have erroneously assumed a one to one relation between >>tenant and VN. This is of course not true, as it >>must be possible to >>demultiplex directly from a header field, but tenant identification is not >>directly possible, only by resolving in a database who is the owner >>of the >>VN. This context seems consistent with the currently published definition of term, regardless of what the new definition will be. >> Which context are you referring to here? The multi-tenant context which is >> quite useless, as in a datacenter we will always have multi-tenant context. >> Or to the >>"Context" in the header of a frame, or to a "context" >> representing a state in an NVE? Now regarding identifiers for a specific virtual network, the framework has defined two related terms, VN Context and VNID, defined as follows: >> Which meaning of "specific VN" are you referring to here? A specific type of >> VN or a specific instance of a VN? "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." >>Lothar: Sorry, but this again is very problematic, as I do not know a single >>example of a globally significant VN context identifier in a format that >>would fit in >>a header. I would say this is technically impossible, or does >>this propose to carry a UUID in each transport layer PDU header? 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. >>Lothar: here the word "maps" is problematic, as it is the subject in this >>sentence. How can a header field "VN Context" become active and map something >>a device >>to a virtual network instance? In my view, it is the NVE that maps >>the VN Context to a VNI. 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." >>Lothar: problematic is, that we now have 3 terms to identify a specific >>instance of a VN: VNI, VN-Name, VN Alias >>plus some term "VN Context" - which is confusingly defined both as a meta >>term and as part of a header: according to above definition 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) - 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
