Hi Mirja,
The value of this document was debated in the WG several times. NVO3 WG has
reached the consensus about publishing this draft as informational RFC. We can
work with David to address his concerns. IETF allows that individuals have
different opinions, and has a policy to go with the consensus.
Personally, I don't think that we should debate following concerns at this
stage.
"It also not clear what these use cases and potential requirements derived from them
means in terms of needed protocol work in nvo3. 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."
Regards,
Lucy
-----Original Message-----
From: Mirja Kuehlewind [mailto:[email protected]]
Sent: Thursday, January 19, 2017 5:00 AM
To: The IESG
Cc: [email protected]; Matthew Bocci; [email protected];
[email protected]; [email protected]
Subject: Mirja Kühlewind's Discuss on draft-ietf-nvo3-use-case-15: (with
DISCUSS and COMMENT)
Mirja Kühlewind has entered the following ballot position for
draft-ietf-nvo3-use-case-15: Discuss
When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this introductory
paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-use-case/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I agree with Alvaro and Suresh that this document doesn't seem to be very
useful as a stand alone document. However, if published it should at least
state requirements clearly. There is one specific transport requirement on
timing as stated in David Black's transport review
(Thanks!) that must be addressed before publication 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.
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.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
For you convince, I post David's full review here:
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
