Re: Start accepting longer prefixes as IPv4 depletes?

[Owen DeLong <owen () delong com>]

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

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