Hi Anoop, See my responses inline, marked with LK>.
Thanks, Larry From: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Tuesday, June 10, 2014 4:52 PM To: NVO3 <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00 This looks like a reasonable starting point. But I have some comments... The document seems to focus only on the case where the TS to NVE is accomplished using L2 connectivity. Is there a reason it chooses to exclude L3 connectivity? If so, what is the rationale for that? It would be good to document that. LK> From my perspective, L2 connectivity works well (for either L2 service or L3 service) because all data center switches (and Hypervisor virtual switches) are already VLAN enabled, so L2 has a built in way to keep tenant traffic separate between the End Devices and the external NVE. If the connectivity to an external NVE were L3, there would need to be something to differentiate each tenant's traffic (e.g. some kind of encapsulation)…but since one of the big reasons for using an external NVE is to offload the encap/decap from software on a Hypervisor to external hardware, that would completely defeat the purpose. Second, it talks about the case where a TS forwards using multiple MAC addresses and requires the registration of all of the MAC addresses. But what about the case where the TS is a transparent appliance? In that case, it may not have MAC addresses to register and may operate simply by flipping the VLAN ID. LK> A VM running as a transparent bridge was indeed one of the use cases I had in mind for a TS with multiple MAC addresses. From the perspective of the L2 NVE, it has no idea whether the MAC address is actually "owned" by a transparent bridge, or whether it is simply emitting the frames as it bridges them. Note that the TS does not actually do the registering with the external NVE. The End Device housing the TS (e.g. Hypervisor) does the registering. For example, when a VM emits a frame with a previously unseen source MAC, the Hypervisor virtual switch would detect it and then register the new address. Finally, being a requirements document, it shouldn't discuss solution, yet it gets into defining state machines and provides the exemplary details of VDP (but no details for any of the other solutions). LK> This came from one of the merged drafts. Some felt is was a very informative example to look at. We are not trying to imply it is the solution, which is why it is in a Appendix and label "Illustrative". Anoop -----Original Message----- From: nvo3 [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bocci, Matthew (Matthew) Sent: Wednesday, May 28, 2014 6:23 AM To: NVO3 Subject: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00 This email begins a two week poll to help the chairs determine if there is consensus to adopt draft-yizhou-nvo3-hpvr2nve-cp-req-00 as an PWE3 working group draft. The draft can be found here: http://www.ietf.org/id/draft-yizhou-nvo3-hpvr2nve-cp-req-00.txt Please read the draft and indicate to the list if you support adoption, or if you do not support adoption (giving reasons). Please note that this is only a call for adoption. There needs to be consensus that this draft is a good basis for the work, but it does not need to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are on the PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond regarding IPR only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. The poll for adoption will close in two weeks time, on Friday 6th June. Matthew and Benson _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
