Excerpts from Brian E Carpenter on Tue, Jan 20, 2009 01:01:02PM +1300: > The e2e principle seems to make it clear that, ultimately, liveness > is the endpoint's responsibility, but that is usually interpreted as > a statement about what the transport layer or above should do. And > they already do it, 100% independently of what we do in layer 3 and > below. I think that limiting layer 3 liveness detection to the > prefix level (except presumably in the case of Mobile IP) is a > perfectly good engineering compromise, unless we're planning to > repudiate [Saltzer].
First let's step back and reiterate that we're talking about how to scale e2e liveness monitoring and failure recovery. xTRs and map-and-encap are not (necessarily) involved, although _monitoring_ intermediaries may be. Disregarding layers and what their responsibilities might be, if I understand correctly you're saying you would do prefix-level liveness monitoring for possible paths but only do specific address-level monitoring for address pairs that are currently in use? If so, are you saying that if that's the best you can get, you'll take it? Or do you really think that's good enough for end users? Excerpts from Joel M. Halpern on Mon, Jan 19, 2009 08:57:48PM -0500: > There are prefixes on RLocs. Such prefixes appear in routing. Clearly, > the presence of such a prefix in routing does not tell you enough to > judge the reachability or liveness of an individual xTR within that > prefix. (The absence of a prefix, that's useful. But that's the easy > part of the problem.) xTRs are only involved in a map-and-encap situation. We _may_ have a map-and-encap situation here but it's not required. > As far as I know, in terms of liveness testing of ETRs, there is no > granularity finer than the ETR to test. So if we are using an ID / RLoc > split, the liveness testing we are interested in is the reachability / > efficacy of a given ETR. [There is the additional complication of the > ETR being live, but not having reachability to the endpoint. That is a > different problem than the liveness problem described in the draft. > There are many additional problems...) Right ... the requirements on xTRs for liveness is completely different from those for end-to-end. xTRs take responsibility for getting traffic between _prefixes_, as opposed to endpoints. Excerpts from Pekka Nikander on Tue, Jan 20, 2009 12:28:44PM +0200: >> 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, That's the big question. I'm surprised people would find it acceptable. Think about how individual machines are multihomed between different providers today. If one of your interfaces goes down, the prefix you are part of in that provider is still available, so your peers would continue to try to talk to you there. I don't see how prefix liveness tests could take the place of e2e liveness tests. If I understand Brian correctly he thinks higher layer tests will take care of this problem, but we still need a way for those higher layer tests to be performed on src/dst pairs other than the ones in use by transport already. Happy Obama Day ... Scott _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
