Automatic creation of an on-demand SR-TE LSP

The SR-TE on-demand LSP simplifies provisioning for networks that may or may not be managed by a network service manager, such as the Nokia NSP. Instead of using a full mesh, LSPs can be automatically created on-demand when a suitable existing tunnel does not exist for a particular BGP prefix next-hop. The prefix could be for base-routing and VPRN or EVPN routes or BGP-LU or BGP shortcuts. Both intradomain and inter-domain use cases are supported.

This mechanism is an extension of the LSP admin-tag and auto-LSP mechanisms and applies to the following objects:

VPRN auto-bind-tunnel
EVPN VPWS auto-bind-tunnel
EVPN VPLS auto-bind-tunnel
BGP-LU, both as an LER and LSR at an ABR or ASBR
BGP shortcuts

The following figure illustrates an application of SR-TE on-demand LSPs.

Figure: VPRN example of an on-demand SR-TE LSP

This example combines route transport coloring and auto LSPs to simplify provisioning for intent-based networking for specific services. In this use case, intent means the ability to meet traffic engineering requirements for a service. This could be, for example, a delay or loss, or the ability to steer the service traffic to avoid LSPs that transit specific geographies or prefer those that take another route.

In this example, a BGP route is advertised for a VRF in a PE for a VPRN service. An extended color community is assigned to the route. This color implies an intent associated with the transport requirements.

When this route is imported at the head-end PE the following steps occur:

The route is matched in a route-import policy.
An admin-tag-policy called red-lsps is applied.
A trigger action occurs to create an MPLS tunnel to the BGP next-hop for the route.

This causes the head-end router to create an SR-TE auto LSP that matches the red LSPs admin-tag policy and steers the traffic associated with "red" routes to the far-end PE, into the red LSP. This SR-TE auto LSP is created based on the configuration in the matching LSP template.

SR OS also offers the ability to use either local CSPF, hop-to-label-translation or a PCE to provide a path for the red LSP. This is determined by a configuration in the matching LSP template.

SR-TE on-demand LSPs are configured using the following steps:

Define a policy statement to import the route, as shown in the following example:
```
configure>router>policy-options>policy-statement
   
   entry
      from
        family <family>
        next-hop <ip-address>
        community <comm-name>
      action accept 
         admin-tag-policy <admin-tag-policy-name>
         create-mpls-tunnel
```
The create-mpls-tunnel action is supported for the following address families:
- vpn-ipv4
- vpn-ipv6
- evpn
- label-ipv4
- label-ipv6
- ipv4
- ipv6
This assigns an admin-tag-policy to the routes that are imported with a specific next hop and match a specified extended community. In most applications, the extended community is the transport color extended community. The create-mpls-tunnel action causes BGP to send the next hop and the include and exclude constraints in the admin-tag-policy (if one was assigned to a route by the policy statement) to the MPLS application.

When such a policy statement is applied in the context of a specific VRF, the create-mpls-tunnel trigger is only actioned by BGP on a per-next-hop basis.
Configure the auto LSP under MPLS with the template type on-demand-p2p-srte.

This type of LSP template supports PCE computation and control and fallback path computation method if the PCE is unreachable. The auto-LSP is configured using the following command:
```
configure>router>mpls
     auto-lsp <on-demand-p2p-srte-template-name>
```
The LSP template may contain an LSP admin-tag-policy. MPLS takes the next hop, and admin-tag includes/excludes constraints from BGP and matches them against the auto-LSP statement with a template with an admin-tag that conforms to the admin-tag-policy constraints.

If BGP does not pass any admin-tag-policy constraints, MPLS only matches against LSP templates that do not have the admin-tag option configured.

If the next-hop and admin-tag-policy match more than one auto-lsp statement, an LSP is created for each matching entry. This results in an ECMP set to the next hop.

Note: Each LSP may have a different admin-tag value, but it is an ECMP next-hop tunnel from the perspective of the colored route that triggers the tunnel creation.

A new SR-TE LSP is consequently created to the next hop passed by BGP according to the parameters contained in the LSP template.

The router tracks the binding between BGP triggers and on-demand LSPs that are successfully created and deleted toward a specified BGP next-hop matching an admin-tag-policy.

SR-TE on-demand P2P auto LSPs are removed by the router in all the following cases:

The classic CLI no auto-lsp (or MD-CLI delete auto-lsp) command is executed. This triggers MPLS to remove auto LSPs created by this command.
The no create-mpls-tunnel is configured in a policy statement that previously had create-mpls-tunnel configured. This triggers a re-evaluation of the policy statement and potentially trigger BGP to inform MPLS that it no longer needs a tunnel.
BGP tracks the binding of a route to an admin-tag-policy. If an admin-tag-policy name in a policy statement action changes, the policy is re-evaluated, which could change the binding. This may result in a request to create a new tunnel or delete an existing tunnel. However, if the contents of an admin-tag-policy that is referenced in a policy statement action change, BGP does not react (for example, request the creation or deletion of a tunnel), although a subsequent route resolution may change.
MPLS reacts to admin-tag changes in the LSP template. When this occurs, it re-evaluates the admin-tag-policy associated with a request from BGP and deletes or creates tunnels accordingly.
If a new LSP is created that is not an on-demand LSP and is preferred to an existing on-demand LSP, BGP can resolve the next hop over the new LSP and traffic moves to it. In this case, the system does not remove the older less-preferred auto-LSP, which was created through an on-demand LSP trigger, until the next hops are removed.
If the LSP template is shutdown all associated LSPs are administratively disabled. To delete the LSP template you must first shut it down, using a no auto-lsp command in classic CLI or delete auto-lsp command in MD-CLI. This removes all the auto LSPs using the template.