[routing-wg]BGP Update Report

On Mon, 11 Sep 2006 11:22:18 -0700, Vince Fuller wrote:
>If one assumes a well-engineered VPN solution that interconnects the ground
>stations to "peering" points to the rest of the Internet, then there should
>be no increase in delay for traffic outbound from the plane toward the
>Internet - traffic path will still be plane -> ground station -> nearest exit
>point to Internet.

As always: It depends.

In this case whether RPF prohibits asymmetric routing.
If RPF comes in the game, there might be some additional delay
if RPF requires the packets to be delivered from/near from the
network originating the prefix.

>The amount of delay increase for return traffic is hard to quantify; it will
>depend on how well the Conxion service network/VPN is connected to its
>upstream providers, how well-connected those providers are to interconnect
>points to the rest of the Internet, whether shortest-exit routing (or some
>other "optimized exit routing") is implemented between the various providers,
>etc. Many of these issues will apply to the current, dynamically-route-every-
>prefix model, too. In some cases, the VPN will make little or no different
>in delay; in some cases, it may increase one-way delay a bit.

To avoid the additional delay, the operator would have either to use
or build an own network with a single AS announced around the
world and with good peering connections all around the world.
Otherwise the traffic would be directed to the AS originating the
traffic on the specific continent, which then would have to
forward it internally probably thru the "big lakes delay line".
An possible solution could be multi-continental multihoming ...

>If one assumes no changes to ipv6 semantics, it is hard to envision such a
>solution being possible. "PI routing" degenerates into flat routing and 
>building "a true dynamic routing system beeing capable to handle large numbers
>of prefixes and dynamic changes in the routing table" is difficult to
>impossible  if one assumes a) a single number space that accomodates both
>routing information and endpoint-identification (which is a fundamental design
>assumption in ipv6 as currently specified) and b) continued super-linear
>growth in the number of unique subnets that are identified using that
>numbering space. 

Practice says: Don't try to find the perfect solution for the next 1000 years.
But do what is possible and reasonable today.

A first step would be to implement the options which are _obvious_
inside a BGP for v6 :

- Convert the "for sake of compatibility" attribute handling of IPv6
  routes into native v6 BGP Update messages.
  There is no reason to keep a >10 years old data format for the
  exchange of a new IP routing protocol, if both peering parties
  agree to a v6 peering, they should be knowledgable enough to
  type something like "bgp new format" once.

- Separate the AS routing information, e.g. the AS path attributes,
  from the prefix information. For the purpose of PI and multihoming
  routing it is absolutely sufficient to announce "Prefix 2001:.... is
  available thru AS1234 or set (AS1234,AS2345,...)"

Currently there is no reason to assume that the number of transit
network operators will increase significantly, it is just the prefix
count which tends to explode. On the other hand the computing
power and memory demand is primarily required for processing of
AS specific information (e.g. AS specific policies).

Thus my suggestion is:
- _Native_ v6 BGP.
- Provide an prefix independend AS-route
- Provide _attachement_information_ which attaches a prefix
  to one or more AS'n
- In case of dynamic changes: Provide change information
  to well defined Servers of all old and new AS'n informing
  them about the change and permitting some re-routing
  to the new AS for some time (similar to a "reroute service"
  of the snail mail in case of a move)
  This would move dynamics away from the global routing
  information base to the local providers.
  A slower update of the BGP database would also permit
  the adoption of link state features for those AS'n which
  support them with new routers containing more computational
  power.

The separation of Prefix and AS information would have
advantages regarding security features. too, and regarding the
adoption of clustering algorithms to reduce the size of the
forwarding information base.

>There are smart people who have been looking at how to fix this for more than
>a decade (some would say that research along these lines dates back to the
>1960s...see http://www.nanog.org/mtg-0606/fuller.html for a recent NANOG
>presentation on this topic, with pointers to earlier work); virtually all of
>the designs that have been offered require routing locator/endpoint-id
>separation. 

Interesting, and I agree: v6 without matching v6 routing is broken.

Unfortunately it seems very difficult to change the IPv6 stack itself,
as this would have implications on all v6 hosts _and_ all v6 routers.

In case of an BGP standard update just backbone routers are
affected and a convergence scheme should be possible.

Kind Regards
Oliver



Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany
oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0