Re: [DNA] DNA BCP Submission

[JinHyeock Choi <jinchoe@samsung.com>]

Dear Sathya 

> Thanks for your comment. Please find my responses inline.
> 
> >First, about DNA definition, there seems a difference  
> >between goals & BCP drafts. 
> >
> >in BCP Abstract, you wrote
> >
> >"Detecting Network Attachment is a set of strategies for
> >determining configuration validity in wireless or rapidly changing
> >environments."
> >
> >whereas goals draft said
> >
> >"The process by which a host collects the appropriate information and
> >detects the identity of its currently attached link to ascertains the 
> >validity of its IP configuration, is called Detecting Network 
> >Attachment (DNA)." 
> >
> >In goals, DNA is supposed to detect the identity of currently attached 
> >link to verify all the configuration at a stroke. In BCP draft, DNA is 
> >supposed to verify configurations one by one. 
> >  
> >
> 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? 

> But, this also brings up the question
> that was raised before - 
> should the BCP be restricted in scope by the 
> goals document. I don't
> think so. So, in the abstract we will include something like " This 
> document details best current practice for
> using Neighbor Discovery procedures to  Detect Network Attachment in 
> IPv6 hosts and other supporting
> procedure to verify relevant configurations".

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

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 think it's wise to confuse what DNA is supposed to accomplish
> >as above.  
> >
> >Second, if you recommend DNA to verify configuraitons separately,
> >instead of link identity detection, I would like you to clearly pinpoint 
> >what configurations DNA is supposed to verify. 
> >
> >In DNA point of view, IMO, it seems to sufficient to verify 
> >1) (paritical) reachability of existing default routers
> >2) validity of exisitng IP addresses
> >  
> >
> We have mentioned these two configurations, in sections 4, 5 & 6 
> basically focuses on these two
> verifications as the heart of DNA procedures.

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. 
  
> >If you think that DNA needs to verify other configurations, clearly 
> >enumerate them. Then we can discuss about them.
> >
> >Right now, it's difficult for me to grasp what configurations you 
> >suggest DNA would verify.
> >  
> >
> OK - I guess I understand the confusion - Its the title of the section 5 
> - "Validity of current
> configurations".  From the section description you can see we are only 
> thinking about the current
> IP address and the current default router address. But, point well 
> taken. We will enumerate them
> 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. 
 
> >For example, I can't see why DNA needs to keen about reachability 
> >confirmation. I agree that Reachability confirmaiton is crucial for
> >Internet connectivity but so does DAD, which we decided to rule
> >out from DNA. 
> >  
> >
> You seem to be contradicting yourself. You mentioned 'reachability of 
> existing default routers' as one
> of the verifications above. Please clarify.

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

   Hence, to determine the need of a further configuration, a host needs
   to check at least that:

    1) Whether it knows a (partially) reachable default router.
    2) Whether it possesses a valid IP address.

   Partial reachability indicates that the host is able to receive
   packets from the router, but not necessarily vice versa.

> Of course, we don't have to do everything required for Internet 
> connectivity, but I think reachability confiirmation
> is crucial to DNA - any form of link-identification used for DNA is 
> going to be derived from the default router - so
> assuming network attachment to be succesful without verifying 
> reachability to the default router doesn't make sense
>  - while I can understand DAD to be a step after network attachment 
> before Internet connectivity becomes active.

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. 

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?  
 
> >Third, it would be helpful if you present why, right now, it's difficult 
> >to verify a specific configuration and how we can overcome the 
> >difficulties. 
> >
> >For example, to verify the (partial) reachability of existing default 
> >routers, two difficulties come into my mind. 
> >
> >1) How to confirm (partial) reachability with link-local address
> >Because router address is link-local scope, a host can't be
> >sure that it's default router is still (partially) reachable, even if 
> >a reply from the same link-local address arrives. 
> >
> >2) How to quickly detects unreachability 
> >It will take substantial time to detect something is not there. 
> >NUD will take 3 secs but BCP draft just says that it may be 
> >better to reduce the number of NS/ NA exchange as belows.  
> >
> >" However, if the host has indication that the link may
> >have changed, this delay may be reduced without significant damage
> >for the network by reducing the number of retries." 
> >
> >Moreover, if we reduce the number to one, it still will take 1 sec. 
> >
> >If you present how we can solve the above two under RFC 2461, it 
> >would be of help. 
> >  
> >
> I would like to talk with you about these two comments - lets discuss 
> this at IETF61.

ok. However, the above I gave only an example to underline my point. 
We need to enumerate other difficulties w.r.t. IP address (prefix) 
verification. 
 
> >Overall I would like the draft be more focused & organized. 
> >  
> >
> Two parallel responses:
> 1) The way we look at the draft right now is - upto section 6 is focused 
> DNA BCP - with some
> additional information in section 5 and 6 - from section 7 to 11 are 
> additional information for some
> specific topics/issues - and section 12 is the security considerations. 
> We do believe the text in there right now
> is all needed in the BCP.

First, I wish the draft talk more about link identity detection. 

It's not clear to me what the draft, especially Sec 5, suggests w.r.t. 
link identity detection. Does it recommend CPL based link identity 
detection? 

If so, DNA needs not concern default router reachability confirmation, 
irrespective of partial or bi-directional. CPL will complete DNA, and 
current protocols can mop up to verify configurations, such as DAD. 

If the draft is intended to present DNA schemes without link identity 
detection, such as verifying IP configuration one by one, I think more 
operational detail is needed. It's my opinion that it would be better to 
present a way how to verify 1) (partial) reachability of default router 
& 2) validity of existing IP address (without DAD) in detail.   

> 2) If you could be more specific it will be very useful. We went through 
> couple of iterations re-organizing the
> draft and removing some text since -00. If you could point to sections 
> which you think are redundant or
> out-of-focus, or, if you could suggest some form of re-orgnaization, it 
> will be great.

It's my opinion that additional configuration process after DNA completion, 
such as bi-directional reachability confirmation or DAD, is non-crucial. It 
seems to me that, in this draft,  many non-crucial parts are mixed with 
the crucial parts that make the draft a difficult read. I would like them to 
put in appendix or better in another draft. 

DNA wrapped with DAD inside bi-directional reachability is hard to see! 
:-(

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock