David, I didn't mean literally using DHCP for this purpose. I just thought that some controller (like DHCP server) for NVE to get local VID would be useful. Well, it might be out of scope for NVo3.
Linda > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, July 12, 2012 5:41 PM > To: Linda Dunbar > Cc: [email protected] > Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility- > issues draft) > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
