IGP Reverse Prefix Metric

The process of strict RPF (Reverse Path Forwarding) checks involves verifying that a packet is received on the interface that matches the router's reverse path to the source address. If the cost to the source is inconsistent between the forward and reverse directions, the strict RPF check fails, resulting in the packet being discarded. Another scenario involves running IGP multi-topology, where multicast traffic is usually situated within a separate topology. In this case, multicast also requires reverse path calculation. This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The strict RPF check process involves verifying that a packet is received on the interface that matches the router's reverse path to the source. If the cost between the forward and reverse path to the source is inconsistent, the strict RPF check will fail, resulting in the packet being discarded. Therefore, when performing strict RPF checks, in cases where forward and reverse path costs are inconsistent, it is necessary to calculate the optimal path based on reverse path costs. This allows strict RPF checks to be conducted using the reverse optimal path. Another scenario involves running multicast in an IGP multi-topology scenarios, where the cost of the multicast topology differs from that of the base topology. In multi-area scenarios, when the multicast topology requires reverse path calculation, the reverse cost between areas must also be considered. Typically, IGP can advertise link information through the link-state database, which provides knowledge of both forward and reverse path costs within the domain. However, in multi-area scenarios, the situation is different. The following describes the situation in multi-area scenarios in detail: In large-scale networks, an AS may be divided into different areas to avoid the problems caused by too many nodes. As shown in the following figure, an AS divided into two areas, each router is connected to the corresponding subnet, R1 is connected to P1, and so on, and R7 is connected to P7. Taking OSPFv2 as an example, R4 and R5, as ABRs, will convert the router LSA (type-1) of R6 and R7 in Area1 into network Summary LSA (type-3) and advertise it to the routers in Area0. Area0 to Area1 are also processed in the same way. The type-3 route received by R3 from R4 will include the subnet of R6, with an originator of R4 and a cost of 10. According to the method described in section 4, R3 will calculate the valid incoming interface of P6 as intf1. If the cost of the two directions of the link between R4 and R6 is different for some reason, for example, the cost from R4 to R6 is 10, but the cost in the reverse direction is 100, which will cause the packet sent by R6 to arrive at R3 from intf2 actually. But the type-3 route advertised by R4 to R3 has only one-way cost from R4 to R6, which cannot reflect the real situation.

)cost 10 +-----+ | | +----+ +-------+ R4 +-------------+ R6 | * * | R1 +---------+ | +-+-+-+ +--+--+ | | +----+ ++--++ | | cost20 | * * | R3 | * * (<->) | | | ++--++ | | | * * +----+ | | +-+-+-+(->)cost 20 +--+--+ | | | R2 +---------+ +-------+ R5 +-------------+ R7 | * * +----+ intf2 +-+-+-+ cost 30(<-) +-----+ | | | | * +-------------------------------+ +-------------------------+ Figure 1: example topology of multi-area ]]>

In order to accurately calculate strict RPF in the scenarios of multi-area, it is necessary to expand the type-3 route and advertise the cost in reverse directions between ABR and a prefix at the same time. That is, when R4 advertises the prefix information of R6, it carries cost of 10 and reverse cost of 100 at the same time. Similarly, the cost of R6 network prefix information advertised by R5 in two directions is 40 and 50 respectively. When ABR advertises network Summary LSA (type-3), ABR needs to calculate the total cost from the node where the prefix in LSA is located to this ABR, and advertises it together through protocol extension. By extending the protocol, R3 can be aware that packets from P6 and P7 will arrive at R3 from R5, so the valid incoming interface of the two protected prefixes can be calculated as intf2. After the AS is divided into different areas, in order to reduce routing messages, the ABR may aggregate the routing information with the same prefix and only publish one route to other areas. If the forward or reverse path costs of the aggregated prefixes are different, after advertising the aggregated route, the ABR also needs to separately advertise a route for the prefixes with different costs, and advertise the forward and reverse costs corresponding to this prefix in this route.

A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the total costs from the router where the prefix is located to reach ABR. The Prefix-Reverse-cost Sub-TLV is a sub-TLV of the OSPF Extended Prefix TLV described in . When the Route Type of OSPFv2 Extended Prefix TLV is Inter-Area (3), Prefix-Reverse-cost sub-TLV can be used. For Multi-Topology support, the TOS field is redefined as MT-ID in the payload of Router, Summary, and Type-5 and Type-7 AS-external LSAs . It SHOULD appear only once in the parent TLV and has the following format:

where: Type: TBD2. Length: 4. Rreverse metric: Total cost value from the router where the prefix is located to ABR.

A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the total cost from the router where the prefix is located to reach ABR. The Prefix-Reverse-cost sub-TLV is a sub-TLV of the following OSPFv3 TLVs as defined in and in Section 5: Inter-Area Prefix TLV It SHOULD appear only once in the parent TLV and has the following format:

where: Type: TBD4. Length: 4. Reverse metric: Total cost value from the router where the prefix is located to ABR.

A sub-TLV called Prefix-Reverse-cost sub-TLV is defined to carry the total cost from the router where the prefix is located to reach ABR. The Prefix-Reverse-cost sub-TLV is a sub-TLV of the following of the following IS-IS TLVs: TLV-135 (Extended IPv4 reachability) defined in . TLV-235 (Multi-topology IPv4 Reachability) defined in . TLV-236 (IPv6 IP Reachability) defined in . TLV-237 (Multi-topology IPv6 IP Reachability) defined in . When the level 2 router leaks routes through the above TLVs, Prefix-Reverse-cost sub-TLV can be used to carry reverse total cost. It SHOULD appear only once in the parent TLV and has the following format:

where: Type: TBD6. Length: 6. Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception Reverse metric: Total cost value from the router where the prefix is located to ABR.

This document describes how OSPF, IS-IS would advertise reverse prefix costs. There are no new security issues introduced by the extensions in this document. As always, if the IS-IS protocol is used in an environment where unauthorized access to the physical links on which IS-IS Protocol Data Units (PDUs) are sent occurs, then attacks are possible. The use of authentication as defined in [RFC5304] and [RFC5310] is recommended to prevent such attacks. As always, if the OSPF protocol is used in an environment where unauthorized access to the physical links on which OSPF packets are sent occurs, then attacks are possible. The use of authentication as defined in [RFC5709], [RFC7474], [RFC4552], and [RFC7166] is recommended for preventing such attacks.

The following values have been allocated:

This document makes the following registrations in the "Sub-TLVs for TLV 135, 235, 236, and 237" registry.