PIM Working Group Y. Liu Internet Draft China Mobile Intended status: Informational M. McBride Expires: 05 March 2025 Futurewei Z. Zhang ZTE J. Xie Huawei C. Lin New H3C Technologies 05 September 2024 Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate Fast Reroute draft-ietf-pim-mofrr-tilfa-05 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 05 March 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires 05 March 2025 [Page 1] Internet-Draft MoFRR based on TILFA September 2024 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. Abstract This document specifies the use of Topology Independent Loop-Free Alternate (TI-LFA) mechanisms with Multicast Only Fast ReRoute (MoFRR) for Protocol Independent Multicast (PIM). TI-LFA provides fast reroute protection for unicast traffic in IP networks by precomputing backup paths that avoid potential failures. By integrating TI-LFA with MoFRR, this document extends the benefits of fast reroute mechanisms to multicast traffic, enabling enhanced resilience and minimized packet loss in multicast networks. The document outlines the necessary protocol extensions and operational considerations to implement TI-LFA in conjunction with MoFRR for PIM, ensuring that multicast traffic is rapidly rerouted in the event of a failure. Table of Contents 1. Introduction...................................................3 1.1. Requirements Language.....................................3 1.2. Terminology...............................................3 2. Problem Statement..............................................3 2.1. LFA for MoFRR.............................................3 2.2. RLFA for MoFRR............................................4 2.3. TI-LFA for MoFRR..........................................5 3. Solution.......................................................6 4. Illustration...................................................7 5. IANA Considerations...........................................11 6. Security Considerations.......................................11 7. References....................................................13 7.1. Normative References.....................................13 7.2. Informative References...................................14 Contributors.....................................................14 Authors' Addresses...............................................14 Liu, et al. Expires 05 March 2025 [Page 2] Internet-Draft MoFRR based on TILFA September 2024 1. Introduction The increasing deployment of video services has heightened the importance for network operators to implement solutions that minimize service disruptions caused by faults in the IP networks carrying these services. Multicast-only Fast Reroute (MoFRR), as defined in [RFC7431], offers a mechanism to reduce multicast packet loss in the event of node or link failures by introducing simple enhancements to multicast routing protocols, such as Protocol Independent Multicast (PIM). However, the current MoFRR mechanism, which selects the secondary multicast next hop based solely on the loop-free alternate fast reroute defined in [RFC7431], has limitations in certain multicast deployment scenarios. This document introduces a new mechanism for Multicast-only Fast Reroute using Topology Independent Loop-Free Alternate (TI-LFA) fast reroute. Unlike traditional methods, TI-LFA is independent of network topology, enabling broader coverage across diverse network environments. The applicability of this mechanism extends to PIM networks, including scenarios where PIM operates over native IP, as well as public network multicast trees established by PIM. Additionally, this document addresses scenarios involving MDT SAFI for Multicast VPN (MVPN) in [RFC6037] and [RFC6514], covering PIM- SSM Tree, PIM-SM Tree, and BIDIR-PIM Tree deployments. 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. 1.2. Terminology This document utilizes the terminology as defined in [RFC7431] and incorporates the concepts established in [RFC7490]. The definitions of individual terms are not reiterated within this document. 2. Problem Statement 2.1. LFA for MoFRR Section 3 of [RFC7431] specifies that the secondary Upstream Multicast Hop (UMH) in PIM for MoFRR is a Loop-Free Alternate (LFA). However, the traditional LFA mechanism requires that at least one neighbor's next hop to the destination node is an loop-free next hop. Due to existing limitations in network deployments, this Liu, et al. Expires 05 March 2025 [Page 3] Internet-Draft MoFRR based on TILFA September 2024 mechanism only covers certain network topology environments. In specific network topologies, the corresponding secondary UMH cannot be computed, preventing PIM from establishing a standby multicast tree and thus from implementing MoFRR protection. Consequently, the current MoFRR functionality in PIM is applicable only in network topologies where LFA is feasible. The limitations of the current MoFRR applicability can be illustrated using the example network depicted in Figure 1. In this example, the metric of the R1-R4 link is 20, the metric of the R5-R6 link is 100, and the metrics of the other links are 10. For multicast source S1, the primary path of the PIM join packet is R3->R2->R1, and the secondary path is R3->R4->R1, which corresponds to the LFA path of unicast routing. In this scenario, the current MoFRR operates effectively. For multicast source S2, the primary path of the PIM join packet is R3->R2. However, an LFA does not exist. If R3 sends the packet to R4, R4 will forward it back to R3 because the Interior Gateway Protocol (IGP) shortest path from R4 to R1 is R4->R3->R2. In this case, the current MoFRR cannot calculate a secondary UMH. Similarly, for multicast source S3, the current MoFRR mechanism is ineffective. [S1]---(R1)----------(R4) | | | | | | | | ------+------ [S2]---(R2)----------(R3)---[R] Link |Metric | | ------+------ | | R1-R4 | 20 | | R5-R6 | 100 | | Other | 10 [S3]---(R5)---(R6)---(R7) ------+------ Figure 1: Example Network Topology 2.2. RLFA for MoFRR The Remote Loop-Free Alternate (RLFA), as defined in [RFC7490], extends the traditional LFA mechanism, allowing it to accommodate a broader range of network deployment scenarios by utilizing a tunnel as an alternate path. The RLFA mechanism requires that there exists at least one node, denoted as node N, in the network where the fault node is neither on the path from the source node to node N nor on the path from node N to the destination node. Liu, et al. Expires 05 March 2025 [Page 4] Internet-Draft MoFRR based on TILFA September 2024 [RFC5496] introduces the RPF Vector attribute, which can be included in the PIM Join packet to ensure that the path is selected based on the unicast reachability of the RPF Vector. By combining the RLFA mechanism with the RPF Vector, the secondary multicast tree for MoFRR can be established, thereby supporting a wider range of network topologies compared to the current MoFRR implementation with LFA. For instance, in the network illustrated in Figure 1, the secondary path for the PIM Join packet towards multicast source S2 cannot be computed by the current MoFRR, as previously described. Utilizing the RLFA mechanism, R3 sends the packet to R4, including an RPF Vector containing the IP address of R1, which serves as the PQ node of R3 with respect to the protected R2-R3 link. Subsequently, R4 forwards the packet to R1 via the R1-R4 link, in accordance with the unicast route associated with the RPF Vector. R1 then continues to forward the packet to R2, thereby establishing the secondary path, R3->R4->R1->R2, using MoFRR with RLFA. 2.3. TI-LFA for MoFRR While RLFA provides enhanced capabilities over LFA, it remains dependent on the network topology. In the network depicted in Figure 1, the primary path of the PIM Join packet towards multicast source S3 is R3->R2->R5. However, an RLFA path does not exist because the PQ node of R3 with respect to the protected link R2-R3 is absent. If R3 sends the packet to R7 with an RPF Vector containing the IP address of R5, R7 will forward it back to R3, as the IGP shortest path from R7 to R5 is R7->R3->R2->R5. Similarly, if R3 sends the packet to R7 with an RPF Vector containing the IP address of R6, R7 will forward it to R6, but R6 will then forward it back to R7, as the IGP shortest path from R6 to R5 is R6->R7->R3->R2->R5. In this scenario, MoFRR with RLFA is unable to compute a secondary UMH. RLFA offers improvements over LFA but still has inherent limitations. [I-D.ietf-rtgwg-segment-routing-ti-lfa] defines a unicast FRR solution based on the TI-LFA mechanism. The TI-LFA mechanism allows the expression of a backup path using an explicit path and imposes no constraints on the network topology, thus providing a more robust FRR mechanism. Unicast traffic can be forwarded according to an explicit path list as an alternate path to protect unicast traffic, achieving full coverage across various network environments. The alternate path provided by the TI-LFA mechanism is represented as a Segment List, which includes the NodeSID of the P-space node and the Adjacency SIDs of the links between the P-space and Q-space nodes. PIM can look up the corresponding node IP address in the Liu, et al. Expires 05 March 2025 [Page 5] Internet-Draft MoFRR based on TILFA September 2024 unicast route according to the NodeSID and the IP addresses of the endpoints of the corresponding link in the unicast route according to the Adjacency SIDs. However, multicast protocol packets cannot be directly forwarded along the path of the Segment List. To establish a standby multicast tree, PIM Join messages need to be transmitted hop-by-hop. However, not all nodes and links on the unicast alternate path are included in the Segment List. If PIM protocol packets are transmitted solely in unicast mode, they effectively traverse the unicast tunnel like unicast traffic and do not pass through the intermediate nodes of the tunnel. Consequently, the intermediate nodes on the alternate path cannot forward multicast traffic because they lack PIM state entries. PIM must create entries on each device hop-by-hop, generating an incoming interface and an outgoing interface list, to form a complete end-to- end multicast tree for forwarding multicast traffic. Therefore, simply sending PIM Join packets using the Segment List, as done with unicast traffic, is insufficient to establish a standby multicast tree. 3. Solution A secondary Upstream Multicast Hop (UMH) serves as a candidate next- hop that can be used to reach the root of the multicast tree. In this document, the secondary UMH is derived from unicast routing, utilizing the Segment List computed by TI-LFA. In essence, the path information from the Segment List is incorporated into the PIM packets to guide hop-by-hop Reverse Path Forwarding (RPF) selection. The IP address corresponding to the Node SID can be used as the segmented root node, while the IP addresses of the interfaces at both endpoints of the link associated with the Adjacency SID can be directly used as the local upstream interface and upstream neighbor. For the PIM protocol, [RFC5496] defines the PIM RPF Vector attribute, which can carry the node IP address corresponding to the Node SID. Additionally, [RFC7891] defines the explicit RPF Vector, which can carry the peer IP address corresponding to the Adjacency SID. This document leverages the existing RPF Vector standards, obviating the need for PIM protocol extensions. This approach allows the establishment of a standby multicast tree based on the Segment List calculated by TI-LFA, thereby providing comprehensive MoFRR protection for multicast services across diverse network environments. Liu, et al. Expires 05 March 2025 [Page 6] Internet-Draft MoFRR based on TILFA September 2024 Consider a Segment List calculated by TI-LFA as (NodeSID(A), AdjSID(A-B)). Node A belongs to the P space, and node B belongs to the Q space. The IP address corresponding to NodeSID(A) can be retrieved from the local link-state database of the IGP protocol and assumed to be IP-a. Similarly, the IP addresses of the two endpoints of the link corresponding to AdjSID(A-B) can also be retrieved from the local link-state database and assumed to be IP-La and IP-Lb. Within the PIM process, IP-a is treated as the standard RPF Vector Attribute and added to the PIM Join packet. IP-La is considered the local address of the incoming interface, and IP-Lb is regarded as the address of the upstream neighbor. Consequently, IP-Lb can be included in the PIM Join packet as the explicit RPF Vector Attribute. The PIM protocol initially selects the RPF incoming interface and upstream neighbor towards IP-a and proceeds hop-by-hop to establish the PIM standby multicast tree until reaching node A. At node A, IP- Lb is treated as the PIM upstream neighbor. Node A identifies the incoming interface in the unicast routing table based on IP-Lb, and IP-Lb is used as the RPF upstream address for the PIM Join packet directed towards node B. Upon receiving the PIM Join packet at node B, the PIM protocol, finding no additional RPF Vector Attributes, selects the RPF incoming interface and upstream neighbor towards the multicast source directly. The protocol then continues hop-by-hop to establish the PIM standby multicast tree, extending to the router directly connected to the source. 4. Illustration This section provides an illustration of MoFRR based on TI-LFA. The example topology is depicted in Figure 2. The metric for the R3-R4 link is 100, while the metrics for the other links are 10. All link metrics are bidirectional. <-----Priamry Path--- (S,G) Join [S]---(R1)---(R2)******(R6)-------[R] | | <--- | | | | | | | | | (R5) | | | | | | | | | | | | | | (R3)------(R4) | Liu, et al. Expires 05 March 2025 [Page 7] Internet-Draft MoFRR based on TILFA September 2024 | | --Secondary Path-- Figure 2: Example Topology The IP addresses and Segment Identifiers (SIDs) involved in the MoFRR calculation are configured as follows: IPv4 Data Plane (MPLS-SR) Node IP Address Node SID R4 IP4-R4 Label-R4 Link IP Address Adjacency SID R3->R4 IP4-R3-R4 Label-R3-R4 R4->R3 IP4-R4-R3 Label-R4-R3 IPv6 Data Plane (SRv6) Node IP Address Node SID (End) R4 IP6-R4 SID-R4 Link IP Address Adjacency SID (End.X) R3->R4 IP6-R3-R4 SID-R3-R4 R4->R3 IP6-R4-R3 SID-R4-R3 The primary path of the PIM Join packet is R6->R2->R1, and the secondary path is R6->R5->R4->R3->R2->R1. However, the traditional LFA does not function properly for the secondary path because the shortest path to R2 from R5 (or from R4) still traverses the R6-R2 link. In this scenario, R6 must calculate the secondary UMH using the proposed MoFRR method based on TI-LFA. According to the TI-LFA algorithm, the P-space and Q-space are illustrated in Figure 3. The TI-LFA repair path consists of the Node SID of R4 and the Adjacency SID of R4->R3. On the MPLS-SR data plane, the repair segment list is (Label-R4, Label-R4-R3). On the SRv6 data plane, the repair segment list is (SID-R4, SID-R4-R3). Liu, et al. Expires 05 March 2025 [Page 8] Internet-Draft MoFRR based on TILFA September 2024 ........ . . [S]---(R1)---(R2)******(R6)---[R] . | . | . | . +++|++++ . | . + | + . | . + (R5) + . | . + | + . | . + | + . | . + | + . (R3)------(R4) + . . + + ........ ++++++++ Q-Space P-Space Figure 3: P-Space and Q-Space In the PIM process, the IP addresses associated with the repair segment list are retrieved from the IGP link-state database. On the IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4, which will be carried in the RPF Vector Attribute. The Adjacency SID Label-R4-R3 corresponds to the local address IP4-R4-R3 and the remote peer address IP4-R3-R4, with IP4-R3-R4 carried in the Explicit RPF Vector Attribute. On the IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4, which will be carried in the RPF Vector Attribute. The End.X SID SID-R4-R3 corresponds to the local address IP6-R4-R3 and the remote peer address IP6-R3-R4, with IP6-R3-R4 carried in the Explicit RPF Vector Attribute. Subsequently, R6 installs the secondary UMH using these RPF Vectors. Liu, et al. Expires 05 March 2025 [Page 9] Internet-Draft MoFRR based on TILFA September 2024 +---------+ |Type = 0 | |IP4-R4 | +---------+ +---------+ |Type = 4 | |Type = 4 | |IP4-R3-R4| |IP4-R3-R4| +---------+ +---------+ No RPF Vector R6----->R5---->R4------------>R3----->R2---->R1 Figure 4: Forwarding PIM Join Packet along Secondary Path (IPv4) On the IPv4 data plane, the forwarding of the PIM Join packet along the secondary path is shown in Figure 4. R6 inserts two RPF Vector Attributes in the PIM Join packet: IP4-R4 of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4 (Explicit RPF Vector Attribute). R6 then forwards the packet along the secondary path. When R5 receives the packet, it performs a unicast route lookup of the first RPF Vector IP4-R4 and sends the packet to R4. R4, being the owner of IP4-R4, removes the first RPF Vector from the packet and forwards it according to the next RPF Vector. R4 sends the packet to R3 based on the next RPF Vector IP4-R3-R4, as its PIM neighbor R3 corresponds to IP4-R3-R4. When R3 receives the packet, as the owner of IP4-R3-R4, it removes the RPF Vector. The packet, now devoid of RPF Vectors, is forwarded to the source through R3->R2->R1 based on unicast routes. After the PIM Join packet reaches R1, a secondary multicast tree, R1->R2->R3->R4->R5->R6, is established hop-by-hop for (S, G) using MoFRR based on TI-LFA. Liu, et al. Expires 05 March 2025 [Page 10] Internet-Draft MoFRR based on TILFA September 2024 +---------+ |Type = 0 | |IP6-R4 | +---------+ +---------+ |Type = 4 | |Type = 4 | |IP6-R3-R4| |IP6-R3-R4| +---------+ +---------+ No RPF Vector R6----->R5---->R4------------>R3----->R2---->R1 Figure 5: Forwarding PIM Join Packet along Secondary Path (IPv6) On the IPv6 data plane, the forwarding of the PIM Join packet along the secondary path is illustrated in Figure 5. The procedure is analogous to that of the IPv4 data plane. 5. IANA Considerations This document has no IANA actions. 6. Security Considerations This document does not introduce additional security concerns. It does not change the security properties of PIM. For general PIM-SM protocol security considerations, see [RFC7761]. The security considerations of LFA, R-LFA, and MoFRR described in [RFC5286], [RFC7490], and [RFC7431] SHOULD apply to this document. When deploying TILFA, packets may be sent over nodes and links they were not transported through before, potentially raising the following security issues: 1. Spoofing and False Route Advertisements * Dependencies of LFA/R-LFA/TI-LFA on Routing Information - LFAs depend on accurate routing information to determine alternate paths. If an attacker can inject false routing information (e.g., by spoofing link-state advertisements), it could cause the network to select suboptimal or malicious paths for LFAs. - R-LFA and TI-LFA also depend on accurate routing information, particularly for determining the tunneling paths or explicit paths. False route advertisements could mislead the network into using insecure or compromised paths. 2. Man-in-the-Middle (MitM) Attacks Liu, et al. Expires 05 March 2025 [Page 11] Internet-Draft MoFRR based on TILFA September 2024 * Use of Alternate Paths - By rerouting traffic through alternate paths, especially those that traverse multiple hops (as in R-LFA and TI-LFA), the risk of MitM attacks increases if any of the intermediate routers on the alternate path are compromised. - TI-LFA, which uses explicit paths, might expose traffic to routers that were not originally part of the primary path, potentially allowing for interception or alteration of the traffic. 3. Confidentiality and Integrity * Traffic Encapsulation - R-LFA and TI-LFA involve encapsulating traffic, which may expose it to vulnerabilities if the encapsulation mechanisms are not secure. For instance, if IPsec or another secure encapsulation method is not used, an attacker might be able to intercept or alter the traffic in transit. * Protection of Explicit Paths - TI-LFA relies on explicit paths that are typically defined using segment routing. If these paths are not properly protected, an attacker could manipulate the segment list to reroute traffic through malicious nodes. 4. Increased Attack Surface * Extended Topology - By introducing LFA, R-LFA, and TI-LFA, the network increases its reliance on additional routers and links, thereby expanding the potential attack surface. Compromise of any router in these alternate paths could expose traffic to unauthorized access or disruption. To address security issues #1 and #2 mentioned above, control plane protocols need to provide security protection. To mitigate the risks associated with false route advertisements and MitM attacks, it is recommended to use secure routing protocols (e.g., OSPFv3 with IPsec, ISIS HMAC-SHA256, or PIM with IPsec) that provide authentication and integrity protection for routing updates. To address security issues #3 and #4 mentioned above, these mechanisms need to run within a trusted network. The security of Liu, et al. Expires 05 March 2025 [Page 12] Internet-Draft MoFRR based on TILFA September 2024 LFA, R-LFA, and TI-LFA mechanisms heavily relies on the trustworthiness of the underlying routing infrastructure. As the solution described in the document is based on Segment Routing technology, readers should be aware of the security considerations related to this technology ([RFC8402]) and its data plane instantiations ([RFC8660], [RFC8754], and [RFC8986]). 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286,DOI 10.17487/RFC5286, September 2008,. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. Decraene, "Multicast-Only Fast Reroute", RFC 7431, August 2015. [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, April 2015. [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,Parekh, R., Zhang, Z., and L. Zheng, "Protocol IndependentMulticast - Sparse Mode (PIM-SM): Protocol Specification(Revised)", RFC 7761, March 2016. [RFC7891] Asghar, J., Wijnands, IJ., Ed., Krishnaswamy, S., Karan, A., and V. Arya, "Explicit Reverse Path Forwarding (RPF) Vector", RFC 7891, June 2016. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [I-D.ietf-rtgwg-segment-routing-ti-lfa] Litkowski, S., Bashandy, A., Filsfils, C., Francois, P., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", draft-ietf-rtgwg-segment-routing-ti-lfa-17, work-in- progress, July 2024. Liu, et al. Expires 05 March 2025 [Page 13] Internet-Draft MoFRR based on TILFA September 2024 7.2. Informative References [RFC6037] Rosen, E., Cai, Y., Wijnands, I., "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC6037, October 2010. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,July 2018, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660,DOI 10.17487/RFC8660, December 2019,. [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986,DOI 10.17487/RFC8986, February 2021,. Contributors Mengxiao Chen New H3C Technologies China Email: chen.mengxiao@h3c.com Authors' Addresses Yisong Liu China Mobile China Email: liuyisong@chinamobile.com Liu, et al. Expires 05 March 2025 [Page 14] Internet-Draft MoFRR based on TILFA September 2024 Mike McBride Futurewei Inc. USA Email: michael.mcbride@futurewei.com Zheng(Sandy) Zhang ZTE Corporation China Email: zzhang_ietf@hotmail.com Jingrong Xie Huawei Technologies China Email: xiejingrong@huawei.com Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Liu, et al. Expires 05 March 2025 [Page 15]