ietf
[Top] [All Lists]

RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC

2016-08-14 07:42:35
AB,

Thanks for the review.

David> Comments inline ...

Thanks, --David

From: Abdussalam Baryun [mailto:abdussalambaryun(_at_)gmail(_dot_)com]
Sent: Saturday, August 13, 2016 10:42 AM
To: ietf
Cc: matthew(_dot_)bocci(_at_)alcatel-lucent(_dot_)com; 
draft-ietf-nvo3-arch(_at_)ietf(_dot_)org; nvo3(_at_)ietf(_dot_)org; Alia Atlas; 
Matthew Bocci
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data 
Center Network Virtualization Overlays (NVO3)) to Informational RFC

Review for the document as per your request.

I would like to thanks the authors and the WG for this work.

In general this document is about data centres DCs, and using IP architecture, 
so this document is an architecture of the overlays above such network purpose. 
The management among both architectures is very essential for the best DC 
performance. The IP architecture is implemented in the network infrastructure 
but the NVO3 architecture is a Software Defined Network SDN architecture. 
Furthermore, DC virtualization has many advantages but increases complexity in 
all standard design. However, the draft needs more defining of the connection 
between the both architectures (i.e, implemented and software-defined) needs to 
be clarified in terms of interactions in both planes (data and control).

 My comments are as below, and suggestions are with the AB sign:-

Comment-1
The approach of the document needs to be more clear, as mentioned in the 
introduction:-

introduction>

It should be possible to build and implement individual components in isolation 
and have them work with other components with no changes to other components.

AB>amend> It should be possible to standardize and implement individual 
components in isolation and have them work with other components with no 
changes to other components.



David> That would be incorrect, as many components (e.g., NVAs) can be expected 
to have additional non-standard protocol (and other) interfaces beyond those 
specified  by the NVO3 standardization activity.   The focus of NVO3 
standardization is specific protocols that interface between components, see 
Section 13 of the draft.



introduction> This document differs from the framework document in that it 
doesn’t attempt to cover all possible approaches within the general design 
space. Rather, it describes one particular approach.



AB>  The introduction needs to answer:- Why you are having one such approach as 
mentioned above?

AB> If this document is for special approach, this needs to be for special use 
case which needs to be mentioned in title, because just saying '' an 
architecture'' is not clear.



David> This is where the NVO3 WG chose to focus.   I’ll add mention of that to 
the introduction.



Comment-2



AB> When defining an architecture we need to define all general components, 
connections, protocols, frames/packets, and services. VN and NV are explained 
used in this document, but still not well defined in terms of requirements, 
design-approaches, and network programming. The document does not define 
general/special nodes, links, and interfaces of such virtualized networks per 
control-data (d/c) plane approach. The document does not include virtual DCs 
and SANs in the definitions. However, looking into other documents under 
progress worked by the NVO3-WG, it is recommended that this architecture 
document should be referencing such work in progress.



David> Please suggest references.



Comment-3



The document needs to clarify the NVO3 architecture is it centralised, 
distributed, or hierarchical distributed for each d/c plane.



David> That’s not necessary, as all three structures are possible, particularly 
for the control plane.



Comment-4



How to identify each VM and configure its policy. or how to identify virtual 
DCs which have SAN and LAN. How to configure, Links that have LAN traffic and 
links that have SAN traffic, and links that do both traffic.  Is it using VN 
tagging only?



David> VM configuration is handled by the VM Orchestration System - see Section 
3.4.

David> Virtual DCs are not part of the NVO3 architecture.



David> Traffic identification is handled by VN identification via a Context ID. 
 This could be clearer - while Section 3 already indicates that  the Context ID 
serves this purpose,  I’ll also add text to item 4 in section 4.3 to indicate 
that VN identification is the purpose of the Context ID.



comment-5



Virtualization is for security, but why the nvo3-architecture addresses are 
using MAC and IP which is not good for security. Also this node identification 
was not mentioned in security consideration.



David> Virtualization is for much more than security, please see RFC 7364 
(Problem Statement: Overlays for Network Virtualization).   The key identifier  
for NVO3 security is the virtual network identifier, as opposed to node 
identifiers such as MAC and IP.  There’s also a  good discussion of security 
requirements in this area in the NVO3 Framework (RFC 7365) - I’ll add a 
reference to that discussion rather than repeat it here.



