[arin-ppml] Routing Research Group is about to decide its scalable routing recommendation

Owen DeLong owen at delong.com
Sat Dec 19 08:59:42 EST 2009

On Dec 18, 2009, at 11:34 PM, Robin Whittle wrote:

> Hi Leo,
> Thanks for the continuing conversation.  You wrote:
>>> OK.  While there may be ways of marginally improving the operation of
>>> the DFZ, including by improvements to the BGP protocol, the goal of
>>> scalable routing is far beyond the modest improvements these might bring.
>> As I outlined in another message, there are really three visions of the
>> future.  
>> A) PA only, you will be aggregated.
>> B) PI for everyone, take your addresses with you for every end user.
>> C) Extending the current scheme of figuring out who is "worth" for PI.
>> If we could do A, BGP is fine.  

I think we are mixing up concepts and overloading terms in this discussion
even worse than the overloaded locator/identifier semantics of IP addresses.

BGP is not the primary issue.  The primary issue we are faced with is the
scalability of the way we make forwarding decisions in the IDR (Inter-Domain
Routing) realm.

Currently, we make those decisions based on the IP prefix, thus overloading
the IP addresses task as an end-system identifier with additional topological
locator semantics.

That is the issue which prevents scaling the routing system to PI for everyone,
much more than any of the deficiencies in BGP4.  In fact, BGP4 contains a
superset of that which would be necessary to build a FIB that could forward
based on destination ASN.  What is needed is a field in the packet header
for the destination ASN to be inserted at some point close to the origin,
and a way to do so without affecting host protocol stacks, at least initially.
A solution which can be incrementally deployed would be vastly superior
to a solution which requires a flag day since a flag day is pretty much
impossible in the current internet.

I am glad to see IETF working on this problem, but, I believe that all of the
current solutions are vastly more complicated than they need to be, and,
encompass changing a lot more than needs to be changed.


More information about the ARIN-PPML mailing list