Sue, Thanks for your input. Please see my comments inline.
Marc ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Susan Hares Sent: Friday, September 20, 2013 10:38 PM To: 'Benson Schliesser'; [email protected] 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 protected] [mailto:[email protected]] On Behalf Of Benson Schliesser Sent: Thursday, September 12, 2013 11:08 PM To: [email protected] 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
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
