" Could the VSI Type ID be used to represent a generic service handle that is interpreted by a network manager to deliver service related configuration to the NVE? How large is the VSI ID? Seems to be only two octets from what I can gather -- this doesn't seem like it is large for environments where there are many defined network service instances/templates."
Aldrin, VSI Type is defined as a set of configuration that can be shared by multiple VSIs. So yes, you are right. The VTID (VSI Type ID) can represent a generic service handle and be interpreted as configuration to NVE. VSI Type ID is 3 octets and VSI ID is 16 octets, so the VSI ID should be large enough. Best Regards Gu Yingjie -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Aldrin Isaac 发送时间: 2012年7月13日 乐乐7:51 收件人: Guyingjie (Yingjie) 抄送: Paul Unbehagen; Thomas Narten; Luyuan Fang (lufang); NAPIERALA, MARIA H; [email protected] 主题: Re: [nvo3] 答复: TES-NVE attach/detach protocol security (mobility-issues draft) Hi Gu, questions inline -- aldrin On Jul 12, 2012, at 3:01 AM, Guyingjie (Yingjie) wrote: > The MACs and VLANs fields in VDP tlv can be null if they are not necessary to > be transferred from End device to NVE. The VSI ID information can be used to > find out which VN the VM belongs to. From this point of view, I don't think > that we need a new protocol for L3. > Could the VSI Type ID be used to represent a generic service handle that is interpreted by a network manager to deliver service related configuration to the NVE? How large is the VSI ID? Seems to be only two octets from what I can gather -- this doesn't seem like it is large for environments where there are many defined network service instances/templates. > To support VN attach/detach on L3VPN discussed in the thread, IMHO, it's easy > to find suitable information or easily add new to /delete unnecessary field > from VDP. > > But there is still something to consider while using VDP in L3VPN case, > because VDP is defined to be running on ECP(Edge Control Protocol), which is > intended to operate between two peers over an IEEE802.1LAN. ECP has a > designated Ether-type. ECP can be used to transmit various Upper Layer > protocol, e.g. VDP and PE CSP(IEEE 802.1BR), and can carry more than one TLVs > in one ECPDU. > > In the case, where TES and NVE are on different physical entities, and using > L2. NVE receives ECP, decap the VDP TLV and send to upper layer for > processing. A L-ACK is sent to TES(or say End Device) before next ECPDU can > be sent from TES. > > If in the case where TES and NVE are on different physical entities, and > using L3 protocol, there are two ways that we can do: > 1) ECP is supported by router NVE, which I think is not difficult. > 2) another protocol is designated to carry VDP, correspondingly Hypervisor > must support this protocol, e.g. BGP > > > > > Best Regards > Gu Yingjie > > > -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 NAPIERALA, MARIA > H > 发送时间: 2012年7月12日 乐乐1:43 > 收件人: Paul Unbehagen > 抄送: Thomas Narten; Luyuan Fang (lufang); [email protected] > 主题: Re: [nvo3] TES-NVE attach/detach protocol security (mobility-issues draft) > > My main point was that VDP is not needed in a layer 3 solution since MACs and > VLANs are irrelevant to layer 3. > Dealing with a protocol which was defined for interoperability with bridging > would be unnecessary complication to a layer 3 solution. > > Maria > > > >> -----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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
