[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA-BOF] Revised WG Charter
Hi JinHyeock,
I hope you're well,
I've been thinking about links.
JinHyeock Choi wrote:
> 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?
I think the term link is OK (as defined in RFC2460/2461) that's
essentially what we're trying to convey, except that in
IPv6, there's also an implicit definition based on link-scope.
A link is where your link-local messages can reach.
We're not trying to change that, but there may be confusion
between (L2/data) link and (L3) link.
So we're just being explicit about which layer.
In order to show that the terms link and L3 link are
interchangeable, I'm rephrasing the above paragraph as:
"...
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, a link is the
range where a given IP configuration is valid.
..."
We just omit the second 'L3'.
I think we may need to use 'L3 link' to disambiguate the case
where we go directly from talking about link hints to link
change (for example in the goals section).
> Moreover I think that we'd better make it clear that 'multi-link subnet'
> is out of consideration in DNA.
>
Let's do that if we need to.
I hope that the term multi-link subnets dies out in general,
so I'd prefer not to put it in the charter.... :)
>
>>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.
I think that you're right here. There's a lot of information
which is specific to the link or subnet to which we're
attached.
There have been discussions about MTU for RFC2461bis
but I'll have to go and look at them.
Perhaps we can keep it in mind when we're developing the
problem statement.
>
>>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.
I'll try to get this worked out...
I think the big thing to indicate here is that connectivity
testing is important.
"...
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.
Therefore detecting network attachment requires not only
change detection but IP layer connectivity testing.
..."
Please tell me how this is.
>>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?
>
OK, let's make it a single set of operations.
"...
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, proposing 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.
>
>
> O.K. I assume this part is about link layer hints.
>
So do I...
>>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 best current practice
for nodes making use of existing L3 and L2 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.
>
>
> 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).
>
I've drafted replacement text for this in response to Jari's
e-mail. Please chave a look there (I'll collate changes
again this morning).
>>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.
Thanks.
>
>>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.
OK.
I'll get the list collated from the recent e-mails & re-post.
> These are my SHORT comments because I don't think this season of harmony
> and peace is appropriate for heated debates. :-)
But in IETF anything's possible :)
> Thanks for your work and Merry Christmas
I hope you've had a relaxing time over in Korea,
I'm sure it's a bit cooler than here.
Greg