SR-TE Pt. 5 (On-Demand Nexthop)

On-Demand Nexthop (ODN) solves the scalability problem we noticed in the last article, in which an SR-TE policy is needed for every single endpoint a router may have as a BGP nexthop. ODN is essentially a candidate path with no specific endpoint. ODN only specifies the color value. If any BGP route matches the color value, the router dynamically creates an SR-TE policy with the BGP nexthop as the SR-TE policy endpoint. Once the policy is dynamically created, it is no different than a regular policy. A BSID is created and BGP traffic is Auto-Steered using the policy.

A manual or “regular” policy looks like this;

segment-routing
 traffic-eng
  policy RED
   color 20 end-point ipv4 6.6.6.6
   candidate-paths
    preference 100
     dynamic
     constraints
      affinity
       include-all name RED

This policy only matches a BGP nexthop of 6.6.6.6
This policy can have multiple candidate paths. (Each candidate path has a different preference, highest is best).

A corresponding ODN candidate path looks like this. With this ODN definition, you no longer need the policy above. The policy above would be generated dynamically upon a BGP route with color=20, nexthop=6.6.6.6

segment-routing
 traffic-eng
  on-demand color 20
   dynamic
    affinity 
     include-all name RED

This policy matches any BGP nexthop, the only matching criteria is the color
The ODN policy has no candidate paths. Essentially the ODN policy itself is a candidate-path, which is used to create the policy dynamically. If there were multiple candidate paths (such as pref 100, include RED, pref 200 include BLUE) then the ODN policy could mean different things on different routers.

Once the last BGP route that matches an ODN-generated policy is withdrawn, the policy is also torn down.

The idea is that you would have a template of ODN candidate paths that are identical on every router. For example 10=low delay, 20=use RED links, etc. Each PE would just need this minimum set of ODN templates, and now any PE can generate a policy towards any other PE, simply matching on the color value of the BGP route.

Lab

In order to use the On-Demand Nexthop feature, we need to remove the current policies on R1 and replace them with on-demand poclies. We’ll also shutdown the R2 BGP neighborship so that we can watch the ODN policy “come to life” as the routes are received from R6.

#R1
segment-routing
 traffic-eng
  no policy RED
  no policy BLUE
  no policy GREEN
  on-demand color 20
   dynamic
    pcep
    exit
    affinity include-all name RED
  on-demand color 30
   dynamic
    pcep
    exit
    affinity include-all name BLUE
!
router bgp 100
 neighbor 2.2.2.2 shutdown

Currently there are no SR-TE policies on R1, because there are no BGP routes matching color 20 or 30.

RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy         
Tue Sep  6 22:22:14.709 UTC

Bring up the BGP neighborship with the RR and check the SR-TE policies again.

#R1
router bgp 100
 neighbor 2.2.2.2
  no shut

RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy tabular 
Tue Sep  6 22:23:55.767 UTC

 Color             Endpoint  Admin   Oper              Binding
                             State  State                  SID
------ -------------------- ------ ------ --------------------
    20              6.6.6.6     up     up                24009

RP/0/RP0/CPU0:R1#show segment-routing traffic-eng policy         
Tue Sep  6 22:24:06.008 UTC

SR-TE policy database
---------------------

Color: 20, End-point: 6.6.6.6
  Name: srte_c_20_ep_6.6.6.6
  Status:
    Admin: up  Operational: up for 00:00:18 (since Sep  6 22:23:47.565)
  Candidate-paths:
    Preference: 200 (BGP ODN) (shutdown)
      Requested BSID: dynamic
      Constraints:
        Affinity:
          include-all:
          RED
        Maximum SID Depth: 10 
      Dynamic (invalid)
        Metric Type: TE,   Path Accumulated Metric: 0 
    Preference: 100 (BGP ODN) (active)
      Requested BSID: dynamic
      PCC info:
        Symbolic name: bgp_c_20_ep_6.6.6.6_discr_100
        PLSP-ID: 5
      Constraints:
        Affinity:
          include-all:
          RED
        Maximum SID Depth: 10 
      Dynamic (pce 2.2.2.2) (valid)
        Metric Type: TE,   Path Accumulated Metric: 4 
          16002 [Prefix-SID, 2.2.2.2]
          16003 [Prefix-SID, 3.3.3.3]
          16006 [Prefix-SID, 6.6.6.6]
  Attributes:
    Binding SID: 24009
    Forward Class: Not Configured
    Steering labeled-services disabled: no
    Steering BGP disabled: no
    IPv6 caps enable: yes

Only one SR-TE policy is up, which is color 20. This is because we have no BGP routes with color 30. Upon receiving the BGP route with color 20 for nexthop R6, R1 tries to dynamically calculate the path itself (preference 200 above) and this fails because it is an inter-domain path. R1 then consults the PCE (preference 100) and the PCE replies with the path seen above.

This is clearly more scalable, as now R1 can calculate a path that only includes RED links to any other router in the network (inter-domain wide). In a real world deployment, all routers would have an identical set of on-demand color policies, so that any router could signal the SLA for any given BGP route using the color extcommunity attribute.

Notice that Automated Steering works with either manually configured policies, or ODN policies. The process of automated steering does not change either way. The difference is simply whether the policy has an explicit endpoint, or has no endpoint (ODN). For ODN, the router matches only on the color value of the BGP route, and dynamically creates a policy using the nexthop as the endpoint. (The policy is calculated on-demand using the BGP nexthop, hence the name “On-Demand Nexthop”).