RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Tue, 29 Oct 2002, Tony Li wrote:

> |   However, if we can build a naming  hierarchy in which
> |   most multihomed networks connect to two places that are
> |   very close in the hierarchy, this buys us aggregatability.

> Unfortunately, that's not going to be so simple.  What happens
> when some organization that spans geographic areas decides
> that they want to multihome through providers on either sides
> of their particular continent?  Or even different continents?

Very few non-ISP organizations do this, as it requires them to move
traffic over their internal network which costs money, while receiving
the traffic where it eventually needs to be usually doesn't cost more
than receiving it at any other location.

In fact, large organizations with a large address block of their own
often announce more specifics in different locations. There is usually
no technical reason for having a large block rather than several smaller
ones.

If we can solve the problem for all other multihomers except the ones
that connect to the net in locations very far apart and _need_ to do
"internal transit", I think that would be good enough. Don't forget that
at this time, NOBODY other than ISPs gets to multihome in IPv6.

> |   That's one of the problems with networking: even
> |   if done wrong it can work so people don't even see they're doing it
> |   wrong. But then sometimes this is an advantage as you can still get
> |   things to work even if there is a reason why it can't be done right.

> Exactly.  What we want to build is a routing architecture that is
> never going to have to be replaced.

I don't think that's in the charter for this wg, but I agree this is a
worthy goal. However, we should also recognize that _some_ form of
multihoming in IPv6 is necessary _soon_ (at a recent AMS-IX technical
meeting the fact that the exchange couldn't get provider independent
IPv6 address space was debated at length, RIPE has similar problems and
that's just what I know first hand). That's the reason I came up with my
provider-internal draft, which I originally named "geo for now" because
it only provides a short-term solution. Unfortunately, it looks like the
RIRs aren't going to implement a new address allocation mechanism as
long as this doesn't get the IETF stamp of approval, despite the fact
that the draft only proposes new operational practices and not a new
protocol.

> It's too difficult to reach in and
> change it, so you'd like it to be done right the first time.

I don't think "this" is the first time.  :-)

> Geographic aggregation is fine if the topology does indeed provide
> a convenient aggregation boundary.

Geography in itself is useless, as it isn't visible to the network.
However, aggregation makes the logical path longer. If we can use
geography to map long logical paths to short physical ones, that isn't
an issue and we can aggregate as aggressively as possible. In other
words: if I have to route a packet to a place where more specific
information is known, it helps if this place is in the direction the
packet has to travel anyway.

> But in many cases, there will be no
> such convenient boundary.  What do you do?  You cannot make an exception
> and flat route any enterprise that has such links, because then their
> overhead dominates the cost of all routing and you're not sufficiently
> scalable.

If we require a solution (even a short-term one) to address this fully,
then yes, this is a problem. However, I think we can leave this problem
unsolved for now as there doesn't seem to be a good reason for an
organization to do this other than cost saving and we're not in the
business of making the internet a more expensive place for all to
accomodate savings for some.

> As has been remarked elsewhere, we've been around and around and
> around on this topic for the last decade.  We have no new answers,
> only the bitter pill of reality that we cannot all seem to swallow
> at the same time.

I think we're getting closer as we've been mostly discussing
multi-address solutions the past week and these are compatible with the
reality pill. There are many concerns with this type of solution, but I
haven't seen any show stoppers yet.

The only question is whether we can agree on a temporary
fix to give us more time to develop one or more of these solutions.

Iljitsch