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]<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
