Hi Dave, See my comments below.
Thanks, Marc > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Monday, June 25, 2012 7:14 PM > To: [email protected]; LASSERRE, MARC (MARC); [email protected] > Cc: [email protected] > Subject: RE: [nvo3] call for adoption: > draft-lasserre-nvo3-framework-02 > > 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. Agreed. I'll change the text accordingly. > > > 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. I think that Lucy was refering to clients that are attached to NVEs. I think that the text is clear about the fact that such clients can either be virtualized or non-virtualized. As far as NVEs, as you said, there are also several paragraphs explaining where such NVE function can reside. > > 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
