Re: [DNA-BOF] Revised WG Charter

[Alper Yegin <alper@docomolabs-usa.com>]

Hello,

Here are my few comments....


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

I suspect we are trying to differentiate between the "L2 link" and "L3
link". Do we need to get into this in the charter text? I'd say we might
want to talk about "IP subnet" vs. "link" if necessary.

...

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

I think we better somehow tie this to the DNA story. Or else, this begs the
question "so?!?".

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

"IP layer configuration change".... I think we are not trying to optimize
(e.g., cut number of round-trips) in router discovery and DHCP, but optimize
the process of detecting we need to engage these protocols. [OK, sometimes
detection overlaps with the configuration. For example, sending RS to detect
if the router has changed already starts the necessary exchange -learning
the prefix- for configuring a new IPv6 address if necessary]


> 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

... "if necessary".

Thanks.

Alper




> 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].
> 
> The DNA WG will not provide explicit directions to
> implementors about datalink layer issues.
> 
> 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
> 
> Existing Link Layer Hints Catalogue (Info)            Aug04
> 
> 
> ?IPv6 DAD Optimization Goals and
> ?         Requirements              (Info)            Aug04
> ?
> ?IPv6 DAD Optimization              (Standards Track) Dec04
> 
>