Subject: [dhcwg] draft on unicast suboption in option 82

From: [email-masked]
Date: Sun, 26 Feb 2006 21:53:37 +0100

Hi,

We submitted some time ago the following draft:

http://www.ietf.org/internet-drafts/draft-decnodder-dhc-rai-unicast-00.txt

It is about reducing the amount of dowstream broadcast DHCP messages in 
large Ethernet aggregation networks.

Your comments would be highly appreciated!

Thanks,

Stefaan

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Feb 2006 14:23:50 -0700

> Your comments would be highly appreciated!

So you're trying to reduce the amount of ARP traffic on the wire?   I'm having 
trouble understanding why this is useful.   Are you trying to avoid assigning 
IP addresses to the "layer 2" devices?

---

From: [email-masked]
Date: Mon, 27 Feb 2006 09:36:39 +0100

Hi Ted,

The access node is a layer 2 device that indeed does not have an IP 
address (except one for management). If it would have routing 
functionality, a full DHCP relay agent could be used at the access node, 
but this is not always accepted as a good solution by some service 
providers and prefer to only have routing in the IP edge.

The main goal is to avoid that some DHCP messages going towards the 
hosts are being broadcasted towards all access nodes because the 
broadcast flag has to be honored by the relay agent. The unicast 
suboption replaces this broadcast flag between access node inserting 
option 82 and the IP edge.

I am not sure why you think that this draft is about reducing ARP. Can 
you be more specific on this question?

Thanks,

Stefaan

---

From: Andre Kostur <[email-masked]>
Date: Mon, 27 Feb 2006 06:31:47 -0800

[email-masked] wrote:
> functionality, a full DHCP relay agent could be used at the access 
> node, but this is not always accepted as a good solution by some 
> service providers and prefer to only have routing in the IP edge.
>

What's the problem with the responses heading towards all of the access 
nodes?  If the problem is that you don't want all of this broadcast 
traffic to head down towards each of the hosts, you could have your 
access node insert a Circuit ID (or I supposed a Remote ID could work 
too) on the upstream, and the access node could check the returning 
traffic to see if the included Circuit ID matches.  If it doesn't, drop 
the traffic.  This mechanism wouldn't require any changes to DHCP 
Servers, or worse DHCP Relays.  The only difference that I can see is 
that the access nodes have to sniff the traffic going both ways (and 
since it's already doing the upstream traffic, it shouldn't be hard to 
do the downstream traffic too).

---

From: [email-masked]
Date: Mon, 27 Feb 2006 16:00:00 +0100

Hi,

see below for some responses.

Andre Kostur wrote:

> traffic to see if the included Circuit ID matches.

That is also what most access nodes are doing today.

   If it doesn't, drop
> do the downstream traffic too).

The problem is indeed the load on the access nodes (not on the hosts!) 
Usually, depending on the switch configuration in the access network, an 
access node only sees the upstream DHCP messages originated from hosts 
attached to itself and not from hosts attached to another access node. 
Ethernet switches can make sure by means of filters that upstream 
broadcasts from one access node is not received by another access node. 
To reduce the processing load on these access nodes also downstream DHCP 
messages destined for other access nodes should not be received. This 
reduces the load on the access node quite lot.

regards,
Stefaan

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Feb 2006 10:44:20 -0700

On Monday 27 February 2006 01:36, [email-masked] wrote:
> address (except one for management).

If the device has an IP address for management, then just use that IP address 
in giaddr, and all your problems go away.   If that address is not 
appropriate for use in address assignment, send a different IP address in the 
relay agent link selection suboption.

The reason I thought your proposal had to do with reducing ARP traffic is that 
if your "layer 2" device has an IP address, then the only reason I can think 
of _not_ to use it is that you don't want all those ARPs.

---

From: Josh Littlefield <[email-masked]>
Date: Mon, 27 Feb 2006 14:39:03 -0500

Stefaan,

I understand the problem you are addressing, and am quite familiar with 
the desire to keep the full L3 addressing details of the SP network out 
of the Access Node's configuration (thereby keeping the Access Node as a 
L2 DHCP Relay).  They downsteam broadcast flooding issue seems (to me) 
to be a minor one, as it is purely on a VLAN-by-VLAN basis, and will 
typically be somewhat localized, but I can imagine there might be cases 
where this flooding is a problem.

I believe the DSLForum already has a mechanism that could be used to 
address this without adding a new general suboption to option-82.

RFC 4243 defines vendor-specific vendor suboptions of option-82. 
DSLForum has an enterprise-id, and is considering using the suboption 
defined by RFC 4243 to provide other information from the Layer 2 DHCP 
relay to full DHCP Relay, DHCP Proxy or DHCP Server that are defined in 
new DSL architectures.

I see no reason why DSLForum can't specify that a vendor-specific 
option-82 suboption carry this MAC address, and supportive DHCP Relays 
that are part of the appropriate DSL architecture can interpret this 
option and unicast as you require.  Further, if the DHCP Relay in the 
BRAS device, or the directly attached DHCP server when no relay is used, 
does not understand this vendor sub-option, then the response will be 
broadcast with no loss of functionality.  Of course, service providers 
who are concerned about this would shop for vendors that supported this 
DSL-specific suboption, or such support could be required by DSLForum 
for compliant products.

I don't see this as a general problem requiring a general solution.

-josh

[email-masked] wrote:
>> So you're trying to reduce the amount of ARP traffic on the wire?   
>> I'm having trouble understanding why this is useful.   Are you trying 
>> to avoid assigning IP addresses to the "layer 2" devices?
>>

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                             1414 Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA  01719-2205