asdfdsaf

pages/1/3(ecmp-symmetric)/1_3_2_1.md

@@ -8,7 +8,7 @@ permalink: 1_3_2_1.html
 summary: "Not *here*, but not *there* either"
 ---
 
-This framework relies heavily on the concept of a transit-zone. That is, a (network security) zone which is tasked with providing transport for traffic *between* other zones.  . The "edge"/"perimeter" of *this* zone is its connection to the firewalls on the perimeter of all the other zones.
+This framework relies heavily on the concept of a transit-zone. That is, a (network security) zone which is tasked with providing transport for traffic *between* other zones. The "edge"/"perimeter" of *this* zone is its connection to the firewalls on the perimeter of all the other zones.
 
 ### The *implicit* transit zone
 

pages/1/3(ecmp-symmetric)/1_3_2_2.md

@@ -3,12 +3,12 @@ l1idx: 1
 l2idx: 3
 l3idx: 2
 l4idx: 2
-title: "Representing the network as a graph"
+title: "Modeling the network as a graph"
 permalink: 1_3_2_2.html
-summary: "Graphs are 'everywhere', let's see what the network we're describing looks like as a graph"
+summary: "In which we make things look different"
 ---
 
-In order to generalize the issue(s?) at play here, we further formalize our model in a graph-theory framework. We will start by mapping the elements of our architecture to a formalized undirectedgraph". 
+In order to generalize the issue(s?) at play here, we formalize our model in a graph-theory oriented framework.
 
 # The reference topology
 
@@ -27,22 +27,20 @@ These two figures illustrate visually that "site" and "security zone" function s
  - Nodes in zone-0 form a tree with the zone-0/site-0 node at its root
  - There are *no* connections between two nodes in site-0
 
-Up to this point we have left "site" and "zone" very loosely defined. Before we proceed with mapping the topology above to a graph, we will define those two terms.
+Up to this point we have left "site" and "zone" very loosely defined. We will formalize them in subsequent sections, but for now, we will integrate them to the graph as properties of the edges and nodes.
 
-## Network Security Zones
 
-We define "network security zone" as a group of nodes on the network that are able to communicate without traversing a firewall. As discussed in the preamble, this "matters" because firewalls enforce statefulness in the traffic that they forward. For two nodes to successfully communicate with each other, messages/traffic in *both* directions (A to B, and B to A) must traverse the *same* firewalls. If a firewall only sees half of the traffic, it will detect that statefulness has not been propertly maintained and discard the traffic.
+# Modeling the network topology as a graph
 
-## Sites
 
-We define "site" as a group of nodes on the network are are within the same metropolitan area as each other. As discussed in the preamble, this is a relatively arbitrary distinction, and one that largely boils down to nodes that are "close enough" that we prefer traffic between nodes stay within that "site."
+## Where are all the endpoints/workloads/hosts?
 
+At this point, we'll finally acknowledge a non-trivial simplification that has been implicit in all of the topologies discussed up to now. We have not included any "workload" (aka "non-forwarding"; aka "end-point", aka "host' etc.. ) nodes in our topologies. The motivation for this omission is a straight-forward desire to reduce visual clutter in the diagrams. In the "actual" networks that these topologies represent, those nodes on the network/graph are "on" subnets that are originated into BGP by the nodes that *are* represented on the topology-diagram and graph. When we begin discussing BGP advertisements and propagation, we will use a unique label for each node as a stand-in for all networks that the BGP router that it represents would originate in an "actual" network.
 
-# Modeling the network topology as a graph
 
 ## Elements
 
-The BGP-speakers on our network are represented as "nodes" on an un-directed graph, and the links between them (transport+eBGP-session) are "edges" on the same graph. (The graph is "undirected" in that there is no "directionality" to the edges.)
+The BGP-speakers on our network are represented as "nodes" on a directed graph (dig), and the links between them (transport+eBGP-session) are "edges" on the same graph.
 
 ## Properties
 

pages/1/3(ecmp-symmetric)/1_3_2_2_2.md → pages/1/3(ecmp-symmetric)/1_3_2_3_1.md

