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

From: Donald Eastlake <[email-masked]>
Date: Thu, 3 Nov 2011 13:37:37 -0400

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
 [email-masked]

On Thu, Oct 27, 2011 at 5:23 PM, Linda Dunbar <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/armd
>
>

---

From: Warren Kumari <[email-masked]>
Date: Sun, 6 Nov 2011 21:28:59 -0500

> with the broadcast destination L2 address. This is normally confined

+1
W

---

From: <[email-masked]>
Date: Tue, 8 Nov 2011 09:47:25 +0100

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.

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:
> On Thu, Oct 27, 2011 at 5:23 PM, Linda Dunbar<[email-masked]>  wrote:

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 08 Nov 2011 09:57:48 +0000

Hi Thomas,

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> [email-masked]
> 发送时间: 2011年11月8日 16:47
> 收件人: [email-masked]
> 主题: Re: [armd] What is the proper definition for Broadcast Domain? which is
> used in draft-ietf-armd-problem-statement-00
> 
> Hi,
> 

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

---

From: <[email-masked]>
Date: Tue, 8 Nov 2011 15:44:50 +0100

Hi Xuxiaohu,

Yes, you are correct that we may have different scopes for broadcast 
traffic, unknown unicast, ARP/ND request, or even multicast... I would 
add that for some of these, the scope is not even constant over time 
(e.g. unknown unicast is not unknown for every device, and not for ever).

My point was that, even though Donald's definition of a broadcast domain 
looks very reasonable to me, it strikes me that the "domain" which 
draft-ietf-armd-problem-statement should talk about is not this domain, 
but the domain in which ARP or ND spreads.

-Thomas

2011-11-08, Xuxiaohu:
>Thomas:
> 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.
>
 >
>> Donald Eastlake:

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 08 Nov 2011 15:14:45 +0000

Thomas:

The "domain" which draft-ietf-armd-problem-statement talk about is same as broadcast in Layer 2. They are all about flooding a frame to all ports which have the VLAN# enabled. Multicast is processed same as broadcast in Layer 2 unless MMRP (IEEE802.1ak) is implemented. Based on my knowledge, not many Layer 2 deployment enable IEEE802.1ak. 

I agree with you on the unknown DA Unicast flooding, the frame is only flooded to all ports on the switch which doesn't have the DA in its FDB. 

Linda   

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, November 08, 2011 8:45 AM
> To: Xuxiaohu
> Cc: [email-masked]
> Subject: Re: [armd] What is the proper definition for Broadcast Domain?
> which is used in draft-ietf-armd-problem-statement-00
> 
> Hi Xuxiaohu,
> 
> >>> On Thu, Oct 27, 2011 at 5:23 PM, Linda
> Dunbar<[email-masked]>
> >> wrote:
> >>>> The phrase of “are members of a given L2 domain” is a bit
> confusing
> >> because

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 08 Nov 2011 15:31:52 +0000

Thomas, 

To be precise, ARP request is in broadcast domain; APR reply is uni-cast. ND's Neighbor Solicitation is in Multicast domain. ND's Neighbor Advertisement is unicast. ND's Unsolicited Neighbor Advertisement is a broadcast message. 

For a Layer 2 switch, Multicast frame is treated same as broadcast message unless IEEE802.1ak is supported, i.e. replicate the frame to all ports which are in the VLAN group. 
For end station, broadcast message has be to processed, but multicast message doesn't have to processed unless the end station is in the Multicast group. 

Linda

> Sent: Tuesday, November 08, 2011 2:47 AM
> To: [email-masked]

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 08 Nov 2011 15:40:29 +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 

> Xuxiaohu
> Sent: Tuesday, November 08, 2011 3:58 AM
> To: [email-masked]; [email-masked]
> 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).
>

---

From: Yizhou Li <[email-masked]>
Date: Wed, 09 Nov 2011 10:04:07 +0800

I think it is worthwhile to mention ARP proxy term and its ambiguity in the problem statement for the following reasons. 
1. It is ARP related and is a common term people always talk about.
2. It has different interpretations which affects ARP performance differently.

"Proxy ARP" appears in problem statement once and it takes the second interpretation in Linda's email rather than that from RFC1027. 

Yizhou

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, November 08, 2011 11:40 PM
To: Xuxiaohu; [email-masked]; [email-masked]
Subject: Re: [armd] What is the proper definition for Broadcast Domain? which is used in draft-ietf-armd-problem-statement-00

Linda

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 9 Nov 2011 11:24:08 -0500

Thomas: 

Are you arguing for both definitions (Donald's) and ND/ARP domain or both?
I'm just a bit confused by your request.

Sue 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 08, 2011 9:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [armd] What is the proper definition for Broadcast Domain? which is used in draft-ietf-armd-problem-statement-00

Hi Xuxiaohu,

-Thomas

---

From: <[email-masked]>
Date: Thu, 10 Nov 2011 16:04:45 +0100

Hi Susan,

> I'm just a bit confused by your request.

I don't have a strong opinion on which definition of a broadcast domain, 
between the current one in the doc and Donald's, is the best one.

However, the document as currently worded implies that the equipments 
which process ARP are all the (IP) equipments that are in a broadcast 
domain. It will be wrong in some cases such as cases where ARP requests, 
even though sent to a broadcast address, are diverted to an ARP cache or 
proxy. Said otherwise, in some cases a broadcast domain could be large 
without introducing ARP/ND scaling issues.  A way to avoid formulating 
things in a way that ignores this fact is to talk in terms of "ARP/ND 
domain" instead of broadcast domain or L2 domain. That said, it is ok to 
mention that the potentially most problematic cases are the ones where 
the ARP/ND domain is as large as the broadcast domain.

Thanks,

-Thomas