Re: [nvo3] New dataplane requirements draft

AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com> Wed, 23 May 2012 14:57 UTC

Return-Path: <Peter.AshwoodSmith@huawei.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63221F85D4 for <nvo3@ietfa.amsl.com>; Wed, 23 May 2012 07:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.932
X-Spam-Level:
X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666]
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 hb0T9XtLkn77 for <nvo3@ietfa.amsl.com>; Wed, 23 May 2012 07:57:55 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9092E21F85A4 for <nvo3@ietf.org>; Wed, 23 May 2012 07:57:55 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGE64500; Wed, 23 May 2012 10:57:55 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 07:55:34 -0700
Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 23 May 2012 07:55:33 -0700
From: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
To: Yiqun Cai <yiqunc@microsoft.com>, "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: New dataplane requirements draft
Thread-Index: Ac00B3cB54Fe5bJjTTaae17BIgRbAwA9DmAgAKZ7+BAAF2JB8AAfVQAgAB3f4SA=
Date: Wed, 23 May 2012 14:55:32 +0000
Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E2012DF95A@dfweml513-mbx.china.huawei.com>
In-Reply-To: <0D12C66279647643A9523DE4CB5BEAB4446B73@TK5EX14MBXC130.redmond.corp.microsoft.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.60.121]
Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E2012DF95Adfweml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [nvo3] New dataplane requirements draft
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "L2 \"Network Virtualization Over l3\" overlay discussion list \(nvo3\)" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nvo3>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2012 14:57:57 -0000

> The volume of IP multicast traffic  in today's data center network is not "0".  Whether it would go towards 0 or away from it is a good
> question.  I'm not sure our speculation of its moving direction will help to determine the MUST/SHOULD/MAY requirement of the service
> models.  A detailed analysis is more useful and IETF can certainly help here.
..
> Yiqun

http://tools.ietf.org/pdf/draft-mcbride-armd-mcast-overview-01.pdf

The above draft goes into an overview of multicast uses in the DC. I assume its far from exhaustive but it's a good start.

They describe 3 broad non ARP/ND/BUM cases, but presumably there are many more which would be useful to add to this draft.

(1) - VM sourcing multicast data to a host outside the DC, like IPTV, stock quotes etc.

(2) - VRRP - so two routers etc. deciding who is active/standby

(3) - Cluster maintenance - Ganglia, Windows Server heartbeats. Etc.

Both (2) and (3) are really signalling control functions taking advantage of multicast, while (1) is presumably not sinking any of that traffic within the DC.

There are applications out there using multicast when what they really want is fast reliable distirbuted signalling and/or PUB/SUB and I think we should be taking a forward looking view here in finding a way to provide that in addition to whatever the legacy applications require of IP/Ethernet multicast.

Peter