[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 28-jun-2006, at 13:15, marcelo bagnulo braun wrote:
Note that this draft overlaps to a large degree with http://
(STILL not posted by the secretariat 8 days after the fact...)
ok, i will comment on this draft in a separate email, but we should
probably try to produce a single document then...
I'm not sure though that your locator pair selection draft should be
a separate document... Maybe it's better to integrate it with the
failure/reachability detection document.
Also, just before section 2.2 the text ends and without
introduction, there is a formula. It is not immediately obvious
that this formula means the same thing as the preceding paragraph.
strange... actually the attempt was that the formula is the exact
formalization of the previous paragraph... do you think there is a
No, that's not what I wanted to say. What I mean is: it's not obvious
that the formula IS the same thing as what's said in the paragraph.
So you may want to say explicitly that the formula expresses the same
thing as the text so people won't be confused.
or just that a sentence like "this means that the candidate locator
pair set can be constructed as follows" would be enough?
If you say it in that way people may still think the formula means
something different than the text. The point is that if you
understand the text you don't have to spend time trying to figure out
what the formula means as long as you know it means the same thing as
I don't think using LOLs(peer) is a good choice, because this
assumes that we always know what the LOLs for the peer are,
without regard to the process of communicating the set back and
forth or the possibility that a peer may not disclose all of its
LOLs. Another name for this would be better.
but the draft defines:
We define the local set of locally-operational locators (LOLs
as the local locators that are included in the local locator set
(Ls(local) as defined in ) and that are locally operational as
defined in . Locally operational addresses are discovered
local means that are outside of the scope of this document.
so the definition states that these are not all the operational
addresses (not for the peer nor for the local host) but the
operational addresses that are included in the particular context
Sure, but it's still not the best possible name.
I'm not sure if reachable/unknown/unreachable is expressive
enough, maybe it's better to express this as a more gliding scale.
I'm not sure yet, though.
well, there is also the age of the reachability information
considered, making a scale among locator pairs for which a
reachability information is available... what else would you
include in this scale?
I would also take the preference values and maybe scope and create
one value that can be used to rank locator pairs.
It seems obvious to say something is reachable or unreachable, but
the problem is that you never really know for sure, because thins can
have changed since the last probe. So it's important to add a
confidence level, which would be the age of the reachable/unreachable
information. But that's two values, you can wrap that into one by
making reachable 100% and unreachable -100% and over time regress to
0% if no newer information becomes available.
I see you copied the weight calculation from the SRV RFC. Wouldn't
it be easier just to say what the results should be and refer to
this RFC for an example?
well, actually the draft states:
The weight field express the relative weight for locators with the
same priority, and as defined in  larger weights should be
proportionally higher probability of being selected.
 Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
do you think something else is needed?
You also include the whole story on how to do this, which is the same
(at least as far as I remember) as in RFC 2782. I think a reference
is sufficient, especially since there is no pressing need that the
actual calculation happens in this particular way.
I'm slightly worried about using so many random numbers, is there
anyone who knows how hard those are to generate?
i couldn't find another mean to include the weight distribution in
any other way.... do you have any ideas of howw to include a
probability distribution without using random numbers?
That would be cool, wouldn't it?
Actually, for this purpose there is no real reason for the numbers to
be truly random, as long as their distribution is fairly even and
different instances of an implementation don't all start with the
same value. So a random seed and a counter would work equally well.
And if you use random numbers, you need more random bits as the
weight values get more precise. For instance, if A and B have weights
1 and 3, then you need two random bits. If A is 1023 and B 3073 then
you need 12, but it seems rather ridiculous to specify weights this
One way to do this would be to translate as many decisions as
possible into a numbers or bit mapped flags which can be compared
much more easily.
this seems promising...
anyway, i guess we should first try to agree on what factors need
to be taken into account and then we can try to summarize them
using this type of technique.
Moreover, i would propose that we still keep the expalantion of all
the factors in the document and we also include this type of rules
because it is true that this type of rules result in an optimized
implementation, it is also true that they are more obscure than the
set rules. So i would keep the rules to make the understanding of
what is going on easier...
Agree. However, don't forget that the way something is explained in a
draft will be the default way it is implemented unless there are
important reasons to do it otherwise.
in other words, there are two issues here that i think are somehow
- on one hand there is the complexity due to the amount of factors
that need to be considered
- on the other hand is the complexity of implementing all the
1: src == dst??? Either this is a mistake and you mean something
like src1 == src2 or I seriously don't get it
this basically means that if you have two (src,dst) address pairs,
one being (IPA,IPA) and the other being (IPB,IPC) then you prefer
i guess this is not very useful in general but only in the specific
case that you are trying to communicate with the local host...
I think if you need to multihome make communication with the local
host more reliable you have problems that are bigger than what we can
fix with smart locator pair selection. :-)
I don't see any reason to keep this rule.
3: isn't this covered by the notion of being locally operational?
i don't think so, because one thing is that a given address is
locally non operational and another thing is that a address pair is
non operational. I mean, two locally operational addresses may
perfectly result in a non operational address pair (because the
path is broken)
Yes, but can we know this before the pair is tested with a probe?
That seems unlikely.
5: may overrule priority information, I think we want this in some
way but this is probably too simple (note that I talk about
stopping address pair exploration for addresses / pairs with equal
or lower preference but continue for ones with higher preference)
i am not sure i am following this...
note that this needs to be started at soem point, meaning that at
the begining, all address pairs will be in unknown state, so this
rule will not apply. So, this means that address pairs with high
preference will be explored and at this point some of these will be
know to be operational. So after that, the ones that are
operational will be preferred over those that are not.
What I'm afraid of is that a context may rehome several times in
quick succession because of this rule... That would be suboptimal.
6 and 7: shouldn't addresses of different families or scope be
procluded from pairing up in the first place? (Although there are
some corner cases where different scopes may work.)
well this may be an approach, but current rfc3484 follows this type
of approach allowing forming address pairs with different scope,
but we could do otherwise....
I have to read the latest version the "main" shim protocol draft
before Montreal so maybe this is in there or maybe not... But
wouldn't a dicussion on which address scopes are appropriate for
shim6 be more at home in the main document?
There is a lot to be said for limiting shim operations to global
unicast addresses only, but I'm afraid that's too simple: it could be
very useful to be able to use the shim on unique site locals in the
cases where two sites have a private interconnect so they can reach
each other using this type of addresses.
However, I don't see how using any kind of ambiguous addresses, such
as link locals or old school site locals can work reliably.
8: mentions locator pair table, but this isn't defined in the
draft, probably needs a reference
section 2.4. Locator-pair selection table states
Ok. I searched for "pair table" but didn't find any other mentions...
9: this is unnecessary.
i thing avoiding deprecated addresses may be useful...
I don't. Either deprecated addresses work, so we use them, or they
don't work, so we don't use them. No special case handling required.
10 and 11: it's becoming unclear to me how this list works. In BGP
you enter with a list of items and continue with the ones that
"win" a rule until you're left with one and that's the best one so
you choose that one. Another way to approach such a list is "if
(r1 && r2 ... r16 && r17) then use this pair" where the pairs are
pre-sorted for preference, but you seem to mix the two approaches
i am not sure i understand...
the draft states that
The goal of the defualt locator-pair selection algorithm is to
produce an ordered list of locator pairs to be tried for
ongoing communication. The ordered list can be produced with any
sorting algorithm. The set of rules described next are the
comparison criteria to be used in the locator-pair sorting
This rules act must be processed in order and if a given rule
a locator pair over the other one, then the following rules don't
need to be processed and the selected locator pair is prefered.
do you think that the described set of rules can be used as a
comparison criteria for a sorting algorithm?
Ok, this is the BGP style of rule processing. Upon rereading the list
of rules I see that this should work. However, some of the "prefer"
or "avoid" rules should really be "only accept" or "never use" rules,
such as don't mix address families and don't mix scopes.
Maybe there should be a separate list of rules for creating address
pairs where these rules could go so that the preference rules can
work as they are written now?
Or do you want to stick to preferring the same address family or
scope but also allowing mixing those?
12: I think this is inappropriate here. Yes, there should be a way
to prefer temporary addresses, but this is a policy setting on
most systems so it shouldn't be hardcoded into shim6 or something
related to shim6.
this is also included in rfc3484 i think and in the case of a
locator selection for the shim, it makes more sense to use a temp
address as oposed to the rfc3484 case, where you usually want to
prefer a public address.
First of all, I don't think it's a good idea to copy a rule just
because it's in a different place as well. This only makes it harder
to get rid of it when it turns out it was not a good rule.
Second, _using_ temporary or non-temporary addresses isn't all that
interesting in our case, it's _disclosing_ those addresses to the
other side that's important. So to be true to the intent of RFC 3041
we should make sure we only include temporary addresses in the
locator set that we send to the other side during shim negotiations.
I mean i agree that more cosnideration needs to be taken about
which temp addresses are included in the candidate set, but i think
this is needed in addition to this rule rather than instead of this
I think in the spirit of limiting the number of rules this is one
that doesn't really buy us much so there is no reason to include it.
A better way to handle this would be to take temporary yes/no into
consideration when building the LOL. Note that generally, a host
will have a temporary and a regular address in the same prefix.
The two of those would be equivalent for the purposes of shim6 so
there's no need to include both.
that makes sense
but are you suggesting that a host that has temp addresses will
generate both public and temp addresses for each prefix and that it
won't use both types in a single context? this may make sense, but
i am not sure we want to hardcode this as the default behaviour...
I think this would be the right thing to do, but in that case it's
important to be able to determine which addresses are the temporary
and non-temporary equivalents.
17: may want to make this one of the first rules after making sure
there is reachability. :-)
this is when you need to select a locator pair after a failure, i
guess so this rule would result in returning to the ulid pair once
that the alternative locator pair that is being used fails... but
we can remove this one...
No, it's a good rule, it's just that I would go back to the ULIDs
unless there is a very big reason to avoid them, not have this rule
sit at the very end as kind of a tie breaker.
What about making sure we only use source addresses that we know
the correspondent knows we have, and/or are covered by HBA?
but this verification is needed in order to be part of Ls(peer),
according to the shim prtocol, but we can include a comment about
this in the security considerations section...