Subject: [nvo3] WGLC for draft-ietf-nvo3-framework-03

From: Benson Schliesser <[email-masked]>
Date: Thu, 12 Sep 2013 23:08:08 -0400

This email begins a one week working group last call for
draft-ietf-nvo3-framework-03.

Please review the draft and post any comments to the NVO3 list.

This working group last call will end on Friday 20-September-2013.

Cheers,
-Benson & Matthew

---

From: "Pat Thaler" <[email-masked]>
Date: Fri, 13 Sep 2013 19:17:01 +0000

The framework is in pretty good shape but not quite ready.

I am concerned that the framework is fuzzy on the relationship of hypervisors to tenant systems and NVEs. This became apparent during recent discussions on the security draft. I looked at the framework and the control plane drafts to see what they said before posting. The figures in the framework don't show the hypervisor - TS just connects to the NVE when in cases where the TS is a VM the hypervisor would be between them.  The figures in the hypervisor NVE draft show the hypervisor as containing the VMs but they don't show the TS.

"Hypervisor" only appears in the terminology section in the definition of NVE (which says the NVE could be part of a hypervisor virtual switch), in its own definition, and in the definitions of server and virtual switch. Clearly the role of the hypervisor in the framework should be described beyond that. At least, its role in communicating about TSes to the NVE and controlling the network behavior of TSes that it hosts (e.g. filtering).

Regards,
Pat

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benson Schliesser
Sent: Thursday, September 12, 2013 8:08 PM
To: [email-masked]
Subject: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Cheers,

-Benson & Matthew

---

From: Lucy yong <[email-masked]>
Date: Wed, 18 Sep 2013 20:03:50 +0000

Here is another point.  The goal of the draft is to provide a framework for Data Center Network Virtualization. Today, it is very common that the hosts in a data center may belong to the same subnet and different subnets. Bridging the hosts in the same subnet and routing them across different subnets are common networking practice. It seems that the Data Center Network Virtualization in industry does not intend to change this practice either (see VMware NSX).  However, current draft describes the framework for L2 VN overlay and L3 VN overlay, respectively, which is not clear to me that address a virtual network attached by the hosts that may belong to the same subnet and different subnets. Not clear to me if the L3VN overlay is sufficient to cover this case.

I brought this up before and like to bring it up again. An NVE can provide L2 and L3 service for a tenant system that attaches to a VN.  If the tenant system sends a packet to a destination that on the same subnet, it sends to that destination MAC directly and NVE forwards on the dMAC too. If the tenant system needs to send a packet to the destination on a different subnet, it sends the packet to the default router w/ default MAC. NVE can be the default router.  In this case, receiving the packets w/ NVE MAC as dMAC, NVE performs IP lookup to get a tunnel EP as well as dMAC and destination TS VN ID.  In L3 VN overlay model, NVE does not need to have default MAC address, no need to resolve the mapping between dest. IP and dMAC/VNID.  Should we address this in the framework?

Regards,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Friday, September 13, 2013 2:17 PM
To: Benson Schliesser; [email-masked]
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Regards,
Pat

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Benson Schliesser
Sent: Thursday, September 12, 2013 8:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Cheers,

-Benson & Matthew

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 19 Sep 2013 10:04:41 +0000

Thanks Pat for your feedback.

The framework is meant to provide a high-level view of the main nvo3 components. The architecture draft, draft-narten-nvo3-arch, is meant to provide add'l details.
In this latter draft, there is text about the relationship between hypervisors, TS's abd NVE's.

We have the following options:

- Leave the framework draft as is and let the architecture draft provide further details
- Cut and paste some text from the architecture draft
- You could provide specific text that you'd like to see included in the framework draft (after WG review)

I'm fine either way even if I favor the first option ;-) Let's hear from the WG and chairs.

Marc

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Friday, September 13, 2013 9:17 PM
To: Benson Schliesser; [email-masked]
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 19 Sep 2013 10:09:50 +0000

Lucy,

Section 2.3 does state that NVEs can support both L2 and L3 services.

Marc

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, September 18, 2013 10:04 PM
To: Pat Thaler; Benson Schliesser; [email-masked]
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Regards,
Lucy

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: Lucy yong <[email-masked]>
Date: Thu, 19 Sep 2013 15:12:25 +0000

Marc,

This statement does not mean to me that both L2 and L3 services may apply to one tenant network. It means that one NVE can instantiate multiple VNIs, some may provide L2 service and other may provide L3 service, to support multiple tenant networks.  This is needed for sure.  I see that two are different, do you?

Lucy

From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
Sent: Thursday, September 19, 2013 5:10 AM
To: Lucy yong; Pat Thaler; Benson Schliesser; [email-masked]
Subject: RE: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Lucy,

