Subject: [nvo3] 答复: Re: proposed liaison text to IEEE 802.1 for VDP extension work

From: [email-masked]
Date: Fri, 8 May 2015 17:04:51 +0800

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.

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?

Thanks!

Zhongyu

"Larry Kreeger (kreeger)" <[email-masked]> 
2015/05/01 06:45

收件人
Lucy yong <[email-masked]>, "[email-masked]" 
<[email-masked]>, Liyizhou <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, nvo3 <[email-masked]>, Pat Thaler 
<[email-masked]>
主题
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-masked]>
Date: Thursday, April 30, 2015 7:13 AM
To: "[email-masked]" <[email-masked]>, Larry Kreeger <
[email-masked]>, Liyizhou <[email-masked]>
Cc: Liyizhou <[email-masked]>, "[email-masked]" <[email-masked]>, nvo3 
<[email-masked]>, Pat Thaler <[email-masked]>
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-masked] [mailto:[email-masked]] 
Sent: Thursday, April 30, 2015 2:18 AM
To: Larry Kreeger (kreeger); Lucy yong; Liyizhou
Cc: Liyizhou; Lucy yong; [email-masked]; 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. 

This is our concerns.

Thanks! 
Zhongyu 

"Larry Kreeger (kreeger)" <[email-masked]>
发件人:  "nvo3" <[email-masked]>
2015/04/30 07:42

收件人
Lucy yong <[email-masked]>, Liyizhou <[email-masked]>, "
[email-masked]" <[email-masked]>, 
抄送
Pat Thaler <[email-masked]>, "[email-masked]" <[email-masked]>, nvo3 <
[email-masked]> 
主题
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-masked]>
Date: Wednesday, April 29, 2015 1:26 PM
To: Liyizhou <[email-masked]>, "[email-masked]" <
[email-masked]>
Cc: Pat Thaler <[email-masked]>, "[email-masked]" <[email-masked]>, 
nvo3 <[email-masked]>
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-masked]] On Behalf Of Liyizhou
Sent: Wednesday, April 29, 2015 4:39 AM
To: [email-masked]
Cc: Pat Thaler; [email-masked]; 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-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2015 10:55 AM
To: Liyizhou
Cc: Liyizhou; [email-masked]; 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-masked]>
发件人:  "nvo3" <[email-masked]>
2015/04/28 10:07

收件人
"[email-masked]" <[email-masked]>, 
抄送
Pat Thaler <[email-masked]>, Liyizhou <[email-masked]>
主题
[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)
 
Cc: 
Ron Bonica (IETF NVO3 Technical Advisor)
Eric Gray (IETF Liaison to IEEE 802.1)
Alia Atlas (IETF Area Director for NVO3)
Dan Romascanu (IETF Liaison to the IEEE SA)
Jari Arkko (Chair, IETF)
Pat Thaler (Chair, IEEE 802.1 DCB Task Group)
Paul Nickolich (Chair, IEEE 802)
 
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-masked]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3
[附件 "image001.gif" 被 顾忠禹104484/user/zte_ltd 删除]

---

From: "TOUVE, Jeremy (Jeremy)** CTR **" <[email-masked]>
Date: Fri, 8 May 2015 19:28:30 +0000

In line>

From: nvo3 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 08, 2015 2:05 AM
To: Larry Kreeger (kreeger); Liyizhou; Lucy yong
Cc: Pat Thaler; [email-masked]; 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.

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-masked]<mailto:[email-masked]>>

2015/05/01 06:45

收件人

Lucy yong <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Liyizhou <[email-masked]<mailto:[email-masked]>>,

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>, Pat Thaler <[email-masked]<mailto:[email-masked]>>

