src/vnet/srmpls/sr_doc.rst

   1 .. _srmpls_doc:
   2
   3 SR-MPLS: Segment Routing for MPLS
   4 =================================
   5
   6 This is a memo intended to contain documentation of the VPP SR-MPLS
   7 implementation. Everything that is not directly obvious should come
   8 here. For any feedback on content that should be explained please
   9 mailto:pcamaril@cisco.com
  10
  11 Segment Routing
  12 ---------------
  13
  14 Segment routing is a network technology focused on addressing the
  15 limitations of existing IP and Multiprotocol Label Switching (MPLS)
  16 networks in terms of simplicity, scale, and ease of operation. It is a
  17 foundation for application engineered routing as it prepares the
  18 networks for new business models where applications can control the
  19 network behavior.
  20
  21 Segment routing seeks the right balance between distributed intelligence
  22 and centralized optimization and programming. It was built for the
  23 software-defined networking (SDN) era.
  24
  25 Segment routing enhances packet forwarding behavior by enabling a
  26 network to transport unicast packets through a specific forwarding path,
  27 different from the normal path that a packet usually takes (IGP shortest
  28 path or BGP best path). This capability benefits many use cases, and one
  29 can build those specific paths based on application requirements.
  30
  31 Segment routing uses the source routing paradigm. A node, usually a
  32 router but also a switch, a trusted server, or a virtual forwarder
  33 running on a hypervisor, steers a packet through an ordered list of
  34 instructions, called segments. A segment can represent any instruction,
  35 topological or service-based. A segment can have a local semantic to a
  36 segment-routing node or global within a segment-routing network. Segment
  37 routing allows an operator to enforce a flow through any topological
  38 path and service chain while maintaining per-flow state only at the
  39 ingress node to the segment-routing network. Segment routing also
  40 supports equal-cost multipath (ECMP) by design.
  41
  42 Segment routing can operate with either an MPLS or an IPv6 data plane.
  43 All the currently available MPLS services, such as Layer 3 VPN (L3VPN),
  44 L2VPN (Virtual Private Wire Service [VPWS], Virtual Private LAN Services
  45 [VPLS], Ethernet VPN [E-VPN], and Provider Backbone Bridging Ethernet
  46 VPN [PBB-EVPN]), can run on top of a segment-routing transport network.
  47
  48 **The implementation of Segment Routing in VPP covers both the IPv6 data
  49 plane (SRv6) as well as the MPLS data plane (SR-MPLS). This page
  50 contains the SR-MPLS documentation.**
  51
  52 Segment Routing terminology
  53 ---------------------------
  54
  55 -  SegmentID (SID): is an MPLS label.
  56 -  Segment List (SL) (SID List): is the sequence of SIDs that the packet
  57    will traverse.
  58 -  SR Policy: is a set of candidate paths (SID list+weight). An SR
  59    policy is uniquely identified by its Binding SID and associated with
  60    a weighted set of Segment Lists. In case several SID lists are
  61    defined, traffic steered into the policy is unevenly load-balanced
  62    among them according to their respective weights.
  63 -  BindingSID: a BindingSID is a SID (only one) associated one-one with
  64    an SR Policy. If a packet arrives with MPLS label corresponding to a
  65    BindingSID, then the SR policy will be applied to such packet.
  66    (BindingSID is popped first.)
  67
  68 SR-MPLS features in VPP
  69 -----------------------
  70
  71 The SR-MPLS implementation is focused on the SR policies, as well on its
  72 steering. Others SR-MPLS features, such as for example AdjSIDs, can be
  73 achieved using the regular VPP MPLS implementation.
  74
  75 The Segment Routing Policy
  76 (*draft-filsfils-spring-segment-routing-policy*) defines SR Policies.
  77
  78 Creating a SR Policy
  79 --------------------
  80
  81 An SR Policy is defined by a Binding SID and a weighted set of Segment
  82 Lists.
  83
  84 A new SR policy is created with a first SID list using:
  85
  86 ::
  87
  88    sr mpls policy add bsid 40001 next 16001 next 16002 next 16003 (weight 5)
  89
  90 -  The weight parameter is only used if more than one SID list is
  91    associated with the policy.
  92
  93 An SR policy is deleted with:
  94
  95 ::
  96
  97    sr mpls policy del bsid 40001
  98
  99 The existing SR policies are listed with:
 100
 101 ::
 102
 103    show sr mpls policies
 104
 105 Adding/Removing SID Lists from an SR policy
 106 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 107
 108 An additional SID list is associated with an existing SR policy with:
 109
 110 ::
 111
 112    sr mpls policy mod bsid 40001 add sl next 16001 next 16002 next 16003 (weight 3)
 113
 114 Conversely, a SID list can be removed from an SR policy with:
 115
 116 ::
 117
 118    sr mpls policy mod bsid 4001 del sl index 1
 119
 120 Note that this CLI cannot be used to remove the last SID list of a
 121 policy. Instead the SR policy delete CLI must be used.
 122
 123 The weight of a SID list can also be modified with:
 124
 125 ::
 126
 127    sr mpls policy mod bsid 40001 mod sl index 1 weight 4
 128
 129 SR Policies: Spray policies
 130 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 131
 132 Spray policies are a specific type of SR policies where the packet is
 133 replicated on all the SID lists, rather than load-balanced among them.
 134
 135 SID list weights are ignored with this type of policies.
 136
 137 A Spray policy is instantiated by appending the keyword **spray** to a
 138 regular SR-MPLS policy command, as in:
 139
 140 ::
 141
 142    sr mpls policy add bsid 40002 next 16001 next 16002 next 16003 spray
 143
 144 Spray policies are used for removing multicast state from a network core
 145 domain, and instead send a linear unicast copy to every access node. The
 146 last SID in each list accesses the multicast tree within the access
 147 node.
 148
 149 Steering packets into a SR Policy
 150 ---------------------------------
 151
 152 Segment Routing supports three methods of steering traffic into an SR
 153 policy.
 154
 155 Local steering
 156 ~~~~~~~~~~~~~~
 157
 158 In this variant incoming packets match a routing policy which directs
 159 them on a local SR policy.
 160
 161 In order to achieve this behavior the user needs to create an ‘sr
 162 steering policy via sr policy bsid’.
 163
 164 ::
 165
 166    sr mpls steer l3 2001::/64 via sr policy bsid 40001
 167    sr mpls steer l3 2001::/64 via sr policy bsid 40001 fib-table 3
 168    sr mpls steer l3 10.0.0.0/16 via sr policy bsid 40001
 169    sr mpls steer l3 10.0.0.0/16 via sr policy bsid 40001 vpn-label 500
 170
 171 Remote steering
 172 ~~~~~~~~~~~~~~~
 173
 174 In this variant incoming packets have an active SID matching a local
 175 BSID at the head-end.
 176
 177 In order to achieve this behavior the packets should simply arrive with
 178 an active SID equal to the Binding SID of a locally instantiated SR
 179 policy.
 180
 181 Automated steering
 182 ~~~~~~~~~~~~~~~~~~
 183
 184 In this variant incoming packets match a BGP/Service route which
 185 recurses on the BSID of a local policy.
 186
 187 In order to achieve this behavior the user first needs to color the SR
 188 policies. He can do so by using the CLI:
 189
 190 ::
 191
 192    sr mpls policy te bsid xxxxx endpoint x.x.x.x color 12341234
 193
 194 Notice that an SR policy can have a single endpoint and a single color.
 195 Notice that the *endpoint* value is an IP46 address and the color a u32.
 196
 197 Then, for any BGP/Service route the user has to use the API to steer
 198 prefixes:
 199
 200 ::
 201
 202    sr steer l3 2001::/64 via next-hop 2001::1 color 1234 co 2
 203    sr steer l3 2001::/64 via next-hop 2001::1 color 1234 co 2 vpn-label 500
 204
 205 Notice that *co* refers to the CO-bits (values [0|1|2|3]).
 206
 207 Notice also that a given prefix might be steered over several colors
 208 (same next-hop and same co-bit value). In order to add new colors just
 209 execute the API several times (or with the del parameter to delete the
 210 color).
 211
 212 This variant is meant to be used in conjunction with a control plane
 213 agent that uses the underlying binary API bindings of
 214 *sr_mpls_steering_policy_add*/*sr_mpls_steering_policy_del* for any BGP
 215 service route received.