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:[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
