Re: [DNA-BOF] Charter statements for DAD optimization

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

Hi Youn Hee,

Thanks for this.

Youn-Hee Han wrote:
> Hello forks,
> 
> As you know, for promoting this DNA group, the first work we should
> do now is to complete the initial Charter. So, in the meantime, I would 
> like to propose partial Charter statements only for DAD optimization. 
> 
> I hope the following is included in the initial full Chater of this DNA WG.
> Please read the following and send comments.
> 
> ### Chater ###
> 
> [Statements related to Network Attachment, Address Confirmation 
> in DHCPv6, Link Detection, Link Triggers, etc.] In addition, this group
> will specify how to optimize the existing procedure for detection of IPv6
> address collision. Duplicate address detection (DAD) optimization aims
> to reduce delay due to the detection of IPv6 address collision. 

I like the top part.


> As Mobile IPv6 matures, the need for reliable and fast address allocation
> and DAD scheme becomes critical to the goal of providing real-time 
> data service. It should be also useful for nodes that are not doing 
> movement detection, but get detached and attached. For any node 
> wishing to send/receive packets immediately after achieving a new 
> attachment, therefore, DAD optimization can be applicable.

Maybe we need to talk about the issue with sending and receiving
packets within the first second of connectivity, rather than
starting with Mobile IPv6.

I'll try to adapt your text:

There are some subsystems which need to send or receive packets,
immediately after attaching to a new network.  Currently DA
specifications prevent transmission or reception from an
address on the new link within the first second of attachment.
Therefore, DAD optimization may be applicable.

> DAD optimization may reveal two distinct strategies: Stateless DAD 
> and Stateful DAD, which may be used to develop new DAD schemes. 
> Such classification of DAD optimization schemes is determined according 
> to whether the DAD state of addresses is stores in a node until they are 
> allocated. 

I'm not sure that this needs to be in the charter at this stage,
since it looks like it belongs either in the requirements space
or solution space.

I think that charter wants to provide an overview of
problem drivers for the working group.

What do you think?

> The goals of the DNA working group are to address the following issues:
> 
>    - [Statements related to Network Attachment, Address Confirmation 
>       in DHCPv6, Link Detection, Link Triggers, etc.]
> 
>       ...
> 
>    - DAD optimization protocol should be independent of any kind of layer
>       2 technology and must offer explicit support for reducing delay due to 
>       the detection of IPv6 address collision.

At a first look this is reasonable.

Thanks for the start.

Does anyone else have a comment on either Youn-Hee's original
text, or my suggestions?

Greg