routing TODOs

Signed-off-by: Larry Peterson <llp@cs.princeton.edu>

Author: llpeterson

policy/routingbgp.rst

@@ -1,6 +1,9 @@
 .. index:: IGP: Interior Gateway Protocol
 .. index:: EGP: Exterior Gateway Protocol
 
+.. TODO -- We need to include a sidebar on using BGP for
+   datacenter fabrics to satisfy a forward reference from Ch 4.
+
 |BGP|.2 Sharing Routes and Routing Policy
 ------------------------------------------
 

routing/design.rst

@@ -12,18 +12,20 @@ forwarding tables are built. Routing often depends on a complex
 distributed algorithm, and is considered part of the network's
 *control plane*.
 
-.. TODO -- Consider whether any of this discussion needs to be
-   tweaked in light of the Switch vs Router blog post. (Probably not.)
-
 Recall also that there isn't a lot of difference between switches and
-routers (no matter how much the vendors of these devices might argue
-otherwise). They have a data plane and a control plane, and the
-control plane is in charge of putting entries in the forwarding table
-so it can be used by the data plane. Historically, switches had a
-simpler control plane (based on the spanning tree protocol) and they
-only forwarded based on the Ethernet header, but today
-there are Ethernet switches that combine traditional switching functions with
-those of a router, so it's harder to make a strong distinction.
+routers. They both have a data plane and a control plane, with the
+control plane in charge of putting entries in the forwarding table so
+the data plane can do its job forwarding packets. Historically,
+switches and routers were completely distinct: switches forwarded
+Ethernet packets based on the destination Ethernet address, routers
+forwarded IP packets based on the destination IP address, and each ran
+the corresponding control plane algorithm. Today, however, there are
+Ethernet switches that combine traditional switching functions with
+those of a router, so it's harder to make a strong distinction; it's a
+matter of exactly what combination of features the network operator
+enables.  For the purposes of this chapter, we consider the range of
+control plane algorithms used by both switches (spanning tree) and
+routers (link-state and distance-vector).
 
 One question we need to ask anytime we try to build a mechanism for
 the Internet is how well it scales. The answer for the algorithms and

routing/fabric.rst

@@ -43,7 +43,11 @@ standard interface between the data and control planes, but it also
 advanced the idea of using a centralized control plane to push
 forwarding rules to many devices implementing the data plane. A
 conceptual picture of an SDN system is shown in :numref:`Figure %s
-<fig-sdn>`.
+<fig-sdn>`. Note that while the main component depicted in the figure
+is often called a *Network Operating System (NOS)* since it serves as
+a platform for a set of applications, it is more accurate to view it
+as a collection of shared libraries. (It is typically not a true
+multi-tenant OS.)
 
 .. _fig-sdn:
 .. figure:: routing/figures/sdn.png
@@ -54,10 +58,6 @@ conceptual picture of an SDN system is shown in :numref:`Figure %s
     applications and providing a logically centralized point of
     control for an underlying network data plane.
 
-.. TODO -- We may want to drop the NOS angle, and just focus
-   on a single "Control Program". Or at least equate NOS with
-   "library"  and note that it's not multi-tenant.
-
 Centralized control opens up the possibility of rethinking how routing
 works in a network.  Rather than a fully distributed algorithm of the
 sort described in the preceding sections, we now have the option of
@@ -84,7 +84,8 @@ traffic.  This problem of mapping a traffic matrix onto a set of links
 is hard to solve efficiently in a fully distributed manner;
 centralizing it makes the problem much easier. Thus, one of the early
 successes of SDN was to solve these *traffic engineering* problems in
-the large backbones interconnecting hyperscale datacenters.
+the large backbones interconnecting hyperscale datacenters. We
+cover this idea more thoroughly in Section |Capacity|.5.
 
 In this section we look at a related example—how to route *within* a
 single datacenter—and the specific method we describe is called *segment
@@ -161,10 +162,6 @@ ports in each group without additional control plane involvement.
 |Routing|.5.3 Segment Routing
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. TODO -- We need to mention other possibilities, including BGP.
-   This would require a forward reference to the interdomain
-   routing chapter. (A sidebar in that chapter might make sense.)
-
 Independent of link aggregation, we still need to discover routes
 between all the servers. One approach is a routing algorithm called
 *Segment Routing (SR)*. The term comes from the idea that the
@@ -239,7 +236,11 @@ implement its forwarding decision.
 
 For a useful overview of one hyperscale data center design that
 leverages SDN, we recommend the paper on Google's Jupiter
-architecture.
+architecture. One thing to note about Jupiter is that it does not use
+Segment Routing, but instead adapts BGP to the problem. It does this
+not because a datacenter fabric spans multiple autonomous systems, but
+because BGP's ability to aggregate routes maps nicely onto the
+hierarchical fabric topology. We'll revisit this idea in Chapter |BGP|.
 
 .. admonition:: Further Reading
 
@@ -248,7 +249,3 @@ architecture.
    Software-Defined Networking
    <https://doi.org/10.1145/3544216.3544265>`__. ACM SIGCOMM '22 Symposium,
    August 2022.
-
-.. TODO -- Could use Jupiter citation as an excuse to mention some
-   of the more advanced ideas in datacenter backbones; e.g., the use of
-   passive optical switches.