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

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

Hi Thomas,

While I've seen some responses already,
I'd like to try step back to your
original review of the charter, so that
we can work out whether the concerns
you have are addressable.

Thomas Narten wrote:
> 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.
> 

I think the original description became focussed on the capabilities
of the device, rather than on the goals.  The number of 'may's in
the two paragraphs didn't help either.

I've tried to reduce this.

"...
Network Attachment occurs when a link-layer connection is established
and a node (re)connects to a link-instance.  For example, this process
occurs when link-layer authentication has completed, a host comes back
into range of a wireless cell, or a cable is plugged in.

When attachment occurs a host needs to determine whether it is
connected to the same link-instance, or whether IP layer
configuration is required.  This attachment detection
should be accomplished as quickly as is reasonable.
..."

It's still two paragraphs, but tighter.

Please tell me if it is better/appropriate.

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

Sounds OK.

I think the original rationale was that we needed to
justify doing detection quickly in the charter.

I think we've got text which covers this above now
(we just have to see whether people agree on
what is reasonable :).

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

OK. That makes sense.

Is this paragraph redundant now, with the first two
paragraphs presented above?

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

I think this makes sense.

If it ends up that the cataloguing work implies
further work should be done, we can put that
into the charter later if it's needed (or ensure
that another WG is ready to take on the work).

We're not going to be able to do that as a BoF
which has already met twice.

How about reducing the above to:

"...
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 catalogue existing link-layer hints.
..."

?

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

I think that Bernard Aboba has principally
been involved with this work, talking to
IEEE handoff ESCG.  The handoff group seemed
to receive his input well.

Then again, DNA represents only a subset of
the requirements for wireless handovers in the
IETF (for example, there's FMIPv6).

Maybe Bernard can guess the value of a liaison
with a (current or future) DNA group, rather
than with individuals or the IESG.

>>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 may be worth discussing within the BoF before
the meeting (if IPv6 is a willing destination for
this work).

I can't see any problem with IPv6 DAD optimization
being taken on by IPv6WG in that case.

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

I think that the two points (above and below) are largely
related.  I'd guess that the requirements and the existing
solutions are partially intertwined.

I'll try to combine these points below.

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

Indeed.

Here is my replacement for the previous two dot points.
"...
   * Liaise with existing working groups (DHC, ZEROCONF, MIPSHOP, IPv6)
         to ensure that their requirements for robust attachment
         detection are met.  Information from this liaison
         will feed into either working group, as is appropriate.
..."

I don't expect that this is about selling DNA to other
working groups.  This would try to ensure that appropriate
needs are met by solutions coming out of DNA, and no
overlap work occurs.

For example, we're fairly confident that DHC is working fine
with DNAv4, but it may be useful to have matched terminology
for both solutions (for DNAv4 and DNAv6).

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

It's fairly realistic assumption that systems will all want to
be fast.  There are existing IPv6 ND issues though, which seem to
create conflicts between the robustness and speed requirements
when ND is used this way.  So we'll probably have to define
one solution (or one solution subset).

How about:

"...
* Develop an optimization framework for network attachment
   detection for time constrained systems.
..."

This implies a single solution.

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

Yes.  Whether this stays here or not
is another issue.

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

I'll put up an alternative charter (with amendments) when people
have made some comment.

Greg