Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC
Abdussalam Baryun <abdussalambaryun@gmail.com> Sat, 13 August 2016 14:41 UTC
Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B80012B05B; Sat, 13 Aug 2016 07:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96WPImTIMDFc; Sat, 13 Aug 2016 07:41:51 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3317112B01B; Sat, 13 Aug 2016 07:41:51 -0700 (PDT)
Received: by mail-qk0-x232.google.com with SMTP id f123so11266629qkd.1; Sat, 13 Aug 2016 07:41:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/2LqodEgweFXYY0sJUbXBLxUsS1VESrwjDTGvD4PH0s=; b=YHxsRbhdT+X4weAkdoMlnJzaIVZbh0UiS8+2TsOkvCa+kvEdV6j+98o/Ugh3VmNVOn MqoYJa52tBANkOEUiGec3+Quqy/BVACFpYvbdBx51NGg7gVyL1RhCJlzJUWXaA8oR6vQ EUGaWSZOTdA4lK5qR5K/FeRH7Jd6V0BVIYkjuxieuktR791UAZeMfI4tpXsvEFnJecla s8+Zc9AC/Du2Ydx2RWgnS0aC0pR/z9VomDJNGUyhEJdSMh4CxkrhIqqwb1fMqlvtVYHt ew7SowJ+8ctK/gfKnAozUOfgJNpv8X/WRYwFyeB40PjmO2eFZjpu/tzJFthS84iO1Lfb JCVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/2LqodEgweFXYY0sJUbXBLxUsS1VESrwjDTGvD4PH0s=; b=UO+7DBJe3BY7XiMUkcpstHhy66xT9ap0UzSck7WYeFxaRgzzfXYkCBvCHHLqp3FK8P ycTeIEFv4GvdBfdhjqssqpaSiHgfjaJcxBEFW+e7GxwoCugyTb62O8BK54nQuW3Pz7Ok aqLdD69YEOGPMnDf5Q4CSIh4EULvLD7f9oT1hVx5z7BJSMArVa+qxSwHnfQytzW4oF3D YhBrVgnats2EW3oG//NUhD7bFIJVGPqY7/H2aeL2/jzX8QxDWxtRKgBczaK295sjXMdu V6PvpP2Z8XUcMnycHrAmjI72+8Qh1uhyUHgcbnKLsvc+Q1QAOUUD1tydDJTYB9apm6NZ gz6Q==
X-Gm-Message-State: AEkoouubj1o88Zdwrk0Pt96WsUOYH4J0N2iPYio9+GqwY4ZIKjj6BpJHCos/A0Xe0AfG/C3ZVhHOBlgEcoC3Uw==
X-Received: by 10.55.163.4 with SMTP id m4mr23350953qke.110.1471099310247; Sat, 13 Aug 2016 07:41:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.81.137 with HTTP; Sat, 13 Aug 2016 07:41:49 -0700 (PDT)
In-Reply-To: <20160729230612.26953.29914.idtracker@ietfa.amsl.com>
References: <20160729230612.26953.29914.idtracker@ietfa.amsl.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Sat, 13 Aug 2016 16:41:49 +0200
Message-ID: <CADnDZ8_L2YBO7TB48ZpO5RPhsA=HmvwrC8CnqH8qEg8y4xg-cg@mail.gmail.com>
Subject: Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An Architecture for Data Center Network Virtualization Overlays (NVO3)) to Informational RFC
To: ietf <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c07702ad114160539f4ff8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Xx2RU67kI_QmlXlQOi13siGzedk>
Cc: draft-ietf-nvo3-arch@ietf.org, Matthew Bocci <matthew.bocci@nokia.com>, nvo3@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Aug 2016 14:41:54 -0000
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. 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. 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. Comment-3 The document needs to clarify the NVO3 architecture is it centralised, distributed, or hierarchical distributed for each d/c 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? 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. 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. comment-7 Figure 1 must show the TSI as it showed the TS!! 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. 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. 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. comment-10 In security section, it was not taken consideration/recommendation of using the IPsec technology, why. Editorial comments: draft>Tenant System Identifier AB> amend> Tenant System Interface draft>Domains be funneled through a particular device AB> amend> Domains be Tunneled through a particular device draft>Packets AB>Change to> NVO3 packets AB> You mention also TS packets. so that TS packet could be any protocol packet. 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@ietf.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@ietf.org mailing lists by 2016-08-12. Exceptionally, comments may be > sent to iesg@ietf.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/ > > > > > >
- RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Black, David
- RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Black, David
- Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Abdussalam Baryun
- Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Abdussalam Baryun
- RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Black, David
- Re: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Abdussalam Baryun
- RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Black, David
- RE: Last Call: <draft-ietf-nvo3-arch-06.txt> (An … Lucy yong