@@ -2,10 +2,10 @@
 l1idx: 1
 l2idx: 3
 l3idx: 2
-l4idx: 2
-l5idx: 2
+l4idx: 3
+l5idx: 1
 title: "Applying a recursive structure to the 'zone' property"
-permalink: 1_3_2_2_2.html
+permalink: 1_3_2_3_1.html
 summary: "Why would we do that? HOW would we do that? ... WOULD we do that?"
 ---
 

pages/1/3(ecmp-symmetric)/1_3_2_4.md

@@ -0,0 +1,15 @@
+---
+l1idx: 1
+l2idx: 3
+l3idx: 2
+l4idx: 4
+title: "Sites"
+permalink: 1_3_2_4.html
+summary: "In which we *almost* lose track of what we're talking about (again)"
+---
+
+## Sites
+
+We define "site" as a group of nodes on the network are are within the same metropolitan area as each other. As discussed in the preamble, this is a relatively arbitrary distinction, and one that largely boils down to nodes that are "close enough" that we prefer traffic between nodes stay within that "site."
+
+

pages/1/3(ecmp-symmetric)/1_3_2_2_1.md → pages/1/3(ecmp-symmetric)/1_3_2_4_1.md

@@ -2,10 +2,10 @@
 l1idx: 1
 l2idx: 3
 l3idx: 2
-l4idx: 2
+l4idx: 4
 l5idx: 1
 title: "Applying a recursive structure to the 'site' property"
-permalink: 1_3_2_2.1.html
+permalink: 1_3_2_4.1.html
 summary: "Why would we do that? HOW would we do that? ... WOULD we do that?"
 ---
 

pages/1/3(ecmp-symmetric)/1_3_2_5.md

