[ppml] 2005-1 status

Owen DeLong owen at delong.com
Thu Feb 2 17:45:25 EST 2006

--On February 2, 2006 9:11:38 AM -0500 Scott Leibrand
<sleibrand at internap.com> wrote:

> Bill and Owen,
> What if the IETF comes up with a routing architecture / protocol design
> that allows for effective multihoming with PA space?  That seems more
> likely to me (in the near term) than a complete replacement of BGP4.
Changing the routing paradigm does not require a complete replacement of
BGP4 or even a modification to the vast majority of routers.  It requires
the following things:

Terms:	RL = Routing Locater -- Destination ASN or equivalent
	ESI = End System Identifier -- Full IPv6 Host address
	Prefix = Same meaning as in IPv4/IPv6 prefixes today.

1.	An extension header for placing the destination RL in the datagram.
	(Extension header type 53 could be given a new subtype to do this,
	the protocol is already designed to support this).

2.	Intra AS routing and routing outside the DFZ continues to be done
	as it is today based on prefixes.

3.	At the edge of the DFZ, routers which are aware of this new
	header would do the lookup necessary to insert it and insert 
	the header into datagrams they are routing.

4.	Within the DFZ, routers which are aware of this new header
	would forward the packet based on its contents and ignore
	the prefix unless the RL matched the local ASN.

5.	A mechanism for providing authenticated trnaslations between
	Prefix->RL(s) would be required.  Said mechanism would have
	to be distributed.  I believe DNS records with digital signature
	chains leading back to IANA is a possible solution.

6.	Eventually, when this is deployed widely enough, BGP could be modified
	to speak only of AS Path data and drop the prefix information
	to improve scalability.

7.	Later, we might be able to gain further optimizations by finding ways
	to hierarchically assign RLs so that less specific AS paths can be
	used as you get further from the destination.

This mechanism would allow for leaf sites to multihome by advertising the
RLs of each of their upstreams instead of having their own RL.  I believe
this would solve the routing table scale problem when we got to the point
that BGP no longer needed to advertise prefixes.

> IMO policy should recognize the status quo for what it is: the way things
> are done.  If the status quo needs to change, fine.  That's why we're
> debating 2005-1.  But I think it's dangerous to make policy with the goal
> of breaking things so that someone else will be forced to fix them later.
> IMO we should make policy that meets the current needs of our
> constituents, and strive to meet their future needs by working through the
> IETF process to fix the routing architecture, and then modifying policy in
> the future when future interests have emerged and we have a clearer idea
> of the tradeoffs.
I'm not proposing that we make policy for the sake of braking things.  I am
proposing that we no longer accept the way in which things are broken and
continue to penalize ARIN constituents in order to work around that
To that end, I believe 2005-1 is a significant step in that direction.
One which we should take.


If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060202/9c470e0b/attachment-0001.sig>

More information about the ARIN-PPML mailing list