Hi Alex, > -----Original Message----- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Tuesday, June 09, 2015 8:14 AM > To: dmm@ietf.org > Subject: Re: [DMM] Scaling properties of AERO > > > > Le 08/06/2015 23:29, Templin, Fred L a écrit : > > Hi, > > > > I finally had a chance to sit back and think about the scaling > > properties of AERO, and I think it is within reason for each AERO > > link to service O(10^9) Clients. Here is what I wrote in the latest > > AERO draft version: > > > > "Scaling properties of the AERO routing system are therefore limited > > by the number of BGP routes that can be carried by Relays. Assuming > > O(10^6) as a maximum number of BGP routes, > > Deserves explanation of the O notation, and deserves expalining why you > assume 10^6 (and not 10^7). > > Another maximum number of BGP routes can be found in the routers in the > Default-Free Zone: 535593 as of January 30th, 2015.
Great; then, I think saying O(10^6) is not such a stretch whereas O(10^7) or more may also be possible but perhaps not as substantiated by current operational parameters? > Do you want the AERO system to scale as much as the entire existing > Internet? Or be part of it? Each AERO link is associated with a "home" network - for example, a major enterprise network, an ISP network, an aviation network, etc. It should be possible for each AERO link to accommodate large-scale deployments of mobile routers within each domain. O(10^9) mobile routers, each with an arbitrary-length prefix delegation, seems like reasonable scaling properties. Also, given that there may be many thousands of AERO links worldwide there may indeed be considerable scaling advantages. > > this means that at most O(10^6) Clients can be serviced by Relays > > within a single BGP instance. > > The O explanation would include the fact that several Clients behind a > Mobile Router keeps the same order of magnitude? Each Client is a Mobile Router, and may connect an arbitrarily large network of multitudes of hosts that travel along with it. Think of an airplane as a good example. Your cellphone and its associated personal area network devices is another good example. > > A means of increasing scaling would be to assign a different set of > > Relays for each set of ASPs, and still have each Server peer with > > each Relay but with a distinct BGP instance for each Relay set. > > Another possibility would be for Servers to institute route filters > > within a single BGP instance so that each set of Relays only > > receives BGP updates for the ASPs they aggregate. > > > > Assuming up to O(10^3) sets of Relays, scaling can then accommodate > > O(10^9) Clients with no additional overhead for Servers and Relays. > > In this way, each set of Relays services a specific set of ASPs that > > they advertise to peers outside of the AERO link, and each Server > > configures ASP-specific routes that list the correct set of Relays > > as next hops." > > > > https://datatracker.ietf.org/doc/draft-templin-aerolink/ > > I still have to understand this draft. It is really very straightforward and something everyone on this list should examine. All it is is a virtual link model that uses DHCPv6 and IPv6 ND the same as for regular physical links like Ethernet. Also BGP as the routing system. > But when talking scaling of a routing system, I think it is worth > characterizing it with maybe a few more parameters. > > The maximum number of IP hops in a shortest path between the BGP routers > which exchanged a route respective to a Moving Network. This is where AERO route optimization comes in. > The positive influence of the default routes on the reduction of route > update messages. Route update messages occur only when a Client changes from an old Server to a new Server which should happen very infrequently. That would constitute a "macro-mobility" event. Client "micro-mobility" events are coordinated between the Client and its Server and are not propagated into the routing system. > The influence of aggregating prefixes in the reduction of routes in the > routing tables (centralized and well-planned addressing architecture). Yes, aggregated prefixes known as AERO Service Prefixes (ASPs) are a fundamental design point in terms of scalability. > It is also worth making affirmative statements of the fact that BGP > worked to support mobility of a network the size of an airliner over two > continents, with an IP hop count of maximum 4(?) between the BGP routers > on the ground which injected the respective route. This would hint at > the fact that a BGP system part of AERO is scalable to support mobility. Need to be careful here. Although AERO uses BGP, it is not the same thing as Connexion By Boeing (CBB). CBB injected and withdrew BGP routes in the global BGP routing system which imparted unacceptable churn. AERO does not inject any mobile network prefixes into the global BGP routing system. The vepc people cited CBB, but they should also take a look at AERO as a viable BGP-based mobility solution. Thanks - Fred fred.l.temp...@boeing.com > Alex > > > > > > Comments? > > > > Thanks - Fred fred.l.temp...@boeing.com > > > > _______________________________________________ dmm mailing list > > dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm > > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
