(resending from my correct mailto email with minor edits) Hi David,
I am also of the opinion that the we don't want to single a VNI to support both L2 and L3 service. The VNIF (VNI interconnecting InterFace) described in Lucy's draft-mity use-cases is used to interconnect an L2VNI with an L3VNI within the same NVE, similar to how an IRB logical interface would be used to connect a routing instance with a bridge instance on a routing switch (as you already seem to be intimately familiar with). Here the L2VNI would be a member of L2VNs and the L3VNI a member of L3VNs. My concern was that the framework draft doesn't seem capture the "VNIF" entity. Are basic interworking entities such as VNIF not in scope? Best -- aldrin On Jun 26, 2012, at 9:51 AM, <[email protected]> <[email protected]> wrote: > Hi Aldrin, > > I observe that for IRB to work on a VNI, the VNI has to provide layer 2 > service. What > I mean by this is that IRB assumes that the Ethernet header is present on all > traffic - > bridging uses that Ethernet header, whereas the routing portion of IRB > (logically) > strips the Ethernet header and operates on the IP header. To apply IRB to > nvo3 traffic, > the inner headers (Ethernet and IP) are involved after decapsulation (again, > logically). > > The reason for “(logically)” is that there are optimization possibilities > when the > same headers will be present outbound (e.g., when routing between two VNIs > that use > the same encapsulation, an integrated implementation may modify the headers > in place > - as long as the outbound traffic is correctly formatted, it doesn’t matter > whether > the headers were stripped and reapplied internally vs. modified in place). > > In order to mix layer 2 service (inner Ethernet header present) and layer 3 > service > (no inner Ethernet header present) on the same VNI, the encapsulation needs > to indicate > whether the first header after the encapsulation header is Ethernet or IP. > Obviously, > there are ways to do that (GRE comes to mind), but I wonder whether there’s a > strong > requirement for multiple nvo3 encapsulation formats on a single VNI vs. > forcing use of > a separate VNI if there’s a desire for more than one encapsulation format. > > Thanks, > --David > > From: Aldrin Isaac [mailto:[email protected]] > Sent: Tuesday, June 26, 2012 9:24 AM > To: LASSERRE, MARC (MARC) > Cc: Aldrin Isaac; Black, David; [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? > > 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]] > > 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
