diff --git a/pages/1/3(ecmp-symmetric)/.$grphth-16.svg.bkp b/pages/1/3(ecmp-symmetric)/.$grphth-16.svg.bkp
new file mode 100644
index 0000000..d694d88
--- /dev/null
+++ b/pages/1/3(ecmp-symmetric)/.$grphth-16.svg.bkp
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/pages/1/3(ecmp-symmetric)/1_3_2_4.md b/pages/1/3(ecmp-symmetric)/1_3_2_4.md
index 5f5ab95..2e9479f 100644
--- a/pages/1/3(ecmp-symmetric)/1_3_2_4.md
+++ b/pages/1/3(ecmp-symmetric)/1_3_2_4.md
@@ -12,25 +12,29 @@ summary: "Why would we do that? HOW would we do that? ... WOULD we do that?"
Applying the concept of recursion to zones follows the same pattern as applying it to recursion, once we get past the initial hurdle of more fully conceptualizing what the "transit zone" *is*, relative to the other zones.
-## Hierarchical relationship of zone "0" to other zones
+## Hierarchical relationship of transit zone (zone "0") to other zones
In the *simplest* conceptual model for network-security zones, there are only two classifications: "trusted", and "un-trusted", and it is presumed that *you* own/control/operate the "trusted" zone, and some *other* group operates the un-trusted zone. If two networks with separate owners/operators want to connect, but regard each other as "un-trusted", you get the timeless "back-to-back-firewalls" topology. From *your* perspective, your firewall and everything on *your* side of it are "trusted" and everything on the other side is "untrusted." From the *other* network's perspective, the situation is reversed. They regard *their* firewall and everything on *their* side of as "trusted", and everything on the *other* side as "untrusted."
-But.. what about the portion of the network *between* the two firewalls? *Nobody* in this scenario regards that segment as trusted, hence the "no-man's land" moniker. In that scenario, if you (and the other network's owner) wanted to *also* connect to multiple *additional* (separately administered; mutually un-trusted) networks, it would be more efficient for you to all *share* that no-man's-land region for mutual interconnection. That raises vexing questions about who would be responsible for operating the no-man's land. We'll get to them next...
+What about the network *between* the two firewalls? *Nobody* in this scenario regards that segment as trusted, hence the "no-man's land" moniker. In that scenario, if you (and the other network's owner) wanted to *also* connect to multiple *additional* (separately administered; mutually un-trusted) networks, it would be more efficient for you to all *share* that no-man's-land region for mutual interconnection. The "transit" zone we've been discussing *is* that multi-party no-man's-land.
-The "transit" zone we've been discussing *is* the multi-party no-man's-land described above. Earlier, when I said that *nobody* regarded the no-mans's land as "trusted", I left out the owner/operator *of* the no-man's-land. *They* would regard it as "trusted".
+The no-man's land framework does raise a new question though: who is responsible for maintaining the no-man's land? When I said that *nobody* regarded the no-mans's land as "trusted", I left out the owner/operator *of* the no-man's-land. *They* might regard it as "trusted", because it is under their control. They might *also* regard it as "un-trusted" because they can't control what gets into (or out of) it through all those other organizations' firewalls. (The whole binary "trusted/untrusted" model doesn't deal well with shades-of-grey.)
+Instead of a binary model though, we might use a *range* of values to denote the *level* of trust we assign to a specific zone, or we might throw "trust" out the window and decide that "risk profile" is a better way of grouping nodes into security zones. Likewise, *we* may be the owner/operator of *all* of these security zones -- including the no-man's-land/transit-zone. This is pretty close to the scenario depicted in the "preamble" of this paper, and our jumping-off point for talking about recursive security-zones.
+In terms of how the network/graph operates, it doesn't really matter whether we consider a "zone" be defined by a shared level of trust, or a shared risk-profile, or the last character of its MAC-address. The functional distinction we have is:
+* Edges may connect *any* two nodes in the *same* zone
+* Edges may connect *transit-zone* nodes *stateful* nodes *in "other" zones"*
-## Creating recursive "site" structures in the graph
- between nodes in non-neighboring levels of the site hierarchy.)
+This gives a functional tree, with the transit zone as the root. Every other zone *must* have an edge the connects to the transit zone. (This is a hierarchical relationship)
+So, how *does* this pattern recurse? With zone-0 as the root of our zone-tree, our reference topology has three additional zones (all children of zone-0): zone-0.1, zone-0.2, and zone-0.3. Applied recursively, each of *those* zones may act as a transit-zone/parent for any sub-zones they contain. The most significant design-decision here is whether the connection from a parent-zone to the child-zone need to terminate on a stateful node on either end.
-### Better Illustrating the Recursion
+The initial pattern we are recursing calls for edges between the parent (0/transit) zone its it child-zones (0.1, 0.2, 0.3) to land on *stateful* nodes in the child-zone, and *stateless* nodes in the parent-zone, we will carry that pattern forward here.
-The following figure presents an alternate arrangement of the same graph, which more intuitively illustrates the recursive nature of its structure.
-[{:class="img-fluid"}](./grphth-15.svg){:target="_blank"}
+## Depicting recursive "zone" structures in the graph
+The following figure depicts the reference topology, modified to add two single-level-recursed sub-zones to zone 0.1, and two single-level-recursed subzones to zone 0.3. The latter two each have their own two (2nd-level-recursed) sub-zones.
-Security zones might also be nested nested using a similar mechanism, although in this case the distinction between child/parent object has a deeper policy significance in the real-world networks that we are modelling. If we entertain the concept of recursively structured network security zones, it becomes quickly apparent that there is a parent-child relationship between "transit zone" and "workload-hosting zone", and that the a workload-hosting-zone with "child" sub-zones *is* the transit-zone for it child/sub-zones. As illustrated in the following figures:
+[{:class="img-fluid"}](./grphth-16.svg){:target="_blank"}
diff --git a/pages/1/3(ecmp-symmetric)/grphth-16.svg b/pages/1/3(ecmp-symmetric)/grphth-16.svg
new file mode 100644
index 0000000..dbdbad8
--- /dev/null
+++ b/pages/1/3(ecmp-symmetric)/grphth-16.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/pages/1/3(ecmp-symmetric)/grphth-2.svg b/pages/1/3(ecmp-symmetric)/grphth-2.svg
index cac8961..09883a6 100644
--- a/pages/1/3(ecmp-symmetric)/grphth-2.svg
+++ b/pages/1/3(ecmp-symmetric)/grphth-2.svg
@@ -1,4 +1,4 @@
-
\ No newline at end of file
+
\ No newline at end of file