This feature like the RSVP-TE auto-LSP using an LSP template of one-hop-p2p type. Although the provisioning model and CLI syntax differ from that of a mesh LSP by the absence of a prefix list, the actual behavior is quite different. When the one-hop-p2p command is executed, the TE database keeps track of each TE link that comes up to a directly connected IGP neighbor. It then instructs MPLS to instantiate an SR-TE LSP with the following parameters:
the source address of the local router
an outgoing interface matching the interface index of the TE link
a destination address matching the router ID of the neighbor on the TE link
In this case, the hop-to-label translation or the local CSPF returns the SID for the adjacency to the remote address of the neighbor on this link. Therefore, the auto-lsp command binding an LSP template of type one-hop-p2p-srte with the one-hop option results in one SR-TE LSP instantiated to the IGP neighbor for each adjacency over any interface.
Because the local router installs the adjacency SID to a link independent of whether the neighbor is SR-capable, the TE-DB finds the adjacency SID and a one-hop SR-TE LSP can still come up to such a neighbor. However, remote LFA using the neighbor’s node SID does not protect the adjacency SID and so, does also not protect the one-hop SR-TE LSP because the node SID is not advertised by the neighbor.
The LSP has an auto-generated name using the following structure:
‟TemplateName-DestIpv4Address-TunnelId”
where:
TemplateName = the name of the template
DestIpv4Address = the address of the destination of the auto-created LSP
TunnelId = the TTM tunnel ID.
The path name is that of the default path specified in the LSP template.