Re: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification Option"
Ralph Droms <rdroms@cisco.com> Tue, 09 May 2006 19:30 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXuW-0000Fz-9a; Tue, 09 May 2006 15:30:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdXuV-0000Fs-BA for dhcwg@ietf.org; Tue, 09 May 2006 15:30:19 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdXuT-0000KB-0q for dhcwg@ietf.org; Tue, 09 May 2006 15:30:19 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 May 2006 12:30:16 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.05,106,1146466800"; d="scan'208"; a="27675225:sNHT24334716"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k49JUEvF014273; Tue, 9 May 2006 15:30:15 -0400 (EDT)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 May 2006 15:30:14 -0400
Received: from 10.86.160.144 ([10.86.160.144]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) with Microsoft Exchange Server HTTP-DAV ; Tue, 9 May 2006 19:30:14 +0000
User-Agent: Microsoft-Entourage/11.2.1.051004
Date: Tue, 09 May 2006 15:30:13 -0400
Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification Option"
From: Ralph Droms <rdroms@cisco.com>
To: Thomas Narten <narten@us.ibm.com>, Stig Venaas <stig.venaas@uninett.no>
Message-ID: <C0866605.171F1%rdroms@cisco.com>
Thread-Topic: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification Option"
Thread-Index: AcZznv3+PJsy3t+SEdqWfgARJOT6eg==
In-Reply-To: <200605091726.k49HQUQQ005549@cichlid.raleigh.ibm.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 09 May 2006 19:30:14.0854 (UTC) FILETIME=[FF19B660:01C6739E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: dhcwg@ietf.org
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. So, this draft will allow *more* reliable maintenance of state in a network element that needs that state than is available through DHCPv4. 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. - Ralph On 5/9/06 1:26 PM, "Thomas Narten" <narten@us.ibm.com> wrote: > I (may) have concerns about this document, and am not sure I can > support it. > > My issue with it is that it may (though I'm not entirely sure) cross a > boundary beyond just being yet another DHC optoin. It seems to perhaps > extend the protocol in a way that I have concerns about. Specifically: > >> The DHCP server is responsible for synchronizing any state created by >> a node through the use of the Assignment Notification option. For >> example, if a DHCP server receives a Release message for a delegated >> prefix, it causes the node to delete any state associated with that >> prefix by sending an Assignment Notification option containing an IA >> Prefix option with the released prefix and a valid lifetime of zero. > > > If I undestand this right, if the DHCP server deletes a lease (e.g., > the client releases the address), the server is obligated to notify > the agent. Is this so? If so, I worry that this is placing reliability > requirements on the server that it is poorly positioned to meet. (I.e, > is this intended to be used so that relay agents can _reliably_ > maintain state about what prefixes are in use behind a particular > link? > > What message does the server send back (per above) that contains an > Assignment Notification option? Is it piggy backed on an existing > message going back to the client (i.e., a response to the release)? Or > some other message? And does this message have to be transported > reliably (i.e., implying the server has to do retransmissions)? > > Or am I reading too much into how this is intended to work? :-) > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] dhc wg last call on "DHCP Relay Agent Ass… Stig Venaas
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Francis Dupont
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Thomas Narten
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Ralph Droms