On 7/11/12 4:29 PM, "[email protected]" <[email protected]> wrote:
>Thomas, > >> > 2) If NVE and TES are not in the same physical device, but TES to >> > NVE using L3 protocols only, there is still no need for VDP or >> > VDP-alike protocol. >> >> More to the point, in a DC, when will an NVE and TES be separated by a >> physical network link that is *only* running L3? Even if L3 is being >> used, it will surely also be running over L2, which I assume (in a DC >> environment) will be ethernet. Or is this assumption wrong? > >It's a good assumption - the next two questions are: > - How many Ethernet links are traversed? > - Is there any IP forwarding involved? >If the answer to the questions are "1" and "no" respectively, a single >Ethernet link is involved, and L2 access control looks like a reasonable >approach for an L2 protocol such as VDP. > >If either question has a different answer, an L2 protocol like VDP gets >more interesting, as pointed out in a thread between Dimitri and I >yesterday. >In particular: > - If multiple Ethernet links are involved, VDP has to somehow > be plumbed through the L2 bridges that connect the links. Or, the device in between can act as a relay. I runs the VDP-like protocol with the End Device to negotiate a local .1Q tag for a VN on that local link, then act as an End Device to the NVE on the other link to negotiate a separate local .1Q tag. It would then translate tags as the traffic flows across the device at L2. I'm guessing this might not be what you had in mind. Are you assuming the intermediate device(s) between the End Device and NVE are unmodified, off the shelf 802.1Q bridges that are not participating in any protocols? If so...assuming the method to keep each VN's traffic separated as it flows across this bridge is 802.1Q VLANs (global to the device), then this will limit how many VNs can be accessed on the NVE to how many VLANs can be trunked on all the ports of this bridge simultaneously. Since this bridge is not running any protocols with the End Device or NVE, the admin would have to statically configure as many VLANs as supported on all the trunk ports which lead to all the End Systems and to the NVE. Assuming this device cannot support 4K VLANs on all its ports, this means the NVE must be configured to negotiate only the limited VLAN range, and all the End Devices must share this limited VLAN space for all of their VNs. > - If there's an IP forwarding node between the End Device and > the NVE, VDP needs to be relayed through that node (this > has some analogies to the function of a DHCP relay). I'm wondering how two tenant's traffic is kept separated while they traverse this IP forwarding node that lies between the End Device and the NVE. It seems like it would require some kind of tunnel, with the End Device required to encapsulate/decapsulate the TES traffic into and out of the tunnel. This seems to diminish the utility of offloading the VN encap/decap to the NVE and only serves to make life more complicated, with little benefit. Am I missing something? >Both of these result in a larger L2 scope for VDP and hence more things >that have to be checked to ensure that the access control is correct. > >An IP-based protocol avoids these L2 complications, but it also cannot >rely >on L2 topology for access control purposes. > >Thanks, >--David > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >>Thomas >> Narten >> Sent: Wednesday, July 11, 2012 1:43 PM >> To: Luyuan Fang (lufang) >> Cc: Paul Unbehagen; [email protected]; Larry Kreeger (kreeger); Lucy yong; >> NAPIERALA, MARIA H >> Subject: Re: [nvo3] TES-NVE attach/detach protocol security >>(mobility-issues >> draft) >> >> Hi Luyuan. >> >> > Thanks for the discussion, and sharing the insight... >> >> > I'd like to get us on the same page on when VDP is needed and when >> > it is not, please help if the following points are not correct? >> >> Let me try, based on my understanding of things... >> >> > 1) If NVE and TES are in the same physical device - there is no >> > external wire between them, then no VDP or VDP-like protocol is >> > needed, regardless L2 or L3 is used. >> >> Agreed. This can all be done internal to the device. >> >> > 2) If NVE and TES are not in the same physical device, but TES to >> > NVE using L3 protocols only, there is still no need for VDP or >> > VDP-alike protocol. >> >> Not sure I agree with this. >> >> More to the point, in a DC, when will an NVE and TES be separated by a >> physical network link that is *only* running L3? Even if L3 is being >> used, it will surely also be running over L2, which I assume (in a DC >> environment) will be ethernet. Or is this assumption wrong? >> >> Thus, VDP can also be used here. Or at least, I'd like to understand >> why it wouldn't be appropriate and why a different (and new) L3 >> protocol is needed. >> >> To be clear, I'm not wedded to using VDP (or any specific >> protocol). We need to figure out requirements and then do a gap >> analysis, so it's premature to be trying to be picking solutions here. >> >> But, my assumption is: >> >> 1) VDP exists and is already being implemented. We do of course need >> to have the conversation about whether its implemented widely enough, >> etc. >> >> 2) Assuming VDP already exists, and we can add the needed NVO3 >> functionality to it (i.e., by defining the needed TLVs), isn't that >> preferred over inventing a new protocol, no matter how "simple" that >> new protocol would be? >> >> > 3) If NVE and TES are not in the same physical device, TES to NVE >> > using L2, then VDP or VDP-like protocol plays important role for >> > discovery and more. >> >> Same arguments as above. >> >> Thomas >> >> _______________________________________________ >> 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
