Re: [DNA] DNA BCP Submission

[Sathya Narayanan <sathya@research.panasonic.com>]

Dear JinHyeock -

I have clipped some of the portions. Please find my responses inline.

>>I understand, we will change the definition part to match with goals 
>>draft. 
>>    
>>
>Thanks. Also kindly clarify what this draft's stance w.r.t link identity detection.
>The above phrase gave me an impression that it tries to present a way for 
>DNA WITHOUT link identity detection. Am I right? 
>  
>
No. We are not trying to present a way for DNA without link identity 
detection. On the other hand, we are
not trying to define a unique 'link identifier' in this document either, 
except in the CPL section. (Greg, Nocolas -
if you disagree with my understanding, please correct me).  As Pekka 
pointed out during an earlier discussion,
we could achive link identification without having a specific identifier 
assigned to each link - in other words, two
node in the same link can have different identification mechanism, for 
ex. one using CPL while another could wait
for a RA with its current active prefix. Both mechanisms, have their own 
efficiency versus accuracy ratio.

>I don't think it's wise to include other helpful, but not relevant to DNA, features 
>in DNA BCP draft. For example, I hardly see how Sec 8.6 is relevant to DNA. 
>I think all it says w.r.t. DNA is "after a link change, MN should get CoA & send 
>BU".  
>  
>
;-) I agree, 8.6 could possibly go - it is more of a place holder right 
now and we may cut it later. But, what about
all the other sub-sections in 8, and 7, 9,11 etc. 10 could possibly move 
to an appendix.
During the last meeting, I got the sense that the working group wanted 
to keep BCP as the place were lot of the
additional issues like MLD, ND cache etc. are discussed. If the group 
feels otherwise, we could either cut them or
move them to the appendix.

>In my opinion, DNA BCP draft would better focus on DNA procedure.
>Wiht link identity detection, how to check for link change &
>Without link identity detection, how to ensure 1) default router (partial) 
>reachability & 2) existing IP address (prefix) validity.    
>  
>
I don't know if DNA is possible without link identification conceptually 
whether or not a unique (for
all nodes) 'identifier' is used. See my response below:

>Correct me if I am wrong, but Sec 4, 5 & 6 hardly tell about 
>'how to verify the existing IP address'. I failed to find it and 
>the content list is of little help. 
>
>Also kindly bear in mind that I mean 
>
>'to verify the validity of existing IP address'
>
>as 
>
>'to verify that the prefix of existing IP address is supported on 
>the currently attached link'.  
>
>IP address can be called really valid only after DAD completion
>but it's not my intention to include DAD in DNA. 
>
>Neither they tell enough of how to confirm (partial) reachability
>in the presence of link-local router address, where there are 
>plenty about bi-directional reachability confirmation. 
>  
>
I don't think it is reasonable for me to argue that sections 4,  5 & 6 
are answering the question
'how to verify the exiting IP address', if you (as a reader) don't agree 
;-) I will note this as part
of the issues and try to do a better job in -02.

>Actually, the two seem the only confirmations that are relevant to 
>DNA. Right now, I don't see any other configuration that need to 
>be verified for DNA. 
>  
>
Again, other configurations like MLD, ND etc., are not directly relevant 
to DNA - and the
question is back to whether the focus of BCP must be restricted by the 
goals or not. I will
raise this question during the meeting to get some consensus from the group.

>Kindly, take notice (partial) Reachability, NOT bi-directional one. In goals 
>draft-00, I wrote as below. 
>  
>
I understand.

>IMO, w.r.t DNA, it's enough for a host to detect that it can hear from 
>the existing default router. In DNA point of view, bi-directional reachability 
>is 'nice to have' feature, NOT 'need to have' one. If necessary, after DNA 
>completion, ND (RFC 2461) can kick in to establish bi-directional reachability. 
>  
>
I agree. Don't you think, if bi-directional reachability can be 
confirmed without additional cost as part of
DNA procedure, it makes sense to do so? I thought the goals draft allows 
(with a may) 'the collection of some of the
necessary information for new IP configuration' as part of the DNA 
procedure, to reduce handoff delay.
 Same logic should apply here, if another 'nice to have' feature can be 
achieved with little or no additional cost.

>Neither do I agree with 'any form of link-identification used for DNA is 
>going to be derived from the default router'. 
>
>What do you suggest a host would do if prefix information & router information 
>conflicts each other, such as a host receives an RA that has the same link-local 
>router address but includes only new Prefix Information Options?  
>  
>
My mistake - I didn't make myself clear - the way I look at it, in your 
example the new prefix options are still
derived from the router and the link-identification depends on the 
information from the router.

>DNA wrapped with DAD inside bi-directional reachability is hard to see! 
>:-(
>  
>
This is not an accurate description of the draft. If you don't read the 
additional information sections, you will not
come across DAD. I agree that as the second step in DNA process we have 
presented bi-directional reachability.
We will have to take a closer look at it.

But primarily, I think, your concerns with the draft are because of a 
fundamental direction issue for the BCP.
Do we to a large extent restrict the scope of BCP based on the goals 
draft or not? I think this question must be
answered in the next meeting.

thanks & regards,
Sathya