Hi Linda, thanks for all the work. I’ll check this on Friday!
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
