Re: [rrg] Next topic?

"Michael K. Smith - Adhost" <mksmith@adhost.com> Fri, 13 May 2011 02:03 UTC

Return-Path: <mksmith@adhost.com>
X-Original-To: rrg@ietfa.amsl.com
Delivered-To: rrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B9C13001C for <rrg@ietfa.amsl.com>; Thu, 12 May 2011 19:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axJIAP6kjZAn for <rrg@ietfa.amsl.com>; Thu, 12 May 2011 19:03:10 -0700 (PDT)
Received: from mail-in04.adhost.com (mail-in04.adhost.com [216.211.128.134]) by ietfa.amsl.com (Postfix) with ESMTP id CFA8413001A for <rrg@irtf.org>; Thu, 12 May 2011 19:03:10 -0700 (PDT)
Received: from AD-EXH02.adhost.lan (unknown [10.142.0.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail-in04.adhost.com (Postfix) with ESMTPS id 08B94614F82; Thu, 12 May 2011 19:03:09 -0700 (PDT) (envelope-from mksmith@adhost.com)
Received: from AD-EXH02.adhost.lan ([fe80::1c5b:7ead:8ba3:6108]) by AD-EXH02.adhost.lan ([fe80::1c5b:7ead:8ba3:6108%11]) with mapi id 14.01.0255.000; Thu, 12 May 2011 19:03:08 -0700
From: "Michael K. Smith - Adhost" <mksmith@adhost.com>
To: Xu Xiaohu <xuxh@huawei.com>, 'Tony Li' <tli@cisco.com>, "rrg@irtf.org" <rrg@irtf.org>
Thread-Topic: [rrg] Next topic?
Thread-Index: AQHMDaP56+KffFPJZUGc782sImRbuJSKdGYA//+UH4A=
Date: Fri, 13 May 2011 02:03:07 +0000
Message-ID: <C9F1DEDC.F502%mksmith@adhost.com>
In-Reply-To: <001e01cc110d$2bb85710$83290530$@com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.10.0.110310
x-originating-ip: [67.183.9.157]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <760163197A1E1342940F922DF45EFDD1@adhost.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rrg] Next topic?
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2011 02:03:11 -0000

On 5/12/11 6:29 PM, "Xu Xiaohu" <xuxh@huawei.com> wrote:

>Hi Tony and all,
>
>In the past few years, RRG has done a lot of excellent research work to
>explore various ideas and approaches (e.g., map&encap, id/locator split
>and
>translation...) to addressing the Internet routing scalability issue.
>Today
>it seems that the cloud Data Center Network (DCN) and Data Center
>Interconnection (DCI) scenarios are facing a similar scalability challenge
>(i.e., MAC forwarding table scalability issue). The demand for VM mobility
>within the whole large L2 data center network or even across
>geographically
>dispersed data centers is one major driving force of extending the L2
>domain
>scope larger and larger.
>
>Although the reason for the MAC forwarding table scalability issue in the
>DCN/DCI scenarios is not the same as that for the Internet routing
>scalability issue, the ideas and approaches suitable for scaling the
>Internet routing system could be utilized to deal with the MAC forwarding
>table scalability issue. There are already many such attempts in reality,
>especially in the academic circle. VL2 , SEATTLE and MOOSE are good
>examples
>of them.
>
>Hence I suggest we spend some time to consider whether we could utilize
>our
>experience which was obtained from the past and ongoing Internet routing
>scalability solution research to address the similar scalability issue
>existed in the DCN/DCI scenarios, for example, we could attempt or even
>develop those familiar ideas or approaches mentioned above to address the
>MAC table scalability issue in the DCN/DCI scenarios.
>
>Best regards,
>Xiaohu

As an adjunct to this line, there is the ARMD group in the IETF (not
officially chartered AFAIK) and an associated BOF at NANOG 52 in Denver.

Mike