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 protected]> Date: Sat, Feb 15, 2014 at 12:35 PM Subject: comments on draft-ietf-nvo3-framework-05 To: Stewart Bryant <[email protected]>, [email protected] Cc: Adrian Farrel <[email protected]> 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
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
