Subject: Re: [nvo3] Virtual Network - what's an instance?

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 1 Jul 2013 09:20:43 +0000

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-masked] [mailto:[email-masked]] Im Auftrag von Larry Kreeger (kreeger)
Gesendet: Montag, 1. Juli 2013 05:22
An: Eric Gray; Lucy yong; Black, David; [email-masked]
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-masked]> 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-masked] [mailto:[email-masked]] On Behalf Of
>Lucy yong
>Sent: Friday, June 28, 2013 11:49 AM
>To: Black, David; [email-masked]
>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-masked]]
>> Sent: Friday, June 28, 2013 10:39 AM
>> To: Lucy yong; [email-masked]
>> 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-masked] [mailto:[email-masked]] On Behalf
>> Of Lucy
>> > yong
>> > Sent: Friday, June 28, 2013 10:44 AM
>> > To: Eric Gray; smith, erik; Joe Pelissier (jopeliss); [email-masked]
>> > 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-masked] [mailto:[email-masked]] On
>> Behalf Of
>> > > Eric Gray
>> > > Sent: Friday, June 28, 2013 6:51 AM
>> > > To: smith, erik; Joe Pelissier (jopeliss); [email-masked]
>> > > 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-masked]]
>> > > Sent: Thursday, June 27, 2013 6:49 PM
>> > > To: Eric Gray; Joe Pelissier (jopeliss); [email-masked]
>> > > 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-masked]]
>> > > Sent: Thursday, June 27, 2013 4:28 PM
>> > > To: smith, erik; Joe Pelissier (jopeliss); [email-masked]
>> > > 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-masked]]
>> > > Sent: Thursday, June 27, 2013 4:11 PM
>> > > To: Eric Gray; Joe Pelissier (jopeliss); [email-masked]
>> > > 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-masked] [mailto:[email-masked]] On
>> Behalf Of
>> > > Eric Gray
>> > > Sent: Thursday, June 27, 2013 3:51 PM
>> > > To: Joe Pelissier (jopeliss); [email-masked]
>> > > 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-masked] [mailto:[email-masked]] On
>> Behalf Of
>> > > Joe Pelissier (jopeliss)
>> > > Sent: Wednesday, June 19, 2013 6:29 PM
>> > > To: [email-masked]
>> > > 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-masked] [mailto:[email-masked]] On
>> Behalf Of
>> > > Black, David
>> > > Sent: Wednesday, June 19, 2013 7:48 AM
>> > > To: LASSERRE, MARC (MARC)
>> > > Cc: [email-masked]
>> > > 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-masked]
>> > > > 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-masked] [mailto:[email-masked]] On
>> > > Behalf
>> > > > > Of Black, David
>> > > > > Sent: Wednesday, June 19, 2013 1:24 AM
>> > > > > To: [email-masked]
>> > > > > 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-masked]        Mobile: +1 (978) 394-7754
>> > > > > ----------------------------------------------------
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > nvo3 mailing list
>> > > > > [email-masked]
>> > > > > https://www.ietf.org/mailman/listinfo/nvo3
>> > > > >
>> > > _______________________________________________
>> > > nvo3 mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/nvo3
>> > > _______________________________________________
>> > > nvo3 mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/nvo3
>> > > _______________________________________________
>> > > nvo3 mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/nvo3
>> > >
>> > >
>> > > _______________________________________________
>> > > nvo3 mailing list
>> > > [email-masked]
>> > > https://www.ietf.org/mailman/listinfo/nvo3
>> > _______________________________________________
>> > nvo3 mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/nvo3
>
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Mon, 1 Jul 2013 13:15:57 +0000

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

> Behalf Of Larry Kreeger (kreeger)
> Sent: Monday, July 01, 2013 5:22 AM
> To: Eric Gray; Lucy yong; Black, David; [email-masked]
> 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."
> 
>        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:
> 
>        context information in other ways (e.g., a locally 
> significant identifier)."
> 
>        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.
> 
> >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.
> >
> >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."
> >
> >> 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".
> >> 
> >> 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.
> >> 
> >> > > 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 IP subnets (i.e. - IP Subnet instances) are 
> identified 
> >> > > in
> >> a
> >> > > 	At the end of the day, every definition is 
> either a tautology, 
> >> > > or it is wrong.
> >> > >
> >> > > > >        a given NVE. Two Virtual Networks are isolated from 
> >> > > > > one another and
> >> > > > >        local state and associated processing for a 
> given VN 
> >> > > > > on
> >> a
> >> > > given

---

From: Lucy yong <[email-masked]>
Date: Mon, 1 Jul 2013 14:11:38 +0000

+1

> From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
> Sent: Monday, July 01, 2013 8:16 AM
> To: Larry Kreeger (kreeger); Eric Gray; Lucy yong; Black, David;
> [email-masked]
> Subject: RE: [nvo3] Virtual Network - what's an instance?
> 
> 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.
>