Subject: [Tsv-art] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15

From: "Black, David" <[email-masked]>
Date: Tue, 17 Jan 2017 23:55:43 +0000

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-masked]  <=== NEW ===
--------------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Jan 2017 00:07:21 +0000

Ok, I've completed and sent the review of this draft.  One of the ADs will need to put that review into the datatracker, which currently indicates that TSV-ART will not review this draft ;-).  I only found one minor transport issue (incorrect requirement on communication disruption/interruption) ... but ...

I also found a major issue (one of the three use case categories is effectively missing), and a number of minor issues.

On terminology, we (the IETF) are stuck with a lot of it, but I did complain about TS (Tenant System) and suggest that the draft be mostly rewritten in terms of Virtual Machines (VMs).  That should help some with clarity and seems (IMHO) to be about the limit of what's reasonable, aside from pointing out that the section on use of BGP/MPLS VPNs is almost incomprehensible to those who aren't already familiar with them.

Enjoy ;-), --David

> -----Original Message-----
> From: Black, David
> Sent: Tuesday, January 17, 2017 6:56 PM
> To: [email-masked]; The IESG
> Cc: [email-masked]; Black, David
> Subject: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jan 2017 11:19:45 -0800

Thanks, David.

I think (hope) the feedback will be useful. The group seems disorganized
but not resistant to guidance.

Joe

On 1/17/2017 4:07 PM, Black, David wrote:
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Lucy yong <[email-masked]>
Date: Thu, 19 Jan 2017 22:24:09 +0000

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-masked]] On Behalf Of Black, David
Sent: Tuesday, January 17, 2017 5:56 PM
To: [email-masked]; The IESG
Cc: [email-masked]; Black, David
Subject: [nvo3] TSV-ART Telechat review of draft-ietf-nvo3-use-case-15

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.

[T-1] There's one minor transport issue in this draft that requires correction in Section 2. Basic NVO3 Networks:

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.

   This, in turn,

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. 

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

   The goal of

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

[Lucy] ack

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

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

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

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Black, David" <[email-masked]>
Date: Fri, 20 Jan 2017 17:41:53 +0000

Hi Lucy,

Thanks for the response and suggested changes.  The suggested changes are fine
for anything that I don't comment on further here:

> 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

  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.

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

Ok, it's the editors'/authors' choice on whether to make this editorial change.

> [Lucy] We will add a NIST reference in next version for these DC service

The Summary is still not a good  place to introduce new concepts and terminology -
this paragraph might work better in the Introduction.

Thanks, --David

> From: Lucy yong [mailto:[email-masked]]
> Sent: Thursday, January 19, 2017 5:24 PM
> To: Black, David; [email-masked]; The IESG
> Cc: [email-masked]
> Subject: RE: TSV-ART Telechat review of draft-ietf-nvo3-use-case-15
> 
> Hi David,
> 
> 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.
> 
> 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.
> 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
> 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.
> 
> 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.
> 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 :-).
> 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
> 
> 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.:
> 
> [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.
> 
> 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
> 
> 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
> 
> 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.