[pim] [Shepherding AD review] Pre-IETF Last-Call review of draft-ietf-pim-mofrr-tilfa-04

["Gunter van de Velde (Nokia)" <[e-mail]>]

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pim-mofrr-tilfa-04

This is a shepherding AD draft review before starting the process of the IETF LC.


#GENERIC COMMENTS
#================
## Many thanks to Stig Venaas for the Shepherd writeup

## idnits spits some warnings and unused references:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-mofrr-tilfa-04.txt

## When searching the PIM WG archives there has been very little discussion about this work on the list. 

## The text sturcture and grammar was not always easy to follow. I tried to provide alternate text proposals fixing them. I tried to keep original objective intact

## section 6. Security considerations is rather compact. The solution in the draft uses tunnels and LFA technology and these may have implicit relevant security considerations. I took liberty to add a set of those considerations at the end of this review message to look at and potentially validate against usage in a MoFRR enabled environment.


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

55	Abstract
56
57	   Multicast-only Fast Reroute (MoFRR) has been defined in RFC7431,
58	   but the selection of the secondary multicast next hop depends on the
59	   loop-free alternate fast reroute, which has restrictions in
60	   multicast deployments. This document describes a mechanism for
61	   Multicast-only Fast Reroute by using Topology Independent Loop-free
62	   Alternate fast reroute, which is independent of network topology and
63	   can achieve the coverage of more network environments.

[minor]
An abstract should be about what is included within this document and be clear about objectives and the procedures. WHat about following alternate 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.
"

84	1. Introduction
85
86	   As the deployment of video services, operators are paying more and
87	   more attention to solutions that minimize the service disruption due
88	   to faults in the IP network carrying the packets for these services.
89	   Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431],
90	   which can minimize multicast packet loss in a network when node or
91	   link failures occur by making simple enhancements to multicast
92	   routing protocols such as Protocol Independent Multicast (PIM). But
93	   the selection of the secondary multicast next hop only according to
94	   the loop-free alternate fast reroute in [RFC7431], and there are
95	   limitations in multicast deployments for this mechanism. This
96	   document describes a new mechanism for Multicast-only Fast Reroute
97	   using Topology Independent Loop-free Alternate (TI-LFA) fast
98	   reroute, which is independent of network topology and can achieve
99	   covering more network environments. This document applies to PIM
100	   networks, including scenarios where PIM operates over native IP, as
101	   well as public network multicast trees established by PIM. It covers
102	   scenarios involving RFC 6037 MDT SAFI for MVPN and RFC 6514 (PIM-SSM
103	   Tree, PIM-SM Tree, BIDIR-PIM Tree).

[minor]
proposed rewrite:

"
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 RFC 6037 MDT SAFI for Multicast VPN (MVPN) and RFC 6514, covering PIM-SSM Tree, PIM-SM Tree, and BIDIR-PIM Tree deployments.
"

113	 1.2. Terminology
114
115	   This document use the terms defined in [RFC7431], and also use the
116	   concepts defined in [RFC7490]. The specific content of each term is
117	   not described in this document.

[minor]
proposed rewrite:

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

119	2. Problem Statement
120
121	 2.1. LFA for MoFRR
122
123	   In [RFC7431] section 3, the secondary Upstream Multicast Hop (UMH)
124	   of PIM for MoFRR is a loop-free alternate (LFA). However, the
125	   traditional LFA mechanism needs to satisfy at least one neighbor
126	   whose next hop to the destination node is an acyclic next hop,
127	   existing limitations in network deployments, and can only cover part
128	   of the network topology environments. In some network topologies,
129	   the corresponding secondary UMH cannot be calculated, so PIM cannot
130	   establish a standby multicast tree and cannot implement MoFRR
131	   protection. Therefore, the current MoFRR of PIM is only available in
132	   the network topology applicable to LFA.
133
134	   The problem of current MoFRR applicability can be illustrated by the
135	   example network shown in Figure 1. The metric of R1-R4 link is 20,
136	   the metric of R5-R6 link is 100, and the metrics of other links are
137	   10.
138
139	   Towards multicast source S1, the primary path of the PIM join packet
140	   is R3->R2->R1, and the secondary path is R3->R4->R1, which is the
141	   same as the LFA path of unicast routing. In this case, the current
142	   MoFRR can work well.
143
144	   Towards multicast source S2, the primary path of the PIM join packet
145	   is R3->R2. However, the LFA does not exist. If R3 sends the packet
146	   to R4, R4 will forward it back to R3, as the IGP shortest path from
147	   R4 to R1 is R4->R3->R2. In this case, the secondary UMH cannot be
148	   calculated by the current MoFRR. Similarly for multicast source S3,
149	   the current MoFRR does not work either.
150
151	            [S1]---(R1)----------(R4)
152	                    |             |
153	                    |             |
154	                    |             |
155	                    |             |             ------+------
156	            [S2]---(R2)----------(R3)---[R]     Link  |Metric
157	                    |             |             ------+------
158	                    |             |             R1-R4 | 20
159	                    |             |             R5-R6 | 100
160	                    |             |             Other | 10
161	            [S3]---(R5)---(R6)---(R7)           ------+------
162
163	                   Figure 1:  Example Network Topology

