[133387] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Start accepting longer prefixes as IPv4 depletes?

daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Dec 8 18:11:20 2010

From: Owen DeLong <owen@delong.com>
In-Reply-To: <4D000B22.9050509@brightok.net>
Date: Wed, 8 Dec 2010 15:07:09 -0800
To: Jack Bates <jbates@brightok.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


On Dec 8, 2010, at 2:48 PM, Jack Bates wrote:

>=20
>=20
> On 12/8/2010 4:12 PM, Owen DeLong wrote:
>> IMHO, a more ideal way to do this would be to add 32 bits to the
>> packet header for "destination ASN" and do IDR based on that,
>> but, changing the packet header at this time is hard and would
>> require a new IP version number.
>=20
> My only problem with this is how to get certain percentages of traffic =
to come through different transits. I realize I could specify a separate =
ASN, and balance traffic based on ASN instead of network, but I'm not =
sure what is saved.
>=20
If you have 200 prefixes and 3 routing policies, you need 3 ASNs in the =
global routing table instead
of 200 prefixes in the global routing table.

> ie, 4 ASNs vs 4 networks? The other issue is that networks are not all =
equal. Thought I presume you could shift networks around to different =
ASNs to accomplish this.
>=20
This assumes a 1:1 ratio between prefixes and routing policies. This is =
unrealistic in all but the most
trivial of networks.

> My hope is that the nature of v6 will actually reduce the routing =
table naturally (even though we are storing larger prefixes). Handing =
out address space on a 3-6 month curve is what has made it a nightmare. =
I'm going to go out on a limb (and not read the last BGP summary =
reports) and say that ISPs being assigned fragmented space has caused =
more routing table bloat than deaggregation for traffic engineering.
>=20
Yes... It should. However, even with the reduced IPv6 routing table, =
there will be circumstances
where multiple prefixes can efficiently be coalesced into common routing =
policies. Unfortunately,
the current designs of IPv4 and IPv6 do not allow us to actually do so. =
What I am proposing
would.

Owen



home help back first fref pref prev next nref lref last post