1. Portland: A Scalable Fault-Tolerant Layer 2 Data Center Network Fabric Offense Kai Chen Shih-Chi Chen

2. Focus is narrow! Portland addressing, routing and forwarding techniques are ONLY working on 3-stage Fattree topology –Do you think all future data centers should have such Fattree topology? –Even we have Fattree topology, do you think we must use 3-stage, not 2, 4, 5 …-stage?

3. Statement is over-claimed In page 3, you claim “the techniques described in this paper generalize to existing data center topologies.” –For example, can you show us how your Distributed Location Discovery work on a 4- stage Fattree, a multi-root multi-level tree, and a hypercube network?

4. Assumption is questionable Your assumption “building and maintaining data centers with tens of thousands of compute elements requires modularity, advance planning, and minimal human interaction. Thus, the baseline data center topology is unlikely to evolve quickly” –Not exactly true. –E.g., Microsoft is doubling the # of servers every 14 months, exceeding Moore's Law.

5. Problems with Central Manager The paper does not explicitly show where to put the fabric manager in its topology? –The location relate to the performance of the networks? –How each edge switches reach the data center manager to query the PMAC of a server? –Will this be a problem when the network is congested? –What will happen when a manager fails?

6. ARP design has a big security problem In your design, “when the fabric manager does not know the PMAC of a server, it will broadcast to the whole network for the PMAC!” –Can you tell me what the consequence if a compromised sever intentionally send many requests to query the PMACs for arbitrary IP addresses?

7. Routing is not efficient Portland’s routing is in impasse –Fattree topology has the potential to deliver full bisection bandwidth among all communicating hosts, but the Portland routing, forwarding, or scheduling is unable to appropriately take advantage of this high degree of parallelism. –E.g., you use ECMP-based hashing, so you cannot avoid the congestion on particular paths while have the other paths quite free!

8. Influence on performance / cost How costly it can be to look up for PMAC? How costly it can be to set up the proxy machines which cache the mapping?

9. Robustness This might facilitate VM migration. But what will happen after a major failure happens? For example, how to recover from a electricity out / shock if the caching machines are all gone?

10. Lack of comparisons No quantitative comparisons with other architectures. Although PortLand looks good, perhaps other architectures perform better?

11. Why not going hybrid? How about using mapping only on migrated VM until the VM finish handling its current connections?