Marc

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Wednesday, September 18, 2013 10:04 PM
To: Pat Thaler; Benson Schliesser; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03
Here is another point.  The goal of the draft is to provide a framework for Data Center Network Virtualization. Today, it is very common that the hosts in a data center may belong to the same subnet and different subnets. Bridging the hosts in the same subnet and routing them across different subnets are common networking practice. It seems that the Data Center Network Virtualization in industry does not intend to change this practice either (see VMware NSX).  However, current draft describes the framework for L2 VN overlay and L3 VN overlay, respectively, which is not clear to me that address a virtual network attached by the hosts that may belong to the same subnet and different subnets. Not clear to me if the L3VN overlay is sufficient to cover this case.

Regards,
Lucy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Friday, September 13, 2013 2:17 PM
To: Benson Schliesser; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: Lucy yong <[email-masked]>
Date: Thu, 19 Sep 2013 16:12:36 +0000

Marc,

If we want to keep the framework in a high-level view, IMO, we at least need the following statement in section 2.3.

An NVE can provide L2 service, L3 service, or both to a tenant network and support multiple tenant networks.

Lucy

Lucy,

Marc

Regards,
Lucy

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 19 Sep 2013 17:52:37 +0000

Lucy,

This was implied but I will make this small editing change.

Thanks,
Marc

________________________________
From: Lucy yong [mailto:[email-masked]]
Sent: Thursday, September 19, 2013 6:13 PM
To: LASSERRE, MARC (MARC); Pat Thaler; Benson Schliesser; [email-masked]
Subject: RE: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Marc,

Lucy

Lucy,

Marc

Regards,
Lucy

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 20 Sep 2013 02:11:27 +0000

Hi Marc,

There was a fairly long email thread (actually a few) on the list regarding Tenant System Interfaces and how they relate to the VAPs, especially when the NVE is external to a hypervisor (search for threads with TSI in the subject).  I was hoping the Framework could define TSI and illuminate the relationship of TSI to VAP (e.g. cardinality).  I think this is the proper place for this.

 - Larry

From: <LASSERRE>, "MARC (MARC)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 19, 2013 3:04 AM
To: Pat Thaler <[email-masked]<mailto:[email-masked]>>, Benson Schliesser <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Marc

I am concerned that the framework is fuzzy on the relationship of hypervisors to tenant systems and NVEs. This became apparent during recent discussions on the security draft. I looked at the framework and the control plane drafts to see what they said before posting. The figures in the framework don’t show the hypervisor – TS just connects to the NVE when in cases where the TS is a VM the hypervisor would be between them.  The figures in the hypervisor NVE draft show the hypervisor as containing the VMs but they don’t show the TS.

“Hypervisor” only appears in the terminology section in the definition of NVE (which says the NVE could be part of a hypervisor virtual switch), in its own definition, and in the definitions of server and virtual switch. Clearly the role of the hypervisor in the framework should be described beyond that. At least, its role in communicating about TSes to the NVE and controlling the network behavior of TSes that it hosts (e.g. filtering).

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Fri, 20 Sep 2013 07:59:36 +0000

Hi Larry,

I do remember this discussion and I think this level of details should fall within the architecture document and not the framework document.

Thanks,
Marc

________________________________
From: Larry Kreeger (kreeger) [mailto:[email-masked]]
Sent: Friday, September 20, 2013 4:11 AM
To: LASSERRE, MARC (MARC); Pat Thaler; Benson Schliesser; [email-masked]
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Hi Marc,

 - Larry

Marc

Cheers,

-Benson & Matthew

---

From: Lucy yong <[email-masked]>
Date: Fri, 20 Sep 2013 12:35:32 +0000

Good.

One smaller editing change in the document:  s/a NVE/an NVE/

Lucy

From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
Sent: Thursday, September 19, 2013 12:53 PM
To: Lucy yong; Pat Thaler; Benson Schliesser; [email-masked]
Subject: RE: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Lucy,

Thanks,
Marc

To: LASSERRE, MARC (MARC); Pat Thaler; Benson Schliesser; [email-masked]<mailto:[email-masked]>

Lucy

From: LASSERRE, MARC (MARC) [mailto:[email-masked]]
Sent: Thursday, September 19, 2013 5:10 AM
To: Lucy yong; Pat Thaler; Benson Schliesser; [email-masked]<mailto:[email-masked]>
Subject: RE: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Lucy,

Marc

Regards,
Lucy

Regards,
Pat

Cheers,

-Benson & Matthew

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Sep 2013 16:38:19 -0400

Benson:

I took the odd approach of reading the document from start-to-finish to see
if it made sense. This document is so vague in places, it makes one wonder
why the authors included the text they did.   

Is this document temporary?  Some WG framework documents that summarize the
state of the opinions are temporary and put the final information in an
architecture document.  The document never goes to RFC, and is a living
summary of the WG actions. If this is the purpose  of this document, then
perhaps this document is sufficient.  

