|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: [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
|