Lothar,
So, we've wandered into the weeds. The logical argument style you refer
to is usually referred to as "reductio ad absurdum" (or "argumentum ad
absurdum")
which might be a clue about where we are headed with this.
Logic allows us to err with confidence. We need to be careful about
that.
As has already come up, the inclusion of "self-reference" is one easy
way
to make any logical argument arrive at any conclusion you might like to arrive
at.
Another is to assert, as an Axiom, something that depends on the desired
conclusion - possibly in some subtle way.
In this case, you assert that - because the difference between VN and
VNI
is the word "instance" - the difference has to be about the word "instance."
Sounds reasonable? No.
This argument could be applied to the difference between Egg and Egg
Shell.
It could also be applied to any number of similar analogies. And here we have
the
absurdity: the difference between an Egg and Egg Shell is not that one has a
shell
and the other does not.
Further, the argument style does not require counter examples. If you
want
to prove that the hypothesis "a VN is not necessarily the same as a VNI" leads
to an
absurdity, you have to show the constructive steps that take you there - not
make a
statement that it does and then challenge somebody to show you an example that
proves you are wrong.
As it happens, however, examples have already been provided.
Lucy Yong pointed out that the term is consistent with similar usage in
other
contexts - where people have felt it necessary to distinguish a logical concept
from a
specific instantiation of that logical concept.
David Black pointed out that the definition in the currently posted
version of
the framework draft includes "additional stuff" (specifically, it includes a
reference
to state information in an NVE about a specific VN). This also is consistent
with the
usages that Lucy referred to.
I've pointed out that the term VN may refer to an IP subnet without
referring
to a specific IP subnet, but that a VNI (that happens to also be an IP subnet)
must be
a specific IP subnet.
I would also argue that the definition that includes a reference to VN
state
information on specific devices can be made more general by saying that a VNI
is the
state information maintained in all devices associated with a specific VN
instance.
And this can be simplified to "a VNI is an instance of a VN that is
identifiable to all
(virtual) devices that are part of a specific VN" or - even simpler - "a VNI is
an instance
of a specific VN."
--
Eric
-----Original Message-----
From: Reith, Lothar [mailto:[email protected]]
Sent: Friday, June 28, 2013 1:18 PM
To: Eric Gray; Joe Pelissier (jopeliss)
Cc: [email protected]
Subject: AW: Virtual Network - what's an instance?
Importance: High
Hi Eric,
well, I may have been a little bit unprecise and intentionally provoking, which
may have lead to your impression, that I was joking.
I was only partly joking, and I try to be a bit more precise now - without
joking.
I was trying to begin a mathematical proof, that the idea of VNI is wrong.
In mathematics, there is this method of indirect proof. You start with the
assumption, that VNI makes sense, and lead it through logical conclusions to
some conclusion, that is absurd. As a result, you have mathematically proven,
that the assumption was wrong.
Let us try with the assumption, that the terms VN and VNI are not synonymous.
This means that there must exist a VNI, which is not the same as a VN.
Since the difference lies in the word instance, the difference must come from
this word. There must exist a virtual network, which is not an instance of a
virtual network.
If someone comes up with an example of such a virtual network which is not an
instance of a virtual network, I would tend to agree with those wanting to keep
the term VNI.
With respect to the namespace, this is another argument against VNI.
What must happens at the time of the creation of the virtual network instance?
Of course the instance must be named, otherwise you cannot refer to it, and you
cannot prove that it exists, nor can you distinguish it from another VN
instance.
Therefore, the more precise question I should have asked is, from how many
different namespaces do we anticipate that the name of newly a created VN
instance will be taken?
And what distinguishes these namespaces?
Will we have different namespaces for:
Simple L2 VNs: string type: e.g. VLAN1-VLAN4094 or integer type: 1-4094 IETF
defined L2 VNs: e.g. 24 bit unsigned integer (VXLAN Section ID) IEEE defined L2
VNs: e.g. 24 bit unsigned integer (I-SID) IETF defined L3 VN: e.g. route
distinguisher or something else?
If really multiple different namespaces must be used, then there may be a
requirement for the definition of a VN type, and an explanation how these types
differ, which is missing currently, and which may be a cause of confusion as I
have the impression, that some people may confuse such VN type with that thing,
which is a VN but not a VN instance.
Or will a future IETF draft specify a single unified VNI namespace: for
example: the name that identifies a VNI is of type String, and you have to
parse the string to find out if it is a L2 VN or a L3 VN?
And regarding my other joke (using the word authoritative): okay, I would
already be happy if someone points me to any IETF definition of the term
"network", because I want to check if the IETF definition(s) of the term
"network" and the IETF definition(s) of the term "virtual network" are aligned,
before we discuss if the IETF definitions of the terms "virtual network" and
"virtual network instance" are aligned.
Lothar
Ceterum censeo terminem "VNI" esse delendam
-----Ursprüngliche Nachricht-----
Von: Eric Gray [mailto:[email protected]]
Gesendet: Freitag, 28. Juni 2013 16:05
An: Reith, Lothar; Joe Pelissier (jopeliss)
Cc: [email protected]
Betreff: RE: Virtual Network - what's an instance?
Lothar,
You must be joking, of course.
The IETF does not have a consensus definition for the term
"Authoritative."
If we can't agree on what it means to be "authoritative" how can we
agree
on an "authoritative definition" for anything?
Thus we introduce the self-referential observation:
"This statement is not authoritative" - causing V'Ger to crash...
--
Eric
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Reith,
Lothar
Sent: Friday, June 28, 2013 9:52 AM
To: Joe Pelissier (jopeliss); [email protected]
Subject: Re: [nvo3] Virtual Network - what's an instance?
Assuming that an NVI would make sense, what would be a sensible namespace for
the NVI. For simple VLANs, the namespace is just integer from 1 to 4094.
For other layer 2 VNs, the namespace maybe larger, such as the VXLAN defined
namespace for VNs allowing roundabout 16 million VXLAN VNs per domain -
assuming that a VXLAN section-ID is a valid VNI of a VN of type layer 2 VN.
And what about Layer3 VN, could someone please provide an example of a Layer 3
VN VNI. Is a CIDR a valid VNI? Is an autonomous system number a valid VNI?
In that context I like to raise the question:
Do we need a VN-type to differentiate a VXLAN based VN with the ID "41" (VNI41)
from a VLAN with VID 41 (VLAN41), and from a VNI identifying a specific
instance of a VN that is a layer3 VN?
In summary, I share the view of those that question the necessity of VNI. Of
course it would be a different story, if the draft specifies a VNI namespace.
In closing, I would also appreciate if someone could point me to an
authoritative IETF definition of the term network.
Lothar
-----Ursprüngliche Nachricht-----
Von: [email protected] [mailto:[email protected]] Im Auftrag von Joe
Pelissier (jopeliss)
Gesendet: Freitag, 28. Juni 2013 01:50
An: [email protected]
Betreff: Re: [nvo3] Virtual Network - what's an instance?
Still trying to find an example of a case in which the term Virtual Network
could not be used instead of Virtual Network Instance. And more importantly,
given that Virtual Network is a defined term, why does Virtual Network Instance
need a definition given that "Instance" in this case has the normal English
meaning of "instance". And most importantly, let's not define a Virtual
Network Instance as "a specific instance of a virtual network". Reminds of the
Star Trek Movie:
SPOCK: And who is the Creator?
ILIA PROBE: The Creator is that which created V'Ger.
KIRK: Who is V'Ger?
ILIA PROBE: V'Ger is that which seeks the Creator.
Joe Pelissier
-----Original Message-----
From: smith, erik [mailto:[email protected]]
Sent: Thursday, June 27, 2013 3:49 PM
To: Eric Gray; Joe Pelissier (jopeliss); [email protected]
Subject: RE: Virtual Network - what's an instance?
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:[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
