New TLV/sub-TLVs are defined in draft-ietf-ospf-segment-routing-extensions-04 and are required for the implementation of segment routing in OSPF. Specifically:
the prefix SID sub-TLV part of the OSPFv2 Extended Prefix TLV
the prefix SID sub-TLVpart of the OSPFv2 Extended Prefix Range TLV
the adjacency SID sub-TLV part of the OSPFv2 Extended Link TLV
SID/Label Range Capability TLV
SR-Algorithm Capability TLV
This section describes the behaviors and limitations of the OSPF support of segment routing TLV and sub-TLVs.
SR OS originates a single prefix SID sub-TLV per OSPFv2 Extended Prefix TLV and processes the first one only if multiple prefix SID sub-TLVs are received within the same OSPFv2 Extended Prefix TLV.
SR OS encodes the 32-bit index in the prefix SID sub-TLV. The 24-bit label or variable IPv6 SID is not supported.
SR OS originates a prefix SID sub-TLV with the following encoding of the flags.
The NP-Flag is always set, meaning that the label for the prefix SID is pushed by the PHP router when forwarding to this router. SR OS PHP routers properly processes a received prefix SID with the NP-flag set to zero and uses implicit-null for the outgoing label towards the router which advertised it.
The M-Flag is always unset because SR OS does not support originating a mapping server prefix-SID sub-TLV.
The E-flag is always set to zero. SR OS PHP routers properly processes a received prefix SID with the E-flag set to 1, and when the NP-flag is also set to 1 it pushes explicit-null for the outgoing label towards the router which advertised it.
The V-flag is always set to 0 to indicate an index value for the SID.
The L-flag is always set to 0 to indicate that the SID index value is not locally significant.
The algorithm field is always set to zero to indicate Shortest Path First (SPF) algorithm based on link metric and is not checked on a received prefix SID sub-TLV.
SR OS resolves a prefix SID received within an Extended Prefix TLV based on the following route preference:
SID received via an intra-area route in a prefix SID sub-TLV part of Extended Prefix TLV
SID received via an inter-area route in a prefix SID sub-TLV part of Extended Prefix TLV
SR OS originates an adjacency SID sub-TLV with the following encoding of the flags.
The F-flag is unset to indicate the Adjacency SID refers to an adjacency with outgoing IPv4 encapsulation.
The B-flag is set to zero and is not processed on receipt.
The V-flag is always set.
The L-flag is always set.
The S-flag is not supported.
The weight octet is not supported and is set to all zeros.
An adjacency SID is assigned to next hops over both the primary and secondary interfaces.
SR OS can originate the OSPFv2 Extended Prefix Range TLV as part of the Mapping Server feature and can process it properly if received. The following rules and limitations should be considered.
Only the prefix SID sub-TLV within the TLV is processed and the ILMs installed if the prefixes are resolved.
The range and address prefix fields are processed. Each prefix is resolved separately.
If the same prefix is advertised with both a prefix SID sub-TLV in a IP reachability TLV and a mapping server Prefix-SID sub-TLV, the resolution follows the following route preference:
the SID received via an intra-area route in a prefix SID sub-TLV part of Extended Prefix TLV
the SID received via an inter-area route in a prefix SID sub-TLV part of Extended Prefix TLV
the SID received via an intra-area route in a prefix SID sub-TLV part of a OSPFv2 Extended Range Prefix TLV
the SID received via an inter-area route in a prefix SID sub-TLV part of a OSPFv2 Extended Range Prefix TLV
No leaking of the entire TLV is performed between areas. Also, an ABR will not propagate the prefix-SID sub-TLV from the Extended Prefix Range TLV (received from a mapping server) into an Extended Prefix TLV if the latter is propagated between areas.
The mapping server which advertised the OSPFv2 Extended Prefix Range TLV does not need to be in the shortest path for the FEC prefix.
If the same FEC prefix is advertised in multiple OSPFv2 Extended Prefix Range TLVs by different routers, the SID in the TLV of the first router which is reachable is used. If that router becomes unreachable, the next reachable one is used.
No check is performed to determine whether or not the contents of the OSPFv2 Extended Prefix Range TLVs received from different mapping servers are consistent.
Any other sub-TLV, for example, the ERO metric and unnumbered interface ID ERO, is ignored but the user can get a dump of the octets of the received but not-supported sub-TLVs using the existing IGP show command.
SR OS supports propagation on ABR of external prefix LSA into other areas with routeType set to 3 as per draft-ietf-ospf-segment-routing-extensions-04.
SR OS supports propagation on ABR of external prefix LSA with route type 7 from NSSA area into other areas with route type set to 5 as per draft-ietf-ospf-segment-routing-extensions-04. SR OS does not support propagating of the prefix SID sub-TLV between OSPF instances.
When the user configures an OSPF import policy, the outcome of the policy applies to prefixes resolved in RTM and the corresponding tunnels in TTM. So, a prefix removed by the policy will not appear as both a route in RTM and as an SR tunnel in TTM.