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

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

On 28-jun-2006, at 13:15, marcelo bagnulo braun wrote:
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...)
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 mistake?
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 the text.
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 (local)) 
   as the local locators that are included in the local locator set
   (Ls(local) as defined in [1]) and that are locally operational as
defined in [2]. Locally operational addresses are discovered through 
   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 [8] larger weights should be given a 
   proportionally higher probability of being selected.



being



   [8]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.



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 precisely.
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. 

Yes.
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 different: - 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 resulting rules 

Right.
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 (IPA,IPA)
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.



why?



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 here. 


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 rehoming an 
   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 algorithm. This rules act must be processed in order and if a given rule selects 
   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 rule...
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? 


or cga...
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... 

Ok.

Iljitsch