[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-shim6-locator-pair-selection-00.txt
On 29-jun-2006, at 13:12, marcelo bagnulo braun wrote:
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...
We can always decide on this later.
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...?
How about local locator set and remote locator set?
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...
But it's not like the whole thing can't be understood without details
on how to handle weights. I think most people understand the idea
when you say that the chance of selecting an address must be equal to
its weight relative to the sum of the weights of the addresses under
consideration. Maybe someone who is a bit more mathematically
inclined can express this in a formula... (ASCII formula??)
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
It's probably enough to state that strong random numbers aren't
required. I think there is a reference to a randomness document,
maybe there is something in there that applies to this, and if not,
it would be possible to say that that document doesn't apply to these
specific random numbers.
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...
Ok.
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
Yes. You would probably even want to remove known non-operational
addresses from the set of addresses communicated to the peer and thus
they wouldn't be eligible for use as locators anyway. (Except in the
case of the ULID.)
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...
It also depends on the probing. If you rehome to address A and then
start probing address B then obviously, if B also works, the age for
B's reachability is less than that of A's reachability. So you have
the potential to rehome after every probe. That shouldn't be a
problem if you only probe addresses you know you want to rehome to if
they're reachable, but it could be troublesome if the probe
scheduling isn't very strict so unnecessary probes may happen.
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
One thing that we may want to consider: prefer locators that are of
the same scope as the ULIDs. So global locators are preferred when
the ULID is global, ULA locators for a ULA ULID (ULAID?).
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
Anyone else have an opinion?
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)
I suppose if you have two addresses that are otherwise 100% equal,
selecting the non-deprecated one would make sense. But that would be
at the very bottom of my list of selection criteria.
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
Ok.
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...
Strange...
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 think it makes sense to move some considerations, such as whether
an address is known to be non-operational, of an inappropriate
(ambiguous) scope, temporary/non-temporary to a different place where
addresses are selected for inclusion in the set of addresses
communicated to the other side. This can be in this draft, or in the
main shim protocol draft. Then, inappropriate pairings are removed
and then the preference is evaluated. In preference evaluation I
don't think we need temp/non-temp. But I guess implementers can add
this if they think it's important.
It may be a good idea to create an explicit place where
implementation specific choices can be made. So we have "strong"
rules from your list, then all the stuff implementers want to add is
looked at, and finally, "weak" rules from your list.
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?
I would like to have it before rule 5, but this may be hard to
implement without annoying corner cases, so maybe after 5?
Iljitsch