Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 9 May 2002 12:35:04 -0500

Oh, I should add that in -24 we have:

---

22.9. Elapsed Time

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      OPTION_ELAPSED_TIME      |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          elapsed-time         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_ELAPSED_TIME (8)

      option-len    2.

      elapsed-time  The amount of time since the client began its
                    current DHCP transaction.  This time is expressed in
                    hundredths of a second (10^-2 seconds).

   A client SHOULD include an Elapsed Time option in messages to
   indicate how long the client has been trying to complete a DHCP
   transaction.  Servers and Relay Agents use the data value in this
                         ^^^^^^^^^^^^^^^^
   option as input to policy controlling how a server responds to a
   client message.  For example, the elapsed time option allows a
   secondary DHCP server to respond to a request when a primary server
   hasn't answered in a reasonable time.

---

I would say to keep things simple, we explicitly DISALLOW relays from using this field??

- Bernie

-----Original Message-----
From: Bernie Volz (EUD) 
Sent: Thursday, May 09, 2002 1:32 PM
To: 'Ted Lemon'
Cc: 'Thomas Narten'; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option 

Ted:

Exactly correct. And in fact from my reading of the DHCPv4 specification, this is required by it. Here's the text from RFC 2131:

     To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.

I did forget to mention that we might just need to do that - have the server return the elapsed time option to the client!

I don't have any issue in changing things from DHCPv4 ... I was just assuming we MIGHT want to use that model since it has been tried and proven?

I also agree that having the relay base the forwarding on the elapsed time is likely bad - but again, that was assumed to happen with DHCPv4!!

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 12:55 PM
To: Bernie Volz (EUD)
Cc: 'Thomas Narten'; [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option 

> If the server should fail to get a Reply to the Request and restarts the 
> Solicit, time should not be reset.
>
> - Time is 0 when first Renew/Rebind is sent. Increases with each 
> retransmission until timeout or Reply.
>
> - Time is 0 when first Decline/Release is sent. Increases with each 
> retransmission until timeout or Reply.
>
> - Time is 0 when first Information-Request is sent. Increases with each 
> retransmission until timeout or Reply.
>

I think if you let the relay agent make relaying decisions based on the 
time sent by the client, you're in big trouble.   Picture this:

client sends solicit A, t=0
relay sends solicit to server A
client sends solicit B, t=100
relay sends solicit to server B
server A responds to solicit A with advertise A
client sends Request A, t=100
relay sends Request A to server B
server B drops Request A on the floor

repeat until bored

The only reliable way to fix this is to have the server send the time it 
received from the client in the solicit back to the client in the advertise,
  and for the client to use that time in every subsequent Request, 
regardless of how long it has to retry.   This is complicated to specify, 
and complicated to implement.   Do we really want this?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 May 2002 13:20:32 -0500

> I would say to keep things simple, we explicitly DISALLOW relays from 

I'd go along with this if nobody else objects.   :')

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

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Fri, 10 May 2002 21:03:15 +0530

RE: [dhcwg] dhcpv6-24: Elapsed Time option
  I feel that this elapsed_time field can be better used by Relays.
  We should not restrict the relays not to use it.

  Request, Renew, Release, Decline - These messages are
  expected to be replied by the particular server which has assigned
parameters, which is
  identified by server id field. So there is no need for the relay to
  divert to secondary server.

  In the case of Solicit and Information-request, the relay can use this
  option to decide up on sending it to secondary server or in load
balancing.

  The problem that Ted referred if the elapsed_time is sent in request wont
be there
  now, since client wont be using the elapsed_time in the request message...

  The possible scenario is...

  Client (SOLICIT (elapsed_time = 0)) --> Relay --> Set A of Servers

  No reply recevied                    <--
                  ..........
                  ..........
  Client (SOLICIT (elapsed_time = 100)) --> Relay --> Set B of servers.

  Case a) -> 1 or more reply received....

  client chooses one of the servers in the set and send REQUEST message

  case b)->no reply received till REQ_MAX_RC
  it can try with less prefered servers in set B who have replied. If still
no reply received...

  it can proceed with solicit. the time elapsed will be the tolal time from
the original SOLICIT sent....
  Client (SOLICIT (elapsed_time = 300)) --> Relay --> Set C of servers

  Its purely configuration issue that whether Sets A B and C are independent
(or)
  one is subset of other one, depending up on whether the relay is trying to
do
  load balancing or trying to take care of failover.

  For confirm and rebind message, A should be subset of B, B in turn subset
of C.
  Because, the client may have got IAs from more than one server and any of
those servers
  should not be left out in subsequent sets.Again, this is purely
configuration issue.

  And processing of elapsed time cannot be a big overhead to the relay. If
the Elapsed_Time
  is used as last option in the client message, the processing will be
easier.

  ~Vijay

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bernie Volz (EUD)
  Sent: Thursday, May 09, 2002 11:05 PM
  To: 'Ted Lemon'
  Cc: 'Thomas Narten'; [email-masked]'
  Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option

  ---

  22.9. Elapsed Time

        0                   1                   2                   3

        option-len    2.

  ---

  I would say to keep things simple, we explicitly DISALLOW relays from
using this field??

  - Bernie

  -----Original Message-----
  From: Bernie Volz (EUD)
  Sent: Thursday, May 09, 2002 1:32 PM
  To: 'Ted Lemon'
  Cc: 'Thomas Narten'; [email-masked]
  Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option

  Ted:

  Exactly correct. And in fact from my reading of the DHCPv4 specification,
this is required by it. Here's the text from RFC 2131:

       To help

  I did forget to mention that we might just need to do that - have the
server return the elapsed time option to the client!

  I don't have any issue in changing things from DHCPv4 ... I was just
assuming we MIGHT want to use that model since it has been tried and proven?

  I also agree that having the relay base the forwarding on the elapsed time
is likely bad - but again, that was assumed to happen with DHCPv4!!

  - Bernie

  -----Original Message-----
  From: Ted Lemon [mailto:[email-masked]]
  Sent: Thursday, May 09, 2002 12:55 PM
  To: Bernie Volz (EUD)
  Cc: 'Thomas Narten'; [email-masked]
  Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option

  repeat until bored

  received from the client in the solicit back to the client in the
advertise,