Subject: [nvo3] FW: New Version Notification for draft-yong-nvo3-nve-01.txt

From: Lucy yong <[email-masked]>
Date: Tue, 12 Nov 2013 19:42:37 +0000

Hello NVO3 Community,

This is a new draft. This document specifies NVE data plane functionality. These functionality specifications are necessary for the interoperability between an NVE and its attached tenant systems and between the NVEs. The data plane functionality described in this document is independent of NVE or NVO3 control plane functionality. However the specifications in this document can support any control plane solution and are helpful in the control plane protocol development.

We love to hear people feedbacks on the draft. Some sections in the draft are not completed yet and will be updated in next version.

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 12:24 PM
To: Lucy yong
Subject: New Version Notification for draft-yong-nvo3-nve-01.txt

A new version of I-D, draft-yong-nvo3-nve-01.txt has been successfully submitted by Lucy Yong and posted to the IETF repository.

Filename:	 draft-yong-nvo3-nve
Revision:	 01
Title:		 Network Virtualization Edge (NVE)
Creation date:	 2013-11-11
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-yong-nvo3-nve-01.txt
Status:          http://datatracker.ietf.org/doc/draft-yong-nvo3-nve
Htmlized:        http://tools.ietf.org/html/draft-yong-nvo3-nve-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-yong-nvo3-nve-01

Abstract:
   This document specifies Network Virtualization Edge (NVE) data plane
   functionality for Network Virtualization Overlays (NVO3). These
   functionality specifications are necessary for the interoperability
   between an NVE and its attached tenant systems and between the NVEs.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Zu Qiang <[email-masked]>
Date: Wed, 13 Nov 2013 14:27:25 +0000

Hello, Lucy
	Nice document. It has many interesting text. A few clarification questions below.
- Very first comment: it would be good to make it clear in the draft what is the working assumption of the NVE function. I see you have many "out of scope" in the text. I understand that how the information is configured in the NVE is not in the scope. But it would be good to make it clear the what. For instance, it is better to make it clear that "assuming the TS has a MAC address configured if L2 service is provided by the NVO3. The TS MAC address may be configured via the VM Orchestration system which is out of the scope of this document."
- 3.1: We cannot assume that the NVE always knows that the TS has at least one L2/L3 address configured, right? It shall be that TS may have a L2 address configured if L2 service is supported by the NVO3 and TS may have a L2 and L3 address configured if L3 service is supported by the NVO3
- ARP is not the only way for peer MAC learning. Better to not limit ourselves to a pure IPv4 network . Needs to make it more generic to cover different network use cases, such as IPv6, 802.1, etc.
- same comments for the GW MAC address learning
- Destination address caching, Ingress filtering and Forwarding handling in the TS, is this an implementation? Or is this just a working assumption for some error case handling? Please clarify it. 
- 3.3, do you want to cover the distributed GW function? 
- Furthermore, what is the intention of this document? Is it an input document to the architecture draft? Or is it a standard track for NVE function level definition? If the intention of this draft is the NVE function level description, maybe we can work together. 
I'll send you more comments on the section 4. 

Have a nice day
Zu Qiang

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Lucy yong
>Sent: Tuesday, November 12, 2013 2:43 PM
>To: [email-masked]
>Subject: [nvo3] FW: New Version Notification for draft-yong-nvo3-nve-01.txt
>
>Hello NVO3 Community,
>
>This is a new draft. This document specifies NVE data plane functionality.
>These functionality specifications are necessary for the interoperability
>between an NVE and its attached tenant systems and between the NVEs. The
>data plane functionality described in this document is independent of NVE or
>NVO3 control plane functionality. However the specifications in this document
>can support any control plane solution and are helpful in the control plane
>protocol development.
>
>We love to hear people feedbacks on the draft. Some sections in the draft are
>not completed yet and will be updated in next version.
>
>Regards,
>Lucy
>
>A new version of I-D, draft-yong-nvo3-nve-01.txt has been successfully
>submitted by Lucy Yong and posted to the IETF repository.
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>nvo3 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nvo3

