IGP Reverse Prefix Metric

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

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.¶

2. Usecase

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 [RFC2328] 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.¶

                                        Area1
      Area0                       +-------------------------+
+-------------------------------+ |                         |
|                               | *      cost 100(<-)       *
*                    intf1    +-+-+-+(->)cost 10  +-----+   |
|   +----+            +-------+  R4 +-------------+  R6 |   *
*   | R1 +---------+  |       +-+-+-+             +--+--+   |
|   +----+        ++--++        | |          cost20  |      *
*                 | R3 |        * *          (<->)   |      |
|                 ++--++        | |                  |      *
*   +----+         |  |       +-+-+-+(->)cost 20  +--+--+   |
|   | R2 +---------+  +-------+  R5 +-------------+  R7 |   *
*   +----+           intf2    +-+-+-+ cost 30(<-) +-----+   |
|                               | |                         *
+-------------------------------+ +-------------------------+

          Figure 1: example topology of multi-area

3. Solution

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.¶

4. Protocol Extension

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      reverse metric                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Reverse metric                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type        |     Length    |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Reverse metric                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Security Considerations

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.¶

6. IANA Considerations

+-------+--------------------+---------------+
| Value | Description        | Reference     |
+=======+====================+===============+
| TBD   | Prefix-Reverse-cost| This document |
+-------+--------------------+---------------+

 Table 1: OSPFv2 Extended Prefix TLV Sub-TLVs

+-------+--------------------+---------------+
| Value | Description        | Reference     |
+=======+====================+===============+
| TBD   | Prefix-Reverse-cost| This document |
+-------+--------------------+---------------+

 Table 2: OSPFv3 Extended Prefix TLV Sub-TLVs

+------+---------------------------+-----+-----+-----+-----+
| Type | Description               | 135 | 235 | 236 | 237 |
+======+===========================+=====+=====+=====+=====+
| TBD  |   Prefix-Reverse-cost     |  y  |  y  |  y  |  y  |
+------+---------------------------+-----+-----+-----+-----+

        Table 3: IS-IS Prefix-Reverse-cost Sub-TLVs

7. Contributors

Yuanxiang Qiu
New H3C Technologies
China
Email: qiuyuanxiang@h3c.com

Authors' Addresses