[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: failure detection
El 18/08/2005, a las 17:06, Paul Jakma escribió:
Suppose you have a multihomed site with ISPA and ISPB and that they
have assigned PrefA and PrefB respectivelly
Suppose you have Host1 in the multihomed host and that it is
communicating with Host2 outside the multihomed site. For that
communication, Host1 is using address PrefA:host1 both as locator and
as ULID. I assume that host2 has a single address host1
Is host2 shim-aware?
It must be for scenario in next sentence to work. Particularly given
RPF filtering at ISPs on "PA" customers.
Now, suppose that an outage in the link between the multihomed site
and ISPA occurs.
Host1 detects and needs to do something about it, how can he try with
an alternative path?
Why must host1 detect this? Host2 could also ;).
not in a unidirectional connectivity scenario
consider the case where the failure implies that:
PrefA:Host1 -> Host2 is not working
PrefB:Host1 -> Host2 is working
Host2 -> PrefA:Host1 is working
Host2 -> PrefB:Host1 is not working
How would you cope with this case?
If, as part of shim6 control, host1 had, /in advance/, informed host2
that prefB:host1 was /also/ a valid locator, then:
- if host2 was first to detect the problem, it could simply switch to
using the prefB:host1 locator
- if host1 notices there is a problem with bidirectional
communication, it can simply start using the PrefB based locator
(which host2 already knows about and should accept)
this last point is influencing SAS and trying with alternative source
locators, which is basically what we are considering here and that you
are opposing right?
This presumes host1 is actively managing its source address according
to state specific to shim6. However, there is a *better* way:
- dont have shim6 pick the ISP dependent part of the locator
- let the OS's existing SAS mechanisms pick the source address
according to routing policy, as per normal, for each and every
- let some external mechanism detect the local failure
Some (non-exhaustive) examples of such mechanisms:
- link status information
(eg PPP has its own heartbeat mechanism. PPP is often used for DSL
connections, which will be a common case for the scenario described
above for host1, today at least)
- Routing information
(eg, host1 /could/ get routing information from either or both of ISP1
and ISP2. Be it just a RIP default announced regularly on up to full
*read-only* BGP feeds)
we have already discussed this point (in multi6) and imho it is not
such a good idea to have the hosts to receive a full BGP feed.. i think
there was ssome kind of concensous on this point, but maybe now has
- Link probing / dead-gateway detection software
(At least one OS provides software to actively probe gateways and
adjust routes as/when required)
- Well-known remote host probing software
And so on.
So, I'm not sure shim6 is at all the best place to take on detection
of /local/ failures.
The idea is that shim performs e2e failure detection (as i already
mentioned earlier) so that the fate of the communicating parties i.e.
the apps is shared with the fault tolerance mechanism and that the shim
can detect all the potential outages and recover from them. Having
different mechanisms deal with different types of failures would result
in a reduced protection i guess
Ie, in your scenario above, what I'm saying is:
- Shim6 on host1 doesnt and shouldn't be involved in detecting local
but you are assuming that host1 detects local failures through other
means and this other means are likely to be injecting a full BGP feed
into end hosts, right?
- Only host2 needs to know and detect whether it must use PrefA or
PrefB based locator for host1.
Ie, this should all be about reachability of the *remote* locator.
Which local locator to use should simply *not* be in scope for shim6 -
then things get easier, and you can avail of one or more existing
mechanisms for detecting local failures.
as i mention above, i am not sure if this supports the unidirectional
case that i mention above.
This implies that in order to explore all the possible paths, we need
to make n^2 probes.
Yes, if you refuse to consider the option of leaving SAS to something
else (a wealth of mechanisms exist /already/), then you'll become
convinced you need n^2 probes. :)
Now, it is important to realize that n^2 is just an upper bound, and
that n^2 probes will only be performed when all paths have failed
except one and this is the last one you have tried with
Even better is to realise that local address selection simply does not
need to be something shim6 has to concern itself with. Then the number
of probes, in the worst case, goes down to n, where n is the number of
locators you have to hand for the remote shim6.
Don't forget, n^2 is per side. Each side will have to have to do it.
So you're looking at, worst case, for host1 with n locators and host2
with y locators, by my potentially incorrect algebra:
shim6 doing SAS and probing each side:
y^2 + n^2
In the worse case, both y and n tend to infinity, so generally n = y,
so the worst case therefore is:
as n and y -> infinity.
Your math is correct
now let me ask: how many unidirectional address pairs are available
between two hosts having y and n addresses each one?
i guess that we agree that there are y^2+n^2 different unidirectional
address pairs, right?
So the point is: if you want to provide full fault tolerance you need
to explore them all, if you don't, there may exists available paths
that you are discarding, hence there are communications that could be
preserved but you are not finding the available path to use.
Of course, you may have optimizations, like testing two unidirectional
paths (one in each directions) with a single packet exchange (2 packets
instead of 4), using local information for discarding some addresses
and so on, but again these are only optimizations.
If you figure out that the local source to use is better left to
other, existing, mechanisms, and only probe the remote side,
That's great, but you have 0 idea whether its the right address.
Determining the right address involves:
- route lookup on the destination to find the local output
- lookup source for this output
Shim6 /could/ do this, but on the other hand it could just leave the
local address in packets sent down the stack as unspecified, and the
OS will just do it for shim6.
how? i guess that you are asuming a BGP feed on hosts right?
I mean, a hosts with a single deafult route, wouldn't really know which
of the n addresses available in its single interface to use for a given
destiantion address... i mean DAS would not result in any particular
address and the source address would be selected randomly...
What is the benefit for shim6 to do this, that it MUST? (It doesn't
need to. Any such optimisations are purely implementation specific).
Ergo: No need for SAS in shim6.
No, shim will try to honor the policy table (or any other tool to
express policy we need to define) Obviously, if the path preffered by
the policy is not available, then shim will have to use others of
See, there's an existing way to send a packet to a remote host and
have the source be set appropriately for the preferred path - don't
specify the source address...
No complications needed.
That's entirely scaleable and well within reason for deployment at
'enterprise' shim6 sites.
agree, but this is not enough to preserve established communications
Are you considering the case that full BGP feed is injected to the
hosts, so that the hosts can find out which path is available towards
its final destination?
Well, in a BGP fed and shimmed network, I would imagine the shimming
would be done just on one or two hosts (or routers) at the edge of the
shimmed network. The BGP feed would be confined to those.
well, this seems a bit far from what is currently being considered imho
So far, we are assuming that the shim is a host based approach and that
each host performs all the functions of the shim
the case of the proxy that you are mentioning have been considered and
it is attractive but it presents some difficulties, especially w.r.t
security... perhaps you could try to consider the security implications
of that split that you are considering...
As far as I know, the ULID and shimming host need not be same machine,
is my understanding correct?
not sure what you mean here... ULID is upper layer identifier, right?
so the ULID belongs to the shim host, so i guess they are in the same