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;
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
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.
Currently there are no SR-TE policies on R1, because there are no BGP routes matching color 20 or 30.
Bring up the BGP neighborship with the RR and check the SR-TE policies again.
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”).
Further Reading
Last updated