---

From: Lucy yong <[email-masked]>
Date: Thu, 14 Nov 2013 17:02:51 +0000

Hello Qiang,

Thanks. I like to make one thing clear about this document. It is to specify the data plane NVE functionality which is necessary for TS-NVE and NVE-NVE interoperability. It leaves the NVE or NV03 control plane functionality out of the scope. The NVO3 framework and architecture documents, IMO, aim on the framework/architecture so we can describe the requirements under the reference model. They are not meant to specify the component functionality for the interoperability purpose. This document aims on this purpose. People may see some similar descriptions between these documents here and there, but this document has the functionality specification for the interoperability.  

Please see inline.

-----Original Message-----
From: Zu Qiang [mailto:[email-masked]] 
Sent: Wednesday, November 13, 2013 8:27 AM
To: Lucy yong; [email-masked]
Subject: RE: New Version Notification for draft-yong-nvo3-nve-01.txt

Hello, Lucy

[Lucy] NVE configuration can be done by manually or automatically. That all we need to say here. How it is configured should not impact the NVE functionality. The document should not mandate how TS configuration that you give.

- 3.1: We cannot assume that the NVE always knows that the TS has at least one L2/L3 address configured, right? It shall be that TS may have a L2 address configured if L2 service is supported by the NVO3 and TS may have a L2 and L3 address configured if L3 service is supported by the NVO3
[Lucy] TS is ether configured with IP gateway address or not, in both case, TS use protocol like ARP to resolve Gateway MAC address. When L2/L3 NVE (i.e. distributed gateway function) is used, NVE has the MAC address for the distributed gateway and always responses that this MAC address in ARP reply regardless TS ARP request has IP gateway address or default address. NVE gets the TS gateway information from NVA. So it will forward the packets to the gateway when the packet has the destination IP addr as the gateway address. In this case, NVE serves as the first hop routing. If inter-VN is allowed at NVE, the NVE serves as the TS gateway role, directly forward the packet to another a VN on the NVE, the NVE performs the packet forwarding as of the packet from the second VN.

- ARP is not the only way for peer MAC learning. Better to not limit ourselves to a pure IPv4 network . Needs to make it more generic to cover different network use cases, such as IPv6, 802.1, etc.
[Lucy] agreed. We will describe other ways in next version.

- same comments for the GW MAC address learning
[Lucy] several common methods to achieve this. We do not need to invent another one. We just need to address how NVE to interwork with these methods in the draft.

- Destination address caching, Ingress filtering and Forwarding handling in the TS, is this an implementation? Or is this just a working assumption for some error case handling? Please clarify it. 
[Lucy] I don't know what is your point. TS can cache or not, NVE MUST work under both conditions.

- 3.3, do you want to cover the distributed GW function? 
[Lucy] Section 3 is to describe types of tenant system. Getaway is one of them. But it points out that the gateway may be implemented on NVE for some cases, where it is named as distributed GW function on NVE. The distributed GW function on NVE is not a tenant system. The draft specifies the distributed GW function, which is important for the interoperability.

- Furthermore, what is the intention of this document? Is it an input document to the architecture draft? Or is it a standard track for NVE function level definition? If the intention of this draft is the NVE function level description, maybe we can work together. 
I'll send you more comments on the section 4. 
[Lucy] I state it clearly in the top.

Many Thanks,
Lucy

Have a nice day
Zu Qiang

>These functionality specifications are necessary for the 
>interoperability between an NVE and its attached tenant systems and 
>between the NVEs. The data plane functionality described in this 
>document is independent of NVE or
>NVO3 control plane functionality. However the specifications in this 
>document can support any control plane solution and are helpful in the 
>control plane protocol development.
>
>We love to hear people feedbacks on the draft. Some sections in the 
>draft are not completed yet and will be updated in next version.
>
>Regards,
>Lucy
>
>Please note that it may take a couple of minutes from the time of 
>submission until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>