Re: [DNA-BOF] BoF Last Call on DNA WG Charter.

[JinHyeock Choi <athene@sait.samsung.co.kr>]

Dear Thomas

Thanks for detailed feedback. Kindly find in line comments. 

Thomas Narten wrote: 
> > Usually link consists of 
> > 1) link-layer connection (access point), 
> > 2) default router (router address) and 
> > 3) the prefixes assigned.
> 
> I think the above is already blurring things in an unhelpful way. One
> either is attached to a link (or not). When one is attached, one wants
> to know if is the same link as before, or a different one. This is a
> yes/no question. If it is the same, no need to do anything. If
> different, one needs to recheck configuration. But exactly what
> configuration that is is (IMO) a bit out of scope for this WG. I.e.,
> in IPv4, one just used DHC. For IPv6, one just needs to get a current
> RA and so forth. There is no need for DNA to be focused on individual
> configuration parameters. That is the business of the configuration
> protocols.

I might not be clear enough. The only configurations I have in mind are 
1) IP address and 2) default router. 

Because other folks may want more configurations, I used the abstract 
expression, which may cause ambiguities.  

I think the main job of DNA is to check 
1) the (partial) reachability of current (if any) default router
2) the validity of current IP address.

and observed that in some cases, after a node moves to a new link, 
it can still use the current IP address. So I think it will make problems 
simpler if a node directly check 1) IP address and 2) default router 
instead of link change. 

By the way it is not clear to me what you meant by a node attached to 
the same link. 

Do you mean 
1) a node is attached to the same link-layer connection or 
2) a node is still reachable from the same default router? 

We'd better clarify this lest there should be confusion. 
 
> > Accordingly a node should configure several parameters, for example,
> > IP address and default router. When a node moves, these 3 entities
> > varies independently.  This makes the problem complicated because
> > it's possible that a node can keep using some parameter while others
> > are no longer valid.
> 
> I disagree. This is already trying to optimize the problem too much.

I have only two configuration in mind. 
1) IP address and 2) default router. 
 
> > In configuraiton view point, the problem is as below.  
> > 1. To be connected to Internet, a node should configure various parameters. 
> >     For example, 1) IP address, 2) default router. 
> > 2. When a node changes its link-layer connection, its configurations may or 
> >     may not be valid. It may be the case that some parameters still remain valid 
> >     while others not.
> 
> And the only way to know which are still valid (if some are not) is
> rerun configuration. That is a higher-layer issue than DNA, IMO.

The way to validity check, which I have in mind, is as belows.
 
A node 
1) To check the reachability with the current default router, sees the router 
    address in an RA and, if necessary, preforms NS/ NA exchange 
3) To check the current IP address is still valid, sees the Prefix Information 
    Option in an RA. 
 
The above seem to me in DNA scope.  
 
> > 3. A node checks which parameters are still valid and which ones need new 
> >     configuration by gathering necessary information.
> 
> You seem to be assuming that there are lots of different ways of
> getting this configuration information. I thought there is basically
> DHC and/or RAs. What else are you thinking of?

Those are exactly what I have in mind. (We may also need NS/ NA 
exchange, though I'd like to avoid it.)

I had used the expression which can accomodate the other views. 

[Omitted] 
> > We plan to design two DNA solution, basic one and optimized one.
> 
> Let's do basic DNA first. Then re-evaluate whether a second one is
> needed. Doing them both now runs the risk of doing premature
> optimizations.

It may but may not. It depends. For example, for quick router discovery, 
there are two solutions, FRD/ FastRA, which are independent to basic 
solution. It will speed up DNA work if we run parallel process. But if WG 
choose a sequential path, I will not make splash any more. It's not 
worthwhile to delay more over this.  
 
> > DNA scheme should be precise, fast and with little
> > overhead. Unfortunately sometimes these requirements are
> > contradictory. For example, after attachment, if a node performs NUD
> > with its current default router, it detects more precisely but will
> > suffer heavy delay. For some cases, a node need fast DNA at the cost
> > of precision.
> 
> I'm not sure why NUD has come into the picture here.

Some people think NUD is the proper way to do MD. KAME MIPv6 stack 
performs NUD with its current AR after movement. 

> > For DNA scheme with little delay, we need additional protocol. For
> > example, current Router Discovery mandates random delay before
> > sending a solicited RA.  To discovery a router fast enough, we need
> > a complementary protocol, FRD or FastRA, which we can't assume all
> > networks will support.
> 
> It is not clear to me that protocol changes (in the form of new
> packets on the wire) are needed. Maybe we need to revisit some of the
> timing assumptions (like how long  and when to delay). Is this what
> you are referring to, or are you assuming on-the-wire changes?

'Link Identifier solution' defines new option format. I will be happy If we can 
do the job without it but, at the current stage, (IMO) we can't rule out the 
possibility of new packet format. 
 
Best regards

JinHyeock