Subject: RE: [dhcwg] dhc wg last call on "DHCP Relay Agent AssignmentNotification Option"

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 9 May 2006 22:09:25 -0400

Thomas:

> OK. Then document needs to be very clear that the operative word is
> "more reliable", and very specifically, "NOT totally reliable".

It is 100% reliable in the sense that if the relay doesn't get the
message, how would the client? Thus, the relay has at least as good
information as the client (and in some cases, perhaps better since the
message could always be lost between the relay and client).

There is of course one exception, and that is if the server sends the
client a Server-Unicast Option; but that would be rather dumb of it.
Though admitted we never say anything about this issue.

- Bernie

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Tuesday, May 09, 2006 3:43 PM
> To: Ralph Droms (rdroms)
> Cc: [email-masked]; Stig Venaas
> Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay Agent 
> AssignmentNotification Option" 
> 
> > Thomas - one way to think about this option is that it 
> defines a capability
> > that replaces the "snooping" technique that some devices 
> use to learn about
> > the state of DHCP clients.
> 
> Kind of what I read between the lines. :-)
> 
> But then, if the purpose of this option is to replace the snooping
> hack, this (or some document -- could be separate) should explore that
> problem space a bit more thoroughly, to make sure we really are
> solving that problem to a degree of reliability that does solve the
> problem good enough. I.e., is this a 99% solution, or only a 60%
> solution (compared with the 30% (???? - I'm obviously guessing)
> solution we have in IPv4 today?)
> 
> > So, this draft will allow *more* reliable maintenance of state in a
> > network element that needs that state than is available through
> > DHCPv4.
> 
> OK. Then document needs to be very clear that the operative word is
> "more reliable", and very specifically, "NOT totally reliable".
> 
> > Perhaps this mechanism could be clarified by stating more explicitly
> > that the Assignment Notification option is usually piggybacked on a
> > message to the client.  In fact, in all the cases I can think of,
> > the Assignment Notification option would always be piggybacked on a
> > message to the client.
> 
> I think the keyword here needs to be "always piggybacked". Even
> leaving the door open to having the message go out in other cases
> makes me nervous, because then I fear this is a then the "nose of the
> camel" w.r.t. extending DHC into something it is not today. This also
> gets back to my first point. If it turns out that this option doesn't
> quite solve the actual problem on hand, there will likely be pressure
> to extend DHC just a little bit more to close the gap.
> 
> I would be a lot happier if we understood the landscape here better
> before moving forward with this option.
> 
> Thomas
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 09 May 2006 22:32:56 -0400

> message could always be lost between the relay and client).

Makes sense.

But, isn't one of the problems (if I recall from what is done in IPv4)
that relay agents can reboot and lose all their state? What happens
then? How does the relay recover? Is this extension going to be used
to help in that case too?

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 09 May 2006 22:35:23 -0400

I think "reliability" is a red herring.  The current snooping mechanism is
"reliable", because (as Bernie points out), any messages delivered to the
client are forwarded through the network element in which the relay agent is
located.

What this notification option provides is *explicit* information, rather
than information inferred from snooped messages.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 10 May 2006 03:59:08 +0000

On Tue, May 09, 2006 at 10:09:25PM -0400, Bernie Volz (volz) wrote:
> if the relay doesn't get the
> message, how would the client?

Via an alternative relay agent?

-- 
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