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

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

Dear Thomas

Thanks for your comments. 

It seems to me that the your main concerns are as below  
1. The term 'Optimization/ Rapid attachment'
2. The work scope of 'Link layer hint' 
3. Including 'DAD'   
4. Including 'DNAv4'  
5. Liaison activities.  

Kindly find in line comments. 

> Here is my reaction to the charter. High-level: the charter appears to
> be aiming too broadly, and would better focus on the immediate problem
> at hand (at no more).

Agree. 

> > Description of Working Group:
> > 
> > Network Attachment occurs when a link-layer connection is established
> > and a node is able to send and receive some IP packets within a link,
> > particularly those used for configuration purposes. This process may
> > occur when link-layer authentication has completed, a host comes back
> > into range of a wireless cell, or a cable is plugged in.
> > 
> > While a host's network layer may initially be unaware of the
> > occurrence of attachment, it may already have valid IP configuration
> > for the link instance where it is attached. A host determines that
> > attachment has occurred, as well as whether it needs additional
> > configuration by Detecting Network Attachment (DNA).
> 
> The above should be the problem statement, but it comes across as not
> being precise enough. Seems to me, the issue is that whenever a node
> detects that it has (re)attached to a link, it needs to determine
> whether it is connected to the same link as earlier (if it remembers
> such things) and if not, go about configuring the link. And doing so
> is quickly as is reasonable. I say "as is resonable" because above
> all, we want robustness.

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. 

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.  

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. 
3. A node checks which parameters are still valid and which ones need new 
    configuration by gathering necessary information.
4. A node initiate configuration.  

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)

> > Rapid attachment detection is required when a host has existing upper
> > layer protocols sessions. This may be the case if a host is connected
> > intermittently, is a mobile host or has urgent data to transmit upon
> > attachment to a link.
> 
> We always want "rapid attachment", but no more rapid than makes sense
> with robustness in mind. I also do not think it is helpful to talk
> about it being "more urgent" for "rapid attachment" at some times
> rather than others (e.g., for mobile hosts). Let us assume that
> everyone wants to attach as quickly is is reasonable. But no more
> rapidly.
> 
> Drop the above perhaps?

We plan to design two DNA solution, basic one and optimized one. 

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. 

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.  

So it may be reasonable to design two solutions.
1. Basic one for all nodes. It uses the current ND features and doesn't need new 
    protocol so any node can safely fall back on but there will be some delay.
2. Optimized one for mobile node. It will reduce DNA delay but needs additional 
    protocol (FRD/ FastRA)    

> > For these nodes, it is also important detect if an acquired subnet or
> > link is new, or has already been visited. This information may be used
> > to distinguish between events where configuration must be initiated,
> > or a host already has valid configuration. For example, there may be a
> > requirement to to undertake address configuration, network-layer
> > authentication and multicast group managment signalling, before
> > receiving packets from off-link.
> 
> I think this effort should be focused on determining whether it has
> reattached to a place it knows about (in which case no further
> configuration is necessary) or a new place, in which case all the
> standard configuration will presumably need to be done.

In some cases, even though a node moves to an entirely new link, it can keep 
using some configuration parameters. It may cause problem if we identify 
'link change' and 'configuration check'. A node would better check configuration 
item by item. 

[Omitted]  
> > There are some IPv6 subsystems which need to send or receive packets,
> > immediately after attaching to a new network. Current address
> > configuration strategies rely upon hosts undertaking Duplicate Address
> > Detection (DAD), when they first configure an address. Current DAD
> > specifications prevent transmission and reception from a newly
> > configured address within the first second of attachment. Therefore,
> > some optimization may be desirable.
> 
> This is a separable item that is related to the DNA topic, but is not
> core. It is not immediately clear to me whether this should be done
> here or in the IPv6 WG. 

If DAD optimization can be done in IPv6 WG, it's good for me to put it there. 
The problem is, right now, it's kind of an orphan. It was first submitted to mobileip, 
which didn't feel like doing it. I wish we find a home for DAD optimization ASAP, 
so it can be done properly. 
  
[Omitted]
> >     * Describe existing attachment detection issues encountered in
> >       DHC, ZEROCONF, IPv6 and Mobileip WGs, documenting procedures
> >       which provide robust attachment detection for IPv4 and IPv6
> >       hosts.
> 
> For IPv4, this is now being done in DHC, i.e., see
> draft-ietf-dhc-dna-ipv4-04.txt.
> 
> So, the remaining question is where to do the IPv6 work.

Do you suggest DNA will deal with IPv6 case only? If so, I agree. 

After resolving above issues, can DNA BoF become a real WG? I feel like 
Pinocchio. :-) 
 
Best Regards

JinHyeock