New TLVs and sub-TLVs are defined in draft-ietf-ospf-segment-routing-extensions-04 and are required for the implementation of segment routing in OSPF. Specifically:
prefix SID sub-TLV part of the OSPFv2 Extended Prefix TLV
prefix SID sub-TLV part of the OSPFv2 Extended Prefix Range TLV
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 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. The label for the prefix SID is pushed by the PHP router when forwarding to this router. SR OS PHP routers process a received prefix SID with the NP-flag set to zero and use implicit-null for the outgoing label toward 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 process a received prefix SID with the E-flag set to 1, and when the NP-flag is also set to 1 they push explicit-null for the outgoing label toward 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 set to zero to indicate Shortest Path First (SPF) algorithm based on link IGP metric or to the flexible algorithm number.
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 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 G-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. Consider the following rules and limitations:
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 an 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
Leaking does not occur within the TLV between areas. Also, an ABR does 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 that is reachable is used. If that router becomes unreachable, the next reachable one is used.
There is no check to determine whether 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 the ABR of external prefix LSAs into other areas with routeType set to 3 as per draft-ietf-ospf-segment-routing-extensions-04.
SR OS supports propagation on the ABR of external prefix LSAs 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 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 does not appear as both a route in RTM and as an SR tunnel in TTM.