[IPsec] scalability questions for draft-sathyanarayan-ipsecme-advpn-03

[Timo Teras <[e-mail]>]

Hi,

In addition to previous questions, I have few additional scalability
concerns regarding draft-sathyanarayan-ipsecme-advpn-03.

1. Scaling hubs, and shortcut creation times

If I have so many spokes (>1000) that single gateway node cannot handle
feasibly simultaneous connectivity all of them.

Appendix A.2. describes shows that in advpn shortcut establishment
requires spoke to first connect to the next nearer 'shortcut suggester'
with the specific SA, at least temporarily, before final shortcut.

This implies that in worst case all short suggester gateways should be
able to handle simultaneous connection to all non-suggester nodes to
handle shortcut formation.

So instead of suggesters requiring SA only for it's static set of
clients, it must be scaled to handle SAs for *all* clients in the same
domain. (As comparison, dmvpn forms shortcuts directly spoke-spoke even
if there multiple hubs involved in between.)

It does not sound feasible that to grow network, say every
additional 500-1000 spokes, I would need to replace all the *core*
locations to be faster so that they can handle the larger number of
connections.

Of course things work if it's assumed that it's not full mesh, but I'm
not happy building architectures around assumptions that cannot be
guaranteed.

Or did I somehow misunderstand these implications? Any comments?

This also means that I might need multiple SA negotiations for one
shortcut which can be very CPU intensive. Additionally it limits the
number of intermediate shortcut suggesters or the shortcut creation can
take long amount of time (both wall and CPU).

Do you have recommendations on how a complicated topology should be
configured? What is the normal / recommended maximum amount of shortcut
suggester nodes 'in a path from A to B' envisioned in this setup?

2. Scaling number of prefixes

Suppose I have medium sized spokes A and B with 10 prefixes. This means
they would need 10*10 SAs in the policy based approach. Additionally,
if these cannot be "supernetted" as less prefixes on hub, each spoke
would need another additional 10*10 SAs with the all of the hubs in
path.

To me this sounds like the CPU power need in spokes is not proportional
to the number of _connected_ devices (as in dmvpn), but instead it is
exponentially proportional to number of prefixes it communicates with
(because of previous point, it needs these prefixes negotiated with
all shortcut suggestors involved and the final spoke).

Or did I misunderstand something?

If the solution is to use routed mode:

- do you have recommendations to when use which mode?

- does it make sense to complicate things by specifying policy based
  mode at all if it does not scale?


Thanks,
 Timo