If this is RFC bound, then the text should be tightened so future people who
naively like me, read without the mail-list context.  IMHO - it needs a good
editing pass and clarity provided for several spots that are "vague".  I
second Pat's comment that the document is fuzzy without more details on
hypervisor.  In addition, the following text is confusing or without
explanation:

I'm sure the authors can improve the document readability and clarity.    -1
on the document ready for RFC now, but +1 on going forward. 

Sue 

 

Sue Hares

Text issues 

==================

Section  1.2: 

Text: 

Network Virtualization Authority (NVA):  . "An NVA is also known as a
controller". 

Sue Comment:  Being as this is in a definition state, this amount of
vagueness is not warranted.  Is it an OFS controller or some other type of
controller? 

Section 1.3: 

Text:  

"Depending on the scale, DC distribution, operations model, Capital
expenditure (CAP) and Operational expenditure (Opex) aspects, DC network
elements can act as strict L2 switches or provide IP routing capabilities,
including network service virtualization." 

Sue comment: Is the point of this statement: DC network elements can be L2
switches or L3 routers? If so, the sentence needs editorial aid.   Break it
into two pieces. 

Text: missed spelled switvches in the access switch section 6 lines down" 

Section 2.1 

Text: "Another example is the case where End system is the tenant system,
and the NVE function can be implemented by connected ToR." 

Technical comment:  Does this imply anything with the paragraph before (VM
in tenant system and NVE in host-server (co-located case)?  Or are we using
virtual switching technology from 802.1QBg or 802.1BR or Vxlan?  I realize
from all the other comments you are trying to be vague. This is so vague it
seems useless to place any requirements.  If it doesn't tie into some
portion of the architecture, why is it here? 

Section 3.1.5.4

"In certain cases, local NVE configuration may be sufficient while in other
cases, some tunneling related information  may need to be shared among NVEs.
The information that needs to be shared will be technology dependent. This
includes the discovery and announcement of the tunneling."

Editorial: If you are really trying to provide a list of key things the
overlay tunneling  is doing, why not just provide a list of options. 

Example for method: 

Potential information required to set up tunnels could include: 

1.       Pre-assigned addresses in tunnel encapsulation header, 

2.       Local NVE configured tunnel header information,

(All/some/none) of this information may need to be shared.

Section 3.2 - Multi-0homing:

Text: 

"When a tenant system is co-located with the NVE, the Tenant system is
single homed to the NVE via a virtual port." 

Technical question: Is this by definition within the architecture? Is this
because of the hypervisor (see Pat's comments)?  The vagueness here makes it
hard to confirm or deny any of the framework suggestions. 

Technical question: You specify "STP" or LAG" without specifying any of the
multi-path multi-link L2 protocols (TRILL/SPB, SPB-EMC).  Why is this? 

Text: "When the NVE providers a L3 service to the end system, it is possible
that no dynamic routing protocol is enabled between the end system and the
NVE.  The end system can be multi-homed to multiple physically separated L3
NVE over multiple interfaces.  When one of the links connected NVE fails,
the other interfaces can be used to reach the end system." 

Technical question: Does the first sentence imply something for the 2nd and
3rd?   Is this a requirement or a constant of nature or something that is
inherent in the framework?  I understand the possibilities (ARP, etc.), but
I'm truly confused why the authors choose to include these sentences here.
Why didn't the authors simply point to the fact that the systems were
designed with no single point of failure (hypervisor, virtual L2, virtual L3
interface, gw out of DC)? 

3.3 Text: 

"Solutions to maintain connectivity while a VM is moved are necessary in
case of "hot mobility" This implies that transport connections among VMs are
preserved. "

Comments:  Is this the transport connection the TCP, SCTP, . transport?  Or
is it OTT transport?  

3.3 text: "Optimal routing during a VM mobility is also an important aspect
to address.  It is expected that the VM's default gateway be as close as
possible to the server hosting the VM." 

Editorial Comment:  Why does the text not specify why the optimal routing is
important? The text does not tell. 

Technical comment: Some hint on why optimal routing is good will help people
decide what "close" and "good is".  A far away pre-allocated path may be
better than a close congested path. 

4.2.6/5 - Better visibility between overlays and underlays/Security 

Technical questions on security? 

Have you considered the security implications of having overlays know what
underlays are doing? Of so, where is this included in the text.  

How do you provide isolation and privacy of the mapping between overlay and
underlay?  Or is that something all should know? 

How do you protect the VM/NVE in the same devices from leaking this
information to other VMs/NVE?  Are all of the securities issues done via
ACLS (authentication) rather than authorization?  

Again, this review is based on reading a framework document without review
of a list.

I'm sure the authors can improve the document readability and clarity. 

Sue 

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Benson Schliesser
Sent: Thursday, September 12, 2013 11:08 PM
To: [email-masked]
Subject: [nvo3] WGLC for draft-ietf-nvo3-framework-03

 
 
Cheers,
-Benson & Matthew