Comment-6

The ip architecture underlying needs to include IPv4 and/or IPv6, in one 
section you mention TTL which is only for IPv4, but what about IPv6.



David> Definitely a problem - that’s section 3.1.2, and it will be corrected.  
Thanks  for noticing!



comment-7



Figure 1 must show the TSI as it showed the TS!!



David> Figure 1 says that it is “Generic” - that figure is aligned with RFC 
7365, and TSI is clearly defined in Section 2.  It would be better to retain 
commonality with RFC 7365.



Figure 1 should say: L3 overlay networks, instead of: L3 overlay network, or 
mentioning that there may be VNs and NVDs. Also to show local and remote TSs 
and remote NVE.



David> The L3 overlay network supports multiple Virtual Networks (which may 
provide L2 or L3 service), so singular “network” is correct.



David> What are NVDs?  That term is not used in this draft.



comment-8



section 3.1.1> To provide complete virtualization the network should provide 
similar properties to the computing layer. The network infrastructure should be 
able to support arbitrary network topologies and addressing schemes. Each 
tenant should have the ability to configure both the computing nodes and the 
network simultaneously.



AB> IPv6 cannot be used by the VMs of a tenant if the underlying physical 
forwarding devices support only IPv4. The section should be clear about this 
issue.



David> Actually, IPv6 can be used in that case.  NVO3 is one of a number of 
technologies that are capable of encapsulating IPv6 in IPv4.



comment-9



section 3.1.1> Just as in the case with ports on Ethernet switches, a number of 
settings could be imagined.

AB> why use the word, imagined. I suggest to change it.



David> Ok, will change “could be imagined” to “are possible”



comment-10



In security section, it was not taken consideration/recommendation of using the 
IPsec technology, why.



David> It’s one of a number of possible ways to address the security 
requirements - I’ll add mention of it as an example with a reference to RFC 
4301.



Editorial comments:



draft>Tenant System Identifier



AB> amend> Tenant System Interface

David> That’s an embarrassing lapse, thanks for finding it, fixed.

draft>Domains be funneled through a particular device

AB> amend> Domains be Tunneled through a particular device



David> “funnelled” is correct in this context, “tunnelled” would be incorrect 
(e.g., tunnels may hide traffic from a firewall).



draft>Packets

AB>Change to> NVO3 packets

David> A global change to “NVO3 packets” will likely detract from clarity, so 
that seems like a bad idea.  Are there specific instances that should be 
changed?

AB> You mention also TS packets. so that TS packet could be any protocol packet.

David> It’s mentioned once, I’ll remove the “TS’ to change that instance to 
just “packets”

Thank you, and sorry for the late submit of the date 12 August, it was due to 
many electricity breaks.



best regards

AB

































kk



On Sat, Jul 30, 2016 at 1:06 AM, The IESG 
<iesg-secretary(_at_)ietf(_dot_)org<mailto:iesg-secretary(_at_)ietf(_dot_)org>> 
wrote:

The IESG has received a request from the Network Virtualization Overlays
WG (nvo3) to consider the following document:
- 'An Architecture for Data Center Network Virtualization Overlays
(NVO3)'
  <draft-ietf-nvo3-arch-06.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org<mailto:ietf(_at_)ietf(_dot_)org> mailing lists by 
2016-08-12. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org<mailto:iesg(_at_)ietf(_dot_)org> instead. In 
either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document presents a high-level overview architecture for
   building data center network virtualization overlay (NVO3) networks.
   The architecture is given at a high-level, showing the major
   components of an overall system.  An important goal is to divide the
   space into individual smaller components that can be implemented
   independently and with clear interfaces and interactions with other
   components.  It should be possible to build and implement individual
   components in isolation and have them work with other components with
   no changes to other components.  That way implementers have
   flexibility in implementing individual components and can optimize
   and innovate within their respective components without requiring
   changes to other components.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nvo3-arch/ballot/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/2320/
   https://datatracker.ietf.org/ipr/2538/