> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Larry > Kreeger (kreeger) > 发送时间: 2012年7月12日 2:06 > 收件人: Luyuan Fang (lufang); Paul Unbehagen; NAPIERALA, MARIA H > 抄送: Thomas Narten; [email protected]; Lucy yong > 主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues > draft) > > On 7/11/12 10:28 AM, "Luyuan Fang (lufang)" <[email protected]> wrote: > > >Thomas, Larry, Lucy, Maria, and Paul, > > > >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? > > > >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. > > >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. > > I don't agree with that one. But first, let's clarify that I'm assuming > that there is an additional component in between the TES and the NVE > (which I believe is called End Device in the framework doc). Here is a > picture to illustrate: > > Hypervisor Access Router/Switch > +-------------------+ +-----+-------+ > | +---+ +-------+ | | | | > | |TES|---| | | VLAN | | | > | +---+ |Virtual|---------+ NVE | +--- Underlying > | +---+ |Switch | | Trunk | | | Network > | |TES|---| | | | | | > | +---+ +-------+ | | | | > +-------------------+ +-----+-------+ > > I'm assuming VDP happens between trusted devices, so in this picture the > hypervisor virtual switch is a trusted End Device. It would run the > VDP-like protocol. In this case, there is still a need to inform the NVE > of the need to participate in a given L3 VN and possibly to be informed of > the TES IP addresses within that VN.
Hi Larry, I agree with you and Thomas that some kind of signaling (e.g., VDP) for VM attachment/de-attachment events between End Device and NVE is needed in this case, no matter L2 or L3 NVE is involved. As an alternative, in the case where the VM profile (e.g., VLAN ID, ACL etc.,) has already been auto-configured on the NVE via the orchestration system, is it possible to allow the TES itself to notify its attachments explicitly and its de-attachments implicitly to the NVE by using some existing protocol, e.g., ARP? For example, when a VM is attached to a given NVE, the VM or its hypervisor on behalf of it could send a gratuitous ARP packet to notify the NVE of its attachment. When a VM is moved from a old NVE to a new NVE, when the event of VM attachment to the new NVE arrives at the old NVE (e.g., via the propagation of the gratuitous ARP, or via the advertisement of the MAC or IP address of the VM), the old NVE would either update its forwarding table entry of that VM directly (imagine the traditional VPLS's behavior) or after it has confirmed that the VM is no longer attached to it (imagine the case where the MAC or IP reachability information of remote VMs is learnt on the control plane). Best regards, Xiaohu > > >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. > > I'm not sure why you differentiate the cases of L2 and L3. The tenant VN > traffic on the wire between the Hypervisor and the Access switch/router > needs to be differentiated (since TESs from different tenants could be > present on the same hypervisor), so some kind of tag (like a locally > significant VLAN tag) needs to be negotiated with the NVE across that > wire, and the NVE still needs to know what TES addresses are > attaching/detaching from what VN regardless of the address family used for > forwarding across the VN. > > > > >Thanks, > >Luyuan > > > >> -----Original Message----- > >> From: Paul Unbehagen [mailto:[email protected]] > >> Sent: Wednesday, July 11, 2012 1:18 PM > >> To: NAPIERALA, MARIA H > >> Cc: Thomas Narten; Luyuan Fang (lufang); [email protected] > >> Subject: Re: [nvo3] TES-NVE attach/detach protocol security (mobility- > >> issues draft) > >> > >> VDP isn't that complicated of a protocol. It was designed to > >> autoconnect VMs to the proper VLAN and any tenant profile required by > >> involving communication to a management system which then configures > >> the proper tenant parameters in the ToR/EoR in a automated way. This > >> is all transparent to the routing layer as the IP and default gateway > >> and vlan assignment take care of all that automatically. > >> > >> I believe it's already in a few server vendors products already as I > >> saw prototypes of it a couple years ago. > >> > >> -- > >> Paul Unbehagen > >> > >> > >> On Jul 11, 2012, at 10:20 AM, "NAPIERALA, MARIA H" <[email protected]> > >> wrote: > >> > >> >> Also VDP is between the Hypervisor and NVE. Thus, it may still be > >> >> needed, even if the service provided to the TES is L3 only. > >> > > >> > In a layer 3 solution (whether encapsulation starts at the hypervisor > >> or on a switch outside of the hypervisor) there is no need to run a > >> complicated (IEEE) protocol such as VDP. VDP was invented to > >> interoperate a virtual server with an external layer 2 switch/bridge. > >> > A layer 3 solution can use much simpler IP-based protocol (developed > >> in IETF) such as Extensible Messaging and Presence Protocol (XMPP). > >> > > >> > Maria > >> > _______________________________________________ > >> > 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
