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