Re: [dc] Comment of draft-dalela-dc-requirements

Bhumip Khasnabish <vumip1@gmail.com> Sat, 14 January 2012 00:07 UTC

Return-Path: <vumip1@gmail.com>
X-Original-To: dc@ietfa.amsl.com
Delivered-To: dc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D761621F84DA for <dc@ietfa.amsl.com>; Fri, 13 Jan 2012 16:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level:
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 XqrLuEbZt1sc for <dc@ietfa.amsl.com>; Fri, 13 Jan 2012 16:07:37 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE71C21F84C3 for <dc@ietf.org>; Fri, 13 Jan 2012 16:07:36 -0800 (PST)
Received: by iaae16 with SMTP id e16so5364968iaa.31 for <dc@ietf.org>; Fri, 13 Jan 2012 16:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hOeXAP12KkEOlB+izLL1aJnGFYOuUR8y7jp1VcQUUxo=; b=nH2cn923d7LTLCvJF0pJZfsfleERic3i9ir3whqi8wWdrmGP+pJjSlt4nrcIeIjOkV M/1FtYoJ/2SqiFAnmMHQ+BkLG6fZZlmDzKuhFtXcwSKgPgK57f4EtmQDqV0V97BIrPNt 4WWx/Znq3qdRrzSYosFKpbMmUdZywg5CU1U2I=
MIME-Version: 1.0
Received: by 10.50.45.195 with SMTP id p3mr221021igm.2.1326499653861; Fri, 13 Jan 2012 16:07:33 -0800 (PST)
Received: by 10.50.77.197 with HTTP; Fri, 13 Jan 2012 16:07:33 -0800 (PST)
In-Reply-To: <CAH==cJxfmae0u0bSF4cn_haLgY1T-vnw2102PApzYtj5Aty=GQ@mail.gmail.com>
References: <CAH==cJxfmae0u0bSF4cn_haLgY1T-vnw2102PApzYtj5Aty=GQ@mail.gmail.com>
Date: Fri, 13 Jan 2012 19:07:33 -0500
Message-ID: <CANtnpwhFJ746ooi9GUCxfBqsOXu14hDka0D9inhh5pPq3U_ZTA@mail.gmail.com>
From: Bhumip Khasnabish <vumip1@gmail.com>
To: Lizhong Jin <lizho.jin@gmail.com>
Content-Type: multipart/alternative; boundary="14dae934061ba9c1a604b671c4c1"
Cc: Lizhong Jin <lizhong.jin@zte.com.cn>, adalela@cisco.com, dc@ietf.org
Subject: Re: [dc] Comment of draft-dalela-dc-requirements
X-BeenThere: dc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Data Center Mailing List <dc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dc>, <mailto:dc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dc>
List-Post: <mailto:dc@ietf.org>
List-Help: <mailto:dc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dc>, <mailto:dc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jan 2012 00:07:38 -0000

Hello Ashish,
Hello Mr. Lizhong,

Please note that, we are also working on a draft related to virtual machine
(and virtual network element) mobility and interconnection
(http://www.ietf.org/id/draft-khasnabish-vmmi-problems-00.txt).
Would appreciate comments and  suggestions. Thanks.
Best.
Bhumip



On Mon, Jan 9, 2012 at 10:00 AM, Lizhong Jin <lizho.jin@gmail.com> wrote:

> Hi Ashish,
> I have several comments to this requirement. Thanks.
>
> Section 5.3, Multi-tenancy problem. From my side, the multi-tenancy
> problem is not only the scalability of segmentation-ID problem, it is also
> required to isolate performance and security among multi-tenant. For
> example, one tenant should not suffer denial-of-service attacks by other
> tenant within same datacenter. A detailed example is, the huge broadcast
> traffic from one tenant should not influence the performace and
> availability of other tenants.
>
> Section 5.3, "The use of L3 VRFs also poses similar challenges of
> scaling". The challenge for VRF is quite different with VLAN. The challenge
> for VRF is the scalability of forwarding table. And you also said:"With
> VRFs, these entries will be present even if there is no traffic from a host
> to other hosts in the VRF". I think this could be optimized that the FIB
> would store only active route entries, while the RIB would store all route
> entries.
>
> Section 5.5, last paragraph about mobility. It seems that this paragraph
> is not much related with "network convergence", but is about "host mobility
> impact to the network resource". While I find that, section 5.1 is about
> the "host mobility impact to L2/3 forwarding", 5.10 is about the "host
> mobility impact to forwarding tables". Suggest to re-organize the three
> parts which are all related with impact of host mobility.
>
> Regards
> Lizhong
>
> _______________________________________________
> dc mailing list
> dc@ietf.org
> https://www.ietf.org/mailman/listinfo/dc
>
>