Thank you for this document. I have no technical comments, and I found the document easy to digest and follow. However, I would like to question the structure of the document as it does not follow https://datatracker.ietf.org/doc/html/rfc7322#section-4.1.1 where the 'Abstract' should be before 'Status of this memo' and 'Copyright notice'. Please bring the Abstract to the front of the document.

Hi Yisong, Mike, Zheng, Jingrong, and Changwang,

Thank you for the effort put into this specification. 

Please find below some comments: 

# Abstract

CURRENT: 

   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. 

## On “protocol extensions”: Seems conflicting with the intended Info status and also the clarification note included in the intro and another section.

## On “operational considerations” or lack of

(1) Which part of the document are you referring to?  
(2) I was expecting to see at least RFC8102 referenced in the main body on the manageability aspects
(3) Also, is the approach immune against micro loops? If not a concern, can we explicit that in the doc?

# Introduction:

(1)

CURRENT:
   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 ...   

One would argue that the increase is related to unicast delivery, mainly. Deleting this sentence and starting with the sentence right after would be fine. No need to over motivate the need ;-)

(2) 

CURRENT:
   fast reroute defined in [RFC7431], has limitations in certain
   multicast deployment scenarios.

Can we call these limitations out or point to the section where this is discussed?

(3) 

CURRENT:
    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 Multicast Distribution Tree
   (MDT) SAFI for Multicast VPN (MVPN) in [RFC6037] and [RFC6514],..

* “public network multicast trees”: Do you mean inter-domain? If so, some discussion on the implications/deployment considerations are needed.
* “[RFC6037] and [RFC6514]”: Why is this cited? Why this specific flavor? What about RFC6513? If you maintain this mention, can we have an example to illustrate the use?

# Section 2.1

* “For multicast source S1, …”: The receiver should be mentioned also.
* Better to include the metrics directly in the graph as this eases following the example.
* Mention that all link metrics are bidirectional?

# Section 2.2

“is neither on the path from the source node to node N”: The source node should be clarified to avoid confusion with multicast source.

# Section 5

CURRENT:
   This document specifies an optional approach for backup join paths,
   intended to enhance the protection scope of existing multicast
   systems.  It is fully compatible with existing protocol
   implementations and does not require changes to protocols or
   forwarding functions on intermediate nodes.  In the event of PIM Join
   conflicts, Join messages without the RPF Vector attribute are prioritized to
   ensure that the original PIM forwarding functionality remains
   unaffected.

Already mentioned in the introduction. Any reason this text repeated? I would delete it.

# Full review

More comments, edits, nits, etc. can be found here: 

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-pim-mofrr-tilfa-09-rev%20Med.pdf 
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-pim-mofrr-tilfa-09-rev%20Med.doc

Thank you to Meral Shirazipour for the GENART.

Thank you for addressing my DISCUSS feedback.

Thanks for addressing my DISCUSS [*], I hope that all authors have agreed on the copyright change (I a trusting the responsible AD). Thanks also for addressing my comments kept below for archiving.

Regards

-éric

[*] https://mailarchive.ietf.org/arch/msg/pim/4-xtXMuxD8VO4dJKJLF8_XKEigg/


# COMMENTS (non-blocking)

## Section 1

It seems that draft-ietf-rtgwg-segment-routing-ti-lfa is about segment routing, is it also the case for this I-D ? If so (as indicated further in the text), suggest to add this to the abstract.

Should "MDT" be expanded ?

## Section 1.1

There is a single occurence of BCP14 terms (in the security section), consider removing this section.

## Section 2.1

`current MoFRR` won't age well once this I-D is published as an RFC; suggest using "RFC7381 MoFRR"

Cosmetic: the aasvg tool may render the figure 1 in a much nicer way.

I’m conflicted as to whether Informational is the right type for this document — it doesn’t change wire encodings, but it does change elements of procedure, albeit in backward-compatible ways. I grant it’s an arguable point though. Too bad the shepherd writeup fails to answer the question “Why is this the proper type of RFC?” 😢

Also, I was sad there was no HTML rendering available. If you’d be willing to share what motivated you to go to the extra work of uploading a non-XML source format, I’d be interested in knowing.

I support Roman's DISCUSS position.

In Security Considerations, there's this:

   The security
   considerations of LFA, R-LFA, and MoFRR described in [RFC5286],
   [RFC7490], and [RFC7431] SHOULD apply to this document.

How can you establish a normative interoperability requirement against a document?

For that matter, since this is Informational, why is BCP 14's inclusion appropriate?

I am supporting Roman's discuss.