Re: [DNA-BOF] Detecting Network Attachment BoF description (rev 2)

[Alper Yegin <alper@docomolabs-usa.com>]

Hi Greg,

> How about this text for the moment?
> 
> "For these nodes, it is also important detect if an acquired
> subnet or link is new, or has already been visited"
> 
> This allows for either the change of subnet or
> link to be important.

Capturing both link and subnet is good, but I still have issues with trying
to optimize the case where link was visited earlier. Please see below.

> 
>> I also think that talking about re-visiting same links/subnets is about some
>> (risky/not_so_trivial) optimizations.
>> 
>>     This information may be used to distinguish between
>>     events where configuration must be initiated, or a
>>     host already has valid configuration.
>> 
>> Nothing guarantees the validity of the previous configs once the host moves
>> off-link. There still needs to be some protocol exchange between the host
>> and the network elements to ensure validity of the parameters.
> 
> I guess you are right for the general case, although
> the concept is not that "we're safe" no signalling,
> but the distinction between already configured (maybe
> needs update later) and needs update now.
> The critical path is important in this.
> 
> In these cases, we certainly don't want to initiate
> MIPv6 binding signalling when the node detaches from an
> AP, and then reattaches immediately afterward, for example.

It depends on how quickly this happens, right? As the disconnection duration
increases, the chances that the CoA is allocated to some other node
increases. Hence the safest would be to re-do DAD.

If we are talking about short disconnections from the same link, the
question is, how often does this happen, and is this worth optimizing.

Also, if all we are dealing is detecting new network attachment, and
figuring out if the config parameters might have to change, then
optimizing the new configuration process is not really in scope. Or, maybe
it is. It really depends on how we set the scope of this WG.

> 
> Similarly, it may be worthwhile to initiate Optimistic
> DAD rather than full DAD, if a node re-attaches to the
> same link (regardless of how the IID was chosen) if the
> detachment was under RetransTimer (since no-one can claim
> the address in this time).  This would allow reception of
> packets while maintaining some of the safety.
> 
> Of course these are just illustrative ideas.
> 
> I still think that the statement is useful, though.

Alper


> 
> Greg
> 
> 
> 
>