Hi Larry, See my comments below.
Thanks, Marc ________________________________ From: Larry Kreeger (kreeger) [mailto:[email protected]] Sent: Saturday, July 07, 2012 1:35 AM To: Aldrin Isaac; LASSERRE, MARC (MARC); [email protected] Cc: [email protected]; Lucy yong; Aldrin Isaac Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 Hi Aldrin, My interpretation of the model in the framework document is that a VNI is the intersection of a single VN with a single NVE, with the VAP determining a connection to a single VNI. This is correct. Your picture seems to show a single VAP connecting to a single VNI where two VNs intersect at the same VNI. Given that, how would the VAP differentiate which VN to associate ingress packets with? For example, if one of the VMs at the bottom sent an ARP to the L2VNI, which VN would the broadcast be sent to? Since each VN is allowed to support overlapping addresses, how would a unicast frame sent by that VM on the VAP be delivered to the correct overlapping destination address in the two VNs? This is clearly a problem. Hence, the reason for having a VNI per VN in the draft. Unless we are talking about unqualified learning? Thanks, Larry From: Aldrin Isaac <[email protected]<mailto:[email protected]>> Date: Monday, July 2, 2012 7:29 PM To: "LASSERRE, MARC (MARC)" <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Lucy yong <[email protected]<mailto:[email protected]>>, Aldrin Isaac <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 (resending from my correct mailto email with minor edits) Hi Marc/David, I've attached a "proof-of-concept" design to express the points I have raised. Hopefully a picture is worth a thousand words. It is a PDF file since I simply don't have the time to draw it as ascii art. The illustration tries to capture (1) multiple VN per VNI (and relatedly, single interface on TES) and (2) VNIF. In this POC the L2-based subnet comprise of 3 VNs to force VMs to remain in their availability zone (DC) but allows them to communicate with other subnets or Internet via gateways in both DC (with preference for local DC). This illustration could represent a single tenant of a cloud DC provider or infrastructure owned and operated by an enterprise. The illustration also tries to capture a more mobile L3-based VN where routing information is in the form of host-routes with aggregation of those routes at the gateways. Best -- aldrin On Jun 26, 2012, at 11:51 PM, Aldrin Isaac wrote: Hi Marc, My comments inline, 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]<mailto:[email protected]>; [email protected]<mailto:[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. Actually I'm not convinced mixing types is good. Needed to clarify where things stood today. 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. Even 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 associated VRF on the PE, the CE and all the associated routing configuration. OTOH, with the interface VRF model each VRF has only one CE connected (sometimes each interface of the CE gets it's own VRF on the PE). In this model enabling an additional VPN for the CE only involves importing and exporting an additional RT pair at it's VRF. 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. I suppose in outfits where the same folks deal with both sides (network and host) this may not matter -- but my understanding is that these folks are a minority. 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
