Subject: Re: [nvo3] comments on draft-ietf-nvo3-framework-05

From: Alia Atlas <[email-masked]>
Date: Wed, 19 Mar 2014 18:58:56 -0400

Hi,

I see that this draft has been awaiting a revised version for over a month.
 In addition to addressing Stewart's comments, please respond to my review
below as well.

As part of my standard processing for progressing routing drafts, I do a
review of drafts before requesting IETF Last Call or progressing the draft.

Regards,
Alia

---------- Forwarded message ----------
From: Alia Atlas <[email-masked]>
Date: Sat, Feb 15, 2014 at 12:35 PM
Subject: comments on draft-ietf-nvo3-framework-05
To: Stewart Bryant <[email-masked]>,
[email-masked]
Cc: Adrian Farrel <[email-masked]>

Hi all,

In general, this is a well written document.  I have a few questions
about some of the differences in functionality or assumptions between
this and the nvo3-problem-statement.

I agree with Stewart about the need for operational management
requirements.  I would also like to see a bit more thought given to
security - particularly around addressing concerns such as
anti-snooping and confidentiality.

More detailed comments follow:

1) In Sec 2.1:

"   It is also possible for NVEs to communicate with an external Network

   Virtualization Authority (NVA) to obtain reachability and forwarding
   information. In this case, a protocol is used between NVEs and
   NVA(s) to exchange information. OpenFlow [OF] is one example of such
   a protocol."

Can you please explain how OpenFlow is being used to do this?  From
looking at the referenced spec, I do not see it.  Certainly, OpenFlow
can be used for a switch to send packets with unrecognized addresses
up to the controller to be processed.  This seems like quite a reach
to claim that is what OpenFlow is doing.  I do not see the rationale
for mentioning this particular protocol here.

2)  In Sec 2.2: NVE hub and NVE spoke appear for the first and only time.

"For instance, an End Device can act as an NVE Spoke, while an access
switch can act as an NVE hub."

Can you please expand on what is meant in the draft?  What
functionality would be in an NVE spoke and what in an NVE hub?

3) In Sec 3.1.3, one option is "One VN Context identifier per Tenant".
 How does this satisfy the problem statement that says "Hence, there
is a one-to-many mapping between tenants and virtual network
instances."

Additionally, in Sec 3.1.3, the concept of globally unique vs. local
seems to be mixed up with the ideas of per-tenant, per-VNI, and
per-VAP.   I'd like to see some text that clarifies why this coupling
exists?  Presumably, it isn't impossible to satisfy the
problem-statement's need for one-to-many using globally unique
values??  If it is, I'd certainly want to see that clearly articulated
with reasons.

4) In Sec. 3.1.4, have you considered the possibility and advantages
of opportunistic encryption to support a stateless tunneling approach?
 Are any tunneling mechanisms with confidentiality considered beyond
IPSec?   Instead of ruling out stateful tunneling approaches, can you
decouple the management considerations (say your centralized
controller can specify the configuration in a rapid fashion) from the
scaling considerations from other pros/cons for stateless versus
stateful?   I'm particularly concerned because the only tunneling
mechanism with confidentiality that is mentioned is IPsec which is
stateful.  In looking at the Security considerations in the
problem-statement, it says "In addition to isolation, assurances
against spoofing, snooping, transit modification and denial of service
are examples of other important data plane considerations.  Some
limited environments may even require confidentiality."

Regards,

Alia