[armd] Comments on draft-ietf-armd-problem-statement-02

<david.black@emc.com> Thu, 24 May 2012 07:43 UTC

Return-Path: <david.black@emc.com>
X-Original-To: armd@ietfa.amsl.com
Delivered-To: armd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD921F855B for <armd@ietfa.amsl.com>; Thu, 24 May 2012 00:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY6ub4st9n8S for <armd@ietfa.amsl.com>; Thu, 24 May 2012 00:43:13 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id ECE2F21F8559 for <armd@ietf.org>; Thu, 24 May 2012 00:43:12 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4O7hC6L031290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <armd@ietf.org>; Thu, 24 May 2012 03:43:12 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for <armd@ietf.org>; Thu, 24 May 2012 03:42:57 -0400
Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q4O7guQ7004705 for <armd@ietf.org>; Thu, 24 May 2012 03:42:57 -0400
Received: from mx15a.corp.emc.com ([169.254.1.236]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Thu, 24 May 2012 03:42:56 -0400
From: david.black@emc.com
To: armd@ietf.org
Date: Thu, 24 May 2012 03:42:50 -0400
Thread-Topic: Comments on draft-ietf-armd-problem-statement-02
Thread-Index: Ac05gNIczm79MGjhRS2Zwok5HhCMRg==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71205813C96@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [armd] Comments on draft-ietf-armd-problem-statement-02
X-BeenThere: armd@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of issues associated with large amount of virtual machines being introduced in data centers and virtual hosts introduced by Cloud Computing." <armd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/armd>, <mailto:armd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/armd>
List-Post: <mailto:armd@ietf.org>
List-Help: <mailto:armd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/armd>, <mailto:armd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 07:43:13 -0000

Overall, I think this draft is worth publishing as an Informational RFC to
record the work that has been done on understanding this problem area.

I think the draft needs some work, primarily because section 4 seems
to be missing a crisp conclusion.  Text should be added at the end of section
4 to make the following three points (that set up the problem discussion in
section 7):

(1)  The L3 to Access Switches design in Section 4.4.1 is the only design
that constrains L2 domain size in a fashion that avoids ARP/ND scaling problems.

(2) That design in 4.4.1 is limited and limiting, in that it cannot address
some of the requirements discussed elsewhere in Section 4 that lead to larger
L2 domains.

(3) Hence the ARP/ND scaling problem exists and is important.

I would move section 4 to after section 6 so that the problem details in section
7 follow section 4 directly.

----------- Nits --------------

-- Section 1 --

Delete ARMD WG mentions in 2nd paragraph.  A published
RFC is an archival document that will live on long after the ARMD WG
is an artifact of history.

-- Section 2 --

In the definition of Application: "a software process" -> "software".

Limit the definition of "Host" to "A computer system on the network".  The rest
of the definition is explanation that belongs elsewhere.

Definition of L2 domain seems to confuse "802.1Q domain" of a set of VLANs with
an individual VLAN (e.g., as broadcast domain).  If both concepts are needed,
two definitions are needed.

Definition of Virtual machine (VM): This definition is overly restrictive to
complete hardware emulation approaches.  There are paravirtualization
approaches for which the second sentence is false, but the overall intent of
the definition that a VM behaves like a physical server for most network
purposes is correct.

Definition of EoR: "network network" -> "network".  Also, should say that this
is the next level of switching above ToR (above = in the direction of the network
core).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------