Re: [DNA-BOF] Modified Charter available.

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Eric,

NJEDJOU Eric FTRD/DMR/REN wrote:
> Hello folks,
> 
> 
>>Description of Working Group:
> 
> 
>>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, a link is the range where a given IP
>>configuration is valid.
> 
> 
> In my opinion talking about "L3 link" is not a good idea at all. People
> will very soon get confused between L2 link and L3 link. The traditional
> "network layer" or "IP layer" expression was very convenient.  
> 

I'm tackling this in another e-mail.
Please check that one.

>>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], neighbor and destination
>>caches[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.
> 
> 
>>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.
> 
> 
> This paragraph should simply follow the first one. In such a way,
> link-layer information would be seen as potentially useful but having
> some shortcomings. Otherwise, in the way it is layed out in this charter
> it could be understood as : ok we need link hints......but they can't be
> used.  

I think there was a sentence which was added recently to
tie this to IP connectivity testing.

please see JinHyeock's email in this thread.

> 
>>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.    
> 
> 
>>The working group will produce a document explaining
>>how a node can make best use of the existing L2 and
>>L3 information for detecting network attachment.
> 
> 
> It seems to me that there is no corresponding deliverable to this target
> (at least for how to make the best use of L2 >information). Is  it
> intended to be in the catalog document? if the response is yes then the
> catalog document should have another name.  The added value of a
> document inside this group will be precisely to indicate what is the
> best use of link hints for the prupose of detecting network attachment.
> Each implementor already has his catalog or can come up with one very
> easily. To inventory link indications per technology is not the
> thoughtest problem.
> 

This text is actually out of date. I unfortunately
neglected to update this in the last round of changes.

This document is actually the BCP for DNA procedures,
without message modification.  This may work on the
'strong hints'/'weak hints' breakdown provided by
Bernard.  I don't think it would go into specifics
of which hints would be used.

For the link hints catalogue, there is value in describing
the exisiting link hints, and their provided information,
without prescribing how to use or present such information.

Please remember that the audience is an IP networking crowd
(implementing IP stacks) not a wireless link one, so they may
not already have a catalogue at hand, nor be aware of what
particular classes of events mean.  Therefore, the presence
of an informational document describing this means that
people won't have to do all that work themselves.

So while this isn't the toughest problem it makes a
contribution.

I get the impression that the IETF (in general) is
wary of:

1) API definition (even the sockets API raises concern)
2) Prescribing modifications to link-layers.

A statement in the charter is to re-assure people that neither
of these things will be in-scope for the group.

If the API work needs to be done, then we can make an argument
for it, based on interest from the community later.
That may not be in DNA WG though.

Greg