On Fri, Jul 13, 2007 at 11:57:26AM -0400, Noel Chiappa wrote: > > From: David Meyer <dmm@1-4-5.net> > > > PI addressing enables a certain kind of "path selection" that might not > > be easy (or possibly desirable) to retain in any of the the LOC/ID > > split schemes we have been discussing. > > ... > > I advertise X to my other upstream, then my advertisement of X has the > > same cost (to the routing system) as a PI advertisement. > > Sure. As I said back in "Some Thoughts on Multihoming": > > http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_points.txt > > "Multihoming is something that is done to provide *benefits*. Those are not > *free*. There is a *cost* for them, and a multihoming design has to think > about *where* and how much those costs are." > > And if you support multi-homing with the routing, it's the routing that > has the costs. Most certainly. > > if I announce PI space, "switching to the new path" is controlled by > > the announcement/withdrawal of the PI prefix, and can happen much > > closer to the source. > > Sure. But go back to what I said next in that note: > > "JTW Principle: - The best design minimizes the overall cost of providing > those benefits. > JNC Corollary to the JTW Principle: - It is best if one can allocate the > costs so that the entities which benefit from the multihoming are > the ones to bear the cost." This was one of the "principles" that we came away from the IAB AMS meeting with, notably, that there is a misalignment in the costs and benefits of multihoming (core bears the cost, sites gain the benefit, etc). > If you have a site which is providing content to a large part of the > Internet, it makes sense (in a system-wide analysis) to have the routing > support multi-homing for that site, because while everyone pays part of the > costs, everyone also benefits. If you have a site that only a few people use, > then, to me at least, it makes sense to use solutions that put more of the > cost on the site and its users. That makes sense, although in the current regime even in the case of a large multihomed content provider, the core (network) still bears the burden while the site gains the benefit. In some sense everyone benefits (as you say), but that cost/benefit tradeoff isn't rationalized (i.e., there's no economy that assigns resources accordingly). Today that large site is no different than a small multihomed site (with respect to this issue). > Yes, the particular routing-based solutions you mentioned (8+8/GSE, PA and > encaps) have the unhappy property that you don't find the problem until the > packets are near the destination, and you may not be able to recover. But > there are other approaches... but they are not without costs of their own. Such as? It might be interesting to explore that space just a bit. And BTW, another problem with all of this is getting *there* (where ever there might be) from here. If the solution isn't incrementally deployable (and those do deploy the solution reap the benefits), then we have a tough sell. > I'd say that any multi-homing solution which is benefitting only a few people > has to involve the hosts more (which is why, architecturally, Multi6 went > down that path). For your particular issue, hosts would have to e.g. notice > that there's a service interruption, and try a different locator for the > service. Ah, of course. But then there are the latency issues with obtaining the mappings and with locator liveness. Trade this for that, I suppose (the mapping latency might not be an issue at "switch over time", since you might have gotten all the mappings at once during the initial query to the mapping system, whatever that may be). > > So in this sense aggregation breaks a certain kind of "path selection". > > I think we all realize that there is no free lunch, and that this is a > > property (such as it is) of the fact that aggregation throws away > > information in the interest of computability (a standard technique). > > There are some similar thoughts in "More Thoughts on Multihoming", here: > > http://ana-3.lcs.mit.edu/~jnc/tech/nsrg/multihoming_more.txt > > "Site multihoming is, fundamentally, a path-selection (routing) issue. That > is, there are multiple paths through the physical connectivity fabric, and > we wish to make more than one of them available for use. > This does not sound hard. Why is it so difficult? The issue turns out to be > simply one of efficiency - i.e. how high a cost (or overhead) do we want > the path selection to have/incur. If any infinite cost were acceptable, > there would be no problem." Sure, aggreed. > I don't have any magical solution to this problem. Indeed, looking at it > the way I laid it out in those two notes, graph theory kind of has you > trapped... Me either. But it is something to think about (along with the latency issues I mentioned about). Dave
Attachment:
signature.asc
Description: Digital signature