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

[Thomas Narten <narten@us.ibm.com>]

"JinHyeock Choi" <athene@sait.samsung.co.kr> writes:


> We'd better approach DNA problem in the framework of not 'link detection' 
> but 'configuration check'. 'link detection' concept may cause complexity.  

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

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

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

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

> 4. A node initiate configuration.

If a node has changed its point of attachment, it must rerun all its
config. There may be ways to optimize that (i.e., renew in DHCv4). But
that is a config issue, not a DNA issue.

> Then the main issues for DNA will be
> 1) What configuration parameters a node should check their validity after (new) 
>     link-layer attachment. ( IMO, IP address and default router.) 
> 2) What information a node should gather for 1).  
> 3) With what procedure a node check configuration parameters 
>    (fpr example using NS/ NA exchange or RS/ RA exchange)

I think the above is the wrong order. 3 should be first.

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

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

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

> So it may be reasonable to design two solutions.

I'd like to see a better case made for this first.

> In some cases, even though a node moves to an entirely new link, it

Thomas