Segment Routing Mapping Server Prefix SID Resolution

The following processing rules apply for IP prefix resolution.

• SPF calculates the next-hops, up to max-ecmp, to reach a destination node.

• Each prefix inherits the next-hops of one or more destination nodes advertising it.

• A prefix advertised by multiple nodes, all reachable with same cost, inherits up to max-ecmp next-hops from the advertising nodes.

• The next-hop selection value, up to max-ecmp, is based on sorting the next-hops by:

  • lowest next-hop router ID

  • lowest interface index, for parallel links to same router ID

  Each next hop keeps a reference to the destination nodes from which it was inherited.

The following processing rules apply for prefix SID resolution

• For a specified prefix, IGP selects the SID value among multiple advertised values in the following order:

  1. local intra-area SID owned by this router

  2. prefix SID sub-TLV advertised within an IP reach TLV

     If multiple SIDs exist, select the SID corresponding to the destination router or the ABR with the lowest system ID that is reachable using the first next-hop of the prefix.

  3. IS-IS SID and label binding TLV from the mapping server

     If multiple SIDs exist, select the following, using the preference rules in draft-ietf-spring-conflict-resolution-05 [sid-conflict-resolution] when applied to the SRMS entries of the conflicting SIDs. The order of these rules is as follows:

     1. smallest range
     2. smallest starting address
     3. smallest algorithm
     4. smallest starting SID
  Note: If an L1L2 router acts as a mapping server and also re-advertises the mapping server prefix SID from other mapping servers, the redistributed mapping server prefix SID is preferred by other routers resolving the prefix, which may result in not selecting the mapping server respecting these rules.

• The selected SID is used with all ECMP next-hops from step 1 toward all destination nodes or ABR nodes which advertised the prefix.

• If duplicate prefix SIDs exist for different prefixes after the above steps, the first SID that is processed is programmed for its corresponding prefix. Subsequent SIDs cause a duplicate SID trap message and are not programmed. The corresponding prefixes are still resolved and programmed normally using IP next-next-hops.

The following processing rules apply for SR tunnel programming

• If the prefix SID is resolved from a prefix SID sub-TLV advertised within an IP reach TLV, one of the following applies.

  • The SR ILM label is swapped to a SR NHLFE label as in SR tunnel resolution when the next-hop of the ISIS prefix is SR enabled.

  • The SR ILM label is stitched to an LDP FEC of the same prefix when either the next-hop of the ISIS prefix is not SR enabled (no SR NHLFE) or an import policy rejects the prefix (SR NHLFE deprogrammed).

    The LDP FEC can also be resolved using the same or a different IGP instance as that of the prefix SID sub-TLV or using a static route.

• If the prefix SID is resolved from a mapping server advertisement, one of the following applies.

  • The SR ILM label is stitched to an LDP FEC of the same prefix, if one exists. The stitching is performed even if an import policy rejects the prefix in the local ISIS instance.

    The LDP FEC can also be resolved using a static route, a route within an IS-IS instance, or a route within an OSPF instance. The latter two can be the same as, or different from the IGP instance that advertised the mapping server prefix SID sub-TLV.

  • Otherwise, the SR ILM label is swapped to an SR NHLFE label. This is only possible if a route is exported from another IGP instance into the local IGP instance without propagating the prefix SID sub-TLV with the route. Otherwise, the SR ILM label is swapped to an SR NHLFE label toward the stitching node.