Hi Pekka, > -----Original Message----- > From: Pekka Nikander [mailto:[email protected]] > Sent: Tuesday, January 20, 2009 2:29 AM > To: RRG > Subject: Re: [rrg] Why a host-based solution does not > necessarily addsignalling load > > > 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.
I'm not sure why you're still thinking of a hybrid HIP/xTR as the preferred mode of operation. IMHO, in many cases the HIP end system should have direct access to the underlying physical links (ethernet, 802.11, etc. etc.) and not the tunnel interfaces of a co-resident xTR. This to allow choosing the correct physical link for the desired mode of operation and possibly based on link metrics. It also saves encapsulation overhead over underprivileged links. The other thing is that the HIP end system may need to do active testing of the path, where with RANGER the xTR gets to do both active and passive testing of the path (i.e., it listens for ICMP unreachables). So, I think the two reachability tests are complementary and not conflicting/interfering. So my answers are: HIP? yes xTR? yes HIP/xTR hybrid? no Fred [email protected] > > --Pekka > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