[minor]
The use of "acyclic next hop" is changed to loop-free as that is terminology most people will be familiar with

[minor]
proposed rewrite:

"
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 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
"

165	 2.2. RLFA for MoFRR
166
167	   The remote loop-free alternate (RLFA) defined in [RFC7490] is
168	   extended from the LFA and can cover more network deployment
169	   scenarios through the tunnel as an alternate path. The RLFA
170	   mechanism needs to satisfy at least one node assumed to be N in the
171	   network that the fault node is neither on the path from the source
172	   node to the N node, nor on the path from the N node to the
173	   destination node.
174
175	   [RFC5496] defines the RPF Vector attribute that can be carried in
176	   the PIM Join packet such that the path is selected based on the
177	   unicast reachability of the RPF Vector. The secondary multicast tree
178	   of MoFRR can be established by using the combination of RLFA
179	   mechanism and RPF Vector, which would cover more network topologies
180	   than the current MoFRR with LFA.
180
182	   For example, in the network of Figure 1, the secondary path of PIM
183	   join packet towards multicast source S2 cannot be calculated by the
184	   current MoFRR, as mentioned above. Based on the RLFA mechanism, R3
185	   sends the packet to R4 along with an RPF Vector containing the IP
186	   address of R1, which is the PQ node of R3 with respect to the
187	   protected link R2-R3. Then R4 will forward the packet to R1 through
188	   the link R1-R4, according to the unicast route for the RPF Vector.
189	   R1 continues to forward the packet to R2, and the secondary path,
190	   R3->R4->R1->R2, is established by MoFRR with RLFA.

[minor]
proposed rewrite:

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

