[DNA-BOF] Do we need a separate DAD Problem Statement? (was Re: About Charter,DAD, and SEND)

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Pekka,

Sorry about the delay in responding.


Pekka Nikander wrote:
> Greg Daley wrote:
> 
>> DAD Optimization
> 
> ...
> 
>> This group will specify how to optimize the existing
>> procedure for detection of IPv6 address collision. "DAD
>> optimization" aims to reduce delay due to the detection of
>> IPv6 address availability.
> 
> ...
> 
>> * Develop a DAD optimization protocol independent of link
>>   layer technology.
> 
> ...
> 
>> * Define IPv6 DAD optimization Problem Scope
>>   (goal: info, initial by IETF58)
> 
> ...
> 
>> * Determine IPv6 DAD optimization Requirements   (goal: info, initial 
>> by IETF58/59)
> 
> 
> 
> Do we really need a separate problem statement draft
> for DAD optimization?  The charter clearly says that
> the goal is to reduce delay, and people seem to agree
> on that on the mailing list.
> 
> IMHO, draft-park-ipv6-optidad-requirement-01.txt
> is already fairly good, and could be directly adopted as
> a WG item. However, if we do so, I would like to change the R-word
> with the less-load "goal", as has recently been done in a few WGs.

I think that there's the possibility that the requirements draft
would be sufficient by itself, but that would mean a (slightly)
larger document (since the charter is ephemeral, there would
have to be text in the reqs document to ensure that the document
provided enough detail by itself).

What do people think?

Is there a reason to avoid using the word requirements?
Are you concerned that a good solution which doesn't meet
one of the 'requirements' would be discounted?


> What comes to draft-park-ipv6-optidad-requirement-01.txt,
> I would suggest adding some text to Section 2. discussing
> the scenario where DAD is taking place simultaneously with DNA.
> I would also add two requirements/goals:
>
> After 3.5/before 3.6:
> 
>   3.N  Interoperability with SEND
> 
>    The optimized DAD mechanism SHOULD work when SEND is used.
>    It is desirable that the SEND and DAD optimization work
>    are closely coordinated so that it DAD optimization could
>    benefit from SEND and vice versa.
> 
> Somewhere:
> 
>   3.N+1  Simultanoeus operation with DNA
> 
>    It SHOULD be possible to optimistically use optimized
>    DAD addresses even before the DNA process has not
>    been completed.  In other words, the hosts SHOULD be
>    allowed to send packets to a newly attached link with
>    the optimistica assumption that the link is the same
>    one that was previously used, without needing to wait for
>    the DAD and/or DNA procedures to complete.
> 
> What comes to the solutions (I know it is early to speak
> about them, but anyway), IMHO using pseudo-random addresses
> (e.g. SEND addresses) with careful collision detection
> procedures should be able to fulfil the latter goal.


I think that 3.N is vital.  I'm not sure about 3.N+1, since
that seems to be looking into the solution space.
(for example, 3.N+1's statement about sending packets may
not be needed if DAD takes almost no time).

I like your line of thought though.

I agree that it is important to be able to do DAD (optimized)
before DNA has occurred. Maybe we need to say:

"3.N+1  Simultaneous operation with DNA

  It SHOULD be possible to use DAD optimization procedures
  to ensure availability of link-local addresses before DNA
  has been completed.  This would allow DNA procedures to
  be undertaken without needing to wait for [RFC-2462] style
  DAD completion."

I think this separates the optimism (which may provide a solution)
from the goal.

Greg