Subject: Re: [DNA] DNA BCP Submission

From: JinHyeock Choi <[email-masked]>
Date: Wed, 03 Nov 2004 00:29:56 +0900

Dear Sathya

I looked through the BCP draft and here are my comments. 

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

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. 

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. 

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. 

Overall I would like the draft be more focused & organized. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock

---

From: Sathya Narayanan <[email-masked]>
Date: Tue, 02 Nov 2004 12:02:11 -0500

Dear JinHyeock -

Thanks for your comment. Please find my responses inline.

>supposed to verify configurations one by one. 
I understand, we will change the definition part to match with goals 
draft. 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".

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

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

>Internet connectivity but so does DAD, which we decided to rule
You seem to be contradicting yourself. You mentioned 'reachability of 
existing default routers' as one
of the verifications above. Please clarify.

Ofcourse, 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.

>If you present how we can solve the above two under RFC 2461, it 
I would like to talk with you about these two comments - lets discuss 
this at IETF61.

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

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.

Once again, thanks for your comments.

with regards,
Sathya

---

From: JinHyeock Choi <[email-masked]>
Date: Wed, 03 Nov 2004 14:01:18 +0900

Dear Sathya 

> 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

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.    
 
> 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. 
  
> taken. We will enumerate them

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

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?  
 
> I would like to talk with you about these two comments - lets discuss 

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

> out-of-focus, or, if you could suggest some form of re-orgnaization, it 

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! 
:-(

Best Regards

JinHyeock

---

From: Sathya Narayanan <[email-masked]>
Date: Wed, 03 Nov 2004 14:08:44 -0500

Dear JinHyeock -

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

>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 think all it says w.r.t. DNA is "after a link change, MN should get CoA & send 
;-) 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.

>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

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

>DNA. Right now, I don't see any other configuration that need to 
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.

>draft-00, I wrote as below. 
I understand.

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

>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

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 04 Nov 2004 11:36:19 +0900

Sathya 

> efficiency versus accuracy ratio.

"An RA with its current active prefix" can't represent a link change 
properly. Hence, it can't be a link identifier, unless a host adopts CPL
technique. I am afraid we have a different notion about what link 
identifier is. 

With a link identifier, a host can properly determine whether 
it still remains at the same link or not. If a host sees the same 
link identifier, it means that it still remains at the same link. 
If it sees a different link identifier, it means that it is attached
to a different link. 

We wrote, in "DNA solution framework" draft, 

   ............................... Each link has its unique Link Identifier and all
   routers in the link advertise the same Link Identifier in RAs.  With
   a Link Identifier, an RA can represent a link identity and hosts can
   check for link change immediately without resorting to approximate
   knowledge.

   When a host receives an RA with the same Link Identifier, it still
   remains at the same link.  If it receives an RA with a different Link
   Identifier, a link change has occurred and the host is attached to a
   different link.

Link identity detection is supposed to check for link change. If you 
present a way for link identity detection without link identifier, that 
would be nice but the only alternative (without standard change)
I can think of is CPL. 

> move them to the appendix.

What concerns me the most is NOT the draft includes many uncruicial 
things BUT it doesn't include enough crucial things. Also I am afraid
that too much focus on uncrucial things may prevent crucial things 
from getting enough attention.  
 
> all nodes) 'identifier' is used. See my response below:

A host may skip to check for link change and directly verify 
IP configuration one by one. 

> of the issues and try to do a better job in -02.

Thanks. 
 
> raise this question during the meeting to get some consensus from the group.

I guess the issue is more of 'priority' rather than 'restriciton'. I think 
the BCP focus should be primarily on the DNA relevant stuffs. If 
those are adequately dealt with, we may work on other less-relevant stuffs. 
In organizational point of view, however, I would like secondary stuff 
be in another draft or appendix. 
 
> >draft-00, I wrote as below. 

ok. 
 
> achieved with little or no additional cost.

I agree. It would be nice if a host can establish bi-directional reachability
while performing DNA. 
 
> information from the router.

ok. 
 
> We will have to take a closer look at it.

ok. 
 
> answered in the next meeting.

As I wrote above, this is about not so much as 'restriction' but 'priority'. 
issue. I understand that DNA BCP draft is about 'how to perform DNA 
without standard change'. What bothers me about the draft is not 
it includes many other stuffs but it doesn't include enough DNA stuff. 

IMO, the draft says much about secondary stuffs, such as DNA & DAD, 
but doesn't pay enough attention to DNA itself, especially link identity 
detection. It hardly say about how a host check for link change. 

For example, after a hint of a possible link change, assume a host 
receives a RA with a link-local router address that is identical to 
the currently stored default router address. How does the draft
suggest host would determine the identity of the currently attached 
link? Can it assume that it still remains at the link based on link-local 
address? If so, what would be the risk? If not, what further activities 
the host would take to corroborate the decision? Also how much 
time it would take to perform all this activities and how to minimize
the delay. I failed to find a guide for hosts in such situations. 

The main issue should be whether the draft deals with DNA adequately 
or not. If so, either way is ok for me about whether to include other 
stuffs or not. If not, the draft would better work on DNA proper, instead 
of payint too much attention on secondary stuffs. 
 
Thanks for your kind consideration. 

Best Regards

JinHyeock