Hi Linda, I’ll clear my discuss next.
One minor comment on the updates text on timing: "The TS reachability update mechanisms should take significantly less time than the typical TCP/SCTP re-transmission Time-out window, so that end points' TCP/SCTP connections won't be impacted by a TS becoming bound to a different NVE." I would recommend the following wording: "The TS reachability update mechanisms should take significantly less time than the typical re-transmission Time-out window of a reliable transport protocol such as TCP and SCTP, so that end points' transport connections won't be impacted by a TS becoming bound to a different NVE.“ Also you say below: "It is important to have those use cases documented in RFC format for people in the future who didn't participate in the NVO3 early discussion to shape their work accordingly.“ I really don’t think this is a reason for publication as RFC. New people that start working in an existing working group always have the problem that they might have missed some previous discussions. If people come to the mailing list and ask question, it’s always possible to also point them to (expired) drafts. An RFC should also have a value in long-term archival which I don’t see here. However, I will not block this document for that reason because this should have been consider earlier in the process. However, I can just remind folks for future document to review if there is a value in publishing in the RFC series or if the time and energy of the contributors can at some point be focused on other work. Thanks for all the work to you and also David! Mirja > Am 14.02.2017 um 19:55 schrieb Linda Dunbar <[email protected]>: > > Mirja, > > I spent 3 hours talking with TSV-ART reviewer David Black over the phone last > week to go through the changes we made to address his comments and reached > agreement before we upload the draft. David indicated that the revision is > ready for publication. > > The updated draft and the following explanation should have addressed your > IESG comment: > There is one specific transport requirement on timing as stated in David > Black's transport review > (Thanks!) that must be addressed before publication > [Linda] David has reviewed our changes in the updated version (-16) and > agreed with the updated working. > > > but other parts could also benefit from stating requirements explicitly and > clearly (also see some comment in David's review). It also not clear what > these use cases and potential requirements derived from them means in terms > of needed protocol work in nvo3. > [Linda] The NVO3 use case draft describes some very important > interconnections, such as what is needed in DC NVO3 virtual network and SP > WAN L2/L3 VPN Interconnection, how/why SFs in DMZ need to terminate NVO3 > tunnels in order to perform the needed processing, and how Virtual DC > interconnect with external networks, etc. > It is important to have those use cases documented in RFC format for people > in the future who didn't participate in the NVO3 early discussion to shape > their work accordingly. The NVO3 WG has reached the consensus on publishing > this draft as informational RFC. > TSV-ART reviewer David Black said that "the use cases can no longer merged > with the NVO3 architecture draft as the RFC has been published". > > > From me it's not clear at all if nvo3 networks are actually that much > different compared to existing virtual networks such that any additional > protocol work is needed. > [Linda] this question is about if NVO3 should be charted. Not specific to > this draft. > > There is one nit (Boarder -> Border for the definition of ASBR). I will > upload a revision. > > Can you to revise your IESG review comment? > Thank you very much. > > Linda > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Black, David > Sent: 2017年2月13日 20:13 > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; Black, David <[email protected]> > Subject: Re: [nvo3] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15 > > The -16 version of this draft addresses the issues noted in the TSV-ART > review of the -15 version. I found one editorial nit in the added material > that is probably worthy of a note to the RFC Editor in the following term > that was added to Section 1.1: > > OLD > ASBR: Autonomous System Boarder Routers (ASBR) NEW > ASBR: Autonomous System Border Router > > I saw a few other editorial nits that will benefit from the RFC Editor's > usual attention to detail. This draft is now suitable for publication, e.g., > it no longer contains incorrect statements. > > I noted in the review that "I have not seen much value in this use case > draft," and that remains the case. Other NVO3 documents are better sources > for requirements (see RFCs 7364, 7365 & 8014, plus the multicast framework > draft), so this draft's purpose has been to record some relevant use cases. > With the NVO3 architecture draft published as RFC 8014, it is no longer > possible to add this use case content to that draft. > > As a reviewer, I leave the decision on the usefulness of publishing this use > case draft to the IESG. > > Thanks, --David > > > -----Original Message----- > > From: Black, David > > Sent: Tuesday, January 17, 2017 6:56 PM > > To: [email protected]; The IESG > > Cc: [email protected]; Black, David > > Subject: 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 :-). > > > > -- 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. > > > > - 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. > > > > [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]. > > > > [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. > > > > [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. > > > > - 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. > > > > 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" > > > > - 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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
