Hi Linda, > [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.
Actually I didn't intend to go there (at least not in this thread), as DHCP traffic is L2 LAN/VLAN scoped, whereas VDP (and ECP) are scoped to a single L2 link, and hence have rather different requirements/behavior in terms of where they hit the control plane. The only thing I'm trying to do is reuse the words "relay" and "proxy" as they are used with DHCP to differentiate two classes of possible VDP functionality in a bridge between an End Device and an NVE. A "relay" just forwards the traffic associated with the protocol whereas a "proxy" is a full participant in the protocol. Thanks, --David > -----Original Message----- > From: Linda Dunbar [mailto:[email protected]] > Sent: Thursday, July 12, 2012 5:48 PM > To: Black, David; [email protected] > Cc: [email protected] > Subject: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues > draft) > > > > > -----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
