Exposition

The leaders of a certain forward-looking enterprise’s IT organization have a vision. They think in terms of “cattle, not pets”, and “scalability, not failability” (aka “resiliency, not redundancy.”) They want to build out infrastrucutre that embodies these principles, so as to enable upper-layer services to do the same. The guiding-principle is trivially expressed as:

When feasible, avoid using a single instance of anytyhing. Instead, use multiple instances of that element running in parallel and providing resiliency for each other. Design systems that are innately resilient.

They envision multiple sites in multiple regions running instances of the various applications that enable their core business functions, and they know that their info-sec/net-sec architecture requires their network to be segregated into discrete “network security zone.” They also (somehow?) read the abstract of this paper and recognize the difficulties that they will be confronted with.

They establish the following design objectives for the enterprise network:

  • The network should provide an optimal path between any two endpoints
    • Traffic between endpoints in the same (network security) zone should not traverse any network firewalls
    • Traffic between endpoints in separate security zones should traverse only one firewall at the edge of each (source and desination) security zone
    • Traffic between endpoints in the same site should not exit that site in transit
  • The network should provide a “high” level of resiliency

The enterprise works through multiple design iterations, getting incrementally closer to optimal pathing. Each However, the fundamental from the abstract remains: `Existing mechanisms for path selection across ECMP links result in asymmetric forward/reverse paths.

The subsequent pages in this section illustrate and explicate various design iterations the led to the novel framework presented in the following section.

Illustration

The following diagram sumarizes this conondrum

image