David,
The problem statement draft does not use the term VNI, at all.
I was surprised to hear you say this, so I checked. :-)
The PS draft does use the phrase "virtual network instance" (a lot) -
but it uses the term in the sense of distinguishing the concept of a "virtual
network" from a specific virtual network (in fact, the words "each",
"specific",
"particular", "different" and/or "individual" are frequently - if not
consistently
- used with the phrase).
There are some cases where the phrase "virtual network instance"
could arguably have been replaced with "virtual network" - but that would
very likely have provoked argument in return.
--
Eric
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Black,
David
Sent: Saturday, June 22, 2013 3:28 PM
To: Reith, Lothar; [email protected]
Cc: Black, David
Subject: Re: [nvo3] Virtual Network - what's an instance?
> > Can someone please come up with a UML cardinality diagram, which
> > explains the relation between VN, VNI, and CUG?
Please don't :-). Here's my 0.02 ... :
a) VN and VNI (spelled out) are used interchangeably in the problem statement
draft. I think it's a bad idea to split hairs to try to distinguish those
terms, and I definitely don't want to rewrite the problem statement draft to
make that distinction.
b) CUG appears to be a term from BGP/MPLS L3VPN space that should be used only
with such L3VPNs, not more generally. NVO3 has settled on VN as the basic
solution-independent concept, and I think CUG only adds confusion (e.g., as
demonstrated by Lothar's message). Let's stick with VN.
c) The Framework draft needs a new term to identify the portion of a VN that
exists in an NVE, as VNI should not be used for that purpose - see a) above.
That new term is not VAP, because VAP is a port abstraction, not a network
abstraction, and we need a port abstraction to identify the entity to which
TS's are connected (i.e., a TS is connected to a VAP, possibly multiple VAPs).
In private email, I've suggested VNLI (Virtual Network Local Instance) for c) -
while I'm not strongly attached to the term, I like the use of the word "local"
to make it clear that this term designates a subset of a VN, and is specific to
an NVE.
Thanks,
--David
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Linda Dunbar
> Sent: Friday, June 21, 2013 10:16 PM
> To: Reith, Lothar; Joe Pelissier (jopeliss); [email protected]
> Subject: Re: [nvo3] Virtual Network - what's an instance?
>
> My 2 cents:
>
> One virtual network may have multiple IDs.
>
> Linda
>
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Reith, Lothar
> > Sent: Friday, June 21, 2013 7:39 AM
> > To: Joe Pelissier (jopeliss); [email protected]
> > Subject: Re: [nvo3] Virtual Network - what's an instance?
> >
> > My 2 cents:
> >
> > For a network centric engineer, there may not be a difference
> > between a virtual network and a virtual network instance.
> >
> > For a compute centric engineer (such as those creating the virtual
> > networks via a Quantum API in OpenStack), there may very well be a
> > fundamental difference as he may associate with " virtual network" a
> > class, and with "virtual network instance" an object.
> >
> > One key problem in IETF is, that key terms often may be loosely defined.
> > I am afraid, that this may be just happening again (similar and
> > related also with the term CUG).
> >
> > Can someone please come up with a UML cardinality diagram, which
> > explains the relation between VN, VNI, and CUG?
> >
> > Or tell us their view regarding which of the following statements
> > are
> > true:
> >
> > 1. There is always a one to one relation between VN and VNI
> > (therefore the terms are actually synonymous and can be harmonized
> > to VN) 2. There is always a 1 to n relation between VN and VNI (like
> > between Class and object) 3. There is always a one to one relation
> > between a VN and a CUG 4. There may be a 1:n relation between CUG
> > and VN, i.e. the members of one CUG may be network endpoints
> > (devices/stations/station
> > interfaces/NICs/vNICs) in multiple VNs (or VNIs?) 5. There may be a
> > 1:n relation between VN and CUG, i.e. a VN may have network
> > endpoints which are members of multiple CUGs 6. There may be an n:m
> > relation between CUG and VN, because both 4 and
> > 5 are true statements.
> >
> > Lothar
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: [email protected] [mailto:[email protected]] Im Auftrag
> > von Joe Pelissier (jopeliss)
> > Gesendet: Donnerstag, 20. Juni 2013 20:00
> > An: [email protected]
> > Betreff: Re: [nvo3] Virtual Network - what's an instance?
> >
> > Ok, that seems to make sense, but in this case, VN Instance does not
> > need to be a defined term. I.e., VN is defined, and "instance" has
> > its normal English meaning. So maybe keep the definition of
> > "Virtual Network", delete the definition for "Virtual Network
> > Instance", and in the text use "Virtual Network instance" instead of
> > "Virtual Network Instance".
> >
> > Still, I doubt that there is any place that the term "Virtual
> > Network Instance" is used that could not be replaced with "Virtual Network"
> > since the singular form of VN is, by definition, an instance. Adding
> > the extra word "instance" may make the intent more clear in some
> > cases; after all, we are network engineers, so we are always
> > promoting redundancy :-).
> >
> > Cheers,
> > Joe Pelissier
> >
> >
> > -----Original Message-----
> > From: Dave Hood [mailto:[email protected]]
> > Sent: Thursday, June 20, 2013 6:00 AM
> > To: Joe Pelissier (jopeliss); [email protected]
> > Subject: RE: Virtual Network - what's an instance?
> >
> > Right.
> >
> > The point is that, to the client, the idea of instance is irrelevant
> > because there is only one.
> >
> > On the other hand, the server instantiates a separate VN for each
> > client, a total of zero or more, depending on the number of clients,
> > so VN instances are an essential concept to the server.
> >
> > Dave
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Joe Pelissier (jopeliss)
> > Sent: Wednesday, June 19, 2013 7:55 PM
> > To: [email protected]
> > Subject: Re: [nvo3] Virtual Network - what's an instance?
> >
> > Hi Dave,
> > Maybe I could rephrase your last sentence:
> > "....From the server's point of view, there are as many VNs as there
> > are clients."
> > This appears to have the same meaning as your sentence, which seems
> > to indicate the terms are synonymous.
> >
> > Cheers,
> > Joe
> >
> > -----Original Message-----
> > From: Dave Hood [mailto:[email protected]]
> > Sent: Wednesday, June 19, 2013 4:03 PM
> > To: Joe Pelissier (jopeliss); [email protected]
> > Subject: RE: Virtual Network - what's an instance?
> >
> > IMO, a virtual network is the set of [network] resources exposed by
> > a server to a client. From the client's point of view, there is only
> > one VN. From the server's point of view, there are as many VNIs as
> > there are clients.
> >
> > Would that be a useful way to describe the difference?
> >
> > Dave
> >
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On Behalf
> > Of Joe Pelissier (jopeliss)
> > Sent: Wednesday, June 19, 2013 3: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:[email protected]]
> > > 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
