Re: [DNA-BOF] [Announce] DNA in IPv6 Problem Statement ID

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

Hi Daniel,

Soohong Daniel Park wrote:
> Hello Jinhyeock and Greg.
> 
> After glancing, I wrote some comment that is a bit
> more straightforward...:-)
> 
> 
> Overall is good.
> 
> Most of all, my understanding is that this document (problem statements)
> will be referred to as a basis to several solution document. So it
> should
> address some possible alternative or solution in this document, of
> course
> it is a small text for each, and solution document will address these
> more detail...
> 
> Unclear Boundary (can be solved by link supporting)

I'm not sure that we want to put any reliance on the underlying
link if we can help it.  If we're making a solution (I'm not
sure we are yet though), it's best to ensure that the solution
complies with wireless system requirements, not the other way around.

> No transitivity (L bit is off ?)

This isn't really a solution, rather a complication...

The L bit means that there are different semantics
for the subnet, but haven't been nailed down in a solution
yet.

> Link local scope of Router Address (R bit in Modified Prefix Information
> option)

That helps, but once again, the fact that Routers don't
need to advertise these things un unsolicited RA is an issue.

> Omission of Prefix Information Option (RS/RA exchange)

Certainly RS/RA exchange is useful, if we have a hint.
Some existing RA acceleration techniques don't use RS/RA
exchange though (MIPv6, RA Caching in APs).

> Then we can clarify possible solution either basic DNA scheme or
> Optimized DNA scheme.

I think that all of this is important to know for the group,
but we've previously done this in the movement detection
optimizations draft (draft-daley-mobileip-movedetect-01.txt -
not very neatly though).

We can work more in that vein, but it's worth just specifying
the problems in one document, without reference to solutions.
The document then has more chance of advancement if we
leave the solutions out, since then people can't fight about
which is best :)

> 
>>5.3 Time delay
> 
> I agree with your definition however I guess this problem should be
> devided into both a host perspective and a router perspective.
> After then we can definitely propose reasonable solutions to meet with 
> each perspective
>
> For example:
> a host perspective: DAD delay, random delay, waiting time for RA, link
> up delay.
> a router perspective: random delay, unsolicited RA interval.

Certainly, you raise some interesting points (particularly
with the unsolicited (and solicited..) RA intervals.
I'm not sure we covered this yet.

I'll talk to JinHyeock about the Host persective and the
router persective.  Essentially, we've concentrated upon
host knowledge so far.

> Possible solutions:
> a host perspective: optimized DAD, random delay=0, reducing waiting time
> for RA, trigger method...
> a router perspective: fast RA, minimized unsolicited RA interval...
 >

Certainly, we need to describe candidate solutions and compare them.
It may be the role of a different document for this though
(maybe the movement detection optimizations draft???).

Would this be a suitable approach?

draft 1) problem statements only
draft 2) problems and some solutions (MDO update, individual submission)

Greg