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

From: "LASSERRE, MARC (MARC)" <[email-masked]>
Date: Thu, 3 Oct 2013 15:40:31 +0000

Sue,

Thanks for your input. Please see my comments inline.

Marc

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, September 20, 2013 10:38 PM
To: 'Benson Schliesser'; [email-masked]
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

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.
Ok, I will break this sentence 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?
The point was not to be vague and to provide specific examples instead.
The previous paragraphs describe that TS and NVE functions can either be co-located or in separate components. The sentence you quoted is an example of the latter, i.e. such as in a non-virtualized case.

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.

The intent was not to provide an exhaustive list but to stay generic.
How about saying for the last sentence "For instance, potential information could include tunnel identity, encapsulation type, and/or tunnel resources"?

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.
Yes, it is part of the architecture. I will add the word "effectively" to clarify what was meant.
"When a tenant system is co-located with the NVE, the Tenant system is  *effectively* single homed to the NVE via a virtual port."

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?

Section 3.2 does say "techniques such as LAG or STP". These are just examples.

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)?
How about saying in the last sentence "Whether dynamic routing is enabled or not, multihoming can be used to protect against single points of failure."?

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?

I will replace "transport connections"  with "connectivity".

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.
Correct. How about saying "It is expected that the path to the VM's default gateway assures adequate performance to VM applications."?

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.
I will add a bullet point in section to say:

- It is desirable to restrict the types of information that can be exchanged between overlays and underlays (e.g. topology information)

How do you provide isolation and privacy of the mapping between overlay and underlay?  Or is that something all should know?
Not sure I understand. Please provide some text you'd like to see added.

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?

Section 4.2.6. says that better visibility may be desirable. Future solutions that may support this functionality would have to describe and/or address respective security aspects.
A sentence saying so could be added at the end of his section.

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

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: "Susan Hares" <[email-masked]>
Date: Thu, 3 Oct 2013 11:53:51 -0400

Marc and Benson: 

If you are ok, I'll take the word alterting portion of this debate off line
to private email exchange between us, and summarize the results to the list.

If not, I'll word-smith debate online.

Sue 

From: LASSERRE, MARC (MARC) [mailto:[email-masked]] 
Sent: Thursday, October 03, 2013 11:41 AM
To: Susan Hares; 'Benson Schliesser'; [email-masked]
Subject: RE: [nvo3] WGLC for draft-ietf-nvo3-framework-03

Sue,

Marc

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Susan Hares
Sent: Friday, September 20, 2013 10:38 PM
To: 'Benson Schliesser'; [email-masked]
Subject: Re: [nvo3] WGLC for draft-ietf-nvo3-framework-03

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.  

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?  

The previous paragraphs describe that TS and NVE functions can either be
co-located or in separate components. The sentence you quoted is an example
of the latter, i.e. such as in a non-virtualized case.

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: 

How about saying for the last sentence "For instance, potential information
could include tunnel identity, encapsulation type, and/or tunnel resources"?

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.  

Yes, it is part of the architecture. I will add the word "effectively" to
clarify what was meant.

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

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?  

Section 3.2 does say "techniques such as LAG or STP". These are just
examples.

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)?  

How about saying in the last sentence "Whether dynamic routing is enabled or
not, multihoming can be used to protect against single points of failure."?

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.  

Correct. How about saying "It is expected that the path to the VM's default
gateway assures adequate performance to VM applications."?

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

- It is desirable to restrict the types of information that can be exchanged
between overlays and underlays (e.g. topology information) 

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?  

Section 4.2.6. says that better visibility may be desirable. Future
solutions that may support this functionality would have to describe and/or
address respective security aspects.

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

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