[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.
"

192	 2.3. TI-LFA for MoFRR
193
194	   However, RLFA is also topology dependent. In the network of Figure
195	   1, towards multicast source S3, the primary path of the PIM join
196	   packet is R3->R2->R5, but the RLFA path does not exist. This is
197	   because the PQ node of R3 with respect to the protected link R2-R3
198	   does not exist. If R3 sends the packet to R7 along with an RPF
199	   Vector containing the IP address of R5, R7 will forward it back to
200	   R3, since the IGP shortest path from R7 to R5 is R7->R3->R2->R5. Or,
201	   if R3 sends the packet to R7 along with an RPF Vector containing the
202	   IP address of R6, R7 will forward it to R6, but then R6 will forward
203	   it back to R7, since the IGP shortest path from R6 to R5 is
204	   R6->R7->R3->R2->R5. In this case, the secondary UMH cannot be
205	   calculated by MoFRR with RLFA.
206
207	   RLFA only has enhancement compared to LFA but still has limitations.
208	   [I-D.ietf-rtgwg-segment-routing-ti-lfa] defines a unicast FRR
209	   solution based on the TI-LFA mechanism. The TI-LFA mechanism can
210	   express the backup path with an explicit path, and has no constraint
211	   on the topology, providing a more reliable FRR mechanism. The
212	   unicast traffic can be forwarded according to the explicit path list
213	   as an alternate path to implement unicast traffic protection, and
214	   can achieve full coverage of various networking environments.
215
216	   The alternate path provided by the TI-LFA mechanism is actually a
217	   Segment List, including the NodeSID of P space node and the
218	   Adjacency SID(s) of link(s) between the P space and the Q space. PIM
219	   can look up the corresponding node IP address in the unicast route
220	   according to the NodeSID, and the IP addresses of the two endpoints
221	   of the corresponding link in the unicast route according to the
222	   Adjacency SIDs, but the multicast protocol packets cannot be
223	   directly sent along the path of the Segment List.
224
225	   PIM join messages need to be sent hop-by-hop to establish a standby
226	   multicast tree. However, not all of the nodes and links on the
227	   unicast alternate path are included in the Segment List. If the PIM
228	   protocol packets are transmitted only in unicast mode, then
229	   equivalently the PIM packets are transmitted through the unicast
230	   tunnel like unicast traffic, and cannot pass through the
231	   intermediate nodes of the tunnel. The intermediate nodes of the
232	   alternate path cannot forward multicast traffic because there are no
233	   PIM state entries on the nodes. PIM needs to create entries on the
234	   device hop-by-hop and generate an incoming interface and an outgoing
235	   interface list. So, it can form an end-to-end complete multicast
236	   tree for forwarding multicast traffic. Therefore, simply sending PIM
237	   join packets with the Segment List, like the unicast traffic, cannot
238	   establish a standby multicast tree.

[minor]
proposed rewrite:

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

240	3. Solution
241
242	   A secondary Upstream Multicast Hop (UMH) is a candidate next-hop
243	   that can be used to reach the root of the tree.  In this document
244	   the secondary UMH is based on unicast routing to find the Segment
245	   List calculated by TI-LFA.
246
247	   In principle, the path information of the Segment List is added to
248	   the PIM packets to guide the hop-by-hop RPF selection. The IP
249	   address of the node corresponding to the Node SID can be used as the
250	   segmented root node, and the IP addresses of the interfaces at both
251	   endpoints of the link corresponding to the Adjacency SID can be used
252	   directly as the local upstream interface and upstream neighbor.
253
254	   For the PIM protocol, the PIM RPF Vector attribute was defined in
255	   [RFC5496], which can carry the node IP address corresponding to the
256	   Node SID. The explicit RPF Vector was defined in [RFC7891], which
257	   can carry the peer IP address corresponding to the Adjacency SID.
258
259	   This document can use the above two RPF Vector standards and does
260	   not need to extend the PIM protocol, to establish the standby
261	   multicast tree according to the Segment List calculated by TI-LFA,
262	   and can achieve full coverage of various networking environments for
263	   MoFRR protection of multicast services.
264
265	   Assume that the Segment List calculated by TI-LFA is (NodeSID(A),
266	   AdjSID(A-B)). Node A belongs to the P Space, and node B belongs to
267	   the Q space. The IP address corresponding to NodeSID(A) can be
268	   looked up in the local link state database of the IGP protocol, and
269	   can be assumed to be IP-a. The IP addresses of the two endpoints of
270	   the link corresponding to AdjSID(A-B) can also be looked up in the
271	   local link state database of the IGP protocol, and can be assumed to
272	   be IP-La and IP-Lb.
273
274	   In the procedure of PIM, IP-a can be regarded as the normal RPF
275	   Vector Attribute and added to the PIM join packet. IP-La can be
276	   regarded as the local address of the incoming interface, and IP-Lb
277	   can be regarded as the address of the upstream neighbor. So IP-Lb
278	   can be added to the PIM join packet as the explicit RPF Vector
279	   Attribute.
280
281	   The PIM protocol firstly can select the RPF incoming interface and
282	   upstream towards IP-a, and can join hop-by-hop to establish the PIM
283	   standby multicast tree until the node A. On the node A, IP-Lb can be
284	   regarded as the PIM upstream neighbor. The node A can find the
285	   incoming interface in the unicast routing table according to the IP-
286	   Lb, and IP-Lb is used as the RPF upstream address of the PIM join
287	   packet to the node B.
288
289	   After the PIM join packet is received on the node B, the PIM
290	   protocol can find no more RPF Vector Attributes and select the RPF
291	   incoming interface and upstream towards the multicast source
292	   directly, and then can continue to join hop-by-hop to establish the
293	   PIM standby multicast tree until the router directly connected the
294	   source.

[minor]
proposed rewrite:

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

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

296	4. Illustration
297
298	   This section provides an illustration of MoFRR based on TI-LFA. The
299	   example topology is shown in Figure 2. The metric of R3-R4 link is
300	   100, and the metrics of other links are 10. All the link metrics are
301	   bidirectional.
302
303	                     <-----Priamry Path--- (S,G) Join
304
305	             [S]---(R1)---(R2)******(R6)-------[R]
306	                            |        |
307	                     <---   |        |   |
308	                        |   |        |   |
309	                        |   |       (R5) |
310	                        |   |        |   |
311	                        |   |        |   |
312	                        |   |        |   |
313	                        | (R3)------(R4) |
314	                        |                |
315	                        --Secondary Path--
316
317	                    Figure 2:  Example Topology
318
319	   The IP addresses and SIDs, which may be involved in the MoFRR
320	   calculation, are configured as following:
321
322	   IPv4 Data Plane (MPLS-SR)
323
324	     Node    IP Address   Node SID
325	     R4      IP4-R4       Label-R4
326
327	     Link    IP Address   Adjacency SID
328	     R3->R4  IP4-R3-R4    Label-R3-R4
329	     R4->R3  IP4-R4-R3    Label-R4-R3
330
331	   IPv6 Data Plane (SRv6)
332
333	     Node    IP Address   Node SID (End)
334	     R4      IP6-R4       SID-R4
335
336	     Link    IP Address   Adjacency SID (End.X)
337	     R3->R4  IP6-R3-R4    SID-R3-R4
338	     R4->R3  IP6-R4-R3    SID-R4-R3
339
340	   The primary path of the PIM join packet is R6->R2->R1, and the
341	   secondary path is R6->R5->R4->R3->R2->R1. However, the traditional
342	   LFA does not work properly for the secondary path, because the
343	   shortest path to R2 from R5 (or from R4) still goes through R6-R2
344	   link. In this case, R6 needs to calculate the secondary UMH using
345	   the proposed MoFRR method based on TI-LFA.
346
347	   According to the TI-LFA algorithm, P-Space and Q-Space are shown in
348	   Figure 3. The TI-LFA repair path consists of the Node SID of R4 and
349	   the Adjacency SID of R4->R3. On MPLS-SR data plane, the repair
350	   segment list is (Label-R4, Label-R4-R3). On SRv6 data plane, the
351	   repair segment list is (SID-R4, SID-R4-R3).
352
353	                           ........
354	                           .      .
355	                 [S]---(R1)---(R2)******(R6)---[R]
356	                           .   |  .     |
357	                           .   |  .  +++|++++
358	                           .   |  .  +  |   +
359	                           .   |  .  + (R5) +
360	                           .   |  .  +  |   +
361	                           .   |  .  +  |   +
362	                           .   |  .  +  |   +
363	                           . (R3)------(R4) +
364	                           .      .  +      +
365	                           ........  ++++++++
366	                           Q-Space    P-Space
367
368	                   Figure 3:  P-Space and Q-Space
369
370	   In the procedure of PIM, the IP addresses associated with the repair
371	   segment list are looked up in the IGP link state database.
372
373	   On IPv4 data plane, the Node SID Label-R4 corresponds to IP4-R4,
374	   which will be carried in the RPF Vector Attribute. The Adjacency SID
375	   Label-R4-R3 corresponds to local address IP4-R4-R3 and remote peer
376	   address IP4-R3-R4, and IP4-R3-R4 will be carried in the Explicit RPF
377	   Vector Attribute.
378
379	   On IPv6 data plane, the End SID SID-R4 corresponds to IP6-R4, which
380	   will be carried in the RPF Vector Attribute. The End.X SID SID-R4-R3
381	   corresponds to local address IP6-R4-R3 and remote peer address IP6-
382	   R3-R4, and IP6-R3-R4 will be carried in the Explicit RPF Vector
383	   Attribute.
384
385	   Then, R6 installs the secondary UMH with these RPF Vectors.
386
387	             +---------+
388	             |Type = 0 |
389	             |IP4-R4   |
390	             +---------+    +---------+
391	             |Type = 4 |    |Type = 4 |
392	             |IP4-R3-R4|    |IP4-R3-R4|
393	             +---------+    +---------+   No RPF Vector
394
395	          R6----->R5---->R4------------>R3----->R2---->R1
396
397	    Figure 4:  Forwarding PIM Join Packet along Secondary Path (IPv4)
398
399	   On IPv4 data plane, the forwarding of PIM join packet along the
400	   secondary path is shown in Figure 4.
401
402	   R6 inserts two RPF Vector Attributes in the PIM join packet, which
403	   are IP4-R4 of Type 0 (RPF Vector Attribute) and IP4-R3-R4 of Type 4
404	   (Explicit RPF Vector Attribute). Then R6 forwards the packet along
405	   the secondary path.
406
407	   When R5 receives the packet, R5 performs a unicast route lookup of
408	   the first RPF Vector IP4-R4 and sends the packet to R4.
409
410	   R4 is the owner of IP4-R4, so it removes the first RPF Vector from
411	   the packet and forwards according to the following RPF Vector. R4
412	   sends the packet to R3 according to the next RPF Vector IP4-R3-R4,
413	   since its PIM neighbor R3 corresponds to IP4-R3-R4.
414
415	   When R3 receives the packet, as the owner of IP4-R3-R4, it removes
416	   the RPF Vector. Then the packet has no RPF Vector, and will be
417	   forwarded to the source through R3->R2->R1 according to unicast
418	   routes.
419
420	   After the PIM join packet reaches R1, a secondary multicast tree,
421	   R1->R2->R3->R4->R5->R6, is established hop-by-hop for (S, G) by
422	   MoFRR based on TI-LFA.
423
424	             +---------+
425	             |Type = 0 |
426	             |IP6-R4   |
427	             +---------+    +---------+
428	             |Type = 4 |    |Type = 4 |
429	             |IP6-R3-R4|    |IP6-R3-R4|
430	             +---------+    +---------+   No RPF Vector
431
432	          R6----->R5---->R4------------>R3----->R2---->R1
433
434	    Figure 5:  Forwarding PIM Join Packet along Secondary Path (IPv6)
435
436	   On IPv6 data plane, the forwarding of PIM join packet along the
437	   secondary path is shown in Figure 5. The procedure is similar with
438	   IPv4 data plane.

[minor]
proposed rewrite:

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

                     <-----Primary Path--- (S,G) Join

             [S]---(R1)---(R2)******(R6)-------[R]
                            |        |
                     <---   |        |   |
                        |   |        |   |
                        |   |       (R5) |
                        |   |        |   |
                        |   |        |   |
                        |   |        |   |
                        | (R3)------(R4) |
                        |                |
                        --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).

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

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

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

