[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA-BOF] Revised WG Charter
Dear Greg
Thanks for new chart.
Kindly find my BRIEF in line comments. I don't think we have
much time for discussion before Christmas holidays. :-)
[omitted]
> We'll remove the DAD specific sections
> if IPv6 WG take on the DAD optimizations.
Sounds reasonable.
[omitted]
> 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.
O.K.
> 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.
The term 'L3 link' may be confusing. What's the difference between
'L3 link' and 'link' defined in RFC 2461 as below?
link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IP.
It seems to me 'L3 link' and 'link' coincide. We know what 'L3 link'
means because we are familiar with the contexts but I am afraid the
term may cause unnecessary confusion among new comers. How
about using the term 'link' or 'subnet' instead?
Moreover I think that we'd better make it clear that 'multi-link subnet'
is out of consideration in DNA.
> 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
> stateful autoconfiguration procedures may take a
> fairly long time due to delays associated with
> Router Discovery and Duplicate Address Detection
> processes.
I wish the above are not exhaustive list but just some examples. Otherwise,
as Jari wrote, the list should be much longer, including link MTU.
> 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 above is not clear to me.
> 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.
Are 'To define standard track...' and 'to propose some optimizations...'
two separate activities or does the first include the second?
> 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.
O.K. I assume this part is about link layer hints.
> 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.
This part is not clear for me. Is this about the BCP document?
> 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.
O.K.
> ?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].
As Jari wrote, this part may give wrong impression.
> The DNA WG will not provide explicit directions to
> implementors about datalink layer issues.
Does the above mean WG will not deal with link layer issues? I hope
not. As you wrote, WG will work on link layer hints. IMHO, for efficient
DNA, we can't avoid link-layer issues and may produce a document as
a suggestion/ proposal (not explicit direction).
> 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.
Typo: produce not preduce.
> 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
It seems to me that goals and deliverables are slightly ajar. I wish we polish
these parts.
These are my SHORT comments because I don't think this season of harmony
and peace is appropriate for heated debates. :-)
Thanks for your work and Merry Christmas
Best Regards
JinHyeock