Early Review of draft-ietf-mboned-redundant-ingress-failover-06
review-ietf-mboned-redundant-ingress-failover-06-opsdir-early-li-2025-06-23-00

OPSDIR Early Review of draft-ietf-mboned-redundant-ingress-failover-06

Reviewer: Tony Li
Status: Serious issues

Overall: This document needs a full rewrite.

Disclaimer: Please note that this document is well outside of my
comfort zone. While I am multicast-adjacent, I am far from well-versed
on this topic.  You get what you pay for.

Editorial: This document is in serious need of editorial assistance
and is far outside of what I am prepared to provide. The authors
should consult a professional copy editor. This is NOT optional. IMHO,
without this, the document should not proceed as it's almost
incomprehensible.

Details:

Section 1:

I must be missing some motivation for this document. It's not
specifying anything, it's merely a cross-mechanism discussion of how
failover works. That turns into more of a survey article than new
technology.  So why is this document needed?

Network architects would have already selected their multicast
architecture and, in doing so, would have an understanding of how
failover would work already.  Who is the audience and how does this
serve them?

Section 2:

I question the definition of IR and ER. You use the term 'closest',
but I doubt that's what you really mean. Using that term implies there
is some metric of distance (e.g., Eucliean physical separation) which
is not at all what you want.  I think you want to define things in
terms of where the mcast flow enters and exits the network.

Your definition of IR implies that it is singular. Unique to a
particular source (or flow?).  How then can the SIR or BIR exist?

Section 3.1:

Please enumerate the initial conditions of this example before
explaining how failure over is going to happen.

Section 3.2:

Paragraph 4: There are a bunch of claims here that are not backed up
by discussion, explanation, or reference. They are not convincing.

Paragraph 6: This is incomprehensible.

Section 4:

These discussion are good, but would benefit from a more complete
elaboration and discussion. For example, you mention that failure
detection is a challenge. Why? You're not proposing solutions, so how
should this work?