LSR Working Group D. Li Internet Draft Tsinghua University Intended status: Standards Track L. Liu Expires: January 7, 2025 Zhongguancun Laboratory C. Lin New H3C Technologies X. Song ZTE Corporation Y. Qiu New H3C Technologies July 8, 2024 IGP Reverse Prefix Metric draft-li-lsr-igp-reverse-prefix-metric-00 Abstract This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 8, 2025. Li, et al. Expires January, 2025 [Page 1] Internet-Draft IGP Reverse Prefix Metric July 2024 Copyright Notice Copyright (c) 2024 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 2. Usecase........................................................3 3. Solution.......................................................5 4. Protocol Extension.............................................5 4.1. Extension of OSPFv2 Reverse Prefix Cost...................5 4.2. Extension of OSPFv3 Reverse Prefix Cost...................6 4.3. Extension of IS-IS Reverse Prefix Cost....................7 5. Security Considerations........................................8 6. IANA Considerations............................................8 7. References.....................................................8 7.1. Normative References......................................8 Contributors......................................................8 Authors' Addresses................................................9 Li, et al. Expires January, 2025 [Page 2] Internet-Draft IGP Reverse Prefix Metric July 2024 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. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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 Li, et al. Expires January, 2025 [Page 3] Internet-Draft IGP Reverse Prefix Metric July 2024 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. Area1 Area0 +-------------------------+ +-------------------------------+ | | | | * cost 100(<-) * * intf1 +-+-+-+(->)cost 10 +-----+ | | +----+ +-------+ R4 +-------------+ R6 | * * | R1 +---------+ | +-+-+-+ +--+--+ | | +----+ ++--++ | | cost20 | * * | R3 | * * (<->) | | | ++--++ | | | * * +----+ | | +-+-+-+(->)cost 20 +--+--+ | | | R2 +---------+ +-------+ R5 +-------------+ R7 | * * +----+ intf2 +-+-+-+ cost 30(<-) +-----+ | | | | * +-------------------------------+ +-------------------------+ Figure 3: example topology of multi-area Li, et al. Expires January, 2025 [Page 4] Internet-Draft IGP Reverse Prefix Metric July 2024 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 4.1. Extension of OSPFv2 Reverse Prefix Cost 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 [RFC7684]. 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 [RFC4915]. Li, et al. Expires January, 2025 [Page 5] Internet-Draft IGP Reverse Prefix Metric July 2024 It SHOULD appear only once in the parent TLV and has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD2. Length: 4. Rreverse metric: Total cost value from the router where the prefix is located to ABR. 4.2. Extension of OSPFv3 Reverse Prefix Cost 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 [RFC8362] and in Section 5: Inter-Area Prefix TLV It SHOULD appear only once in the parent TLV and has the following format: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD4. Length: 4. Li, et al. Expires January, 2025 [Page 6] Internet-Draft IGP Reverse Prefix Metric July 2024 Reverse metric: Total cost value from the router where the prefix is located to ABR. 4.3. Extension of IS-IS Reverse Prefix Cost 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 [RFC5305]. TLV-235 (Multi-topology IPv4 Reachability) defined in [RFC5120]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-237 (Multi-topology IPv6 IP Reachability) defined in [RFC5120]. 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: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Li, et al. Expires January, 2025 [Page 7] Internet-Draft IGP Reverse Prefix Metric July 2024 5. Security Considerations This document does not introduce any new security consideration. 6. IANA Considerations TBD. 7. References 7.1. Normative References [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, . Contributors Li, et al. Expires January, 2025 [Page 8] Internet-Draft IGP Reverse Prefix Metric July 2024 Authors' Addresses Dan Li Tsinghua University Beijing China Email: tolidan@tsinghua.edu.cn Libin Liu Zhongguancun Laboratory Beijing China Email: liulb@zgclab.edu.cn Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Xueyan Song ZTE Corporation China Email: song.xueyan2@zte.com.cn Yuanxiang Qiu New H3C Technologies China Email: qiuyuanxiang@h3c.com Li, et al. Expires January, 2025 [Page 9]