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

Re: [DNA] DNA Goals Issue List

Title: 

> What I mean by 'link identity detection' is 'To determine whether a host 
> remains at the same link or not.' In this sense, CPL detects the identity 
> of the currently attached link.
It was difficult for me to see the meaning 'To determine whether a host remains at the same link or not'
from 'link identity detection', but if everybody agrees thats what it means, I am OK with it.

> Hence, IMHO, it is valid to argue that DNA aims to detecting the
> _identity_ of the link.  That does not imply that you _necessarily_
> need to have (unique) identifiers.  In principle, an entity can exist
> and have an identity without having any identifier that denotes it.
Agreed. This explanation was very helpful.

Erik, JinHyeock and Pekka - Thanks for the clarification.

-Sathya

JinHyeock Choi wrote:
Sathya 

This is a single reply to your multiple mails as a single RA response 
to multple RSs in RFC 2461. :-)

  
G1 DNA schemes should detect the identity of the currently attached
     link to ascertain the validity of the existing IP configuration.
     They should recognize and determine whether a link change has
     occurred and initiate the process of acquiring a new configuration
     if necessary.
      
Shouldn't the first sentence just be "DNA schemes should ascertain the validity
of current IP configuration." 
    

No. I don't think so.  

  
I would think, how (detecting the identity of currently attached
link) the goal (ascertaining the validity of existing
IP configuration) is acheived should not be specified in the goals document?
    

The above statement is not entirely clear for me. What is not specified in Goals 
draft? Kindly clarify your reason why we should omit 'check for link change' part. 

Actually we already talked about the idea 'checking for link change' 
when we set up DNA charter. This is an extract from the AD's, Thomas Narten, 
mail (28th Oct 2003)  

     > A host determines that
     > attachment has occurred, as well as whether it needs additional
     > configuration by Detecting Network Attachment (DNA).

     Seems to me, the issue is that whenever a node
     detects that it has (re)attached to a link, it needs to determine
     whether it is connected to the same link as earlier (if it remembers
     such things) and if not, go about configuring the link. And doing so
     is quickly as is reasonable. 

So I guess this is fairly settled issue unless there is a convincing reason 
for a modification.  

  
I am not sure you need to detect the identity of currently attached link for quick
configuration either. For example, considering the CPL as the link identity, you don't 
need to detect the identity of currently attached link (the COMPLETE prefix list)
to ascertain the validity of the existing IP configuration or to quickly re-configure 
yourself. You only need one prefix - right? So, making "detecting the identity of 
the currently attached link" part of the goal is kinda misleading.
    

What I mean by 'link identity detection' is 'To determine whether a host remains 
at the same link or not.' In this sense, CPL detects the identity of the currently 
attached link. 

I confess that terminologies is less than perfect, so kindly interprete the term 
not literally but within the draft context. 

I can't imagine a fast DNA scheme without checking for link change, (the term is 
defined in Goals draft.) 

I can modify the terminology but see few reason to remove the idea of 'checking 
for link change'. If you still think that we should remove the idea 'checking for 
link change', it will be of help if you bring this up at Friday f2f meeting.  

Best Regards

JinHyeock