Subject: RE: [dhcwg] additional comments on dhcpv6-24

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 15 May 2002 14:36:37 -0500

Jinmei:

Regarding (1), based on -24 the server shouldn't be sending an Advertise. And, yes, I think your assumption that the client should discard it is correct. Having said that, I would like to see the Rapid Commit change to be more of just an option. A server set up to respond to Rapid Commit would send the Reply. Other servers could send an Advertise. The client would use the Reply if received; otherwise simply start using the Advertises as if a Solicit w/o Rapid Commit was done.

Regarding (2), good question ... I would say it should. The logic might simply be send a Solicit, wait IRT, check if any Advertises received ... if so, go use them otherwise send Solicit again.

Regarding (3), your understanding is correct. I can't see that it hurts for us to indicate that RAND be greater than 0.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, May 15, 2002 2:17 PM
To: [email-masked]
Subject: [dhcwg] additional comments on dhcpv6-24

I have some additional comments (and questions) on dhcpv6-24,
particularly about server solicitation.

(1) If the client sent a solicit message with a rapid commit option
    but the server responds to the solicitation with an advertise
    message, what should the client do?  Should it ignore the
    advertise, should it accept the advertise and send a request, or
    others?  Section 17.1.4 says

     ...If the client does not
     receive a Reply message, the client restarts the server solicitation
     process by sending a Solicit message that does not include a Rapid
     Commit option.

   So, the client should probably ignore the advertise (and keep
   waiting for a reply.)  But I'm not 100% sure about this.

(2) Section 17.1.2 says:

   If the client is waiting for an Advertise message, the mechanism in
   section 14 is modified as follows for use in the transmission of
   Solicit messages.  The message exchange is not terminated by the
   receipt of an Advertise before IRT has elapsed.  Rather, the client
   collects Advertise messages until IRT has elapsed.

Should this rule apply if the client is retransmitting solicit
messages?  For example, suppose that there is no advertise in response
to the first solicit, and so the client retransmit the solicit.  If
the client then receives a first advertise, should it still wait until
IRT elapses?

(3) The paragraph above then says:
   Also, the first
   RT MUST be selected to be strictly greater than IRT by choosing RAND
   to be strictly greater than 0.

However, according to Section 13, the first RT should be

      RT = 2*IRT + RAND*IRT

where  RAND is a random number chosen with a uniform distribution
between -0.1 and +0.1.  Thus,

      RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT
      (the rightmost '=' is satisfied only when IRT is 0)

So the RT should always be greater than IRT regardless of the value of
RAND, and "by choosing RAND to be strictly greater than 0" seems to be
redundant.  Is my understanding correct?

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 May 2002 15:02:45 -0500

> Regarding (2), good question ... I would say it should. The logic might 
> simply be send a Solicit, wait IRT, check if any Advertises received ... 
> if so, go use them otherwise send Solicit again.

I think it makes more sense to say that if IRT has elapsed since the first 
Solicit was sent, the client just takes the first Advertise it gets.   This 
is how I implemented the ISC DHCPv4 client, and it seems to work pretty 
nicely.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 17 May 2002 01:51:56 +0900

>>>>> On Wed, 15 May 2002 14:36:37 -0500, 
>>>>> "Bernie Volz (EUD)" <[email-masked]> said:

> Regarding (1), based on -24 the server shouldn't be sending an
> Advertise. And, yes, I think your assumption that the client should
> discard it is correct. Having said that, I would like to see the
> Rapid Commit change to be more of just an option. A server set up to
> respond to Rapid Commit would send the Reply. Other servers could
> send an Advertise. The client would use the Reply if received;
> otherwise simply start using the Advertises as if a Solicit w/o
> Rapid Commit was done.

I'm a bit confused...so are you saying the followings?

- the client should discard the unexpected advertise *with the current
  specification*.
- but we should change the spec so that the client will accept an
  advertise.

> Regarding (2), good question ... I would say it should. The logic
> might simply be send a Solicit, wait IRT, check if any Advertises
> received ... if so, go use them otherwise send Solicit again.

Okay.  I don't have a particular opinion on this as long as the
wording is clear.

> Regarding (3), your understanding is correct. I can't see that it
> hurts for us to indicate that RAND be greater than 0.

Okay.  I would simplify the specification so that there will be no
special case, but I don't make an objection to the current spec.

					JINMEI, Tatuya