[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA-BOF] Revised WG Charter
Hi Daniel,
It's good to see so much useful input.
Soohong Daniel Park wrote:
> It looks good for me and look into my inline comments.
>
>
>
>> -----Original Message-----
>> From: owner-dna@ecselists.eng.monash.edu.au
>> [_mailto:owner-dna@ecselists.eng.monash.edu.au_] On Behalf Of Greg Daley
>> Sent: Tuesday, December 23, 2003 8:47 AM
>> To: dna@eng.monash.edu.au
>> Cc: Pekka.Nikander; greg.daley@eng.monash.edu.au
>> Subject: [DNA-BOF] Revised WG Charter
>>
>>
>> Hi,
>>
>> Here's the charter which Pekka and I put together
>> after the last session.
>>
>> Please tell us what you think of the text
>> (clarity/coverage) and work-items.
>>
>> Let's start a separate thread if there's need
>> to discuss the location of DAD optimization work,
>> though.
>>
>> Greg
>>
>> We'll remove the DAD specific sections
>> if IPv6 WG take on the DAD optimizations.
>> Of the text in the charter, only the second last
>> paragraph and one of the dot-points refer to
>> IPv6 DAD optimization (Indicated with question marks).
>>
>> Also, there are two deliverables tied to this topic.
>>
>> ---------------------------------
>>
>> 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
>> stateful autoconfiguration procedures may take a
>> fairly long time due to delays associated with
>> Router Discovery and Duplicate Address Detection
>> processes.
>
> Is this working group treating on *stateful configuration*
> within a scope of item ? Above sentence occurs a
> ambiguousity. If considering, I think below sentence should be
> added...
>
> ...multicast listener (MLD) stage [RFC2710], Dynamic Host
> Configuration Protocol for IPv6 [RFC 3315].
>
> If not considering, you should remove "stateful autoconfiguration"
> from above sentence.
Certainly {stateful|stateless} address configuration is
part of the IP layer configuration, but DHCP is more than
that (containing application layer configuration as well).
I'd guess that we'll have to focus just on Layer 3 issues,
to keep the task managable.
so perhaps this is the way to phrase the above paragraph:
"...
In IPv6, the IP layer configuration information
includes the set of valid unicast addresses[RFC2462,
RFC3315], 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.
..."
This pre-introduces both DHC and SAA before we talk about
autoconfiguration.
(note the change from 2461 to 2462 in the first point).
Is this reasonable?
>> 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.
>
> Below is a individual thought.
> The purpose of the DNA working group is to define
> standard and BCP mechanisms (or protocol) that
> allow.....
BCPs aren't explicitly protocols. They are definitions
of how existing protocols are used.
"standards track" has an explicit meaning within IETF
which should remain here. Certainly we will develop
documents, but I hope we end up defining standards...
I suppose it depends on whether you think the IETF
is a standards or document development organization... :)
Does anyone else have a preference here (for mechanisms/
procedures/documents)?
I think it reads OK with the existing text (given the
particular meaning of standards track and BCP).
>> 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.
>
> As you know, IPv6 wg is working on RFC2461,2462-bis
> and considering lots of issues to extend each protocol.
> Don't we need to clarify what extensions are work items
> in DNA and relationship between them ?
Not really, we're mainly defining new procedures, or
new semantic interpretations of existing features.
The scope of the RFC246[12]bis updates are to clear
up ambiguity in the draft standards.
No new function is being introduced in the IPv6 updates
(AFAIK).
> and what issues happens on RFC 3315 ? possibly is so
> ambiguous for me...
RFC 3315 is DHCPv6. I don't think that we're explicitly
going to define DHC parameters, but it may become obvious
that additions are needed to DHCP discovery capabilities
(through IPv6 Router Discovery, for example).
I'm pretty sure that any protocol additions or modifications
will be reviewed or developed (even last called) in the group
which owns the original document, if it's appropriate.
At this stage, I'm not sure if DNA needs to use DHCPv6 at all.
I'd prefer not to pre-define a solution in the charter though.
>> ?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].
>
> In my opinion, *without* is not accurate. It is because we
> have been working for optimized DAD not skiped DAD
> against current DAD mechanism.
I think the issue is not without DAD, but without the cost
of traditional DAD.
Is there a better way to say this?
>> 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
>>
>
> Goals and Milestones:
> =================
> Feb 2004 ~ July : What happens during this period ?
We develop the documents within the group, and get them
reviewed.
I think that it may be hard to get a good discussion of
the documents without assuming that an IETF meeting will
pass.
Maybe we can get some of them done before August, but
I think there's no reason to set goals which are
uniformly out of reach from the start.
> Aug 2004: Submit Detecting Network Attachment in IPv6 as informational.
> Aug 2004: Submit Best Current Practice for Detecting Network Attachment
> in IPv6 as BCP
> Aug 2004: Submit Existing Link Layer Hints Catalogue as informational.
> Aug 2004: Submit IPv6 DAD Optimization Glals and Requirements as
> informational.
> Dec 2004: Submit IPv6 DAD Optimization as standard.
> Dec 2004: Submit Detecting Network Attachment in IPv6 as standard.
> Sep 2004: Close WG or Re-charter.
>
I think some of the dates and syntax are incorrect on
these.
I'll still keep the question marks for the DAD items
How about this:
"...
Aug 2004: Submit Detecting Network Attachment in IPv6
as informational.
Aug 2004: Submit Best Current Practice for Detecting
Network Attachment in IPv6 as BCP
Aug 2004: Submit Existing Link Layer Hints Catalogue
as informational.
?Aug 2004: Submit IPv6 DAD Optimization Goals and
? Requirements as informational.
?Dec 2004: Submit IPv6 DAD Optimization as Proposed
? Standard
Dec 2004: Submit Detecting Network Attachment in IPv6
as Proposed Standard
Feb 2005: Close or Re-charter WG.
..."
Thanks for your feedback.
Greg