[routing-wg]BGP Update Report
BGP Update Report Interval: 25-Aug-06 -to- 07-Sep-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4134 37938 2.8% 61.8 -- CHINANET-BACKBONE No.31,Jin-rong Street 2 - AS17974 18693 1.4% 36.9 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 3 - AS8685 13836 1.0% 406.9 -- DORUKNET DorukNet Istanbul / Turkey 4 - AS6197 11668 0.9% 11.3 -- BATI-ATL - BellSouth Network Solutions, Inc 5 - AS9121 11449 0.8% 97.0 -- TTNET TTnet Autonomous System 6 - AS15464 11391 0.8% 474.6 -- IHLASNET IHLASNET Autonomous System 7 - AS8386 10412 0.8% 433.8 -- KOCNET KOCNET-AS 8 - AS17557 10189 0.8% 28.4 -- PKTELECOM-AS-AP Pakistan Telecom 9 - AS15611 10017 0.7% 88.6 -- Iranian Research Organisation 10 - AS855 9974 0.7% 17.7 -- CANET-ASN-4 - Aliant Telecom 11 - AS34104 9297 0.7% 464.9 -- TELETEK-AS TELETEK TELEKOMINIKASYON HIZMETLERI A.S 12 - AS12497 8715 0.6% 174.3 -- SANET-GE SANET NETWORK (AS) 13 - AS7011 8589 0.6% 12.8 -- FRONTIER-AND-CITIZENS - Frontier Communications, Inc. 14 - AS33783 8176 0.6% 76.4 -- EEPAD 15 - AS4621 8164 0.6% 60.9 -- UNSPECIFIED UNINET-TH 16 - AS4787 8063 0.6% 30.2 -- ASN-CBN ASN CBNnet 17 - AS9394 8062 0.6% 17.6 -- CRNET CHINA RAILWAY Internet(CRNET) 18 - AS9021 7775 0.6% 555.4 -- ISNET ISBANKASI Autonomous System 19 - AS6198 7755 0.6% 15.0 -- BATI-MIA - BellSouth Network Solutions, Inc 20 - AS34695 7252 0.5% 164.8 -- E4A-AS E4A Primary AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS3043 3039 0.2% 3039.0 -- AMPHIB-AS - Amphibian Media Corporation 2 - AS30298 988 0.1% 988.0 -- FIRST-AMERICAN-BANK-SSB - First American Bank 3 - AS34378 900 0.1% 900.0 -- RUG-AS Razguliay-UKRROS Group 4 - AS12922 842 0.1% 842.0 -- MULTITRADE-AS Bank Outsourcer 5 - AS34984 794 0.1% 794.0 -- BITEL-AS BILISIM TELEKOM 6 - AS35080 784 0.1% 784.0 -- OYAK-TELEKOM-AS Oyak Telekom Hizm. BGP AS 7 - AS39298 762 0.1% 762.0 -- SERI Seri Bilgi Teknolojileri ve Destek Hizmetleri 8 - AS4271 1493 0.1% 746.5 -- WORX - Networx 9 - AS31526 745 0.1% 745.0 -- TEKOFAKS-AS TEKOFAKS 10 - AS29666 725 0.1% 725.0 -- TRHENKEL Turk Henkel Kimya Sanayi 11 - AS39080 721 0.1% 721.0 -- SIMETRI-AS SIMETRI YAZILIM 12 - AS31365 1432 0.1% 716.0 -- SGSTELEKOM SGS Telekom Autonomous System 13 - AS31085 711 0.1% 711.0 -- VIKINGNET-AS VIKING TUR 14 - AS29635 700 0.1% 700.0 -- BANVIT-AS Banvit A.S 15 - AS30734 682 0.1% 682.0 -- METISBILG-AS Metis Bilgi Sistemleri A.S 16 - AS31704 677 0.1% 677.0 -- ROBERTCOLLEGE-AS Robert College 17 - AS38920 676 0.1% 676.0 -- MNGBANK-TR Mng Turkiye 18 - AS39328 668 0.1% 668.0 -- BOTO-AS Borusan Oto 19 - AS31307 668 0.1% 668.0 -- YKYATIRIM YAPI KREDI YATIRIM 20 - AS29549 2646 0.2% 661.5 -- ZIRAATBANK-AS T.C. Ziraat Bankasi A.S. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.125.147.0/24 3980 0.2% AS17557 -- PKTELECOM-AS-AP Pakistan Telecom 2 - 208.0.225.0/24 3068 0.2% AS11139 -- CWRIN CW BARBADOS 3 - 209.140.24.0/24 3039 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 5 - 143.81.0.0/21 1618 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 6 - 205.98.32.0/20 1147 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 7 - 195.46.34.0/23 1013 0.1% AS31200 -- NTK Novotelecom ltd. 8 - 216.85.162.0/23 1001 0.1% AS6467 -- ESPIRECOMM - Xspedius Communications Co. 9 - 209.189.231.0/24 988 0.1% AS30298 -- FIRST-AMERICAN-BANK-SSB - First American Bank 10 - 205.97.69.0/24 933 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 11 - 130.36.88.0/21 931 0.1% AS2686 -- AT&T Global Network Services - EMEA 12 - 205.97.70.0/24 930 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 13 - 80.64.80.0/23 928 0.1% AS31200 -- NTK Novotelecom ltd. 14 - 193.242.123.0/24 900 0.1% AS34378 -- RUG-AS Razguliay-UKRROS Group 15 - 217.195.192.0/21 843 0.1% AS9121 -- TTNET TTnet Autonomous System 16 - 194.105.61.0/24 842 0.1% AS12922 -- MULTITRADE-AS Bank Outsourcer 17 - 60.253.32.0/24 822 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 18 - 216.51.192.0/18 808 0.1% AS5056 -- INS-NET-2 - Iowa Network Services 19 - 213.91.174.0/24 800 0.1% AS8866 -- BTC-AS Bulgarian Telecommunication Company Plc. 20 - 85.29.0.0/18 794 0.1% AS34984 -- BITEL-AS BILISIM TELEKOM Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog@merit.edu eof-list@ripe.net apops@apops.net routing-wg@ripe.net afnog@afnog.org ausnog@ausnog.net
On Fri, 8 Sep 2006, cidr-report@potaroo.net wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 17 - 60.253.32.0/24 822 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing
Hank Nussbacher http://www.interall.co.il
Hank,
Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
That's exactly how they do it. Each plane has a /24, each of the earth-stations has an ASN and as the flight progresses, the prefix moves from ASN to ASN. There were a couple of talks about it by Boeing people last year, but I can't find any slides offhand. However, I guess the service is now being run down? http://www.vnunet.com/vnunet/news/2162586/boeing-cans-flight-broadband http://networks.silicon.com/broadband/0,39024661,39161740,00.htm Rob
On Sep 8, 2006, at 10:57 AM, Hank Nussbacher wrote:
On Fri, 8 Sep 2006, cidr-report@potaroo.net wrote:
Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
They presented at NANOG saying they would be re-announcing a /24 per plane as it crosses the ocean. I can't recall if the originating (or transit) ASNs were going to change, but it doesn't seem wholly unreasonable. IMHO, of course. -- TTFN, patrick
That's exactly what we're doing. The aircraft traffic is sent to one of five satellite ground stations around the globe and released there to the Internet. To maintain connectivity for things like VPNs, we withdraw and re-announce the route for each plane as it is handed off from one ground station to another wrt satellite beams. Refer to several earlier presentations at NANOG. BTW, you may have seen the public announcement ~month ago that Connexion is closing down its commerical service by year end, so you won't be seeing these after that. TE Tom Eastgard Senior Manager Network Engineering Connexion By Boeing
-----Original Message----- From: Hank Nussbacher [mailto:hank@efes.iucc.ac.il] Sent: Friday, September 08, 2006 7:57 AM To: cidr-report@potaroo.net Cc: nanog@merit.edu; routing-wg@ripe.net Subject: Re: [routing-wg]BGP Update Report
On Fri, 8 Sep 2006, cidr-report@potaroo.net wrote:
Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 17 - 60.253.32.0/24 822 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing
Hank Nussbacher http://www.interall.co.il
Hi, On Fri, Sep 08, 2006 at 05:57:10PM +0300, Hank Nussbacher wrote:
On Fri, 8 Sep 2006, cidr-report@potaroo.net wrote:
Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing
Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even "per week")... - which should be the only time the BGP announcement moves. Sounds more like "the BGP-follows-plane system has some stability problems". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi Gert, On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote:
Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even "per week")... - which should be the only time the BGP announcement moves.
Sounds more like "the BGP-follows-plane system has some stability problems".
Nack. Probably they are using low or medium earth orbit satellites, which _are_ damn fast in orbit. Otherwise the round trip time would be unacceptably high. As the whole thing is 3D, some of them might have contact to ground stations on this or the other side of the great lake, depending on their 3D position, even thru the plane travels on a well defined track (probably a 3D circle, too) in just one direction only. Ceterum censeo: Nevertheless this moving-clients application shows some demand for a true-location-independend IP-addresses announcement feature (provider independend "roaming") in IPv6, as in v4 (even thru this isn't the "standard" way, but Connexion is anything but standard). Shim etc. is not sufficient ... Kind Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Hi, On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote:
Hi Gert, On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote:
Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even "per week")... - which should be the only time the BGP announcement moves.
Sounds more like "the BGP-follows-plane system has some stability problems".
Nack.
Probably they are using low or medium earth orbit satellites, which _are_ damn fast in orbit. Otherwise the round trip time would be unacceptably high.
The announcement is generated by the earth stations, and those are *not* fast. All the available papers clearly describe that - the BGP isn't coming from the plane itself, and the BGP announcement is supposed to change only when crossing to another continent. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote:
Hi Gert, On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote:
Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even "per week")... - which should be the only time the BGP announcement moves.
Sounds more like "the BGP-follows-plane system has some stability problems".
Nack.
Probably they are using low or medium earth orbit satellites, which _are_ damn fast in orbit. Otherwise the round trip time would be unacceptably high.
As the whole thing is 3D, some of them might have contact to ground stations on this or the other side of the great lake, depending on their 3D position, even thru the plane travels on a well defined track (probably a 3D circle, too) in just one direction only.
Ceterum censeo: Nevertheless this moving-clients application shows some demand for a true-location-independend IP-addresses announcement feature (provider independend "roaming") in IPv6, as in v4 (even thru this isn't the "standard" way, but Connexion is anything but standard). Shim etc. is not sufficient ...
One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed. --Vince
Hi, On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote:
One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed.
As has been said before, and is also readable in that blog entry: the system is supposed to create *one* advertisement change when the plane is crossing from the "Europe" to the "US" ground station (etc.), not 1000+. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote:
One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed.
As has been said before, and is also readable in that blog entry: the system is supposed to create *one* advertisement change when the plane is crossing from the "Europe" to the "US" ground station (etc.), not 1000+.
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. --Vince
Hello; On Sep 11, 2006, at 1:34 PM, Vince Fuller wrote:
On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote:
One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000 + routing changes per prefix per day as satellite handoffs are performed.
As has been said before, and is also readable in that blog entry: the system is supposed to create *one* advertisement change when the plane is crossing from the "Europe" to the "US" ground station (etc.), not 1000+.
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.
In a typical flight Europe / China I believe that there would be order 10-15 satellite transponder / ground station changes. The satellite footprints count for more that the geography.
--Vince
Regards Marshall
Marshall Eubanks writes:
In a typical flight Europe / China I believe that there would be order 10-15 satellite transponder / ground station changes. The satellite footprints count for more that the geography.
What I remember from the Connexion presentations is that they used only four ground stations to cover more or less the entire Northern hemisphere. I think the places were something like Lenk (Switzerland), Moscow, Tokyo, and somewhere in the Central U.S.. So a Europe->China flight should involve just one or two handoffs (Switzerland->Moscow(->Tokyo?)). Each ground station has a different ISP, and the airplane's /24 is re-announced from a different origin AS after the handoff. It's possible that there are additional satellite/transponder changes, but those wouldn't be visible in BGP. -- Simon.
On Mon, 11 Sep 2006 10:34:14 -0700, Vince Fuller wrote:
As has been said before, and is also readable in that blog entry: the system is supposed to create *one* advertisement change when the plane is crossing from the "Europe" to the "US" ground station (etc.), not 1000+.
Interesting. It sounds to me like the difference between theory and practice.
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. 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 ... Kind Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
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
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@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Vince Fuller writes:
On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote:
Ceterum censeo: Nevertheless this moving-clients application shows some demand for a true-location-independend IP-addresses announcement feature (provider independend "roaming") in IPv6, as in v4 (even thru this isn't the "standard" way, but Connexion is anything but standard). Shim etc. is not sufficient ...
Ehm, well, Connexion by Boeing is maybe not such a good example for this demand. Leaving aside the question whether there is a business case, I remain unconvinced that using BGP for mobility is even worth the effort. It is obvious that it "worked" for Boeing in IPv4, for some value of "worked", but the touted delay improvements on the terrestrial ISP path (ground station - user's "home" ISP) are probably lost in the noise compared to the 300ms of geostationary. But, hey, it's free - just deaggregate a few /19's worth of "PA" (what's that?) space into /24 and annouce and re-announce at will. Vince has an outline of an excellent solution that would have avoided all the load on the global routing system with (at least) the same performance (provided that the single network/VPN is announced to the Internet from good locations on multiple continents):
One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed.
But that would have cost money! Probably just 1% of the marketing budget of the project or 3% of the cost of equipping a single plane with the "bump" for the antenna, but why bother? With IPv4 you get away with advertising de-aggregated /24s from PA space. At one of the Boeing presentations (NANOG or RIPE) I asked the presenter how they coped with ISPs who filter. Instead of responding, he asked me back "are you from AS3303"?. From which I deduce that there are about two ISPs left who filter such more-specifics (AS3303 and us :-). IMHO Connexion by Boeing's BGP hack, while cool, is a good example of an abomination that should have been avoided by having slightly stronger incentives against polluting the global routing system. Where's Sean Doran when you need him? -- Simon (AS559).
Hello; On Sep 11, 2006, at 6:32 AM, Oliver Bartels wrote:
Hi Gert, On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote:
Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even "per week")... - which should be the only time the BGP announcement moves.
Sounds more like "the BGP-follows-plane system has some stability problems".
Nack.
Probably they are using low or medium earth orbit satellites, which _are_ damn fast in orbit. Otherwise the round trip time would be unacceptably high.
I believe that all Connexion support is / was from geostationary satellites.
As the whole thing is 3D, some of them might have contact to ground stations on this or the other side of the great lake, depending on their 3D position, even thru the plane travels on a well defined track (probably a 3D circle, too) in just one direction only.
Ceterum censeo: Nevertheless this moving-clients application shows some demand for a true-location-independend IP-addresses announcement feature (provider independend "roaming") in IPv6, as in v4 (even thru this isn't the "standard" way, but Connexion is anything but standard). Shim etc. is not sufficient ...
That seems like a reasonable conclusion.
Kind Regards Oliver
Regards Marshall
Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On Fri, 8 Sep 2006, Hank Nussbacher wrote: > Strike me as curious, but this seems as if Connexion by Boeing is handing > off a /24 from ASN to ASN as a certain plane moves over certain geographic > areas. Yes, that was their architecture, originally. My understanding was that they'd subsequently moved to a more complicated system of NATing, but my understanding may be incorrect, or they may not have done so entirely. -Bill
On Fri, Sep 08, 2006 at 05:57:10PM +0300, Hank Nussbacher wrote:
On Fri, 8 Sep 2006, cidr-report@potaroo.net wrote:
Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
Detailed at nanog 31 (among other meetings): http://www.nanog.org/mtg-0405/abarbanel.html 2005 detail from a blogger: http://bayosphere.com/node/879 2006 detail from another blogger: http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
On Fri, 8 Sep 2006, Joe Provo wrote:
On Fri, Sep 08, 2006 at 05:57:10PM +0300, Hank Nussbacher wrote:
On Fri, 8 Sep 2006, cidr-report@potaroo.net wrote:
Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation?
Detailed at nanog 31 (among other meetings): http://www.nanog.org/mtg-0405/abarbanel.html
2005 detail from a blogger: http://bayosphere.com/node/879
2006 detail from another blogger: http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml
-- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Yep. And they also presented it on this side of the Atlantic, back in May'2004: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-routing-globa... Best Regards, ./Carlos Skype: cf916183694 -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (196663/675), naming (millions) and... people!"
participants (13)
-
Bill Woodcock -
Carlos Friacas -
cidr-report＠potaroo.net -
Eastgard, Tom -
Gert Doering -
Hank Nussbacher -
Joe Provo -
Marshall Eubanks -
Oliver Bartels -
Patrick W. Gilmore -
Rob Evans -
Simon Leinen -
Vince Fuller