Re: [RRG] some musings on PI v. PA, and assumptions, requirements, and tradeoffs

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > 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.


    > 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."

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.

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.

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.


    > 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."

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...

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg