MoFRR Path Liveness for Network Failures
draft-mankamana-pim-mofrr-failure-detection-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Mankamana Prasad Mishra | ||
| Last updated | 2026-07-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mankamana-pim-mofrr-failure-detection-00
PIM Working Group M. Mishra
Internet-Draft Cisco Systems
Intended status: Informational 20 July 2026
Expires: 21 January 2027
MoFRR Path Liveness for Network Failures
draft-mankamana-pim-mofrr-failure-detection-00
Abstract
This document discusses an operational gap in Multicast-Only Fast
Reroute when failures occur inside an upstream multicast path but do
not cause a visible RIB or RPF change at the merge point. The
document motivates the need for a scalable path-liveness mechanism
that can detect such hidden multicast delivery failures without
requiring expensive per-flow packet monitoring.
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 21 January 2027.
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.
Mishra Expires 21 January 2027 [Page 1]
Internet-Draft MoFRR Path Liveness July 2026
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
6. Path Liveness Signaling . . . . . . . . . . . . . . . . . . . 4
7. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
8. Relationship to RFC7431 . . . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 5
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
13. Informative References . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Problem Statement
[RFC7431] describes Multicast-Only Fast Reroute (MoFRR). In MoFRR, a
merge point joins a multicast tree through both a primary Upstream
Multicast Hop (UMH) and a secondary UMH. Multicast packets may be
received on both paths, but the merge point accepts and forwards
traffic from only one active RPF path. When failure is detected on
the primary path, local repair is performed by switching packet
acceptance to the secondary path.
One common operational model is RIB-based MoFRR, where the merge
point uses changes in source reachability, route state, or RPF
information to determine that the primary path should no longer be
used. This model can provide fast repair when the failure changes
the merge point's route or RPF selection. However, it does not
detect all multicast delivery failures. In particular, a failure can
occur inside the upstream primary multicast path while the merge
point's RIB continues to show the same primary next hop toward the
source.
Mishra Expires 21 January 2027 [Page 2]
Internet-Draft MoFRR Path Liveness July 2026
Source / FHR
S
|
FHR
/ \
primary / \ secondary
/ \
P4 B4
/ \ / \
/ \ / \
P2 P3 B2 B3
\ / \ /
\ / \ /
P1 B1
\ /
\ /
\ /
LHR
|
Receiver
Primary RPF at LHR: toward P1
Secondary RPF at LHR: toward B1
Example hidden failure:
link P2--P4 fails, or node P2 fails.
Figure 1: Failure Hidden from RIB-Based MoFRR at the LHR
Figure 1 illustrates the problem. The last-hop router (LHR), acting
as the MoFRR merge point, has two upstream multicast paths toward the
source or first-hop router (FHR). The LHR joins both paths and
selects the path through P1 as primary and the path through B1 as
secondary. The primary and secondary paths are both internally
redundant, forming diamond-shaped topologies above the LHR.
If the LHR-facing primary link or the primary next hop P1 fails, the
failure is visible to the LHR and RIB-based MoFRR can react.
However, if an internal link or node in the primary diamond fails,
such as the P2--P4 link or node P2, the multicast packets on the
primary branch may stop reaching the LHR even though the LHR still
has the same RIB route and the same primary RPF next hop toward the
source. From the LHR's RIB perspective, source reachability has not
changed. Therefore, a RIB-based trigger may not switch packet
acceptance from the primary RPF path to the already-joined secondary
RPF path.
Mishra Expires 21 January 2027 [Page 3]
Internet-Draft MoFRR Path Liveness July 2026
In this condition, the secondary path may still be receiving valid
multicast packets, but those packets are discarded because the LHR
has not changed its active RPF path. The result is multicast traffic
loss despite the existence of a working secondary MoFRR path. The
underlying issue is that RIB-based liveness does not always imply
multicast data-plane liveness for the selected primary path.
Flow-based MoFRR can address this class of failure by monitoring
packet arrival for each multicast flow and switching to the secondary
path if packets are not received on the primary path within a
configured time interval. This can detect hidden primary-path
delivery failures, but it requires per-flow packet tracking in the
forwarding hardware or fast path. In large IPTV or multicast
deployments with many active (S,G) flows, maintaining timers and
packet-arrival state for each flow can be expensive and may not scale
well.
There is therefore a need to explore a scalable mechanism for MoFRR
path liveness that can detect upstream multicast delivery failures
that are hidden from the merge point's RIB, while avoiding the
operational and hardware cost of continuous per-flow packet
monitoring. Such a mechanism would complement the MoFRR procedures
described in [RFC7431] by improving failure detection in topologies
where source reachability remains stable but multicast delivery on
the active primary path has failed.
2. Requirements Language
To be added.
3. Terminology
To be added.
4. Applicability
To be added.
5. Protocol Overview
To be added.
6. Path Liveness Signaling
To be added.
Mishra Expires 21 January 2027 [Page 4]
Internet-Draft MoFRR Path Liveness July 2026
7. Router Behavior
To be added.
8. Relationship to RFC7431
To be added.
9. Security Considerations
To be added.
10. IANA Considerations
To be added.
11. Open Issues
To be added.
12. Acknowledgements
To be added.
13. Informative References
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015,
<https://www.rfc-editor.org/info/rfc7431>.
Author's Address
Mankamana Mishra
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: mankamis@cisco.com
Mishra Expires 21 January 2027 [Page 5]