> > 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. > > Agreed with both parts: virtual switch would run VDP, and the need for > it. >
In a layer 3 VN solution there is no need for VDP. The issue with VDP is that it is tied to the physical location (link-layer) of the information it conveys. It is an example of a protocol where the application payloads ride directly over Ethernet, without a layer 3 header. Designing protocols that put application payloads on top of Ethernet directly is not a good idea. Assume that system A (e.g., end-system) is managed by a management station that sends to it a message m1; A then sends a subset of this information as a message m2 to B (e.g., the first-hop switch/router). Now, it might be much more secure to turn this flow information around and make the management station to send m2 directly to B. This will ensure that A does not alter the content of m2. If m2 is an application message that rides directly on a layer 2 protocol (e.g., VDP message) the above is not possible (the management station and B will not be on the same subnet). The application protocols should ride on top of a transport that can be secured. It would also be reasonable to expect that the application protocol is expressed in a way that is easily extendable. One obvious choice is an XML document on a channel that can be authenticated using TCP/IP at layer 3/4. There are several IETF standardized ways to carry XML documents. XMPP is one such option, there are also other. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
