Subject: [dhcwg] Feedback on Layer 2 Relay Agent functionality

From: Bharat Joshi <[email-masked]>
Date: Mon, 3 Sep 2007 19:47:30 +0530

Hi All,

        We presented draft 'Layer 2 Relay Agent' [http://www.ietf.org/internet-drafts/draft-joshi-dhc-layer2-relay-agent-01.txt] in Chicago.  WG Chairs had asked the Working Group participants if Working Group would like to work on 'Layer 2 Relay Agent' and there were considerable 'hums' in the favor of the document. So it was decided to work on this area.

        It was felt that as this is a new area for the working group, working group need to understand the requirements, problem space and architecture to define the 'Layer 2 Relay Agent' functionality. We have described this in the draft we had presented and would like to get your feedback on this. We also wanted the feedback on the text in our draft so that we can enhance it in future versions.

        Please also look at our presentation available at [http://www3.ietf.org/proceedings/07jul/slides/dhc-1.pdf].

        'Layer 2 Relay Agent' document describes following functionality:

* A typical Layer 2 Network, why Layer 2 Relay Agent is required and where it fits in the Layer 2 Networks?

* How Layer 2 Relay Agent forwards various DHCP messages between DHCP clients and DHCP server?

* Extension of RFC #4388 [Lease Query] to Layer 2 Relay Agents.

* Mechanism to unicast DHCP replies from a Layer 3 Relay Agent to Layer 2 Relay Agent.

        Please let us know your questions, comments and feedback on this document.

Thanks & Regards,
Bharat

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

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

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Sep 2007 11:40:49 +0200

At the wg meeting in Chicago there appeared to be a great interest among
people in the room to look at layer-2 relay agents. We asked the room if
the wg should study this problem and there was at least a rough
consensus.

As a first step I believe the we in the working group need to get a
common understanding of what we want to solve and what we mean by a
layer-2 relay agent (the latter might be obvious...).

In what scenarios do we believe this is needed. Does
draft-joshi-dhc-layer2-relay-agent-01.txt give a fair description? Are
there other scenarios where layer-2 relay agents might be of use?

Before we dig too much into solutions I think we need to have some
discussion and understanding of what we are trying to solve and make
sure we are all on the same page.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Thu, 27 Sep 2007 10:13:12 +0200

With the big number of people that wanted the wg to work on this
problem at the meeting I would have hoped a few would respond to
my request. Does the silence mean a lack of interest or that the
below document actually does a very good job at describing what
you think we should work on?

Stig

---

From: "Wacker, Michael" <[email-masked]>
Date: Thu, 27 Sep 2007 18:03:04 +0200

This is just some feedback about our experience with the layer 2 relay functionality.

we support this functionality already since a few years in our switches.
The reason was to provide static IP assignment based on the topology (using option 82) even in our small managed access switches.

One of the differences between your draft and our implementation is that our access switches already put their mangement IP address into the giaddr field and not 0.0.0.0. 

This was used on a DHCP server to identify the switch instead of using the RemoteID.

Doesn't a router ignore a DHCP paket if it is transmitted as a unicast directly to the DHCP server?
Wouldn't a giaddr value of 0.0.0.0 make sense if the BC flag is used?

Most L2 switches are not able to take the initial DHCP broadcast off the network. They can identify it and forward a unicast copy to a DHCP server but the original BC will still be flooded.

If you cascade switches you should be able to disable the relay function on trunk ports (switch to switch) otherwise you'll have an interesting effect on these trunk ports sending another copy of the original DHCP BC to the DHCP server. In this case with different topology informations.

I don't now if this is beyond the skope of this draft but just some experience we made.

With best regards, mit freundlichen Grüssen

Michael Wacker
Product Manager Industrial Networking

Hirschmann Automation and Control GmbH
Stuttgarter Str. 45-51
D-72654 Neckartenzlingen
* +49 7127 14 1800
*     +49 7127 14 1561
* [email-masked]
* http://www.hirschmann.de

* * *
Hirschmann Automation and Control GmbH, Neckartenzlingen
Amtsgericht Stuttgart HRB 225927
UST.-IdNr. DE 814 212 604
Geschäftsführer: Reinhard Sitzmann (Vors.), Laurence Burns, Rainer Schenkyr, Dr. Georg Schneider

-----Ursprüngliche Nachricht-----
Von: Stig Venaas [mailto:[email-masked]] 
Gesendet: Donnerstag, 27. September 2007 10:13
An: [email-masked]
Betreff: Re: [dhcwg] Feedback on Layer 2 Relay Agent functionality

Stig

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 27 Sep 2007 10:38:36 -0700

sorry stig, i'm trying desperately to catch up.  bit off a bit
more than i can chew this month.

> you think we should work on?

There are a few things I think are missing; I think we can use a
general document that describes what an ("official") l2 relay agent
is and does, and things it can and cannot rely upon.  For example, I
have had l2 relay agent manufacturers express grief when I had to
explain that yes, one DHCPDISCOVER may net more than one DHCPOFFER,
and they may not agree.  Further grievances were uttered upon the
discussion that one DHCPREQUEST may net multiple DHCPACKs under
imprecise circumstances, and they also may not agree upon some finer
details (you may even see DHCPACKs and DHCPNAKs mixed, and will have
to deal with this case as best as you can).

The main problem with those grievances being those services that
l2 relay agents are trying to deliver using something vaguely
referred to as 'dhcp snooping' as a transport.  I don't think we
need to get into 'dhcp snooping' in a standard way in this document
(but I would welcome a second document that at least describes the
practices!), but rather a more generic discussion of what can (and
some explicit things that can't) be relied upon.

So, essentially, a 'step by step' explanation of an L2 relay agent's
operation, similarly to what we see in rfc2131, something similar
(unless there's a better way) to the 'timeline' graphs in that
document.

Second, I think this document could actually use some helpful hints
for server implementors, based solely on my own experience.  From
our DHCP software distribution's RELNOTES, as an easy summary;

- In the case where an "L2" DHCP Relay Agent (one that does not set giaddr)
  was directly attached to the same broadcast domain as the DHCP server,
  the RFC3046 relay agent information option was not being returned to the
  relay in the server's replies.  This was fixed; the dhcp server no longer
  requires the giaddr to reply with relay agent information.  Note that
  this also improves compatibility with L2 devices that "intercept" DHCP
  packets and expect relay agent information even in unicast (renewal)
  replies.  Thanks to a patch from Pekka Silvonen.

My finding that lead to inclusion of this patch upon reading the relay
agent option RFC basically was that the relay agent options are
included in any replies to packets that had the option in them...not
restricted by a non-zero giaddr.

I swear there was something else we changed or fixed for L2 agent
compatibility, but I can't seem to find it now.  I might be confused,
it wouldn't be the first time.

Ohyeah, one other thing I've had to explain that I think may not be
obvious is why server operation changes when the 'giaddr' is nonzero.

In particular, this goes back to 'getting multiple DHCPACKs in
response to one DHCPREQUEST'.  Where giaddr is set, our servers
believe the client to be "REBINDING", and since you only reach
REBINDING if REQUESTING fails (e.g., the peer has failed to answer
for a not-insubstantial period), our failover pair will elect not to
load balance...both will answer.  This lead us into the discussion
about multiple replies.

I'm not sure failover needs to be referenced explicitly, I just
include that for discussion, but I think it's important to note
that a device acting in this way creates the illusion of a
REBINDING when the client is in actuality REQUESTING.  This is
basically a loss of information in the absence of some other way
to convey it (like the relay agent flags sub-option).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: pavan_kurapati <[email-masked]>
Date: Fri, 28 Sep 2007 21:23:59 +0530

Hi Michael,

Please find replies inline

Thanks,
Pavan Kurapati
________________________________________
From: Wacker, Michael [[email-masked]]
Sent: Thursday, September 27, 2007 9:03 AM
To: [email-masked]
Subject: AW: [dhcwg] Feedback on Layer 2 Relay Agent functionality
>One of the differences between your draft and our implementation is that our access switches already put their mangement IP address into the giaddr field and not 0.0.0.0.

Right. But using management IP address is not feasible in all the cases. i.e In bigger deployments like in the case of DSL service providers, management IP subnet and networks will be totally different from the subnets that are allocated to the clients. L2 RA usually will have a single/two upstream interfaces which point to a edge router which typically acts as a Layer3 relay agent inserting giaddr. Ofcourse, we did mention a note on usage of management ip address as giaddr in our draft.

>Wouldn't a giaddr value of 0.0.0.0 make sense if the BC flag is used?

No, in a lot of cases even unicast DHCP messages are snooped. This is to maintain the DHCP lease information in the binding table present in the router. This also helps in DHCP servers allocating ip address and other parameters based on option 82 passed by the L2RA.

>Most L2 switches are not able to take the initial DHCP broadcast off the network. They can identify it and forward a unicast copy to a DHCP server but the original BC will still be flooded.

We handled a few scenarios in our draft where we tried to prevent flooding in the L2 network irrespective of the Broadcast flag set. Please refer the "Layer 2 Relay Agent" draft and give us feedback on these mechanisms.

>If you cascade switches you should be able to disable the relay function on trunk ports (switch to switch) otherwise you'll have an interesting effect on these trunk ports sending another copy of the original >DHCP BC to the DHCP server. In this case with different topology informations.

Would be interested to know more details about this scenario.