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 > >> underlying network. Why describe the tunnel as Tunnel Overlays or > >> Tunneling Overlay in the doc.? It should be the tunnel or > the tunnel provided by underlying network. > >> > >> [ml] The VN and VNI are defined in the terminoly section. > The overlay > >> network is realized via NVE edge nodes over an L3 underlay > network. > >> The overlay network defines a L2 or L3 service, with its own > >> encapsulation header. The underlay use IP and/or MPLS to > provide connectivity between NVEs. > >> Let me know whether specific sentences in the draft need > clarification. > >> [[LY]] Section 3.1.4 title is "tunnel overlays and encapsulation > >> options", Tunnel overlay also used in the reference model. > Consider > >> replacing with "tunnel". > >> > >> 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. > >> > >> 3) Suggest to illustrate a VN packet structure in data > plane and state: > >> > >> the tunneling may in turn be tunneled over other intermediate > >> tunnels. It is also possible that intra DC and inter DC > tunnels are > >> stitched together to form an end- to-end tunnel between two NVEs. > >> > >> +-------------------------------------------+ > >> | L2/L3 Tenant Payload | > >> +-------------------------------------------+ > Overlay network > >> | VN Context | > >> +-------------------------------------------+ --------- > >> | Tunnel Source Addresses | > >> +-------------------------------------------+ > Underlying network > >> | Tunnel Destination Address | > >> +-------------------------------------------+ > >> > >> [ml] Thanks for this suggestion. We can certainly add such > a figure > >> in a future revision. > >> > >> 4) Text: Different IP tunneling options (GRE/L2TP/IPSec) > and tunneling > >> options (BGP VPN, PW, VPLS) are available for both > Ethernet and IP > >> formats. Comments: should also mention LSP tunnel too. > >> > >> [ml] BGP VPNs, and PW/VPLS use MPLS labels for service > demuxing and > >> can use either MPLS or IP/GRE tunneling. Hence MPLS is > implicit in the text. > >> [[LY]] It is better to explicit LSP tunnel in the text. Because VN > >> may be over LSP tunnel directly without VPN,PW, or VPLS. > It has difference. > >> > >> 5) It is not clear to me when an NVE resides on DC GW, the > VNI on the > >> NVE associates to a logical interface on a port facing WAN. Do we > >> describe the interface as VAP or not? In this case, the logical > >> interface does not connect to end system. > >> > >> If the NVE function were to reside on a DC GW, the same concepts > >> still apply i.e. VAPs logical interfaces where VM traffic > arrives are attached to DC GWs. > >> [[LY]] My indication is more about the traffic of VMs in a > VN from/to > >> Internet, i.e. the use case in section 4.1 of use case draft. > >> > >> 6) For the pros of overlay network, it should state that > the overlay > >> architecture eliminates IP > >> subnet constraints in the underlying network when VMs move. This > >> makes VM mobility easier. > >> > >> [ml] Overlays do not solve VM mobility. > >> [[LY]] Right, VM mobility requires other. But the overlay > does move > >> away this restriction. IMO: it is worth to mention. > >> > >> 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. > >> > >> 8) The doc. often refers NVO3 as a service. It may not > true for DC. > >> The service in DC is about compute, storage, networking, and > >> applications. In this case, NVO3 provides the networking > capability but not a service itself. > >> > >> [ml] NVO3 NVEs do provide a service as L2 and L3 PEs do. > NVEs provide > >> per- tenant VN instance services. > >> [[LY]] In DC, both NVEs and VMs may be on the same hardware and > >> managed by the same operators who offers cloud services. > Such service > >> provides virtualized compute, storage, networking, and > applications. > >> In this case, NV03 provides the networking functions but not a > >> service itself from DC operator perspective. The doc. > should capture > >> both cases, i.e. NVo3 as a service and > >> NVo3 for the networking of a service. > >> > >> --end > >> > >> 9) Consider a section about overlay network OAM. > >> > >> [ml] Good point for a future revision. > >> > >> 10) overlay node is not defined but used in text. I think > it should be NVE. > >> > >> [ml] Yes, there have been used interchangibly. I will > change the text > >> to only mention NVE instead. > >> > >> Cheers, > >> Lucy > >> > >> -----Original Message----- > >> From: LASSERRE, MARC (MARC) > [mailto:[email protected]] > >> Sent: Friday, June 22, 2012 11:48 AM > >> To: Lucy yong; Benson Schliesser; [email protected] > >> Cc: Bocci, Matthew (Matthew); > >> [email protected] > >> Subject: RE: [nvo3] call for adoption: > >> draft-lasserre-nvo3-framework-02 > >> > >> Hi Lucy, > >> > >> Thanks for supporting this draft. > >> > >> If you do have specific concerns about the draft content, we can > >> discuss these on the list. But this would contradict your > first sentence below... > >> Note that changes in -02 are only related to terminology (expanded > >> section) and the alignment of such terminology in the rest > of the draft. > >> > >> I won't comment on your last emails about the process > (which Stewart > >> alrady addressed in his mail). > >> But I'd ask that you change the subject of future emails > wrt process > >> in order not to confuse the list. > >> > >> Marc > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] > On Behalf > >> Of Lucy yong > >> Sent: Wednesday, June 20, 2012 5:03 PM > >> To: Benson Schliesser; [email protected] > >> Cc: Bocci, Matthew (Matthew); > >> [email protected] > >> Subject: Re: [nvo3] call for adoption: > >> draft-lasserre-nvo3-framework-02 > >> > >> > >> Hi Ben and Matt, > >> > >> I want to say that the draft is well written and thanks to > authors. I > >> support this work. > >> > >> I also want to raise a question regarding the WG process. > >> > >> Last IETF (IETF83) had NVo3 BOF.(I heard that was well > done) NVo3 WG > >> is just formed on May 1 2012. The framework draft 00 was > just published in March 2012. > >> The 02 uploaded recently has fair amount of changes from 01. > >> > >> Why do the WG want rapidly adopting the draft into WG draft. Are > >> there some DC operator want this badly? It seems the time > line in the > >> charter is not the reason. Frankly, this set of works are > pretty new > >> to IETF people. It should give people more time to think > and contribute. > >> > >> Regards, > >> Lucy > >> > >> > >> > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] > On Behalf > >> Of Benson Schliesser > >> Sent: Monday, June 18, 2012 4:51 PM > >> To: [email protected] > >> Cc: Matthew (Matthew) Bocci; > >> [email protected] > >> Subject: [nvo3] call for adoption: draft-lasserre-nvo3-framework-02 > >> > >> Dear NVO3 Participants - > >> > >> This message begins a two week Call for Adoption of > >> http://tools.ietf.org/html/draft-lasserre-nvo3-framework-02 by the > >> NVO3 working group, ending on 02-July-2012. > >> > >> Please respond to the NVO3 mailing list with any statements of > >> approval or disapproval, along with any additional comments that > >> might explain your position. Also, if any NVO3 participant > is aware > >> of IPR associated with this draft, please inform the > mailing list and/or the NVO3 chairs. > >> > >> Thanks, > >> -Benson & Matthew > >> > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
