Subject: Re: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

From: Zu Qiang <[email-masked]>
Date: Mon, 2 Jun 2014 01:31:45 +0000

Hello, authors
	I have no objections to this adaptation. But I really prefer authors can make a clarifications on the scope of the draft. The terminologies used in the draft are not in line with the framework draft. The text in the introduction section is very confused. If I understand the draft correctly, the control protocol is between the NVE and the device where the TS hold. This covers the case where the VM is running on top of a hypervisor or on the server without a hypervisor. And the protocol is only used to report to the NVE about the TS (e.g. VM) statues (e.g. connection or disconnection). The configuration data (e.g. inner-outer address mapping table) is retrieved using NVA-NVE interface, not the hypervisor-NVE interface. Is that right understanding? 

Have a nice day
Zu Qiang

>-----Original Message-----
>From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew
>(Matthew)
>Sent: Wednesday, May 28, 2014 9:23 AM
>To: NVO3
>Subject: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-
>00
>
>This email begins a two week poll to help the chairs determine if there is
>consensus to adopt draft-yizhou-nvo3-hpvr2nve-cp-req-00 as an PWE3
>working group draft.
>
>The draft can be found here:
>http://www.ietf.org/id/draft-yizhou-nvo3-hpvr2nve-cp-req-00.txt
>
>Please read the draft and indicate to the list if you support adoption, or if you
>do not support adoption (giving reasons).
>
>Please note that this is only a call for adoption. There needs to be consensus
>that this draft is a good basis for the work, but it does not need 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 PWE3 WG email list but are not listed as an author or
>contributor, then please explicitly respond regarding IPR only if you are aware
>of any IPR that has not yet been disclosed in conformance with IETF rules.
>
>The poll for adoption will close in two weeks time, on Friday 6th June.
>
>Matthew and Benson
>
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: Eric Gray <[email-masked]>
Date: Mon, 2 Jun 2014 12:38:58 +0000

Support

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, May 28, 2014 9:23 AM
To: NVO3
Subject: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

This email begins a two week poll to help the chairs determine if there is consensus to adopt draft-yizhou-nvo3-hpvr2nve-cp-req-00 as an PWE3 working group draft.

Please read the draft and indicate to the list if you support adoption, or if you do not support adoption (giving reasons).

Please note that this is only a call for adoption. There needs to be consensus that this draft is a good basis for the work, but it does not need 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 PWE3 WG email list but are not listed as an author or contributor, then please explicitly respond regarding IPR only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

Matthew and Benson

---

From: "Black, David" <[email-masked]>
Date: Mon, 2 Jun 2014 11:56:17 -0400

Hi Zu,

> 	I have no objections to this adaptation. But I really prefer authors can
> make a clarifications on the scope of the draft. The terminologies used in the
> draft are not in line with the framework draft.

Yes - this is the initial merge of text from three drafts written by at least
four authors, so there's quite a bit of work still to be done, including lining
up terminology with the problem statement, framework and architecture drafts.
I do want to thank Yizhou for doing the bulk of the text surgery involved so far.

> If I understand the draft correctly, the control
> protocol is between the NVE and the device where the TS hold. This covers the
> case where the VM is running on top of a hypervisor or on the server without a
> hypervisor. And the protocol is only used to report to the NVE about the TS
> (e.g. VM) statues (e.g. connection or disconnection). The configuration data
> (e.g. inner-outer address mapping table) is retrieved using NVA-NVE interface,
> not the hypervisor-NVE interface. Is that right understanding?

That's close enough, although the "server without a hypervisor" case probably
needs some more discussion, as the TS is not expected to be involved in this
control protocol, so the control protocol may not extend to the server in all
variants of that case.  OTOH, NVA-NVE interactions are definitely out of scope
for this draft; instead, see draft-ietf-nvo3-nve-nva-cp-req-02 for requirements
on those interactions.

Thanks,
--David

> From: nvo3 [mailto:[email-masked]] On Behalf Of Zu Qiang
> Sent: Sunday, June 01, 2014 9:32 PM
> To: Bocci, Matthew (Matthew); NVO3
> Subject: Re: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-
> 00
> 
> Hello, authors
> 	I have no objections to this adaptation. But I really prefer authors can
> make a clarifications on the scope of the draft. The terminologies used in the
> draft are not in line with the framework draft. The text in the introduction
> section is very confused. If I understand the draft correctly, the control
> protocol is between the NVE and the device where the TS hold. This covers the
> case where the VM is running on top of a hypervisor or on the server without a
> hypervisor. And the protocol is only used to report to the NVE about the TS
> (e.g. VM) statues (e.g. connection or disconnection). The configuration data
> (e.g. inner-outer address mapping table) is retrieved using NVA-NVE interface,
> not the hypervisor-NVE interface. Is that right understanding?
> 
> Have a nice day
> Zu Qiang
> 
>

