Multicast-only Fast Reroute Based on Topology Independent Loop-free Alternate (TI-LFA) Fast Reroute
draft-ietf-pim-mofrr-tilfa-14

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.

Thanks to the authors for addressing all of my comments.

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

Thank you for addressing all my previous comments [1] and also some remaining comments from Jürgen's opsdir review.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/pim/acks1tazEShLwMB0tzQOZ6WdlNY/

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.