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

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


El 29/06/2006, a las 13:29, Iljitsch van Beijnum escribió:


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.
i am not sure about this, especially if we want to leave the door open to allow the faildet protocol to be used for other protocols... the locator pair selection seems quite shim6 specific to me...
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. 



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



ok will try to express this
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.



suggestions...?
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. 



right this is what we are talking about below...
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.
but this is the age as it is used in the current draft i think... i mean, locator paris with newer reachability information are prefered over those with older information...
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.
well, the goal here is to simplify the reading and not forcing the reader to look for that in the other doc...
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. 

yes pseudo random number would be acceptable i guess

i can change this
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.
the weigth is only one octet, so maximum 255 i guess, but anyway, i agree that having high weights doesn't make much sense in any case...
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.
yes, but my idea was to, once we agree on the rules, include in the draft some implementations guidelines, describing this type of formulas that you suggest that summarize a set of rules...
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.


i have no strong preference here, i can remove this one




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. 



agree
but then you create all the potentially reachable locator pairs using the locally operational addresses and then you try them to figure out which of those are actually reachable.
So you discard the non locally operational addresses from the start and then you probe with the the others to see which ones are actually working
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. 

indeed, but i fail to see how this would happen...
i mean you will only try to change after a failure has been detected, right? so if no failure is detected, no rehoming, independetly of what the rules for the preferred locator pair to use next states...
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?
i don't think this is mentioned in the shim protocol document... it was mentioned once upon a time in the failure detection protocol, but not sure if it there still
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. 



agree
However, I don't see how using any kind of ambiguous addresses, such as link locals or old school site locals can work reliably. 



may agree with this too
i don't have a problem eliminating site and link local addresses form here 



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.
but if they are deprecated, they may stop working anytime soon, right? (for some definition of anytime)
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. 

with families i agree

with scopes, mixed scopes may work
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? 



in the creation of the candidate set perhaps?
Or do you want to stick to preferring the same address family or scope but also allowing mixing those? 



for versions i agree, for scopes i am not sure...
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. 



well, actually in this case, the rule is exactly the oposite...
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.
yes, you are right... we have talked about including some comment about this in the shim protocol document...
so would you say that once that the temp addresses have been included in the locator set, we don't need to make a distinction when selecting the address? i.e. remove this rule and only leave the cosniderations about including temp addresses in the locator sets?
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. 



ok, i guess this answer my question above :-)

i may agree with this...
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. 



ok, where would you put it?



regards, marcelo
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