[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DNA-BOF] Draft charter now online



Hi JinHyeock,

Sorry I'm late sending this, I started preparing it
previously.

JinHyeock Choi wrote:
> Hi Greg
> 
> Thanks for your helpful elaboration. Kindly find my inline comments. 
> 
> Greg Daley Wrote: 
> 
> 
>>Hi JinHyeock,
>>
>>We're talking about two separate concepts here:
>>
>>* connection to a single link-instance (isolated subnet),
>>
>>* connection to the Internet.
> 
> 
> It's not all clear to me why you distinguish them.  


I think that Internet Connectivity is when you can send packets to
Yahoo (or wherever).

I think that IP connectivity is when you can send
Internet Protocol Packets (not necessarily to the Internet,
just that we have network layer connectivity).
This may only be packets on the local link, unless we have
valid routing configuration.

This is partly why I've been talking about Network Attachment
instead of IP. It's because we're only talking about one
network (or subnet), rather than the Internet part of IP.

> 
>>JinHyeock Choi wrote:
>>
>>
>>>IMHO, No. To be called connected, I think, you should be able to access 
>>>Yahoo at least. :-)   
>>>
>>
>>To be connected to Yahoo entails:
> 
> 
> Thanks for your helpful elaboration below. 
> 
> 
>>1  Link Layer connection occurs.
>>2  Link-layer authentication is completed
> 
> 
> IMHO, Link layer attachment occurs at this point.  
 >

or Link-Local Connectivity

>>3  IP packets can be sent and received.
> 
> 
> IMHO, at this stage, a node don't have IP connectivity. IP connectivity is established 
> only after, at least, a node has suitable IP address. Even though it is attached to a 
> single subnet, it needs a link-local address. Definitely at this stage, a node can't access 
> Yahoo. :-). 

It does need a link-local address, or it can use the
unspecified address, and send or receive to/from
multicast addresses.

It doesn't explicitly need a unicast address to detect
if its configuration has changed (but may benefit from
a link-local address).

> This may be a matter of terminology. But we'd better clarify this lest there should 
> be confusion. 

Indeed.

> 
>>4  Detection of the new link or router availability
> 
> 
> IMHO, we'd better include the detection of the validity of current IP address. While
> it is attached to a new link, a node may be able to use its current IP address.  

I think that there's not much of a problem if we're talking
about global addresses and the address has been defended
immediately before.

If we move off the IP subnet, we're not going to conflict
with anyone.

If someone else joined the link in the interval, it is quite
likely that we can defend against them (unsolicited NA to
the solicited nodes' address within a second of leaving??)

Otherwise, if we've been away longer we'll definitely need
to check validity.

> 
>>5  Selection of a default router
>>6  Configuration of a topologically correct global address
>>     (through DHCP or Stateless autoconfiguration)
>>7  IP ARP/Neighbor Discovery for the default router completes
>>8  Network layer authentication to the router has completed.
> 
> 
> IMHO, IP Connectivity occurs at this point or after 10. 
> 
> 
>>9  DNS server is configured
>>10 DNS resolution completes.
> 
> 
> IMHO, IP Connectivity occurs at this point or after 8. 
> 


Definitely Internet Connectivity should be available then.


>>11 http traffic is sent and received.
>>
>>Which ones do we want to do?
>>I'd guess we have to do 4, and maybe hint at
>>5 and 6 (preferably we leave this to the systems
>>which already perform these tasks).
> 
> 
> IMHO, DNA have to do 4 and 
> gather information for 5, 6, 7. 
> 
> To do 4, a node should gather information for 5, 6, 7. Usually they are done 
> simultaneously. To detect, a node should gather information. In general, a node 
> can perform all the above by getting a suitable RA. 
> 
> For example, to detect a new router, a node compare the router address in RA 
> with its current default router address (For convenience, let's forget link-local scope 
> of router address for the while.). If they differ, the one in RA can be used to select 
> a new default router. 

This is the essence of the issue in DNA.
We really have an issue of information being used
to reliably indicate change of configuration requirements.

> 
>>In some cases, we it may be necessary to help to
>>start 8, but once again, we're not providing the code
>>to do this.
> 
> 
> I agree. 
> 
> 
>>This above is all about Internet connection.
>>
>>I think we have send/receive connectivity at 3 (though
>>we may not detect it) until 4.
> 
> 
> In here, we have disagreement. This may be the matter of terminology. Let's resolve 
> lest there should be confusion. 

OK.  I think I'll talk with you off-list about some of these
ideas, so we can come back to the list after we've
sorted out some ambiguities.

> 
>>This is sufficient to be connected to the (isolated) subnet.
> 
> 
> Even a node is connected to an isolated subnet, I wonder how it can perform ND 
> without receiving a suitable RA. 

I think that when I meant isolated subnet, that
we may not have generic traffic forwarding to the
Internet (we may have attached to a new network).

> 
>>If we want to be able to send packets further, this is
>>a configuration issue, not a detection issue.
> 
> 
> It may not be DNA issue to configure to send packets further. But, IMHO, it's DNA 
> issue to gather information for such configuration, for example, the on-link
 > prefixes on a link.

Definitely.

> 
>>I'd prefer we stick to detection that we've got a connection
>>to a new subnet or link-instance, and maybe indicate
>>(informatively) how we can use the detection to initiate
>>configuration.
>>
>>Does this make sense?
> 
> 
> I think it's impossible to separate detection and information gathering. To detect, a node 
> should gather information, which can be used for configuration. 
> 
You're right at least for the initial detection component.
For IPv4 or IPv6, either ND/ARP, DHCP or Router Discovery
are required.

I'd prefer it if we don't have to receive and interpret packets
from other configuration subsystems (than are explicitly
necessary) to accomplish DNA.

Greg