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

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Greg,

>> 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.

...

> Is there a reason to avoid using the word requirements?

I am just trying to avoid the multi6 rathole.  Multi6
stalled for over a year, basically debating about requirements,
and the issue was finally resolved by rephrasing the document
as a less ambitious goals documents.

I have also heard multiple stories about IETF WGs
endlessly debating about requirements, and not getting
into real proposals how to solve the problems.  (This
may be due to more and more telecom people being involved
at the IETF, and they being used to fulfil all requirements,
even if the solutions get horrendously complex.)

IMHO, completing rigorious requirements is complete
waste of time.  What finally matters are the solutions.
Goals are good in aligning the people's mindset, though.

>>   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.
> 
> 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).

We have to remember that whatever we do, the optimized DAD
procedure must be compatible with the current DAD procedure.
Hence, it cannot be "completed" in almost no time.  There
will always be the possiblity (however small) that a collision
will be detected only when another node gets its current
DAD procedure complete.

I'm also afraid that DNA may take quite long is some cases.

> 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."

This is good, IMHO, too, and probably should be added as a goal.

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

Well, if we rewrite my 3.N+1 as follows, I think the meaning
is the same but that avoids the optimistic wording:

   It SHOULD be possible to use optimized DAD addresses even
   before the DNA process has been completed.  In other words,
   the hosts SHOULD be allowed to send packets to a newly
   attached link with the assumption that the link may be
   the same one that was previously used, without needing to
   wait for the DAD and/or DNA procedures to complete.  Such
   practise MAY result in packet loss, and it MUST NOT cause
   packet storms or excessive traffic in the case the newly
   attached link is not the previously used one.

--Pekka Nikander