Hi Yves, In my interpretation, the NVA is a logically centralized function, and if that function happens to be co-resident on the same device as the NVE, then it is still the NVA (not the NVE). See other responses below.
- Larry From: "Yves Hertoghs (yhertogh)" <[email protected]<mailto:[email protected]>> Date: Friday, November 15, 2013 1:33 AM To: Larry Kreeger <[email protected]<mailto:[email protected]>>, Lucy yong <[email protected]<mailto:[email protected]>>, Xuxiaohu <[email protected]<mailto:[email protected]>>, "Bocci, Matthew (Matthew)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Larry, I guess this is where the abstraction that Xiahou is referring to can lead to confusion. In LISP the NVA function is mostly logically centralised, however the local cache at the xTR's are authoritative as well i.e. They can be seen as an extension of the NVA function. LK> I would not consider the caches in the NVEs to be part of the NVA. This is how DDT operates, the xTR's can be part of the DDT lookup (very similar to a DNS). LK> I admit, I've never looked into the details of DDT, but I was under the impression that the protocol between xTRs and MS/MRs was decoupled from whatever protocol MS/MRs use between themselves. e.g. you could use BGP tunnels, or DDT within the mapping system, but xTRs always use the same LISP protocol to the MS/MR and are oblivious to how the mapping system works internally (BGP tunnels or DDT). So perhaps my question is now: are the NVE and NVA entitities that we are talking about nodes, or functions within a node? Based on my understanding it is the latter, hence my interpretation that the pure NVE 'function' does not need a control-plane to interact with the NVE function on another node, although it could interact with the NVA function resident on the same node. LK> I still think it is useful for NVEs to be able to communicate directly with other NVEs in some cases, with the most useful example, where an NVE essentially sends the equivalent of a Host Unreachable ICMP message back to a source NVE when the destination TS is no longer connected to the decapsulating NVE. This doesn't necessarily communicate mapping information directly, but instead a notification that the source NVE may have a stale cache, or an indication that the source NVE should use an alternate mapping if they have another available (which may be useful during a VM migration event). Yves From: "Larry Kreeger (kreeger)" <[email protected]<mailto:[email protected]>> Date: Friday 15 November 2013 04:39 To: Cisco Hertoghs <[email protected]<mailto:[email protected]>>, Lucy yong <[email protected]<mailto:[email protected]>>, Xuxiaohu <[email protected]<mailto:[email protected]>>, Matthew Bocci <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Hi Yves, See inline. - Larry From: "Yves Hertoghs (yhertogh)" <[email protected]<mailto:[email protected]>> Date: Thursday, November 14, 2013 11:15 AM To: Lucy yong <[email protected]<mailto:[email protected]>>, Xuxiaohu <[email protected]<mailto:[email protected]>>, "Bocci, Matthew (Matthew)" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt I disagree with the need for an NVE to NVE control plane. LK> Yves, in section 3.2.5.2 of draft-hertoghs-nvo3-lisp-controlplane-unified-00 (near the bottom of page 11), it describes an ETR sending a Solicit Map Request message to an ITR directly. Given this, why do you disagree since your own draft describes an NVE sending a control message to another NVE? That doesn't mean that you can't colocate a portion of the distributed NVA with every NVE, which is the model that e.g. BGP/L3VPN or ISIS/TRILL uses. Yves From: Lucy yong <[email protected]<mailto:[email protected]>> Date: Thursday 14 November 2013 16:59 To: Xuxiaohu <[email protected]<mailto:[email protected]>>, Matthew Bocci <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt I share my view. The current architecture document is more focusing on NVE-NVA interface and assumes that NVA is able to obtain all VN and/or address mapping information’s that an NVE needs. That does implicitly indicate that no control plane protocol is needed between NVEs. (NVE-NVE data plane protocol is still needed). From the architecture perspective, if it allows the control plane protocol exist both between NVE-NVA and NVE-NVE, it may lead very complex solution and many operation issue; it has to resolve which information NVE should trust or use, i.e. from NVA or from NVE. Weather this means excluding TRILL or SPB, it is debatable. The current charter clearly states that NVO3 targets network virtualization over IP network. Beyond this point, TRILL has directory based solution, which fits into NVE-NVA architecture. SPB also have SPB-EVPN solution that also aligns with NVE-NVA architecture. IMO: NVE-NVA based control plane architecture and NVE-NVE based control plane architecture are both possible for NVO3, but not the combined architecture. As you said, it is true that NVE-NVE based architecture is useful in some small applications. Since TRILL and SBP already address it, NVO3 should only focus on the NVE-NVA based architecture. One of NVO3 goal is the scalability. Lucy From:[email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Xuxiaohu Sent: Thursday, November 14, 2013 2:58 AM To: Bocci, Matthew (Matthew); [email protected]<mailto:[email protected]> Subject: [nvo3] 答复: Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt Hi all, In the current arch draft, there is no mention of NVE-NVE protocol. Does it mean that there is no need for direct exchange of VN and/or address mapping information between NVEs? If so, Does it mean that the control plane mechanisms used by TRILL or SPB which depend on the NVE-NVE interaction are not suitable for multi-tenant data center networks anymore, leaving aside whether the underlay is IP or not. IMHO, the NVE-NVE protocol is still useful in some small and medium sized multi-tenant data center networks. AFAIK, most tenants within public cloud data centers are small and medium sized enterprises which usually don’t need a lot of VMs. That means the number of NVEs for most VNs would not be very large especially in the case where the NVE is deployed at physical switches, rather than hypervisors/servers. In this case, the VN membership can be discovered via IGP flooding and the address mapping information of a given VN could be directly exchanged among NVEs of that VN, without a need for a dedicated NVA. Best regards, Xiaohu 发件人:[email protected]<mailto:[email protected]> [mailto:[email protected]] 代表Bocci, Matthew (Matthew) 发送时间: 2013年11月13日 21:58 收件人:[email protected]<mailto:[email protected]> 主题: [nvo3] Poll for WG adoption and IPR check for draft-narten-nvo3-arch-01.txt This email begins a two week poll to help the chairs judge if there is consensus to adopt draft-narten-nvo3-arch-01.txt as an NVO3 working group draft. Please respond to this email on the list with 'support' or 'do not support'. Please also send any comments on the draft to the NVO3 list. Please consider whether this draft takes the right basic approach, and is a good basis for the work going forward (and potential future rechartering). It does not have to be perfect at this stage. Coincidentally, we are also polling for knowledge of any IPR that applies to this draft, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email whether or not you are aware of any relevant IPR. The draft will not be adopted until a response has been received from each author and contributor. If you are on the NVO3 WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. This poll closes on Friday 29th November 2013. Regards Matthew and Benson
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
