Re: [armd] What is the proper definition for Broadcast Domain? which is used in draft-ietf-armd-problem-statement-00

Linda Dunbar <linda.dunbar@huawei.com> Tue, 08 November 2011 15:40 UTC

Return-Path: <linda.dunbar@huawei.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 5FD6F11E807F for <armd@ietfa.amsl.com>; Tue, 8 Nov 2011 07:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.419
X-Spam-Level:
X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 cXuYHTgXf6ly for <armd@ietfa.amsl.com>; Tue, 8 Nov 2011 07:40:44 -0800 (PST)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8254711E808A for <armd@ietf.org>; Tue, 8 Nov 2011 07:40:44 -0800 (PST)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC001YBM7TMU@usaga02-in.huawei.com> for armd@ietf.org; Tue, 08 Nov 2011 09:40:41 -0600 (CST)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUC00GP1M7TPM@usaga02-in.huawei.com> for armd@ietf.org; Tue, 08 Nov 2011 09:40:41 -0600 (CST)
Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 07:40:37 -0800
Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 07:40:31 -0800
Date: Tue, 08 Nov 2011 15:40:29 +0000
From: Linda Dunbar <linda.dunbar@huawei.com>
In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7477C7@szxeml525-mbs.china.huawei.com>
X-Originating-IP: [10.192.11.155]
To: Xuxiaohu <xuxiaohu@huawei.com>, "thomas.morin@orange.com" <thomas.morin@orange.com>, "armd@ietf.org" <armd@ietf.org>
Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120BD044@dfweml506-mbx>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: en-US
Thread-topic: [armd] What is the proper definition for Broadcast Domain? which is used in draft-ietf-armd-problem-statement-00
Thread-index: AQHMnfMLxgfxU4gzHEa/RkGz1/Y1JJWjQ/MA///XX4A=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <4A95BA014132FF49AE685FAB4B9F17F6120AEBDD@dfweml505-mbx> <CAF4+nEFFHXu+TMH6YPsRFkcoViH+FHVrgd3o_DD4OZVvN3dxug@mail.gmail.com> <B11765B89737A7498AF63EA84EC9F5774C1219@ftrdmel1> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7477C7@szxeml525-mbs.china.huawei.com>
Subject: Re: [armd] What is the proper definition for Broadcast Domain? which is used in draft-ietf-armd-problem-statement-00
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, 08 Nov 2011 15:40:45 -0000

The term “ARP Proxy” is a loaded phrase, with different interpretations depending on vendors or environments.  RFC1027’s ARP Proxy is for Gateway to return its own MAC address on behalf of target host, whereas some ARP Proxy approach is for ToR to intercept ARP requests and return target hosts’ MAC if it is present in ToR’s ARP cache.

[RFC1027] was developed prior to the concepts of VLANs. It is for gateway to return its own MAC when the requesting host doesn't have subnet supported. 

Unknown DA flooding is a pure layer 2 approach for a data frame to reach its destination when the switch doesn't have the DA in its FDB. Let's not mix it with address resolution. 


Linda 


> -----Original Message-----
> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of
> Xuxiaohu
> Sent: Tuesday, November 08, 2011 3:58 AM
> To: thomas.morin@orange.com; armd@ietf.org
> Subject: Re: [armd] What is the proper definition for Broadcast Domain?
> which is used in draft-ietf-armd-problem-statement-00
> 
> Hi Thomas,
> 
> > -----邮件原件-----
> > 发件人: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] 代表
> > thomas.morin@orange.com
> > 发送时间: 2011年11月8日 16:47
> > 收件人: armd@ietf.org
> > 主题: Re: [armd] What is the proper definition for Broadcast Domain?
> which is
> > used in draft-ietf-armd-problem-statement-00
> >
> > Hi,
> >
> > In the context of ARMD, we could also find it useful to distinguish
> the
> > broadcast domain (as defined below) and the "ARP/ND domain", which we
> > could define as the set of links and devices that are traversed by an
> > ARP/ND request and/or its reply. Those are distinct things, generally
> > speaking: if for instance ARP proxying is used, the former will be a
> > strict superset of the latter.
> 
> If the ARP proxy [RFC 1027] is used, both the unknown unicast broadcast
> domain and the ARP broadcast domain are confined. In addition, the MAC
> learning domain is also confined. For more details, please see Virtual
> Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-06).
> 
> Of course, if what you mean is ARP cache by saying ARP proxying (see
> http://tools.ietf.org/html/draft-shah-armd-arp-reduction-02), the ARP
> broadcast domain is confined only when there does exist an ARP cache
> entry for the requested host.
> 
> In a word, the ARP proxy return its own MAC address while the ARP cache
> return the real MAC of the requested host.
> 
> Best regards,
> Xiaohu
> 
> > Then draft-ietf-armd-problem-statement could be revised to talks
> about
> > ARP/ND domain in places where it would be more precise than broadcast
> > domain.
> >
> > Thanks,
> >
> > -Thomas
> >
> >
> > Donald Eastlake:
> > > You might have an 802.1D network without VLANs so I would suggest,
> as
> > > a general definition, something like:
> > >
> > > "The set of all links and switches that are traversed by a
> broadcast
> > > frame, that is, a frame
> > > with the broadcast destination L2 address. This is normally
> confined
> > > to a single VLAN."
> > >
> > > Thanks,
> > > Donald
> > > =============================
> > >   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
> > >   155 Beaver Street, Milford, MA 01757 USA
> > >   d3e3e3@gmail.com
> > >
> > >
> > > On Thu, Oct 27, 2011 at 5:23 PM, Linda
> Dunbar<linda.dunbar@huawei.com>
> > wrote:
> > >> draft-ietf-armd-problem-statement-00 has the following definition
> for
> > >> Broadcast Domain:
> > >>
> > >>
> > >>
> > >> Broadcast Domain: The set of all links and switches that are
> > >>
> > >> traversed in order to reach all nodes that are members of a given
> > >>
> > >> L2 domain. For example, when sending a broadcast packet on a
> > >>
> > >> VLAN, the domain would include all the links and switches that the
> > >>
> > >> packet traverses when broadcast traffic is sent.
> > >>
> > >>
> > >>
> > >> The phrase of “are members of a given L2 domain” is a bit
> confusing
> > because
> > >> L2 domain could have up to 4095 VLANS, with each one being its own
> > broadcast
> > >> domain.
> > >>
> > >>
> > >>
> > >> Therefore, I think it is more accurate to say “The set of all
> links and
> > >> switches that are traversed in order to reach all nodes that are
> members of
> > >> a given VLAN of a L2 domain.”
> > >>
> > >>
> > >>
> > >> Any other suggestions?
> > >>
> > >>
> > >>
> > >> Linda
> > >>
> > >> _______________________________________________
> > >> armd mailing list
> > >> armd@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/armd
> > >>
> > >>
> > > _______________________________________________
> > > armd mailing list
> > > armd@ietf.org
> > > https://www.ietf.org/mailman/listinfo/armd
> > _______________________________________________
> > armd mailing list
> > armd@ietf.org
> > https://www.ietf.org/mailman/listinfo/armd
> _______________________________________________
> armd mailing list
> armd@ietf.org
> https://www.ietf.org/mailman/listinfo/armd