主题

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-masked]<mailto:[email-masked]>>
Date: Thursday, April 30, 2015 7:13 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Larry Kreeger <[email-masked]<mailto:[email-masked]>>, Liyizhou <[email-masked]<mailto:[email-masked]>>
Cc: Liyizhou <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>, Pat Thaler <[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, April 30, 2015 2:18 AM
To: Larry Kreeger (kreeger); Lucy yong; Liyizhou
Cc: Liyizhou; Lucy yong; [email-masked]<mailto:[email-masked]>; 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.

This is our concerns.

Thanks!
Zhongyu

"Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
发件人:  "nvo3" <[email-masked]<mailto:[email-masked]>>

2015/04/30 07:42

收件人

Lucy yong <[email-masked]<mailto:[email-masked]>>, Liyizhou <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

抄送

Pat Thaler <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>

主题

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-masked]<mailto:[email-masked]>>
Date: Wednesday, April 29, 2015 1:26 PM
To: Liyizhou <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Pat Thaler <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, nvo3 <[email-masked]<mailto:[email-masked]>>
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-masked]] On Behalf Of Liyizhou
Sent: Wednesday, April 29, 2015 4:39 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Pat Thaler; [email-masked]<mailto:[email-masked]>; 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-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Wednesday, April 29, 2015 10:55 AM
To: Liyizhou
Cc: Liyizhou; [email-masked]<mailto:[email-masked]>; 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.

Thanks in advance!

Zhongyu
Liyizhou <[email-masked]<mailto:[email-masked]>>
发件人:  "nvo3" <[email-masked]<mailto:[email-masked]>>

2015/04/28 10:07

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

抄送

Pat Thaler <[email-masked]<mailto:[email-masked]>>, Liyizhou <[email-masked]<mailto:[email-masked]>>

主题

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.

Thanks a lot,

Yizhou

-----------

To: Glenn Parsons (Chair, IEEE 802.1 Working Group)<mailto:[email-masked]>

Cc:
Ron Bonica<mailto:[email-masked]> (IETF NVO3 Technical Advisor)
Eric Gray<mailto:[email-masked]> (IETF Liaison to IEEE 802.1)
Alia Atlas<mailto:[email-masked]> (IETF Area Director for NVO3)
Dan Romascanu (IETF Liaison to the IEEE SA)<mailto:[email-masked]>
Jari Arkko<mailto:[email-masked]> (Chair, IETF)
Pat Thaler<mailto:[email-masked]> (Chair, IEEE 802.1 DCB Task Group)
Paul Nickolich (Chair, IEEE 802)<mailto:[email-masked]>

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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3
[附件 "image001.gif" 被 顾忠禹104484/user/zte_ltd 删除]

---

From: [email-masked]
Date: Tue, 12 May 2015 14:40:34 +0800

Thanks for your comments.

For VN automatic provisioning, the main works may be related to how VN 
context can be created automatically in NVE and how VM automatically to 
join VN.

Regards,

"TOUVE, Jeremy (Jeremy)** CTR **" <[email-masked]> 
发件人:  "nvo3" <[email-masked]>
2015/05/09 03:28

收件人
"[email-masked]" <[email-masked]>, "Larry Kreeger (kreeger)" 
<[email-masked]>, Liyizhou <[email-masked]>, Lucy yong 
<[email-masked]>, 
抄送
Pat Thaler <[email-masked]>, "[email-masked]" <[email-masked]>, nvo3 
<[email-masked]>
主题
Re: [nvo3] 答复: Re:  proposed liaison text to IEEE 802.1 for VDP 
extension work

In line>
 
From: nvo3 [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Friday, May 08, 2015 2:05 AM
To: Larry Kreeger (kreeger); Liyizhou; Lucy yong
Cc: Pat Thaler; [email-masked]; nvo3
Subject: [nvo3] 答复: Re: proposed liaison text to IEEE 802.1 for VDP 
extension work

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 

收件人
Lucy yong <[email-masked]>, "[email-masked]" <
[email-masked]>, Liyizhou <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, nvo3 <[email-masked]>, Pat Thaler 
<[email-masked]> 
主题
Re: [nvo3] proposed liaison text to IEEE 802.1 for VDP extension work

ZhongYu, 

Lucy 

The terminology is ok. 

This is our concerns.

Thanks! 
Zhongyu 

收件人

- Larry 

Lucy

Hi Zhongyu,

Thanks,
Yizhou

Hi Yizhou and all,

Thanks in advance!

Zhongyu 

收件人

 
Hi folks,

Thanks a lot,

Yizhou 

-----------

Cc: 

Purpose: For action 

Attachments: (none) 

Body: 
Dear Glenn, 

Sincerely Yours,