Thomas, and DHC WG:

Thomas' comments got me thinking some more about this "reliablity"
issue. And, though I don't know if Thomas intended it this way, there is
an issue. Ralph will be submitted an updated draft to "correct" this
issue.

Suppose we have the following timeline of events:

T+00 - Client sends REQUEST for a binding.
     - Relay forwards to server.
     - Server sends REPLY, which is "delayed" by the network.
       (Relay and client don't yet see this packet; assume
       there is a cloud between relay and server and some
       route is flopping and/or congested.)
T+02 - Client retransmits REQUEST for a binding. 
     - Relay forwards to server.
     - Server sends REPLY.
     - Relay forwards REPLY to client and processes data from
       notification option and records binding.
     - Client records binding but discovers that it can't use
       the address.
[Both client and relay are in agreement.]
T+03 - Client sends a DECLINE.
     - Relay forwards to server.
     - Server sends REPLY.
     - Relay forwards reply to client and processes data from
       notification option and removes binding.
     - Client completes DECLINE.
[Both client and relay are in agreement.]
T+04 - Delayed REPLY from REQUEST (T+00) arrives at Relay.
     - Relay forwards REPLY to client and processes data from
       notification option and records binding.
     - Client ignores REPLY as the transaction-id is invalid
       for an outstanding transaction.

Now, the Relay believes the client has a binding which it doesn't have!

If a RELEASE/DECLINE REPLY were delayed, a Relay may REMOVE an active
binding.

So, the updated draft will correct this by adding a new option which is
added by the server and includes a 64-bit monotonically increasing
sequence number (there are suggestions for how a server might do this).
This sequence number is for the REPLYs that a server sends (at least
those that contain the Notification option).

When a Relay receives the notification option and this new sequence
number option (a server-id option is also required to be sent by the
server), the relay can examine its database and ignore things from the
same server with a lower sequence number.

One other change is that a Relay must not remove information for at
least the maximum datagram lifetime (similar to what TCP requires). That
way, it can correctly handle all of the issues.

And, the server is required to send ALL current bindings (for the client
on the link) in the Notification option, not just the deltas.

Again, a revised draft will be published shortly (though perhaps it will
take a bit to pop out of the queue?).

So, thanks for catching this issue Thomas!

- Bernie

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com] 
> Sent: Tuesday, May 09, 2006 10:33 PM
> To: Bernie Volz (volz)
> Cc: dhcwg@ietf.org; Stig Venaas; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] dhc wg last call on "DHCP Relay 
> AgentAssignmentNotification Option" 
> 
> > 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).
> 
> 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
> 
> _______________________________________________
> 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