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

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Iljitsch,

thanks for the review and comments...

El 27/06/2006, a las 13:21, Iljitsch van Beijnum escribió:
> 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 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??

actually i wanted to use weight' :-)

i will try to improve readability of the doc

>  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? or just that a sentence like "this means that the candidate  
locator pair set can be constructed as follows" would be enough?

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

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

the situation is the following
the peer has a set of addresses S
the peer announces a subset of the set of addresses in a shim context  
Ls(peer)
now some of these addresses may be tagged with the broken flag in the  
locator preference option, which would be interpreted that these  
locator a know to be locally not operational by the peer. the rest are  
the set of locators that the peer knows that they are locally  
operational... of course, as you point out this does not imply that  
these are all the locators that are locally operational for the peer,  
but it means that these are all the locators of the peer that are  
locally operational for the peer in this particular context at this  
point in time.

actually this is the same situation for the local locators, since the  
local host doesn't need to include all its locators in all its  
contexts...


> 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 mean, what was considered in the document was that either the last  
reachability test was successful or not and also the time elapsed since  
the last reachability test... would you consider additional  
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?

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

> I was slightlty shocked when I saw you have 17 rules.

me too!

>  I think this is way too many, hopefully this can be reduced.

fully agree


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

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

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

of course, having a big set of rules will result in a complex  
implementation

This approach that you are suggesting seems to simplify the second more  
than the first one and i think is a good idea, but i would rather first  
try to simplicy the first i.e. the amount of factors that need to the  
taken into account, first (as you do in the following comments)

> 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

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

> 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)

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

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

> 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

   We define the Locator-pair selection table to express preferences
   about which source address prefix to use when communicating with a
   given destination address prefix.  The table contains entries having
   a source prefix and a destination prefix each.  Given a locator pair,
   it is then possible to find a match when both the source prefix is
   contained in the source address and the destination prefix is
   contained in the destination address.

do you thing something else is needed?

> 9: this is unnecessary.

why?

i thing avoiding deprecated addresses may be useful...

could you expand on this?

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

> 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. Probably we could also define sets of temp addresses and  
addresses belonging to different sets shouldn't be used in the same  
communication...

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

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

> 13 and 16: may want to say that this only applies in the case of MIPv6

ok

> 14 and 15: see earlier

i guess i have addressed this earlier...

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


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


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

indeed comments about temp address should be included in the sec cons  
section

thanks,marcelo


> Iljitsch