mpls expansion

capacity/traffic.rst

@@ -1,5 +1,4 @@
 .. index:: TE: Traffic Engineering
-.. index:: MPLS: Multiprotocol Label Switching
 
 
 |Capacity|.5  Traffic Engineering
@@ -91,14 +90,16 @@ agree on what labels to use and how to forward packets with particular
 labels? The short answer is that some control plane protocol handles
 the task. There have actually been a few different protocols used,
 included RSVP (the Resource Reservation Protocol) and extensions to
-existing routing protocols. For now it suffices to say
-that it is possible to distribute label mappings to nodes on an explicitly
-specified path (e.g., R1-R3-R6-R7) and thus set up label
-forwarding table entries all along that path.  This is very similar to
-the process of establishing a virtual circuit.
+existing routing protocols. MPLS-SR (segment routing), which we saw in
+the datacenter context in Chapter |Routing|, provides another set of
+control plane options. For our purposes here it suffices to say that
+label mappings are distributed to nodes on an explicitly specified
+path (e.g., R1-R3-R6-R7) and thus set up label forwarding table
+entries all along that path.  This is very similar to the process of
+establishing a virtual circuit.
 
 Once we have the mechanism of explicit routing, we can apply it to the
-task of traffic engineering. The most common approaches is
+task of traffic engineering. The most common approach is
 *constrained shortest path first* (CSPF), which is a link-state
 algorithm, but which also takes various *constraints* into
 account. For example, if it was required to find a path from R1 to R7

routing/fabric.rst

@@ -1,5 +1,7 @@
 .. index:: ECMP: Equal-Cost Multipath
 .. index:: SRv6: Segment Routing (IPv6)
+.. index:: MPLS: Multiprotocol Label Switching
+
 
 |Routing|.5 Routing in Datacenters
 ------------------------------------
@@ -222,13 +224,41 @@ which is similarly unaware of any end-to-end paths.
 Finally, we answer the question about how labels are added to packets.
 There are two standardized approaches. One, called SR-MPLS, takes
 advantage of labels already being an integral part of *Multi-Protocol
-Label Switching (MPLS)*. We refer you to Chapter |Capacity| for more
-information about MPLS. The second, called SRv6, is an SR-specific
+Label Switching (MPLS)*. MPLS labels can be used for all sort of
+purposes, some of which we will see in Chapter |Capacity| (traffic
+engineering) and Chapter |Virt| (virtual private networks). MPLS
+labels are 20-bit tags that have a locally defined meaning, and it is
+up to the control plane to determine what that meaning is. Labels may
+be stacked one on top of the other and the forwarding operations
+performed on a label include push (add another label), pop (remove a
+label), and swap (replace the top label).
+
+In the segment routing case, the MPLS label stack is used to represent
+one or more *Segment IDs*. In the example we just used, Leaf 1 would
+push on a single MPLS label corresponding to the segment ID, and Spine
+1 would pop off the label. The MPLS header is illustrated in
+:numref:`Figure %s <fig-mpls>` and shows the case where a single label
+has been pushed onto the IP packet. The remaining fields in the MPLS
+header are the ``EXP`` bits (typically used to represent
+class-of-service information), a *stack bit* ``S`` which is set to
+indicate the last label in a stack of labels, and a ``TTL`` field
+which works just like the equivalent field in IP for loop prevention.
+
+
+.. _fig-mpls:
+.. figure:: routing/figures/mpls.png
+    :width: 350px
+    :align: center
+
+    MPLS label stack header on an IP packet.
+
+
+The second header encoding, called SRv6, is an SR-specific
 extension to IPv6. We discuss IPv6 in Chapter |Fed|, but for the
 purposes of this discussion, SRv6 attaches a list of 128-bit *Segment
 IDs* to the end of the IPv6 header, plus a ``Segments Left`` field
 that points to (is an index for) the current active segment.
-:numref:`Figure %s <fig-srv6>` shows the general fomat of the SRv6
+:numref:`Figure %s <fig-srv6>` shows the general format of the SRv6
 extension, but our example pushes only one label onto the list (by
 Leaf 1). Once that label is popped off the list (by one of the spine
 switches), Leaf 2 is left to match the original destination address in
@@ -239,7 +269,7 @@ the IPv6 header to implement its forwarding decision.
     :width: 350px
     :align: center
 
-    SRv6 header formet, as a routing extension to IPv6.
+    SRv6 header format, as a routing extension to IPv6.
 
 For a useful overview of one hyperscale data center design that
 leverages SDN, we recommend the paper on Google's Jupiter

virtual/vpn.rst

@@ -1,4 +1,5 @@
 .. index:: VPN: Virtual Private Network
+.. index:: MPLS/BGP VPNs
 
 |Virt|.3 Virtual Private Networks (VPNs)
 -----------------------------------------------
@@ -364,26 +365,19 @@ correctly encapsulate it for its trip across the backbone.
    A customer IP packet is encapsulated with two MPLS labels to allow
    it to be forwarded correctly across the provider's backbone.
 
-.. TODO -- We refer to MPLS in multiple places. Ch4 is only in
-   passing, but Ch8 is where the index currently points and here is
-   where we come the closest to showing the MPLS header format.
-   Neither reads as definitive, leaving the reader to wonder if "MPLS
-   is magic... just add a tag". Is there something more grounded we
-   can do here or in Ch8, and then make that set the index
-   accordingly. Maybe a sidebar explaining that "just add a tag" is
-   a useful feature, so the idea has been standardized.
 
 In order to send the packet across the provider's backbone, the packet
 is encapsulated with an MPLS header as shown in :numref:`Figure %s
 <fig-mpls-hdr>`.  This header functions much like a tunnel
 encapsulation, and is removed as the packet leaves the provider
-network on its way to the destination VPN site. Usually, a pair of
-MPLS labels are used. The outer label, which we have indicated as the
+network on its way to the destination VPN site. Here we see the label
+stack feature of MPLS being used to apply two labels, inner and
+outer. The outer label, which we have indicated as the
 Provider Path Label, is associated with a path across the provider's
-network to a particular egress provider router. The second label maps
+network to a particular egress provider router. The second (inner) label maps
 to the customer route that was passed around in BGP. So the outer
 label serves to tunnel the packet across the provider backbone, and
-the ``VPN label`` allows it to be forwarded to the current customer
+the ``VPN label`` allows it to be forwarded to the correct customer
 site upon egress. Both labels are removed before the packet is passed
 off to the customer, so they only see IP packets passing between
 sites.
@@ -408,7 +402,7 @@ book on MPLS listed below.
    February 2006.
 
    B. Davie and Y. Rekhter. MPLS: Technology and Applications. Morgan
-      Kaufmann Publishers, 2000.
+   Kaufmann Publishers, 2000.
 
 
 |Virt|.3.5 Software-Defined WANs