Thanks David, sorry again for late reply due to some issues.
Reply inline
On Sun, Aug 14, 2016 at 2:41 PM, Black, David
<david(_dot_)black(_at_)emc(_dot_)com> wrote:
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.
I do not understand why incorrect, usually having an architecture is making
standards
The focus of NVO3 standardization is specific protocols that interface
between components, see Section 13 of the draft.
This draft is not proposed-standard, so it is informational, so engineers
can start with as basic points. The components of the NVO3 need to
be determined, so the figure 1 needs to add NVAs, furthermore, the
interface to NVO3 should be determined. IMHO architecture should define all
components in the system and their interaction but also the
interface requirements or interface protocols. Overall, this is an
informational document, so if we explain that you mentioned now above it
can show what is out of scope.
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.
draft-ietf-nvo3-use-case-08
draft-ietf-nvo3-gue-04
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.
Ok, so could we clarify this in the draft as you mentioned now, because
IMHO when we don't mention it in the draft it can mean that it was not
included in such approach.
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.
but vDC was defined in the document, so I suggest you mention that it is
not allowed in nodes of NVO3.
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.
Ok, thanks,
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.
ok
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.
it is not same as the figure in 7365, NVA is missing in the draft.
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.
I mean devices or nodes, so we can know the node's principle functions, but
from the draft it was not clear to me. As what it can do and cannot do, I
usually in virtual environment want to know what it must not do.
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.
ok, that needs configuration issues I think, depending on the hypervisor
system.
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.
For security consideration in virtualizations, imho communication methods
and programming methods are both important. The interfaces with NVO3 will
determine these issues.
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?
yes agree not global, only when needed, as to have a unique packet method
for NVO3,
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”
ok
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> 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 mailing lists by 2016-08-12. Exceptionally, comments
may be
sent to 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/