> > > do we have any idea whether 5000 PIDs is a realistic assumption for > > > foreseeable deployments? > > > > Indeed, 5000 seems like an extreme case. Yet, I think one could > really > > end up there, depending on how ALTO is used. > > > > For instance, let's assume an ALTO use case like > > draft-scharf-alto-vpn-service for a large enterprise with many > > branches. As argued in the draft, only could possibly use one PID for > > each VPN endpoint. > > > > In that case, 5000 is not entirely unrealistic. As a random data > > point, Bank of America is reported to have 5,377 branches in the US. > > Other large organizations (e.g., retailers) may have a similar order > > of magnitude of branches. A L2VPN or L3VPN could be used to > > interconnect such branches. > > > > Obviously, there are certain ways to reduce the network/cost size in > > such a scenario, e.g., by introducing a hierarchy, or by topology > > encoding (for cost map). Also, I doubt that an application would > > really require an accurate cost map entry for any given combination > of > > PIDs. Thus, 5000 looks like a kind of worst-case scenario. > > In this use case, would you really have a full(!) 5000x5000 matrix? > Or would it be more like a sparse matrix, defining cost only for > 5000 branch offices X 100 data centers, > while most (all?) other costs (i.e., branch office to branch office) > are > "default"?
Sure, the non-default-entries in such a matrix could be sparse (and topology encoding could help). And, indeed, as already mentioned, I'd guess that one would mainly be interested in a small subset of the cost map. As a result, 5000x100 may be more realistic than 5000x5000. But we still have O(5000) PIDs. Michael _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
