NANOG/IEPG/ISOC's current role

I think that its a fair description.

And honestly, I don't think a substantial percentage of end-networks
will renumber if there are not substantial incentives. If renumbering
becomes less-painful, with time & better tools, perhaps more will
renumber, but again I personally don't foresee a substantial number
doing so without some incentive(s).

The scenario that was previously described by Michael Dillon, I believe,
was one in which a singularly-homed [to provider 'a'] end-network [x]
moved to another provider [provider 'b'] and wanted to take their
provider [a] allocated address(es) with them. This is a case where, if
a larger aggregate is being announced by [a], then a specific component
announced from the [a] CIDR block would be announced by [b].

Of course, this happens anyway if [x] is dual-homed. I think we can all
agree that the peace-of-mind obtained by [x] in becoming dual-homed is
less than optimal for the Routing Table Watchers (tm). :slight_smile:

This just happens to be a Catch-22 with multihomed end-networks.

- paul

And honestly, I don't think a substantial percentage of end-networks
will renumber if there are not substantial incentives.

This is true. One incentive could be peer pressure created by industry
magazines publishing how-to articles with tools being readily available
and the stigma of toxic waste dumps attached to those who don't renumber.

Of course, use of RFC1918 addresses like 10/8 coupled with proxy
firewalling solves the renumbering problem quite handily but ISP's who
are trying to justify /16 allocations would be loathe to recommend
use of RFC1918 to their customers. Negative incentives, eh?

The scenario that was previously described by Michael Dillon, I believe,
was one in which a singularly-homed [to provider 'a'] end-network [x]
moved to another provider [provider 'b'] and wanted to take their
provider [a] allocated address(es) with them. This is a case where, if
a larger aggregate is being announced by [a], then a specific component
announced from the [a] CIDR block would be announced by [b].

One problem ISP's run into is that if they allocate addresses to customer
networks and then move to another provider they either need to keep their
IP allocation or force their customers to renumber. Many customers may
choose to switch ISP's or other nasty things, therefore the ISP would
like a way to keep the allocation. I'm not sure my idea was terribly
great, the real solution is probably to keep the old T1 for the old
customers and buy a new T1 for expansion with the new NSP and a new set
of addresses. It's not neccessary to run BGP4 in order to have two T1's
from two providers with two different CIDR blocks.

Has anyone ever proposed this as a solution to an ISP?

This just happens to be a Catch-22 with multihomed end-networks.

It really is about time that some of the larger ISP's started following
the lead of folks like netaxs.com and become aggregate providers for
local ISP's in their cities. This way the aggregator can be doubly and
triply homed and deal with all the BGP4 nastiness. The ISP's gain the
benefit of that multihoming to their city and in addition can get some of
the redundancy-in-case-of-failure by buying a T1 and frame relay, or a T1
and ISDN dialup to their aggregate provider.

Every ISP wants to have a backup connection and right now most assume
that multi-homing is the only way to achieve this.

I believe that a middle-tier between the ISP and the NSP is the best way
to achieve this and could very well decrease global routing table size.

Michael Dillon Voice: +1-604-546-8022
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com