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

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

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

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

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

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

> While it is a goal of DNA to provide network attachment detection
> systems which do not rely upon link-layer information, in some
> circumstances reception of hint information from lower layers may be
> valuable in speeding detection. In order to provide guidance to
> implementors, the group will survey existing link-layer hints and
> define general abstractions. The mechanisms developed by the WG will
> specify how these abstracted hints are utilized when they are
> present.

It might be reasonable to survey existing L2 hints, but I think it is
premature to include as in-scope the development of abstractions that
will be used. Let us see first what existing L2's do before assuming
that it makes sense to do the abstractions.

> The group will also undertake liaison opportunities with link-layer
> standardization authorities, in an effort to improve the quality of
> link indications for network attachment detection in future wireless
> link technologies.

This needs a lot more justification in my mind. I.e., it sounds like
wishful thinking on our part. What specific SDOs are we talking about?
And which of those is actually doing stuff that we'd have influence
on? IMO, fixing other LLs is quite far away from what this effort
should be focusing on. Let's focus on things we actually have some
real influence over (i.e, IETF protocols).

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

> This group will specify how to optimize the existing procedure for
> detection of IPv6 address collision. "DAD optimization" aims to reduce
> delay due to the detection of IPv6 address availability.
> 
> The following items are considered on-topic tasks for DNA group.
> 
>     * Liaise with other working groups which perform attachment
>       detection, to ensure their requirements for detecting network
>       attachment are met.

Can you be more explicit in terms of which WGs you have in mind? And
what sort of requirements do you think they would need to provide?

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

>     * Develop optimizations to network attachment detection for
>       time-constrained systems, such as MobileIPv6.

I'm very uncomfortable with the phrasing of this item. We don't need
more "optimizations" for every customer that thinks they are special
and needs to do things "faster". This is also an unscoped bullet in
which potentially any work could be brought in.

>     * Document a useful subset of existing Link-Hint mechanisms for
>       Detection of Network Attachment.

>     * Develop a DAD optimization protocol independent of link layer
        technology.

Presumably, this is IPv6 only.

Given the above, I think this scope of the charter could be slimmed
down quite a bit.

Thomas