[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-shim6-locator-pair-selection-00.txt
- To: shim6-wg <shim6@psg.com>
- Subject: draft-ietf-shim6-locator-pair-selection-00.txt
- From: Iljitsch van Beijnum <iljitsch@muada.com>
- Date: Tue, 27 Jun 2006 12:21:26 +0200
Hi Marcelo,
Apparently your visit to the Nomadiclab was a productive one, judging
by the ackowledgment sections of all those drafts. (-:
Note that this draft overlaps to a large degree with http://
www.muada.com/drafts/draft-van-beijnum-shim6-reach-detect-00.txt
(STILL not posted by the secretariat 8 days after the fact...)
I found some of the text a bit hard to follow, but it's hard to
pinpoint exact problems, except maybe that you use weight and weight*
as different variables, which I don't like. How are you going to
pronounce the second one?? 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. Words to this effect or even letting the
paragraph end in a colon rather than a period would help.
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.
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.
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?
I'm slightly worried about using so many random numbers, is there
anyone who knows how hard those are to generate?
I was slightlty shocked when I saw you have 17 rules. I think this is
way too many, hopefully this can be reduced. 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. Don't forget
that math can easily be pipelined and parallelized in a modern CPU
while if/thens can be detrimental to performance and make software
harder to debug. Example of what I mean:
preference = priority * 4096 + scope * 256 + weight * random[0-255]
Maybe even divide by the number of seconds since the last successful
packet exchange...
Scope can also be done as global = 1, site = 2, link local = 4, ipv4
= 8 then do a binary AND for source/dest and if the result != 0 the
scopes are compatible, if == 0, these addresses don't make for a
working pair.
Now let's have a look at those 17 rules...
1: src == dst??? Either this is a mistake and you mean something like
src1 == src2 or I seriously don't get it
3: isn't this covered by the notion of being locally operational?
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)
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.)
8: mentions locator pair table, but this isn't defined in the draft,
probably needs a reference
9: this is unnecessary.
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 here.
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. 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.
13 and 16: may want to say that this only applies in the case of MIPv6
14 and 15: see earlier
17: may want to make this one of the first rules after making sure
there is reachability. :-)
What about making sure we only use source addresses that we know the
correspondent knows we have, and/or are covered by HBA?
Security considerations: may want to think about the situation where
a host uses temporary addresses, whether or not it lets the other
side know about its non-temporary addresses.
Iljitsch