[routing-wg]BGP Update Report

>> The comment still applies. Imagine that this system were implemented
>> globally on all international/intercontinental air routes. It would still
>> be nice to avoid having each of those airplanes cause a globally-visible
>> routing update whenever it crosses some geographical boundary.
> 
> The problem is physics: The speed of light is about 300.000km/s in air
> and about 200.000km/s in fibre, which means a VPN solution causes an
> _additional_ >70ms delay for some additional 7000km VPN distance.

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.

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. On the upside,
worries about more-specific filtering and route-dampening will go away.

> No, VPN and NAT and PA and shim are not the solution for todays
> mobile communications demands. From the view point of the developer
> of such an intercontinental communications system todays internet
> technology looks outdated, the BGP re-anouncement is just a hack.
> Indeed, RFC1661 is dated July 1994.
> 
> This is just another example for the obvious demand of a true dynamic
> routing system beeing capable to handle large numbers of prefixes and
> dynamic changes in the routing table. Other demand results from mobile
> networks, IPv6 PI etc.
> 
> The demand _is_ there, simply saying "don't use PI, do keep 200 customers
> rules (IPv6), don't accept small prefixes, don't permit dynamic changes,
> do wait for our perfect shim solution which takes short additional 10 years
> to develop, do purely theoretical discussions on geoadressing" as the
> "restrictive approach" is not the solution.
> 
> Either the Internet community will find good answers to these demands,
> or the markets will find solutions without the Internet community ...
> 
> Ceterum Censeo: BGP_Standard_Update subito, IPv6 PI subito ...

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. 

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. Unfortunately, those who put together the current ipv6 did not
choose to follow the locator/endpoint-id separation path. For a variety of
reasons, trying to retro-fit the split into ipv6 with something like shim6
is difficult and it running into a lot of resistance.

	--Vince