Subject: [DNA] Comments on BCP for routers ID

From: [email-masked]
Date: Thu, 10 Mar 2005 19:15:12 +0000

Hi,

Overall comments:
I think this is a very good document to begin with. I'm not sure if we
should combine statistical analysis of ND procedures with
recommendations/BCP for routers. Perhaps they would be better in separate
companion documents? I'm thinking of the network admins that will just want
a list of recommendations with perhaps short justifications. Poisson
formulae will probably scare many of them away ;-)  Nevertheless the
analysis is useful for researchers and implementors.

More detailed comments:

Section 1.2:
It is unclear to me what you are trying to say in this bit "Hosts wish to
identify if their currently configured prefix is present on the link". Are
we talking about detecting reachability of the current router or if the
current prefix has expired or both? I think a host will only disregard a
configured prefix if the current router becomes unreachable and/or the
prefix lifetime expires.

Section 1.3
I'm trying to think of a situation where the random interval delay doesn't
apply (you say "in almost all cases" it cannot be avoided). I can't think of
one where it can. If there is one, perhaps you should mention it?

Typo: Router should -> Routers should
Regarding this last sentence, perhaps say that this is discussed in 2.4?

Section 2.1
"Since unicast RAs are almost always sent in response to solicitation...".
The current standard (6.2.6 in rfc2461) says "the usual case is to multicast
the response to the all-nodes group". I'm not sure what the default
behaviour is for most implementations... my feeling is that they follow 2461
but perhaps it's worth checking.

Section 2.2
I think we should explicitly define in words what we mean by delay with
respect to the 'probability of delay'. I read it to mean any delay > the
computed random interval.

For P_mcdelay I got 0.8571 instead of 0.851

Is the basic lambda = 0.05 derived from any empirical evidence / observed
behavour? It would be a function of the number of hosts active on the link,
have you used some kind of 'average' for this?

Section 2.4
It would be useful to combine the 2 tables (have one column for rfc2461
minima and another for rfc3775 minima) and then put it in section 2.2 where
it would be a useful reference for following the analysis.

Section 2.5
Can you elaborate on what you mean by "additional storage may cause harm"?
Do you mean that movement detection may be slower because there are more
(stale) prefixes to check for? Or do you mean something more serious?

Section 2.6
I'm confused between the difference of
"Routers SHOULD include at least one global Prefix Information Option in
every Router Advertisement" and
"Routers SHOULD advertise at least one global address consistently in a
Prefix Information Option, by setting the Router Address 'R' Flag."

What is the 'R' flag? I can't see it in rfc2461 or 2461bis. Do you mean the
'L' flag?

If you mean for a router to enter its full global address for the on-link
interface in the 'prefix' field of the Prefix Inormation Option, be aware
that the advertised prefix may not necessarily be the same prefix used to
number the interface of the router. It is quite common practice for some
sites to set aside a particular prefix (e.g. a /64) to number all their
router interfaces.

Section 3.2
Makes some good points but I'm not sure it is applicable to DNA and in
particular a BCP for routers.

Section 3.3
Why not more than 3 routers on a link? What is the justification here? If a
link can support n routers according to a site's particular configuration
and needs, what's the problem?

Section 3.5
Multiple routers from different administrative organisations advertising on
the same link? I think this needs to be clarified with an example of such a
situation. It doesn't seem a realistic scenario to me?

Section 4.1
Type: authorization mechanisms exits -> authorization mechanisms exist

Section 4.2
I'm not sure we should be recommending the used of SEND here (i.e. saying
routers SHOULD support it). I dont think it is falls within the jurisdiction
of the DNA wg. Perhaps note that SEND could be used, and if it does then it
has implications such as key managment, configuring hosts with trust anchors
etc. More important would be to comment on what extent SEND impacts on the
latency of host configurations. Has anyone studied this?

That's about it for now.

Cheers,
Martin Dunmore