Hi Brian,
Thanks for your comments. See my replies inline.
Marc
-----Original Message-----
From: nvo3 [mailto:nvo3-bounces(_at_)ietf(_dot_)org] On Behalf Of Brian
E Carpenter
Sent: Saturday, May 24, 2014 10:46 PM
To: ietf(_at_)ietf(_dot_)org
Cc: nvo3(_at_)ietf(_dot_)org
Subject: Re: [nvo3] Last Call:
<draft-ietf-nvo3-framework-06.txt> (Framework for DC Network
Virtualization) to Informational RFC
A few comments below. I can't help feeling that NVO3 is
creating a monster, however.
Hopefully not... The intent being to reuse as many existing solutions and to
describe the actual gaps to offer a scalable DC solution.
4.1. Pros & Cons
...
- Traffic carried over an overlay may not
traverse firewalls and
NAT devices.
I don't know whether "may not" means "might not" or "must
not", and that completely determines what the sentence means.
For example, does it mean this?
- Traffic carried over an overlay might fail to
traverse firewalls and
NAT devices.
Yes, it does. It will be changed accordingly.
I suggest reviewing every instance of "may not" to avoid this
ambiguity.
Ok.
- Hash-based load balancing may not be optimal as the hash
algorithm may not work well due to the limited number of
combinations of tunnel source and destination
addresses. Other
NVO3 mechanisms may use additional entropy
information than
source and destination addresses.
Load balancing appears out of nowhere here. Are we supposed
to assume that load balancing is a requirement? Load
balancing between what - between different tenants, different
physical DCs, different servers?
It is mentionned as one possible challenge. I agree this sentence is a bit out
of place though.
Hence, I have no problem removing it. This is actually discussed in much more
details in the dataplane requirements draft.
The text implied load balancing of TS traffic by NVEs over underlay paths.
Also, there seems to be an assumption that load balancing is
only based on addresses. Actually it's usually based on ports
as well, and more or less by definition they are invisible to
the underlay.
So it's worse than "may not work well".
The text does mention that "additional entropy information" can be used. NVEs
have such visibility before sending traffic over the underlay.
I would have expected QoS support to also appear as a
challenge, for similar reasons. Isn't giving tenants a fair
share of the underlay capacity an issue? (There's a mention
of traffic engineering later, but surely you don't want this
issue to be handled by operators twiddling knobs?)
Indeed. This is discussed in section 4.2.6.
4.2.4. Path MTU
...
TCP will
adjust its maximum segment size accordingly.
And how will that work for non-TCP traffic?
It is the while point of this section... It is either Path MTU discovery or IP
fragmentation.
It is also possible to rely on the NVE to perform
segmentation and
reassembly operations without relying on the Tenant
Systems to know
about the end-to-end MTU. The assumption is that
some hardware
assist is available on the NVE node to perform such
SAR operations.
However, fragmentation by the NVE can lead to performance and
congestion issues due to TCP dynamics and might require new
congestion avoidance mechanisms from the underlay
network [FLOYD].
In a word: yuck. Surely you should be recommending against
anything like that, or any attempt to re-segment TCP on the fly.
This sentence needs some rewording as the last sentence (starting with
"however") was meant to say that this is not a desirable solution.
Finally, the underlay network may be designed in
such a way that the
MTU can accommodate the extra tunneling and possibly
additional NVO3
header encapsulation overhead.
Surely you should be recommending this, which is by far the
safest solution. (And of course it should allow for the IPv6
minimum MTU.)
Agreed.
7. References
...
[NVOPS] Narten, T. et al, "Problem Statement :
Overlays for Network
Virtualization", draft-narten-nvo3-overlay-problem-
statement (work in progress)
Nit: that draft was replaced a long time ago by
http://tools.ietf.org/html/draft-ietf-nvo3-overlay-problem-statement
(which is already in the RFC Editor queue).
Ok
Brian
_______________________________________________
nvo3 mailing list
nvo3(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nvo3