> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, July 12, 2012 11:27 AM > To: [email protected] > Cc: [email protected] > Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility- > issues draft) > > Larry, > > > >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. > > To extend the DHCP functional analogy, that's a proxy, not just a relay. > Translating the VLAN tag may not be desirable because that translation > makes it more difficult to match up End Device and NVE configurations.
[Linda] I think that it is a great idea to extend DHCP, to allow NVE request a local VID for a newly discovered Virtual Network. > > > 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? > > I'm assuming that the intermediate bridges may have enough onboard > functionality that VDP does not pass through their data planes as if it > were ordinary Ethernet traffic. I believe that support for any form > of spanning tree in such a bridge may be enough to cause this diversion > of VDP to the control plane. > > > > - 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? > > Yes, VLANs plus a virtual router for each tenant that operates across > VLANs would suffice as the traffic is VLAN tagged but not nvo3-encapped. > Whether IP forwarding between the End Device and NVE is appropriate > depends on the structure of the network. > > Thanks, > --David > > > -----Original Message----- > > From: Larry Kreeger (kreeger) [mailto:[email protected]] > > Sent: Wednesday, July 11, 2012 8:47 PM > > To: Black, David; [email protected] > > Cc: [email protected] > > Subject: Re: [nvo3] TES-NVE attach/detach protocol security > (mobility-issues > > draft) > > > > > > > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
