[pim] Re: Mohamed Boucadair's No Objection on draft-ietf-pim-mofrr-tilfa-09: (with COMMENT)

[linchangwang <[e-mail]>]

Hi Med,

Thank you for your review.
We appreciate your thoughtful comments and suggestions.

All your comments have been addressed in latest version.
https://datatracker.ietf.org/doc/draft-ietf-pim-mofrr-tilfa/10/

Pls check and let us know if there are any further comments.


Thanks,
Changwang



-----邮件原件-----
发件人: Mohamed Boucadair via Datatracker <[e-mail]>
发送时间: 2025年3月24日 21:30
收件人: The IESG <[e-mail]>
抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
主题: Mohamed Boucadair's No Objection on draft-ietf-pim-mofrr-tilfa-09: (with COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-pim-mofrr-tilfa-09: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pim-mofrr-tilfa/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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



-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, which is
intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender
by phone or email immediately and delete it!