Re: [DNA-BOF] Revised WG Charter

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

Hi Alper,


Alper Yegin wrote:
> 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.
> 
> ...


The question is whether you're talking about "IP Subnet"
as the L3 and "Link" as the L2?

The problem with using subnet as a term is that while
IPv6 routers can form a subnet (by advertising and
routing a prefix), IPv6 (ND: 2461)explicitly allows
routers with disjoint sets of prefixes to co-exist
on the same link.

A link (at L3) is already defined by the link-local
scope (which all of the routers would share,
regardless of their configuration).

In DNA I guess that we're interested in ensuring that
packets received from a router on the same link-local
scope domain (L3 Link) but a different prefix set
don't cause change procedures.

For our initial work, defining BCP, I'd guess (and
have been told) that it may not be necessary to
avoid extra configuration operations when receiving
an RA from a new router (with different prefixes) on
the same link.

For the longer term goal, it would be good to ensure
that reception of an unknown RA doesn't start a
flurry of packet transmission over a wireless link.

> 
>>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?!?".

I've proposed the following text:

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

I think this covers some of the issues discussed last year
on the list.


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

Thanks.

I think the grammar may have to change a bit too:

"... allow hosts to detect IP layer configuration change 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.
>>
>>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".

Well perhaps a null extension if we find that there's
no need for modifications.

Thanks for your feedback,

Greg.