---

From: Zu Qiang <[email-masked]>
Date: Mon, 2 Jun 2014 16:41:43 +0000

Thanks David for your clarification. I do support this draft and also would like to contribute. The "server without a hypervisor" case is more referring to the  For the Physical Network Service Appliance with an External NVE case which is included in figure 1 of the draft. Of cause, we can discuss it more. For the clarification text, I would prefer to have it in the updated version of the draft. But this can be done after the adaptation. 

Have a nice day
Zu Qiang

>From: Black, David [mailto:[email-masked]]
>Sent: Monday, June 02, 2014 11:56 AM
>To: Zu Qiang; NVO3
>Subject: RE: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-
>req-00
>
>Hi Zu,
>
>> 	I have no objections to this adaptation. But I really prefer authors
>> can make a clarifications on the scope of the draft. The terminologies
>> used in the draft are not in line with the framework draft.
>
>Yes - this is the initial merge of text from three drafts written by at least four
>authors, so there's quite a bit of work still to be done, including lining up
>terminology with the problem statement, framework and architecture drafts.
>> If I understand the draft correctly, the control protocol is between
>> the NVE and the device where the TS hold. This covers the case where
>> the VM is running on top of a hypervisor or on the server without a
>> hypervisor. And the protocol is only used to report to the NVE about
>> the TS (e.g. VM) statues (e.g. connection or disconnection). The
>> configuration data (e.g. inner-outer address mapping table) is
>> retrieved using NVA-NVE interface, not the hypervisor-NVE interface. Is
>that right understanding?
>
>for this draft; instead, see draft-ietf-nvo3-nve-nva-cp-req-02 for
>requirements on those interactions.
>
>Thanks,
>--David
>
>> 	I have no objections to this adaptation. But I really prefer authors
>> can make a clarifications on the scope of the draft. The terminologies
>> used in the draft are not in line with the framework draft. The text
>> in the introduction section is very confused. If I understand the
>> draft correctly, the control protocol is between the NVE and the
>> device where the TS hold. This covers the case where the VM is running
>> on top of a hypervisor or on the server without a hypervisor. And the
>> protocol is only used to report to the NVE about the TS (e.g. VM)
>> statues (e.g. connection or disconnection). The configuration data
>> (e.g. inner-outer address mapping table) is retrieved using NVA-NVE
>interface, not the hypervisor-NVE interface. Is that right understanding?
>>
>> Have a nice day
>> Zu Qiang
>>
>>
>> >This email begins a two week poll to help the chairs determine if
>> >there is consensus to adopt draft-yizhou-nvo3-hpvr2nve-cp-req-00 as
>> >an PWE3 working group draft.
>> >
>> >Please read the draft and indicate to the list if you support
>> >adoption, or if
>> you
>> >that this draft is a good basis for the work, but it does not need 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
>> >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 PWE3 WG email list but are not listed as an author
>> >or contributor, then please explicitly respond regarding IPR only if
>> >you are
>> aware

---

From: ramki Krishnan <[email-masked]>
Date: Tue, 3 Jun 2014 22:10:56 -0700

Support.

Thanks,
Ramki

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, May 28, 2014 6:23 AM
To: NVO3
Subject: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

Matthew and Benson

---

From: [email-masked]
Date: Fri, 6 Jun 2014 11:14:16 +0800

I read this draft and found it is helpful to extend the candidate 
protocols for the communication between hypervisor and NVE. So, I support 
the WG adoption for it.

Thanks,
Hongjun Zhai
---------------------------------------------
Add: No.68 Zijinghua Road, Yuhuatai District,
Nanjing City, R.P. China, 210012

Tel: +86 025 52877345
Email: [email-masked]
---------------------------------------------

ramki Krishnan <[email-masked]> 
发件人:  "nvo3" <[email-masked]>
2014-06-04 13:10

收件人
"Bocci, Matthew (Matthew)" <[email-masked]>, NVO3 
<[email-masked]>
抄送

主题
Re: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

Support.

Thanks,
Ramki

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew 
(Matthew)
Sent: Wednesday, May 28, 2014 6:23 AM
To: NVO3
Subject: [nvo3] Poll for WG adoption of 
draft-yizhou-nvo3-hpvr2nve-cp-req-00

