Conversely, although the liveness testing must be on the basis of
individual ETRs, it does seem likely that many hosts in a site will
be trying to reach endpoints behind the same set of ETRs. As such,
having a border guy (or someone else, if you really want to
complicate life) testing / monitoring that liveness / reachability
on behalf of the various sources within the site would seem likely to
1) reduce the probing traffic
2) increase the odds of having accurate data when packets need to be
sent.
Exactly.
To recap what I tried to say:
So far we've had two models on the table: tunnel-router-based and
host-based. The tunnel-router based obviously checks reachability at
the TR granularity, and host-based on host granularity. This has
received criticism that a host-based model causes more signalling/
reachability testing traffic than the tunnel-router-based one.
My point was a simple one: not necessarily so. If TR-level
granularity is acceptable, then it is doable with a hybrid host+TR-
based solution (like the one I've been hand waving during the last
month or so), and in that case the amount of reachability testing /
signalling will be at the *same* level as for a TR-only solution.
Of course, in a hybrid solution the hosts can do reachability testing
themselves. However, if the only interface they have is behind a TR,
then it doesn't give any extra pay off to the host. That is, the host
has a slight pay off if it delegates the task to the TR, since the TR
may do more efficiently, as it has better information about the
multiple local links, and (at least sometimes) on the behalf of
multiple hosts at the same time.
Still, in a hybrid solution, a multi-homed the host has the option of
doing reachability testing on some interfaces itself, and on others
delegate the task to the TR.
--Pekka
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
