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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
