Hi Marc, Thanks for the clarifications.
Wrt my first question, should we assume that there isn't yet a consensus on whether a VNI can support more than one type of VN? Regarding one-to-one mapping of VNI to VN, this implies that an end-station that needs to be a part of more than one VN will require a separate interface into each associated VNI. This implies that the end-station will require a potentially complex routing table (depending on how aggregateable the address space within a VN is). Unfortunately as an operator I don't find this an acceptable trade off. Can we please address the issue of managing multiple interfaces and complex tables in end-systems? I believe the problem statement needs to capture this. Best -- aldrin On Tuesday, June 26, 2012, LASSERRE, MARC (MARC) wrote: > Hi Aldrin, > > See my comments below. > > Thanks, > Marc > > > -----Original Message----- > > From: Aldrin Isaac [mailto:[email protected] <javascript:;>] > > Sent: Monday, June 25, 2012 8:23 PM > > To: LASSERRE, MARC (MARC) > > Cc: Lucy yong; [email protected] <javascript:;>; > > [email protected]<javascript:;> > > Subject: Re: [nvo3] call for adoption: > > draft-lasserre-nvo3-framework-02 > > > > Hi Marc, > > > > Looking for more clarity on the following... > > > > Should we assume that a VNI can only support L2VNs (VNI = > > L2VNI) or L3VNs (VNI = L3VNI) but not both? > > > > draft-mity-nvo3-use-cases describes a "virtual network > > instance interconnecting interface" (VNIF) to interconnect > > VNI of different type. An example of a VNIF would be an IRB > > (integrated routing and bridging) interface that is common on > > "L3 switches". Is this something that draft-lasserre captures? > > While the current draft focuses on L2VNs and L3VNs as distinct services, > no assumptions have been made about the ability to support IRB. > A couple of sentences could be added to highlight this possibility. > > > > > Are there any restriction to the topology of a VN or topology > > created using a set of VNs. I.e. can (1) a VNI be a member > > of multiple VN and (2) can a VN be either hub-and-spoke or > > full-mesh? Does draft-lasserre support (1) and (2)? > > A VN is represented by a VNI created within NVEs that participate in this > VN. Hence there is a one-to-one mapping between a VN and VNI. > > Hub-and-spoke is discussed briefly in this draft. More details are > provided in draft-bl-nvo3-dataplane-requirements. > > > > > Best -- aldrin > > > > > > On Jun 25, 2012, at 1:14 PM, <[email protected]> wrote: > > > > > Extracting a couple of items for additional comment: > > > > > >> 2) section 2.3, why call it NVE service type? Should we call it VN > > >> (or VNI) service type? One NVE may terminate both L2 VNI > > and L3 VNI. > > >> NVE is equivalent to PE in L2VPN/L3VPN. We did not have > > service type > > >> for PE and had service type for VPN. > > >> > > >> [ml] Like with L2 and L3 PEs, there are L2 and L3 NVEs. > > >> [[LY]] Should we consider this as VN service type? I > > understand the > > >> description but have trouble with the title of NVE service type. > > > > > > I think VN service type makes sense, as an NVE could conceivably > > > support both > > > L2 and L3 services for the same end system. OTOH, mixing L2 and L3 > > > service types on the same VN requires that the > > encapsulation indicate > > > the service type (for correct decap processing), and that > > would also be useful to note. > > > > > >> 7) It is important to state that the major difference > > between other > > >> overlay network technology and NVO3 is that > > >> the client edges of the NVO3 network are individual virtualized > > >> hosts and not network sites. > > >> > > >> [ml] NVO3 can cope with both virtualized and non-virtualized hosts. > > >> [[LY]] Yeah, that is more precise. The point is that the > > client edge > > >> is not network sites like CEs in a VPN. > > > > > > Actually the NVE can be in a network node. See Figure 3 and the > > > discussion of "traditional physical server" in the last > > paragraph on > > > p.10, including the statement that the NVE can be in the > > ToR. FWIW, > > > the Storage Systems example in that paragraph is fine, although one > > > can envision storage systems that contain NVEs. > > > > > > Thanks, > > > --David > > > > > >> -----Original Message----- > > >> From: [email protected] [mailto:[email protected]] > > On Behalf > > >> Of Lucy yong > > >> Sent: Monday, June 25, 2012 11:52 AM > > >> To: LASSERRE, MARC (MARC); Benson Schliesser; [email protected] > > >> Cc: Bocci, Matthew (Matthew) > > >> Subject: Re: [nvo3] call for adoption: > > >> draft-lasserre-nvo3-framework-02 > > >> > > >> Marc, > > >> > > >> Please see inline below with [[LY]]. > > >> > > >> Lucy > > >> > > >> -----Original Message----- > > >> From: LASSERRE, MARC (MARC) > > [mailto:[email protected]] > > >> Sent: Monday, June 25, 2012 9:23 AM > > >> To: Lucy yong; Benson Schliesser; [email protected] > > >> Cc: Bocci, Matthew (Matthew) > > >> Subject: RE: [nvo3] call for adoption: > > >> draft-lasserre-nvo3-framework-02 > > >> > > >> Hi Lucy, > > >> > > >> Thanks for your comments. > > >> See my comments below prefixed with [ml]. > > >> > > >> Marc > > >> > > >> -----Original Message----- > > >> From: Lucy yong [mailto:[email protected]] > > >> Sent: Saturday, June 23, 2012 1:11 AM > > >> To: LASSERRE, MARC (MARC); Benson Schliesser; [email protected] > > >> Cc: Bocci, Matthew (Matthew) > > >> Subject: RE: [nvo3] call for adoption: > > >> draft-lasserre-nvo3-framework-02 > > >> > > >> Marc, > > >> > > >> Here are some comments on this draft: > > >> > > >> 1) The VN (or VNI?) in the doc. is an overlay network that is > > >> transported over the tunnels. These tunnels are provided by the >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
