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

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

Hi Pekka,

Pekka Nikander wrote:
> 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.

OK.   We'll have to ask people what they think about this.

For the DAD optimization especially, since there are
existing solutions, a set of goals may be sufficient.

I was actually thinking that we could aim at producing
one optimization scheme as a 'first' standard, though.
If we're going to choose one to standardize first though,
we'd need to clearly demonstrate its sufficiency with
regards the the goals and requirements.

>>>   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 agree that DNA can take a long time to complete (and therefore
we're unlikely to be able to complete global address configuration
quickly then).

In some of the proposed schemes (a-DAD, MLD-DAD [which has just expired,
but I'll see what I can do to update it]) the confirmation
that an address is available is possible with a single
message, because of server with pre-existing state.

If we're talking about a stateless, serverless system
you are correct. There needs to be time to ensure
that no conflict exists (Although we can avoid this
being on the critical path for DNA).

This may allow us to use addresses which are undergoing
DAD or have been statefully allocated for DNA (maybe with
some constraints, as in Nick's optimistic-DAD).

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

I'm not sure that this covers my entire concern,  I think I'd
be happier if the following goal was added:

...MUST NOT steal service from another node in the case that there
is a collision, in a way which is not recoverable using
[RFC-2462] DAD defence.

Is this too strong?

Greg