Re: [armd] soliciting typical network designs for ARMD

Vishwas Manral <vishwas.ietf@gmail.com> Tue, 09 August 2011 20:26 UTC

Return-Path: <vishwas.ietf@gmail.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 4F14B5E8023 for <armd@ietfa.amsl.com>; Tue, 9 Aug 2011 13:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.966
X-Spam-Level:
X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.632, 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 ZkJFS6QlD8X5 for <armd@ietfa.amsl.com>; Tue, 9 Aug 2011 13:26:37 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 657DA5E8021 for <armd@ietf.org>; Tue, 9 Aug 2011 13:26:37 -0700 (PDT)
Received: by gxk19 with SMTP id 19so297863gxk.31 for <armd@ietf.org>; Tue, 09 Aug 2011 13:27:06 -0700 (PDT)
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=9h8EXG/kQXrLm3rdQXSTZ4AK1nDo9Tvx1VLhQ1UT5fo=; b=Np9u6BOWht2dbhv5ZJQijP5/dbwqK2STzvHT3N8b/mz+XbqB3vjWPwhuWLQQ4XYJ1s +yo0KOeyR8Hd0FWLVLO/t8PRbkT4uu6DVogMObtwmyNY0+sf1VPm+m4JhkXrOhH5bMRW E1Zca6BHx0dHVwIgfSmHcXBFVauYYG3kt+f3o=
MIME-Version: 1.0
Received: by 10.142.203.10 with SMTP id a10mr7004195wfg.51.1312921625232; Tue, 09 Aug 2011 13:27:05 -0700 (PDT)
Received: by 10.142.126.9 with HTTP; Tue, 9 Aug 2011 13:27:05 -0700 (PDT)
In-Reply-To: <CAP_bo1Ya7p+OS7fS40jE4+UZuhmeO+MAroC=CZK5sMEE625z8Q@mail.gmail.com>
References: <CAP_bo1b_2D=fbJJ8uGb8LPWb-6+sTQn1Gsh9YAp8pFs3JY_rrw@mail.gmail.com> <CAOyVPHTLYv=-GbjimpDr5NsxMUeWKtVKzStY9yxQO7s4YD2Ywg@mail.gmail.com> <CAP_bo1Ya7p+OS7fS40jE4+UZuhmeO+MAroC=CZK5sMEE625z8Q@mail.gmail.com>
Date: Tue, 09 Aug 2011 13:27:05 -0700
Message-ID: <CAOyVPHTcFr7F4ymQyXyECtS6f8z1XyZn40a_5WcpcjF9y0hZvQ@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Linda Dunbar <dunbar.ll@gmail.com>
Content-Type: multipart/alternative; boundary="000e0cd1446a17064904aa18630a"
Cc: armd@ietf.org
Subject: Re: [armd] soliciting typical network designs for ARMD
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: Tue, 09 Aug 2011 20:26:38 -0000

Hi Linda,

The data packets can be tunnelled at the ToR over say a GRE packet and the
core is a Layer-3 core (except for the downstream ports). So we could have
encapsulation/ decapsulation of L2 over GRE at the ToR.

The very same thing can be done at the hypervisor layer too, in which case
the entire DC network would look like a Layer-3 flat network including the
ToR to server link and the hypervisor would do the tunneling.

I am not sure if you got the points above or not. I know cloud OS companies
that provide the service and have big announced customers.

Thanks,
Vishwas
On Tue, Aug 9, 2011 at 11:51 AM, Linda Dunbar <dunbar.ll@gmail.com> wrote:

> Vishwas,
>
> In my mind the bullet 1) in the list refers to ToR switches downstream
> ports (facing servers) running Layer 2 and ToR uplinks ports run IP Layer 3.
>
>
> Have you seen data center networks with ToR switches downstream ports (i.e.
> facing servers) enabling IP routing, even though the physical links are
> Ethernet?
> If yes, we should definitely include it in the ARMD draft.
>
> Thanks,
> Linda
>   On Tue, Aug 9, 2011 at 12:58 PM, Vishwas Manral <vishwas.ietf@gmail.com>wrote:
>
>> Hi Linda,
>> I am unsure what you mean by this, but:
>>
>>    1. layer 3 all the way to TOR (Top of Rack switches),
>>
>> We can also have a heirarchical network, with the core totally Layer-3
>> (and having seperate routing), from the hosts still in a large Layer-3
>> subnet. Another aspect could be to have a totally Layer-3 network.
>>
>> The difference between them is the link between the servers and the ToR.
>>
>> Thanks,
>> Vishwas
>>   On Tue, Aug 9, 2011 at 10:22 AM, Linda Dunbar <dunbar.ll@gmail.com>wrote:
>>
>>> During the 81st IETF ARMD WG discussion, it was suggested that it is
>>> necessary to document typical data center network designs so that address
>>> resolution scaling issues can be properly described. Many data center
>>> operators have expressed that they can't openly reveal their detailed
>>> network designs. Therefore, we only want to document anonymous designs
>>> without too much detail. During the journey of establishing ARMD, we have
>>> come across the following typical data center network designs:
>>>
>>>    1. layer 3 all the way to TOR (Top of Rack switches),
>>>    2. large layer 2 with hundreds (or thousands) of ToRs being
>>>    interconnected by Layer 2. This design will have thousands of hosts under
>>>    the L2/L3 boundary router (s)
>>>    3. CLOS design  with thousands of switches. This design will have
>>>    thousands of hosts under the L2/L3 boundary router(s)
>>>
>>> We have heard that each of the designs above has its own problems. ARMD
>>> problem statements might need to document DC problems under each typical
>>> design.
>>> Please send feedback to us (either to the armd email list  or to the ARMD
>>> chair Benson & Linda) to indicate if we have missed any typical Data Center
>>> network designs.
>>>
>>> Your contribution can greatly accelerate the progress of ARMD WG.
>>>
>>> Thank you very much.
>>>
>>> Linda & Benson
>>>
>>
>