[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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