@@ -0,0 +1,95 @@
+---
+l1idx: 1
+l2idx: 3
+l3idx: 2
+l4idx: 3
+title: "Back to 'the problem'"
+permalink: 1_3_2_3.html
+summary: "In which we describe the three 'equal-cost' paths between nodes with differing zone and site values"
+---
+
+## Where are all the endpoints/workloads/hosts?
+
+At this point, we'll finally acknowledge a non-trivial simplification that has been implicit in all of the topologies discussed up to now. We have not included any "workload" (aka "non-forwarding"; aka "end-point", aka "host' etc.. ) nodes in our topologies. The motivation for this omission is a straight-forward desire to reduce visual clutter in the diagrams. In the "actual" networks that these topologies represent, those nodes on the network/graph are "on" subnets that are originated into BGP by the nodes that *are* represented on the topology-diagram and graph. When we begin discussing BGP advertisements and propagation, we will use a unique label for each node as a stand-in for all networks that the BGP router that it represents would originate in an "actual" network.
+
+## The original problem, illustrated (again)
+
+The following figure illustrates the challenge described in the preamble section of this article, on the formalized graph described in the immediately preceding pages. As previously discussed, in this model, each node on the graph is a BGP router, and each edge represents an eBGP peering between two nodes.
+
+[![image](./grphth-18.svg){:class="img-fluid"}](./grphth-18.svg){:target="_blank"}
+
+The new additions to this figure are the path-tracings between nodes labeled "S0.1 Z0.1" and "S0.0 Z0.3". 
+
+"S*n*.*m*" signifies an index value in the "site" hierarchy ("S"). "*n*" indicates the number of parent/child relationships between the node and the root of the "site" hierarchy (which is equivalent to number of edges between it and the root of the site-tree.)
+
+"Z*n*.*m*" signifies and index value in the "zone" hierarchy ("S"). "*n*" indicates the number of parent/child relationships between the node and the root of the "zone" hierarchy (which is equivalent to number of edges between it and the root of the zone-tree.)
+
+## Paths on the graph; paths on a network
+
+In the preceding figure, three paths have been high-lighted between nodes "S0.1-Z0.1" and "S0.3-Z0.3". These are the three "shortest" paths between those two nodes, and they are all *equally* short. On our graph, we count the number of edges (6) in the path to determine the "length" of that path. This represents the AS-path length of the corresponding path in the "real" networks that we are modeling.
+
+As with the scenario in the preamble of this paper, the challenge we have set ourselves is to develop a path *selection* algorithm from which:
+
+>The source/destination-inverted flows of a flow-pair between two nodes with differing zone and site values will traverse the *same* set of *stateful* nodes as each other.
+
+An important refinement of this problem statement is to qualify it with the following:
+
+>The path selection algorithm must:
+> * Execute on each node, selecting the the next edge in the path
+>  * Using only the following inputs:
+>  * Topology data it has received through BGP advertisements
+>  * Static local configuration/variables
+>  * The destination/end-point node's "network name"
+>  * The source/start-point node's "network-name" may **not** be used 
+
+In other words, it has to "act like a routing protocol" (and no source-based routing is allowed.)
+
+### But, what *kind* of routing protocol?
+
+The scenario discussed in the preamble involved an enterprise network using eBGP, and that is the the scenario that our path-selection algorithm will build on, and that we describe here in terms of assumptions about the behavior of nodes on our graph:
+
+* Each node has a unique identifier (we'll call it a "network name" for now)
+* Each node sends/receives messages from the nodes that it shares edges with.
+ * The messages are functionally analagous to BGP UPDATE messages
+ * The "network name" parameter acts as both ASN, router-ID, and network.
+ * Node "1" sends an update of "1" to node 2
+ * Node "2" receives the update, and adds an entry to its forwarding table (
+ * Reach "1" via the edge I just received the update on (the edge between "1" and "2" on the graph)
+ * Node "2" prepends that same update with its own "network name" and a space ("2 1") and sends it to nodes 5,6,7
+ * The behavior of the nodes is equivalent to that of an eBGP peer
+
+The graph in the following figure modifies the previous figure by removing the previous explicit textual annotations for site, and zone properties and adding a "network name" value to each node. The previously discussed properties of the nodes and edges are depicted visually (refer to the key to the left of the graph in the figure.)
+
+[![image](./grphth-19.svg){:class="img-fluid"}](./grphth-19.svg){:target="_blank"}
+
+We've changed the labels on our graph, but the previously identified 3 "equidistant" paths between two nodes in different "sites" and "zones" still applies. Those paths are between nodes now labeled as "14" and "22".
+
+## Comparing the paths
+
+The three equi-distant paths between nodes 14 and 22 are compared below.
+
+### Path "a"
+
+* Traverses two stateful nodes
+ * 11 (zone 0.1), and 13 (zone 0.3)
+ * Both in the same "site" as 22 (but not the same site as 14)
+
+### Path "b"
+
+* Traverses two stateful nodes
+ * 5 (zone 0.1), and 7 (zone 0.3)
+ * Both in the same "site" as 14 (but not the same site as 22)
+
+### Path "c"
+
+* Traverses two stateful nodes
+ * 5 (zone 0.1), and 13 (zone 0.3)
+ * 5 is in the same site as 14 (but not the same site as 22)
+ * 13 is in the same site as 22 (but not the same site as 14)
+
+## Restating the problem (again)
+
+We need a forwarding-decision process that can execute on each node of the graph and which results in the src/dst-inverted flow-pairs for any two hosts traversing the *same* set of stateful nodes.
+
+In this particular instance of that problem, that boils down to we need to choose path "A", "B", or "C" (consistently) for both the 14 -> 22 path and the 22 -> 14 path.
+

pages/1/3(ecmp-symmetric)/1_3_3.md

@@ -74,4 +74,6 @@ Let's walk through how this would work.
  * And so on, through node 23 to node 14.
 
 
-In this specific topology, our new path-selection rule will work
+In *this* specific graph/topology, our new path-selection rule will work as intended. This graph represents our reference network topology in steady-state, but what happens in various failure modes (if we remove one or more edges or nodes from the graph; modeling link/device failure on a network?)
+
+As we will see in the following page, the viability of this path selection mechanism for inter-site/inter-zone will require some additional logic/guard-rails