draft-ietf-shim6-locator-pair-selection-00.txt

[Iljitsch van Beijnum <iljitsch@muada.com>]

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