Segment Routing Mapping Server Prefix SID Resolution

The rules for IP prefix resolution, prefix SID resolution, and SR tunnel programing are as follows:

• 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, will inherit up to max-ecmp next hops from the advertising nodes

  • 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 given prefix, IGP selects the SID value among multiple advertised values respecting the following preference order:

    1. local intra-area SID owned by this router

    2. prefix SID sub-TLV advertised within a OSPF Extended Prefix TLV

       If multiple SIDs exist, select the SID corresponding to the destination router or ABR with the lowest OSPF Router-ID which is reachable via the first next hop of the prefix

    3. OSPF Extended Prefix Range TLV from mapping server

       If multiple SIDs exist, select the following, using the preference rules in draft-ietf-spring-conflict-resolution-05 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

  • The selected SID is used with all ECMP next hops from step (I) towards all destination nodes or ABR nodes which advertised the prefix.

  • If duplicate prefix SIDs exist for different prefixes after above steps, the first SID which is processed is programmed for its corresponding prefix.

    Subsequent SIDs causes a duplicate SID trap and are not programmed. The corresponding prefixes themselves are still resolved normally using IP next-hops.

• SR Tunnel Programming

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

    1. The SR ILM label is swapped to an SR NHLFE label as in regular SR tunnel resolution when the next-hop of the OSPF 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 OSPF 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 OSPF 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. The SR ILM label is swapped to an SR NHLFE label toward the stitching node.