444	6. Security Considerations
445
446	   This document does not change the security properties of PIM. For
447	   general PIM-SM protocol Security Considerations, see [RFC7761].

[major]
When deploying TILFA the packet may be sent over nodes and links it was not transported before, opening security issues. 

for example have a look at following LFA security considerations. Maybe some of these influence and have  relevance when applied to MoFRR:


1. Spoofing and False Route Advertisements

* LFA/R-LFA/TI-LFA Dependencies 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

* 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 in 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 LFAs, R-LFAs, and TI-LFAs, 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.

5. Complexity and Configuration Errors

* Misconfigurations:

  - The complexity of configuring LFAs, R-LFAs, and TI-LFAs increases the risk of misconfigurations, which could inadvertently create security vulnerabilities, such as routing loops or the selection of insecure paths.

* Overhead and Resource Exhaustion:

  - The additional overhead introduced by encapsulation in R-LFA and the use of segment routing in TI-LFA can be exploited by attackers to exhaust network resources, such as CPU and memory, on routers.

6. Trust Model

* Trust in Routing Infrastructure:

  - The security of LFA, R-LFA, and TI-LFA mechanisms relies heavily on the trustworthiness of the underlying routing infrastructure. If the control plane is compromised (e.g., through route poisoning), the alternate paths selected by these mechanisms could lead to traffic being routed through untrusted or compromised parts of the network.

7. Securing the Routing Protocols

* Use of Secure Routing Protocols:

  - 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, or ISIS HMAC-SHA256 ) that provide authentication and integrity protection for routing updates.

8. Monitoring and Detection

* Anomaly Detection:

  - Implementing monitoring and anomaly detection mechanisms can help identify when traffic is being rerouted in unexpected ways, which could indicate a security issue with LFA, R-LFA, or TI-LFA mechanisms.



"