Subject: [DMM] Scaling properties of AERO

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Jun 2015 21:29:24 +0000

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, this means that at most
   O(10^6) Clients can be serviced by Relays within a single BGP
   instance.  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/

Comments?

Thanks - Fred
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 09 Jun 2015 17:14:24 +0200

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:
>
> 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.

Do you want the AERO system to scale as much as the entire existing
Internet?  Or be part of it?

> 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?

> 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.
>
> configures ASP-specific routes that list the correct set of Relays
> as next hops."
>

I still have to understand this draft.

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.
The positive influence of the default routes on the reduction of route
update messages.
The influence of aggregating prefixes in the reduction of routes in the
routing tables (centralized and well-planned addressing architecture).

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.

Alex

>
> Comments?
>
> Thanks - Fred [email-masked]
>
> _______________________________________________ dmm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 9 Jun 2015 16:45:11 +0000

Hi Alex,

> -----Original Message-----
> From: dmm [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Tuesday, June 09, 2015 8:14 AM
> To: [email-masked]
> Subject: Re: [DMM] Scaling properties of AERO
> 
> 
> 

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?

> 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. 

> 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.

> 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.

> 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

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.

> 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.

> 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

> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm