Re: [rrg] Next topic?

Xu Xiaohu <xuxh@huawei.com> Fri, 13 May 2011 01:20 UTC

Return-Path: <xuxh@huawei.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 7E18BE07AC for <rrg@ietfa.amsl.com>; Thu, 12 May 2011 18:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.21
X-Spam-Level:
X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_35=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
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 EnIZohY42pXs for <rrg@ietfa.amsl.com>; Thu, 12 May 2011 18:20:01 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1CCE0759 for <rrg@irtf.org>; Thu, 12 May 2011 18:20:01 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL4002EV11ATC@szxga03-in.huawei.com> for rrg@irtf.org; Fri, 13 May 2011 09:19:58 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LL400FL511A8X@szxga03-in.huawei.com> for rrg@irtf.org; Fri, 13 May 2011 09:19:58 +0800 (CST)
Received: from x41208c ([10.110.98.38]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LL400DYK119HU@szxml04-in.huawei.com> for rrg@irtf.org; Fri, 13 May 2011 09:19:58 +0800 (CST)
Date: Fri, 13 May 2011 09:29:14 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com>
To: 'Tony Li' <tli@cisco.com>, rrg@irtf.org
Message-id: <001e01cc110d$2bb85710$83290530$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="gb2312"
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: AcwNpAXMeI4W9GDOTd6n2cjxY0HXVADYy61A
References: <06B61955-CA9F-4CE7-9DA3-6DA8ECF6CD07@cisco.com>
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 01:20:02 -0000

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


> -----邮件原件-----
> 发件人: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] 代表 Tony Li
> 发送时间: 2011年5月9日 1:18
> 收件人: rrg@irtf.org
> 主题: [rrg] Next topic?
> 
> 
> Hi all,
> 
> It's time to start the conversation about where the RRG is headed.
Towards
> that end, I'd like to open the floor for the discussion of topics.  Any
_research_
> topic within the broad area of routing and addressing is appropriate.
> 
> I propose the following process: we hold this discussion this month,
trying to
> identify relevant topics.  Each topic should have a succinct statement of
its
> goals.  At the end of the month, we poll to determine the interest level
in the
> various topics.  Those that seem to have critical mass are recommended to
> the IRTF Chair for consideration.
> 
> The default answer, if no topic has critical mass, is for the RG to go on
hiatus.
> 
> Any questions or comments on the process?
> 
> Any proposals of research topics?
> 
> The floor is open...
> 
> Tony
> 
> _______________________________________________
> rrg mailing list
> rrg@irtf.org
> http://www.irtf.org/mailman/listinfo/rrg