Skip to main content

Early Review of draft-ietf-mboned-redundant-ingress-failover-07
review-ietf-mboned-redundant-ingress-failover-07-rtgdir-early-qu-2025-08-08-00

Request Review of draft-ietf-mboned-redundant-ingress-failover
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2025-08-06
Requested 2025-06-09
Requested by Lenny Giuliano
Authors Greg Shepherd , Zheng Zhang , Yisong Liu , Ying Cheng , Gyan Mishra
I-D last updated 2026-04-26 (Latest revision 2026-04-26)
Completed reviews Opsdir Early review of -06 by Tony Li (diff)
Rtgdir Early review of -07 by Yingzhen Qu (diff)
Assignment Reviewer Yingzhen Qu
State Completed
Request Early review on draft-ietf-mboned-redundant-ingress-failover by Routing Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/rtg-dir/l0iTFKYY-BOjkMmwbaHjwUJVdcQ
Reviewed revision 07 (document currently at 10)
Result Not ready
Completed 2025-08-08
review-ietf-mboned-redundant-ingress-failover-07-rtgdir-early-qu-2025-08-08-00
Hello

I have been selected to do a routing directorate “early” review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-mboned-redundant-ingress-failover/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-mboned-redundant-ingress-failover-07
Reviewer: Yingzhen Qu
Review Date: 06-August-2025
Intended Status: Informational

Summary:
This document analyzes the redundant ingress-router failover problem within a
multicast domain.

Comments:
The draft needs some editorial work.

Take the abstract as an example. The current one doesn't read one, please
consider the following suggestion: This document analyzes the problem of
failover between redundant ingress routers in multicast domains. It describes
cold, warm, and hot standby modes, detailing their advantages, limitations, and
deployment considerations to help operators select appropriate mechanisms.

Some sentences are too long and hard to read, for example:
"
The redundant ingress routers may be deployed to forward the same multicast
flow with only one router active at a time while the others act as backups. "

Terminology:
121      IR: The ingress router for multicast flows in a multicast domain.
Instead of "The ingress router", I think this should be "An ingress router",
considering there might be multiple ingress routers.

123      ER: The egress router for multicast flows in a multicast domain.
should be "An egress router".

125      SIR: The IR responsible for sending the multicast flow, or the IR
126      whose flow is received by the ER, is called Selected-IR, or SIR for
127      short.
Can you pleas clarify that instead of "or the IR whose flow is received by the
ER", should this be "and ...." Suggested text: The IR that actively sends the
multicast flow, whose traffic is received by the egress router, is referred as
the Selected-IR, or SIR for short.

"failover" and "switchover " seems to be interchangeable, please clarify.

For the different backup modes:
Cold Standby section could mention implications for control-plane churn (e.g.,
slow convergence due to PIM Join/Prune updates). Warm Standby could elaborate
on synchronization mechanisms between routers (state sync, sequence numbers, or
shared RPF logic). Hot Standby: The trade-off between duplicate traffic and
fast failover is good, but might benefit from a clear reference to seamless
protection mechanisms like BFD-assisted PIM or BI-DIR multicast. Adding some
examples may help.

A session about deployment consideration will be helpful. Especially for
multi-domain scenarios, how this failover will behave across AS boundaries?

Section 3.2, about the failure detection, more details and comparisons should
should be provided.

The table in section 4.4 can add more content about comparisons of different
failover modes, such as failover time, control plane load, typical use cases
etc.