In line> From: nvo3 [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, May 08, 2015 2:05 AM To: Larry Kreeger (kreeger); Liyizhou; Lucy yong Cc: Pat Thaler; [email protected]; nvo3 Subject: [nvo3] 答复: Re: proposed liaison text to IEEE 802.1 for VDP extension work
Dual mode scenario is possible and it is different solution based on the same assumptions as split-NVE did. And the solution to this mode may be not so difficult. More information please refers to the in-line description. And the tNVE and nNVE terminlogy can also be used in dual mode scenario. And can it be accepted as an option to split-NVE architecture? We’ve also noted that additional extensions mentioned in the draft, for example, extension for diminishing the limitation of original VDP that the end device shall be directly connected to ToR. So for dual mode, we only need to clarify the requirement is reasonable or not. As you mentioned before, for manual configuration in dual mode internal NVE implementation, the VDP is not needed. But if VDP need to be extended to support automatic VN provisioning, the tNVE needs to implement some EVB bridge function to process the VDP message to realize the VM joining VN. In this case the VDP needs to be extended to indicate which NVE it prefers to. The following picture shows some more information. [cid:[email protected]] Maybe this scenario is very specific one, no further discussion are needed for liaison in this stage. May I ask some general question, do you interested in VN automatic provisioning in NVO3, if VDP can be extended to support or other mechanism supporting automatic provisioning? JT> VDP itself can support automatic provisioning through its exchanges. I believe that the main requirements for auto provisioning are between the nVNE and VNA in order to map VN name to VNID in some manner (and thus outside VDP). I am confused at the need to extend auto provisioning into a tVNE however. In most instances that I know of the same software that is managing the VMs, is also in sync with the NVA (in fact, is usually driving the NVA) and would be able to configure a the tNVE with the VN information necessary. Thanks! Zhongyu "Larry Kreeger (kreeger)" <[email protected]<mailto:[email protected]>> 2015/05/01 06:45 收件人 Lucy yong <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Liyizhou <[email protected]<mailto:[email protected]>>, 抄送 "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, nvo3 <[email protected]<mailto:[email protected]>>, Pat Thaler <[email protected]<mailto:[email protected]>> 主题 Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work I agree with Lucy and Yizhou that this is a very unlikely scenario. The NVE should either be contained in the End Device, or external ---agree. this is the common/regular scenario, the end device should self-contain the entire NVE functions, but it seems conflict with the concept of split-NVE which may result in the problems of: (1) how to partition the functionality between end device and external NVE; and (2) end device needs to negotiate with external NVE for the capability and related parameters or vice versa. Although, I still think it is possible to run in this type of dual mode, but it is not what is meant by the term split-NVE---Yes, dual mode and split-NVE are different solutions, which are probably based on the same assumptions, e.g. lack of processing power or offloading or something like that in some circumstances. If the NVE is internal to the End Device, then it communicates with the NVA and performs all encap/decap. The End Device needs access to the underlay for reaching other NVEs, and this is provisioned once with no need for VDP. If the NVE is external, VDP is needed to communicate the current state of VN connectivity (what VNs, what tenant addresses within that VN) to the external NVE. If there are NVEs both within a End Device and external (simultaneously), then the End Device just needs to decide which to use (how would it make that decision? ---maybe the solutions are simple, for example, either via the VDP/control plane protocol messages explicitly indicating the preference of which type of NVE or making the selection decisioning according to some internal/external NVE selection policy. ). There are no additional VDP requirements I can think of if you wanted your End Device to support this for some reason. - Larry From: Lucy yong <[email protected]<mailto:[email protected]>> Date: Thursday, April 30, 2015 7:13 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, Larry Kreeger <[email protected]<mailto:[email protected]>>, Liyizhou <[email protected]<mailto:[email protected]>> Cc: Liyizhou <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, nvo3 <[email protected]<mailto:[email protected]>>, Pat Thaler <[email protected]<mailto:[email protected]>> Subject: RE: Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work ZhongYu, Not sure if operator is interested in such configuration. Even yes, for this configuration, VN1’s NVE is on end device, i.e. co-located, so VDP is not needed for VN1 at all; Hypervisor will perform the mapping and encapsulation for VN1 traffic. VDP only handles VMs associated to VN2. Lucy From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Thursday, April 30, 2015 2:18 AM To: Larry Kreeger (kreeger); Lucy yong; Liyizhou Cc: Liyizhou; Lucy yong; [email protected]<mailto:[email protected]>; nvo3; Pat Thaler Subject: 答复: Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work The terminology is ok. The scenario please refer to the following picture. VN2, for example, needs more processing for QoS or/and ACL etc. been deployed in TOR/NVE. In this case, refers to EVB architecture(ER, S-VLAN component, C-VLAN component), should all VN1 and VN2's VDP messages be terminated in Hypervisor/NVE(tNVE), or all forwarded to ToR/NVE(nNVE)? It seems some filter mechanism needed to intercept VN1's VDP messages for local processing, while forward VN2's VDP messages to ToR/NVE for processing there. [cid:[email protected]] This is our concerns. Thanks! Zhongyu "Larry Kreeger (kreeger)" <[email protected]<mailto:[email protected]>> 发件人: "nvo3" <[email protected]<mailto:[email protected]>> 2015/04/30 07:42 收件人 Lucy yong <[email protected]<mailto:[email protected]>>, Liyizhou <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, 抄送 Pat Thaler <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, nvo3 <[email protected]<mailto:[email protected]>> 主题 Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work Yes, to be clear, the previous terminology of External NVE was changed to Split-NVE at the urging of Thomas Narten. It is the same architecture/functionality. Thomas felt the name change better reflected that their was some knowledge within the End Device of the External NVE that needed to be signaled. This awareness within the End Device was dubbed tNVE (tenant NVE), while the External NVE was dubbed nNVE (network NVE). If this naming change is causing more harm than good, then perhaps we should change it back. - Larry From: Lucy yong <[email protected]<mailto:[email protected]>> Date: Wednesday, April 29, 2015 1:26 PM To: Liyizhou <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Pat Thaler <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, nvo3 <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work I agree with Yizhou. Don’t know why operators want to configure that way. An NVE is either co-located or at external for a server, not per VM base. Split-NVE is a special design for co-located case, i.e. offloading. VDP usage for an external NVE and split-NVE are the same. Lucy From: nvo3 [mailto:[email protected]] On Behalf Of Liyizhou Sent: Wednesday, April 29, 2015 4:39 AM To: [email protected]<mailto:[email protected]> Cc: Pat Thaler; [email protected]<mailto:[email protected]>; nvo3 Subject: Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work Hi Zhongyu, Thanks for pointing out you would like to see the VDP extension work in previous emails. For the use case you brought up, I am not too sure why such a scenario is required and has not seen any discussions on it. It would be good if consensus to be reached on adding such use case to architecture or use case document before it is taken into consideration in liaison. Thanks, Yizhou From:[email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, April 29, 2015 10:55 AM To: Liyizhou Cc: Liyizhou; [email protected]<mailto:[email protected]>; nvo3; Pat Thaler Subject: 答复: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work Hi Yizhou and all, This is a formal liaison to IEEE, so it should cover all possible extension consideration in NVO3. The following are two more consideration. Firstly, as you may know, we posted a message: http://www.ietf.org/mail-archive/web/nvo3/current/msg04418.html. In it, we discussed and concluded it's possible to extend VDP to realize the VN automatic provisioning. Secondly, we wonder if VDP suitable for all the usage scenarios in NVO3, especially for the typical Hypervisor/NVE-ToR/NVE scenario, because it is different from VDP/EVB architecture (Hypervisor/EVB station - ToR/EVB Bridge). For example, when some VMs/VNs reside in Hypervisor/NVE and at the same time other VMs/VNs(VMs belong to the same Hypervisor) reside in ToR/NVE, results in Hypervisor works as EVB station while working as EVB brige simultaneously. If this understanding is right, it’s critical to VDP extension. Of course, these points are not discussed before in NVO3. If possible, please take them into account here. Thanks in advance! Zhongyu Liyizhou <[email protected]<mailto:[email protected]>> 发件人: "nvo3" <[email protected]<mailto:[email protected]>> 2015/04/28 10:07 收件人 "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, 抄送 Pat Thaler <[email protected]<mailto:[email protected]>>, Liyizhou <[email protected]<mailto:[email protected]>> 主题 [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work Hi folks, We are going to send a liaison to IEEE 802.1 to bring their attention to ietf-nvo3-hpvr2nve-cp-req draft and to suggest the work to extend VDP protocol based on the consensus reached during Dallas meeting. Chairs asked me to post the proposed text here for your review. Thanks a lot, Yizhou ----------- Liaison Statement： NVO3 Liaison to IEEE 802.1 From: Matthew Bocci and Benson Schliesser (Co-Chairs, IETF NVO3 Working Group) To: Glenn Parsons (Chair, IEEE 802.1 Working Group)<mailto:[email protected]> Cc: Ron Bonica<mailto:[email protected]> (IETF NVO3 Technical Advisor) Eric Gray<mailto:[email protected]> (IETF Liaison to IEEE 802.1) Alia Atlas<mailto:[email protected]> (IETF Area Director for NVO3) Dan Romascanu (IETF Liaison to the IEEE SA)<mailto:[email protected]> Jari Arkko<mailto:[email protected]> (Chair, IETF) Pat Thaler<mailto:[email protected]> (Chair, IEEE 802.1 DCB Task Group) Paul Nickolich (Chair, IEEE 802)<mailto:[email protected]> Purpose: For action Attachments: (none) Body: Dear Glenn, The IETF NVO3 Working Group has been developing the requirements for a Control Plane Protocol between server Hypervisors and Network Virtual Edge (NVE) devices in virtualized overlay networks. The current draft can be found at http://datatracker.ietf.org/doc/draft-ietf-nvo3-hpvr2nve-cp-req/. This requirements document suggests extending the VDP (VSI Discovery and Configuration Protocol) protocol specified by IEEE Std 802.1Qbg as a solution. We would particularly welcome IEEE 802.1 Working Group’s review of Section 5 of the draft. That section compares the conceptually similar terms in NVO3 and the VDP context. It also summarizes the potential technical extension work required for VDP to be used as the control plane protocol between the hypervisor and NVE. In view of the progress of this work, we would like to suggest IEEE 802.1 Working Group to use that draft as a base requirement reference for VDP extensions in the aforementioned context. Please note that the status of this draft in the IETF, that it is a “Working Group draft”, indicates that the Working Group considers it an appropriate starting point but it is still subject to change. While a determination has not yet been made that there is technical consensus on all the details of the draft, there is consensus on basing the Hypervisor to NVE protocol on VDP with appropriate extensions. Sincerely Yours, Matthew Bocci & Benson Schliesser IETF NVO3 Working Group Co-Chairs _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3_______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3 [附件 "image001.gif" 被 顾忠禹104484/user/zte_ltd 删除]
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
