Hi Maria, If I remembered correctly, "end-system L3VPN" proposed that end-system (i.e., physical server) act as PE routers (i.e., NVE) and use XMPP instead of BGP as a L3VPN signaling with XMPP signaling gateways. Of course, I haven't check whether the recent "end-system L3VPN" reversions have made changes as I mentioned before.
In fact, there has been a L3VPN+host route based DCVPN proposal referred to as Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-08) (proposed two year earlier) which covers the scenario where the L3NVE and TES are located at different physical devices. Best regards, Xiaohu > -----邮件原件----- > 发件人: NAPIERALA, MARIA H [mailto:[email protected]] > 发送时间: 2012年7月12日 11:39 > 收件人: Xuxiaohu; Larry Kreeger (kreeger); Luyuan Fang (lufang); Paul > Unbehagen > 抄送: Thomas Narten; [email protected]; Lucy yong > 主题: RE: [nvo3] TES-NVE attach/detach protocol security (mobility-issues > draft) > > Xiaohu, > > > I guess the current "end-system L3VPN" proposal should belong to case > > 1, rather than case 3 where NVE and TES are not in the same physical > > device, unless the "end-system L3VPN" makes some changes as follows: > > XMPP is only used as a signaling of VM attachment/detachment events > > between hypervisors and ToRs, rather than as a replacement of BGP-based > > L3VPN signaling. In this way, the NVE functionality (i.e., L3VPN PE) is > > performed on the ToRs, rather than on the end-systems. > > Actually, "end-system L3VPN" proposal covers both cases. In the case NVE > functionality is on external switch, it operates as an XMPP server processing > requests from end-systems and as a client of one or more controllers/signaling > gateways. It relays to the signaling gateways(s) messages it receives from > the end-system. In this scenario, the VPN routing information the NVE > receives from a signaling gateway is not propagated to the end-system. > > > Maria _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
