Re: [dhcwg] dhc wg last call on "DHCP Relay Agent Assignment Notification 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.  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