Hi Lucy, Thanks for the response and suggested changes. The suggested changes are fine for anything that I don't comment on further here:
> [T-1] There's one minor transport issue in this draft that requires > correction in > Section 2. Basic NVO3 Networks: > > The TS reachability update mechanisms need be fast enough so that > the updates do not cause any communication disruption/interruption. > > That requirement is overstated. NVO3 technology can and does disrupt > communication by dropping packets when a TS (e.g., a virtual machine) moves to > a different network attachment point (i.e., NVE). [... snip ...] > [Lucy] how about: the update should not cause a disruption for applications > running on TSes. The TS reachability update mechanisms need to be fast enough to not cause significant disruption to applications that use the network (e.g., a protocol like TCP may see a few packet drops and have to retransmit, but does not drop the connection). Moving to application disruption from communication disruption is good - a concept that I'm looking to convey is that reliable transport protocols (like TCP) can hide some minor communication disruptions from applications. > [A] Section 2 of the draft is a problem. [... snip ...] > [Lucy] We can restate that the traffic from such applications is called DC > East- > West traffic in the end of first paragraph if that is helpful. IMO: Basic > NVO3 Virtual > Network is the right title for the section. Perhaps we can shorten Section 2 > description to focus on the use cases. A shortened Section 2 that focuses on use cases sounds promising. I'd like to see the rewritten text before commenting further. > [4] As written, this sentence in Section 4.2 is incorrect: > > As a result, a tunnel carrying NVO3 > network traffic must be terminated at the GW/firewall where the NVO3 > traffic is processed. > > as there are deployed "running code" counterexamples. [... snip ...] > [Lucy] Disagree. The use case in section 4.2 aims for a DC cloud application > for > Internet users, where DMZ is required. When using NVO3 technology to support > an DMZ application, multiple NVO3 virtual networks can be used to achieve the > goal. If that is not clear to you, we need to make it more clear. There is deployed "running code" that does that class of DMZ enforcement (of a logical DMZ) without terminating tunnels at GW/firewall nodes between zones. The sentence appears to only be correct when the DMZ is required to have physical boundaries. --- Editorial --- > I would suggest that the draft be written in terms of Virtual Machines beyond > this > point, with a sentence added after the above sentence to say that the draft is > written in terms of virtual machines as a motivating example of TSs for > clarity, but > the use cases apply to TSs in general, not just VMs. > [Lucy] This draft uses NVO3 terms. Personally, I prefer that way. Ok, it's the editors'/authors' choice on whether to make this editorial change. > In section 5 Summary, remove the following paragraph: > > DC services may vary, from infrastructure as a service (IaaS), to > platform as a service (PaaS), to software as a service (SaaS). > In these services, NVO3 networks are just a portion of such services. > > as those *aaS terms occur nowhere else in the draft, and hence this text > doesn't > summarize any prior material. > [Lucy] We will add a NIST reference in next version for these DC service > definition. The Summary is still not a good place to introduce new concepts and terminology - this paragraph might work better in the Introduction. Thanks, --David > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Thursday, January 19, 2017 5:24 PM > To: Black, David; [email protected]; The IESG > Cc: [email protected] > Subject: RE: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 > > Hi David, > > Thank you for your detail review and comments. Sorry for a delayed reply due > to > my business travel. > > I am the same as you who wish that some of your concerns should be caught out > and addressed in early stage. Unfortunately, we have to address them now. > Please see my reply inline below. > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Black, David > Sent: Tuesday, January 17, 2017 5:56 PM > To: [email protected]; The IESG > Cc: [email protected]; Black, David > Subject: [nvo3] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 > > Document: draft-ietf-nvo3-use-case-15 > Reviewer: David Black > Review Date: January 17, 2017 > IETF LC End Date: January 11, 2017 > IESG Telechat date: January 19, 2017 > > Review result: Has Issues > > I've reviewed this document as part of TSV-ART's ongoing effort to review key > IETF documents. These comments were written primarily for the transport area > directors, but are copied to the document's authors for their information and > to > allow them to address any issues raised. > Please always CC tsv-art at ietf.org if you reply to or forward this review. > > This draft describes use cases for Data-Center Network Virtualization over > Layer 3 > (NVO3) technology being worked on the NVO3 WG. > > I should apologize for this review coming relatively late - the desirability > of a TSV- > ART review of this draft was not discovered until after IETF Last Call had > concluded, and actually not until after an initial TSV-ART decision had been > made > to not review this draft. > > In the spirit of full disclosure, I have been an active member of the NVO3 WG, > and an author of two of its three published RFCs, RFC 7364 and RFC 8014. I > have > not seen much value in this use case draft, and for that > reason I did not carefully review it in the WG. I have no fundamental > objection to RFC publication of this draft, but having reviewed it in detail > now, I > believe it needs some serious attention before being approved for RFC > publication, and hope that the IESG concurs. > > -- TSV-ART review comments: > > [T-1] There's one minor transport issue in this draft that requires > correction in > Section 2. Basic NVO3 Networks: > > The TS reachability update mechanisms need be fast enough so that > the updates do not cause any communication disruption/interruption. > > That requirement is overstated. NVO3 technology can and does disrupt > communication by dropping packets when a TS (e.g., a virtual machine) moves to > a different network attachment point (i.e., NVE). > > This requirement should be restated in terms of disruption to transport > protocols > - it's ok to drop a packet or two thereby causing a TCP or SCTP > retransmission, but > dropping enough packets to cause termination of a TCP connection or SCTP > association is clearly unacceptable. > In contrast, UDP-based applications will see packet drops in this (and other) > scenarios, but avoidance of that is not an NVO3 goal - while the U in UDP does > not stand for Unreliable, in NVO3 context, this is a good way to think about > that > letter :-). > [Lucy] how about: the update should not cause a disruption for applications > running on TSes. > > -- Other review comments > > - Major Issue > > [A] Section 2 of the draft is a problem. While Section 1 characterizes > Section 2 as describing a use case referred to as "DC East-West traffic," > that use > case is not to be found in Section 2 (e.g., nothing in Section 2 appears to > distinguish East-West traffic from North-South traffic). In its current form, > Section 2 is really an NVO3 Background section, as it describes > NVO3 terminology in general terms - while it uses different text, nearly all > of the > material that it contains can be found elsewhere, e.g., RFC 8014 on NVO3 > Architecture (NB: This reviewer is an author of RFC 8014). Section 2's title > should > be changed to "NVO3 Background" or something similar, and Section 1 changed > accordingly. > [Lucy] We can restate that the traffic from such applications is called DC > East- > West traffic in the end of first paragraph if that is helpful. IMO: Basic > NVO3 Virtual > Network is the right title for the section. Perhaps we can shorten Section 2 > description to focus on the use cases. > > - Minor issues > > [1] The draft's use of the term "NVO3 network" is sloppy and imprecise. > This is actually an NVO3 Virtual Network or VN - the word "virtual" > should be inserted in all cases. > [Lucy] Agree to use term "NVO3 Virtual Network or VN" in the doc. Will be > changed in next version. > > [2] This text in section 3 is vague on what a VPN is: > > This, in turn, > becomes the case of interconnecting an NVO3 network and the virtual > private network (VPN) on the Internet or wide-area networks (WAN). > Note that a VPN is not implemented by NVO3 solution. > > By itself, the latter sentence is incorrect, however, reading onward, one > discovers that not all forms of VPNs are intended - section 3.1 uses an IPsec > VPN, > and section 3.2 uses a BGP/MPLS L3VPN. I would suggest deleting the second > sentence and rewriting the first to use these two technologies as an example, > e.g.: > > WAN connectivity to the virtual gateway can be provided by VPN > technologies such as IPsec VPNs [RFC4301] and BGP/MPLS IP > VPNs [RFC 4364]. > [Lucy] Like your proposed text. > > [3] The first paragraph in section 3.2 is very hard to understand for someone > who > is not already an expert in BGP/MPLS VPNs (RFC 4364 & RFC 7432) - e.g., it > contains many unexpanded acronyms from that domain - ASBR, PE, SP, etc., > none of which appear in this draft's terminology section. It is not > reasonable for a > general use case draft such as this to assume that degree of expertise in > another > technical domain. > [Lucy] We received this comments from other reviewer and will fix them in next > version including expanding acronyme and providing references. > > [4] As written, this sentence in Section 4.2 is incorrect: > > As a result, a tunnel carrying NVO3 > network traffic must be terminated at the GW/firewall where the NVO3 > traffic is processed. > > as there are deployed "running code" counterexamples. > > The underlying problem appears to be that the use case in section 4.2 > includes an > implicit, but unstated, requirement for physical network segmentation/ > isolation > via physical GW/firewall network nodes. That requirement needs to be stated, > and I suggest changing the section title to somehow convey this physical > segmentation/isolation requirement. > [Lucy] Disagree. The use case in section 4.2 aims for a DC cloud application > for > Internet users, where DMZ is required. When using NVO3 technology to support > an DMZ application, multiple NVO3 virtual networks can be used to achieve the > goal. If that is not clear to you, we need to make it more clear. > > - Editorial > > In Section 1. Introduction: > > The goal of > data center network virtualization overlay (NVO3) networks is to > decouple the communication among tenant systems from DC physical > infrastructure networks and to allow one physical network > infrastructure: > > Pluralize and edit to "The goals of ... are ... infrastructure to:" and edit > the > bulleted list so that each list item is a grammatically correct completion of > this > sentence in the singular (i.e., "The goal of ... is to:"). > > The paragraph about gateways in the Introduction ("An NVO3 network may > interconnect ..." seems out of place - try moving it to somewhere in Section > 2, > e.g., so that it comes after the definition of the vGW acronym in the > terminology > section. > [Lucy] ack > > In Section 1.1 Terminology: > > - DMZ definition should use the relative terms "more trusted" and > "less trusted" in place of the absolute terms "trusted" and "untrusted" > [Lucy] ack > > - In DC Operator definition: "A role who" -> "An entity that" That wording > should also be used instead of "A company that" in the definition of > DC Provider. > [Lucy] ack > > Some usage of NVO3 terminology, while correct, makes this draft less > accessible to those not familiar with the NVO3 WG. TS (Tenant System) > is a particular problem although this sentence near the start of Section 2 > that > introduces the term is fine: > > A TS can be a physical server/device or a virtual machine (VM) > on a server, i.e., end-device [RFC7365]. > > I would suggest that the draft be written in terms of Virtual Machines beyond > this > point, with a sentence added after the above sentence to say that the draft is > written in terms of virtual machines as a motivating example of TSs for > clarity, but > the use cases apply to TSs in general, not just VMs. > [Lucy] This draft uses NVO3 terms. Personally, I prefer that way. > > In section 4.1, use "physical servers" instead of "metal servers." The > latter isn't even a good term - "bare metal servers" was probably intended, > but > "physical servers" is the better term. > [Lucy] ack > > In section 5 Summary, remove the following paragraph: > > DC services may vary, from infrastructure as a service (IaaS), to > platform as a service (PaaS), to software as a service (SaaS). > In these services, NVO3 networks are just a portion of such services. > > as those *aaS terms occur nowhere else in the draft, and hence this text > doesn't > summarize any prior material. > [Lucy] We will add a NIST reference in next version for these DC service > definition. > > Thanks, > Lucy > > Thanks, --David > -------------------------------------------------------- > David L. Black, Distinguished Engineer > Dell EMC, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 Cell: +1 (978) 394-7754 > [email protected] <=== NEW === > -------------------------------------------------------- > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