This email begins a two week poll to help the chairs determine if there is 
consensus to adopt draft-yizhou-nvo3-hpvr2nve-cp-req-00 as an PWE3 working 
group draft.

Please read the draft and indicate to the list if you support adoption, or 
if you do not support adoption (giving reasons).

Please note that this is only a call for adoption. There needs to be 
consensus that this draft is a good basis for the work, but it does not 
need 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 PWE3 WG email list but are not listed as an author or 
contributor, then please explicitly respond regarding IPR only if you are 
aware of any IPR that has not yet been disclosed in conformance with IETF 
rules.

Matthew and Benson

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 10 Jun 2014 16:52:34 -0700

This looks like a reasonable starting point.

But I have some comments...

The document seems to focus only on the case where the TS to NVE is
accomplished using L2 connectivity.  Is there a reason it chooses to
exclude L3 connectivity?  If so, what is the rationale for that?  It would
be good to document that.

Second, it talks about the case where a TS forwards using multiple MAC
addresses and requires the registration of all of the MAC addresses.  But
what about the case where the TS is a transparent appliance?  In that case,
it may not have MAC addresses to register and may operate simply by
flipping the VLAN ID.

Finally, being a requirements document, it shouldn't discuss solution, yet
it gets into defining state machines and provides the exemplary details of
VDP (but no details for any of the other solutions).

Anoop

> 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.
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 11 Jun 2014 14:32:26 +0000

Hi Anoop,

Thank you for the great comments. Yes, the requirement should apply to both L2 and L3 connectivity. We will make that clear in next version. Yes, we should not give the detail solution in requirement draft, will fix that too.

Thanks,
Lucy

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Tuesday, June 10, 2014 6:53 PM
To: NVO3
Subject: Re: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

The document seems to focus only on the case where the TS to NVE is accomplished using L2 connectivity.  Is there a reason it chooses to exclude L3 connectivity?  If so, what is the rationale for that?  It would be good to document that.

Second, it talks about the case where a TS forwards using multiple MAC addresses and requires the registration of all of the MAC addresses.  But what about the case where the TS is a transparent appliance?  In that case, it may not have MAC addresses to register and may operate simply by flipping the VLAN ID.

Finally, being a requirements document, it shouldn't discuss solution, yet it gets into defining state machines and provides the exemplary details of VDP (but no details for any of the other solutions).

Anoop

-----Original Message-----
From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, May 28, 2014 6:23 AM
To: NVO3
Subject: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

Matthew and Benson

_______________________________________________
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

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Thu, 12 Jun 2014 00:48:18 +0000

Hi Anoop,

See my responses inline, marked with LK>.

Thanks, Larry

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 10, 2014 4:52 PM
To: NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

LK> From my perspective, L2 connectivity works well (for either L2 service or L3 service) because all data center switches (and Hypervisor virtual switches) are already VLAN enabled, so L2 has a built in way to keep tenant traffic separate between the End Devices and the external NVE.  If the connectivity to an external NVE were L3, there would need to be something to differentiate each tenant's traffic (e.g. some kind of encapsulation)…but since one of the big reasons for using an external NVE is to offload the encap/decap from software on a Hypervisor to external hardware, that would completely defeat the purpose.

LK> A VM running as a transparent bridge was indeed one of the use cases I had in mind for a TS with multiple MAC addresses.  From the perspective of the L2 NVE, it has no idea whether the MAC address is actually "owned" by a transparent bridge, or whether it is simply emitting the frames as it bridges them.  Note that the TS does not actually do the registering with the external NVE.  The End Device housing the TS (e.g. Hypervisor) does the registering.  For example, when a VM emits a frame with a previously unseen source MAC, the Hypervisor virtual switch would detect it and then register the new address.

LK> This came from one of the merged drafts.  Some felt is was a very informative example to look at.  We are not trying to imply it is the solution, which is why it is in a Appendix and label "Illustrative".

Anoop

-----Original Message-----
From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Bocci, Matthew (Matthew)
Sent: Wednesday, May 28, 2014 6:23 AM
To: NVO3
Subject: [nvo3] Poll for WG adoption of draft-yizhou-nvo3-hpvr2nve-cp-req-00

Matthew and Benson

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Jun 2014 11:00:37 -0400

Support as co-author and I am not aware of IPR on this document.

Thomas

> 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).
> 
> you are aware of any IPR that has not yet been disclosed in
> conformance with IETF rules.
>