Larry,
Please see inline.
Snipped ..
>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.
[[LY]] In this case, should we request vswitch to be a vrouter? i.e. forward
based on IP? We can still use vlans to segregate the VN traffic on the wire.
Then it would be similar to VRF-Lite.
>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.
[[LY]] If we do not differentiate the cases of L2 and L3, L3VN is not a
end-to-end L3VN.
I don't think the framework catch this scenario. When TES and NVE are
physically separated, the current framework assumes that TES is non-virtualized
server. This case makes non end-to-end overlay for both L2 and L3 cases.
Thanks to depict this case clearly.
Lucy
>
>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
