Re: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification Option"

Thomas Narten <narten@us.ibm.com> Tue, 09 May 2006 19:43 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdY7K-0002tl-5D; Tue, 09 May 2006 15:43:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdY7I-0002tg-Gv for dhcwg@ietf.org; Tue, 09 May 2006 15:43:32 -0400
Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdY7G-0000vP-6r for dhcwg@ietf.org; Tue, 09 May 2006 15:43:32 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k49JhTwu029875 for <dhcwg@ietf.org>; Tue, 9 May 2006 15:43:29 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k49JhTUi269094 for <dhcwg@ietf.org>; Tue, 9 May 2006 13:43:29 -0600
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k49JhTv2000855 for <dhcwg@ietf.org>; Tue, 9 May 2006 13:43:29 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-76-145-108.mts.ibm.com [9.76.145.108]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k49JhRRG000737; Tue, 9 May 2006 13:43:28 -0600
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.6/8.12.5) with ESMTP id k49JgxKK009047; Tue, 9 May 2006 15:43:10 -0400
Message-Id: <200605091943.k49JgxKK009047@cichlid.raleigh.ibm.com>
To: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification Option"
In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> of "Tue, 09 May 2006 15:30:13 EDT." <C0866605.171F1%rdroms@cisco.com>
Date: Tue, 09 May 2006 15:42:59 -0400
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: dhcwg@ietf.org, Stig Venaas <stig.venaas@uninett.no>
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org

> 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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg