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
