(resending from my correct mailto email with minor edits)
Hi Marc, My comments inline, Best -- aldrin On Jun 26, 2012, at 9:43 AM, LASSERRE, MARC (MARC) wrote: > Hi Aldrin, > > See my comments below. > > Thanks, > Marc > > From: Aldrin Isaac [mailto:[email protected]] > Sent: Tuesday, June 26, 2012 3:24 PM > To: LASSERRE, MARC (MARC) > Cc: Aldrin Isaac; [email protected]; [email protected]; Lucy yong > Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 > > 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? > It does not preclude it. I'd like to hear how much interest there is to > support this capability. I'm not convinced mixing types is a good idea from a standardization perspective. > > 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. > This is not any different than with existing VPN technologies. Supporting > multiple interfaces to connect to different subnets and/or nvo3 domains does > not make routing really complex. > Have you had specific problems with past technologies? If you are referring to VRFs and the like, then I don't see host-facing VNI as equivalent. For one, most PE connect to a CE which generally tend to be a router, not a host -- the difference here is network versus system administration. Even in cases where the PE connects to an access subnet (as opposed to a CE router), there are scenarios where the subnet-connecting VRF is a member of multiple VPNs. For example: a regional extranet DMZ subnet connected to a VRF which is both a member of a customer-facing regional hub-and-spoke VPN as well as an internal DMZ mesh. The advantage of this approach is that the servers do not need to have an interface on a subnet connected to an internal DMZ VRF which is a member of the internal mesh VPN and yet another separate interface on a subnet connected to another DMZ VRF which is a member of the customer-facing regional hub-and-spoke VPN. In addition, the servers would only need a default route as opposed to the complex management of static routes on the servers which can become quite challenging to manage at scale. Along similar lines, in a PE to CE-router scenario, there is also the concept of "shared VRF" model and "interface VRF" model. In the shared VRF model multiple CE are connected to the same VRF and each VRF is connected to one VPN. Here if a CE needs to be connected to another VPN you provision yet another interface to connect to the VRF on the PE associated to that VPN. In this case there is also the additional configuration required on the CE and all the associated routing configuration and the overhead associated to managing additional interfaces and configuration. OTOH, with the interface VRF model each VRF has only one CE connected. In this model enabling an additional VPN for the CE only involves importing and exporting an additional RT pair at it's VRF -- no additional interfaces or routing configuration beyond that is generally required. In a DC/overlay setting, a particular scenario where multiple VN per VNI are involved would be a DMZ subnet with public addressing provided by the ISP. The DMZ would need to support different CUGs with a common gateway/firewall to efficiently share the ISP assigned prefix. In this scenario, it is very common that "private vlans" are used (informational RFC 5517). This would need to be implemented with at least two VNs per VNI -- a hub-and-spoke VN with the gateway/firewall as the hub and multiple "community" VNs where each community VN represents a CUG wherein members need to communicate with one another. Furthermore, in an enterprise setting it is generally expected that the network bears the network-related complexity. All this to say that I am strongly of the opinion that one-to-one mapping of VN to VNI should not be an implicit or explicit requirement/mandate of nvo3. Would like to see the framework draft address this since this is an important issue. > > 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]] > > Sent: Monday, June 25, 2012 8:23 PM > > To: LASSERRE, MARC (MARC) > > Cc: Lucy yong; [email protected]; [email protected] > > 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
