Segment Routing Mapping Server Prefix SID Resolution

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, up to max-ecmp, value is deterministic and is based on sorting the next-hops by:

  1. lowest next-hop router-id

  2. lowest interface index, for parallel links to same router-id

  Each next-hop keeps a reference to the destination nodes of whom it was inherited.

Prefix SID Resolution

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

  1. the local intra-area SID owned by this router

  2. the 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. the IS-IS SID and label binding TLV from the mapping server

     If multiple SIDs exist, select the following 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:

     - smallest range

     - smallest starting address

     - smallest algorithm

     - 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 step (I) towards 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 and are not programmed. The corresponding prefixes themselves are still resolved and programmed normally using IP next-next-hops.

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.

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

  2. 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 could 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.

  1. 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 could 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.

  2. Otherwise, the SR ILM label is swapped to a 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 a SR NHLFE label towards the stitching node.