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
