a radical proposal (Re: protocols that don't meet the need...)

Vince Fuller vaf at cisco.com
Thu Feb 16 01:25:49 UTC 2006

I'm sure I'm going to regret posting this, if for no other reason than that
I will immediately start receiving more spam, and I suspect that I am just
re-stating things that TLi and others have been trying to state both here
and on PPML, but I guess I just can't resist today...

[Disclaimer: I don't work for a provider these days; in fact, I work for
 the same vendor that Fred does, so it may seem odd that we are arguing...
 but I did work for university/regional/national/global ISPs from 1988
 until 2001 and during this time did participate, to some degree, in the
 IETF process. I even tried to contribute to the IPNG process early on
 until it became clear that the political process that drove the selection
 of ipv6 had very little connection to operational reality. In case it
 isn't obvious, these views are mine alone and do not represent the position
 of my or your employer]

> Interesting. This is what has been called metropolitan addressing.  
> I'm certainly not the one who first proposed it, although I have  
> thought about it for a while, dating at least as far back as 2001.
> This turns the business model of routing on its head. Typically today  
> if Alice is using ISP AliceNet and Bob is using ISP BobNet, Alice  
> hands her packet to AliceNet, AliceNet gets it to BobNet in the  
> cheapest way it can, and BobNet carries it halfway around the world  
> to Bob. Bob's ISP carries the burden of most of the work. But in this  
> model, if AliceNet happens to also provide service in Bob's region,  
> AliceNet might carry the packet to the region and only give it to  
> BobNet for the last 500 feet.

To address your points:

> Whenever I have talked about the model with an ISP, I have gotten  
> blasted. Basically, I have been told that
> (1) any idea on operations proposed in the IETF is a bad idea because  
> the IETF doesn't listen to operators

Would you disagree that the IPNG process essentially ignored the "hard"
issues (multihoming, endpoint-id/routing locator split, easy/transparent
renumbering, etc.) that were raised some 10 or more years ago? It may have
been "operators" who were most vocal in raising these issues (since they
are the ones who are suffering and will suffer the consequences of their
not being addressed -- no pun intended) but there were some pretty smart
people who didn't work for operators (e.g. JNC, TLi) who also argued for
something better than "IP with bigger addresses" as being needed for IPNG.
This certainly gave some credence to the idea that the IETF "doesn't listen
to operators" or to the others calling for a re-examination of the routing

Slight digression: I recall getting up during the plenary (at the time, I
was very public-speaking-averse, so the memory is vivid) at the Amsterdam
IETF (July, 1993) back when the whole "IP isn't going to scale; we need to
build something better" sentiment was starting. I stated that any solution
that didn't deal with transparent renumbering and multihoming was a non-
tarter. There was lots of applause then and promises that these issues would
definitely be covered. We still wound up with a non-functional ipv6.

> (2) the ISPs aren't going to be willing to make settlement payments  
> among themselves in accordance with the plan
> (3) routing isn't good enough to support it
> (4) and in any event, this makes it too easy to change ISPs
> In short, "hell no".

It's a little more basic than that. I'm no graph theory expert and reading
such stuff gives me a headache, but I do understand that abstraction
(summarization or aggregation) of routing information is only possible if the
identifiers that are used for numbering network elements (the "addresses") are
assigned in a manner that is isomporphic to the network topology. TLi started
writing a good paper which described this in terms of sets and subsets;
unfortunately, I don't think it ever saw the light of day).

Those who propose "geo-topological" addressing, an oxymoron if ever there
were one, are effectively dictating how the network topology is to be
organized, with rather profound implications for provider business models.
If addresses are assigned in this manner, then service providers whose
networks span multiple address assignment domains (connect to more than
one city or however the geograpic areas are split up) must:

  a) connect to all designated interconnection facilities associated with
     the address assignment authorities in the geographic areas they wish
     to serve


  1) carry all more-specific routes for all providers in all of the cities
     that they serve (which eliminates aggregation)


  2) provide free transit service for any customer of a competitor in a
     geographic area whose addresses are aggregated


  3) enter into a settlement agreement (which implies a regulatory regime
     unprecedented in the Internet business) with all other providers in
     geographic areas which they serve

Is it any surprise that large service providers are fundamentally opposed to
such a radical change in Internet business practices, one which effectively
dictates how they have to build their networks, what interconnection
facilities they must join, and how they must interact with competitors,
either by offering free transit service or by negotiating settlement contracts?

Until the IP "address" is replaced by an endpoint identifier and a routing
locator, it will not be possible to design a scalable routing architecture.
Years ago, some smart people (much smarter than me) tried to make it clear
how vitally important this distinction was. But the IPNG political process
ignored those people and the result was the undeployable mess that is ipv6.
If you want the Internet to scale to millions of customer sites that have
full flexibility to multihome with providers of their choice, the id/locator
split is essential; it may be possible to acheive this and still use ipv6
packet formats but incompatible implementation changes to "address" handling
semantics are needed at the transport and internetworking layer (think:
8+8/GSE and "agile transport identifier use").


More information about the NANOG mailing list