[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA-BOF] Revised WG Charter

Hi Greg. The charter looks very good, thanks! A few nits
inline:

> Detecting Network Attachment (DNA)
> 
> When an IP node detects or suspects that its
> underlying link layer (L2) connectivity has or
> may have undergone a change, it needs to check
> whether its IP layer (L3) configuration and
> connectivity are still valid or have changed.
> In the case that the L3 connectivity has changed,
> the node needs to reconfigure and may need to
> initiate mobility procedures, such as sending
> Mobile IP binding updates. Changes in an L2
> connection do not necessarily mean that
> there has been change in L3 connectivity.
> 
> For the purposes of detecting network attachment,
> an L3 link is defined by the range within which
> IP packets may be sent without resorting to
> forwarding.  In other words, an L3 link is the
> range where a given IP configuration is valid.
> 
> In IPv6, the IP layer configuration information
> includes the set of valid unicast addresses[RFC2461],
> the DAD status of the addresses[RFC2462], valid
> routing prefixes[RFC2461], set of default
> routers[RFC2461], multicast listener (MLD)
> state[RFC2710].  The current IPv6 stateless and

Is this expected to be an exhaustive list or just
some examples? RFC 2461 Neighbor Cache and Destination
Cache should perhaps be included as well?

> stateful autoconfiguration procedures may take a
> fairly long time due to delays associated with
> Router Discovery and Duplicate Address Detection
> processes.
> 
> In some wireless technologies, the link layer state
> and events may not be accurate and unambiguous from
> the IP point of view.  For example, a host may be
> able to see a base station but still be unable to
> deliver or receive IP packets within the link.
> Similarily, a hardware indication that a radio link
> is up does not necessarily mean that all link layer
> configuration, such as authentication or virtual
> LAN connectivity has been completed.
> 
> The purpose of the DNA working group is to define
> standards track and BCP documents that allow hosts
> to detect their IP layer configuration and
> connectivity status quickly, and to propose some
> optimization to the current specifications that
> would allow a host to reconfigure its IPv6 layer
> faster than today.
> 
> Initiation of link change detection procedures can
> be achieved either through reception of messages at
> the IP layer or through indications from other
> layers.  The working group will produce a document
> that contains a catalogue of the indications
> available from a number of link layer technologies.
> 
> The working group will preduce a document explaining
> how a node can make best use of the existing L2
> and L3 information for detecting network attachment.
> 
> The working group will define a set extensions to the
> current IPv6 configuration protocols [RFC2461, 2462,
> possibly RFC3315] that allow the nodes to
> discover whether L3 configuration or connectivity
> may have changed more reliably and easily than today.
> 
> ?In order to detect network attachment, it is important
> ?to be able to send and receive IP messages on the link,
> ?even if the link has changed.
> ?The DNA WG will develop a system which allows use of
> ?an IPv6 addresses while determining if a link has
> ?changed without the latency cost of the traditional
> ?DAD [RFC2462].

This seems a bit unclear. Is the optimistic DAD procedure
only allowed to be used for the probes related to DNA, but
not for real traffic?

> The DNA WG will not provide explicit directions to
> implementors about datalink layer issues.

I did not get this, but maybe its just me.

> Goals:
> 
> * Document existing link layer (L2) information which is
>       useful to start detecting network attachment.
> 
> * Specify a solution framework for detecting network
>       attachment and L3 link change in IPv6 networks.
> 
> * Specify a set of extensions to the current IPv6
>       protocols for detecting network attachment and
>       L3 link change more reliably or more easily than
>       today.
> 
> ?* Develop a DAD optimization protocol, independent of
>       link layer (L2) technology.
> 
> 
> ----------------------------------------
> Deliverables:
> 
> 
> Detecting Network Attachment in IPv6:
>             Goals and Requirements  (Info)            Aug04
> 
> Best Current Practice for Detecting Network
>           Attachment in IPv6        (BCP)             Aug04
> 
> Detecting Network Attachment in
>           IPv6 Protocol             (Standards Track) Dec04

Hmm... I don't see a clear mapping between these three items
and the two items from the goals list relating to IPv6 DNA.
In the goals list, you talk about a framework and a set of
extensions. Here, you talk about a requirements document,
an "IPv6 as-is" DNA BCP, and the "extended IPv6" DNA RFC.

I think the deliverables list makes more sense than the
framework approach.

Perhaps you should also change "goals and requirements" into
"problem statement"? This might ensure that we don't spend
a lot of time listing detailed requirements, which would be
a waste of time, imho.

> Existing Link Layer Hints Catalogue (Info)            Aug04
> 
> 
> ?IPv6 DAD Optimization Goals and
> ?         Requirements              (Info)            Aug04
> ?
> ?IPv6 DAD Optimization              (Standards Track) Dec04

--Jari