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
