Re: [DNA-BOF] Draft charter now online

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

Hi Spencer and JinHyeock,

I think your questions are interesting,
and I'll try to get to the heart of the issue.

JinHyeock Choi wrote:
> Hi Greg
>  
> I think we need more clarification on a few points. Kindly find my 
> in line comments. 
>   
> 
>>I think that we have to be careful to distinguish between
>>the ability to send datagrams, and the configuration
>>being available in order to do so.
>>
>>If we arrive on the same IP subnet which we have been
>>previously attached to (maybe a momentary disconnection),
>>then we already have enough configuration to transmit
>>to hosts within the link.  Additionally we already have
>>authentication configuration which allows us to transfer
>>data off the link.
>>(Although there are some difficult cases where not
>>all hosts on the subnet are reachable in from
>>another link-instance which is part of that subnet....)
>>
>>
>>In the case where we arrive on a new link-instance,
>>but we are unaware of the subnet to which we are attached,
>>we may not have valid global addresses, validated link-local
>>addresses or the capability to send data off the link.
>>
>>I believe that our task is to determine that we've
>>arrived on a new link, with a new IP subnet so that
>>other processes can undertake the configuration.
> 
> 
> I agree that our task is to determine that we've arrived on a new link, 
> with a new IP subnet. But I think that it is also the task of DNA to 
> gather some information (to receive a suitable RA from a router), 
> in case the node actually has arrived on a new IP subnet.  
> 
> This is the example which, I hope, will clarify my point. 
> 
> Assume a node arrives at a new link and receives a RA with Link Identifier 
> Option. If that link identifier differs from the current link identifier, the node 
> can detect movement. But the RA may not contain enough information 
> to configure new default router. In this case, I think it's DNA job to get a 
> proper RA.  

I think that this is reasonable, but we may not want to do the
configuration of the default router then, even if we want
to check that we have full RA information, if there is
another subsystem which is responsible for this.

For example, if a device is doing policy routing,
it may need to know which routers are valid on an interface,
without DNA explicitly setting the route itself.

> 
>>This means (for example) that if we don't need to
>>configure the host's global address in DNA, then we
>>leave it to the subsystem which is responsible for
>>that (be it DHCPv6 or SAA).  I'd guess the same applies
>>to Authentication for off-link data transfer.
>>
>>So I guess we have IP connectivity (the ability to
>>send and receive datagrams on the link, which I have been
>>calling Network Attachment) and IP configuration,
>>which entails appropriate Authentication, Addressing,
>>and Routing for the subnet.
>>My hunch is that the IP connectivity event (the network
>>attachment) comes when the wire is plugged into the host,
>>or the link-layer authentication is completed.
> 
> 
> It seems that we have ambiguity in terminology here. I think 
> what you mean by IP connectivity (Network Attachment) is not 
> what I mean by IP connection or IP Network Attachment 
> (On Spncer's suggestion). 
> 
> As I wrote on your suggestion, there are two attachments, 
> Datalink Attachment and Network Attachment.  IMHO, when link-layer 
> authentication is completed, Datalink Attachment occurs, not 
> Network Attachment.    
>   
> I hope we clarify this, lest there should be confusion. 

For the purposes of this discussion, I'm going to assume
that DNA's responsibility during ends when it has no more
packets to send on link, and no more indications to
provide to other subsystems.

If we're talking about connection to the Internet, then
there's obviously a time when we can send packets which
we can reasonably expect to be routed.

I'm not sure if the responsibility stops when we've handed
off the discovered RA information, and any meta information
to the configuration systems, or we've waited until
IP authentication or MIPv6 signalling has been
accomplished (both of these receiving some sort of
Ack).

If DNA is responsible for managing the whole process of
configuration, then the IP transmission subsystem or TCP
would be informed of the change in network from DNA,
rather than from the MIPv6 or AAA client subsystem.

Since we're not (explicity) in the role of providing API's or
Layer 3 hints, I'd prefer not to worry too much about this
at this time (as a DNA goal).  That's not to say that it
wouldn't be useful (I'm fairly sure it would be).

What is vital is that we help start off the authentication,
or that the MIPv6 address binding procedures are started
correctly.

In the case where no configuration is required, we can send
and receive packets as soon as we're on the link.
We may still be interested in sending a hint to upper layers.
In this case, we may need to distinguish between the
events, though:

* L2 only link change complete.
* L3 configuration change complete

DNA could certainly provide the first of these, but should
it send the second?

Is then network attachment the capability of having
routed packets go to Yahoo (for example)?

Today, I'd prefer to say that we can send and receive locally
as soon as we've "network attached", and that our job is to
use DHCPv4, ARP or Neighbor discovery to detect this.

Further work on top of this may be useful, but is still
dependent on th first goal of detection of topology change.

What do you think?

I guess that what we've got here is not a problem with
what we want to achieve. I think there's a need to clarify
what terms we're using, why, and what implications there
are from using particular terms.

> I hope we understand clearly what it means a node has network 
> attachment. 

Indeed. We need to work this out so we can
start our work.

Greg