[pim] Ketan Talaulikar's No Objection on draft-ietf-pim-mofrr-tilfa-12: (with COMMENT)

[Ketan Talaulikar via Datatracker <[e-mail]>]

Ketan Talaulikar has entered the following ballot position for
draft-ietf-pim-mofrr-tilfa-12: 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:
----------------------------------------------------------------------

Please find below some comments inline in the idnits output of the v12 of the draft:

General Comment: I found it odd that this document that is titled TI-LFA has text
and description for a solution for rLFA. TI-LFA subsumes rLFA in a manner of
speaking and the document would not have lost anything if instead of rLFA it had
used the same example to illustrate a TI-LFA repair path with a single PQ node
using the RFP Vector Attribute and then gone on to solve the more complex TI-LFA
repair path using a mix of RPF Vector and Explicit RFP Vector attributes. I will
leave this to the authors and the WG given the time that this document has spent
going back/forth.


94	   This document introduces a new mechanism for MoFRR using Topology
95	   Independent Loop-Free Alternate (TI-LFA)
96	   [I-D.ietf-rtgwg-segment-routing-ti-lfa] fast reroute.  Unlike
97	   conventional methods, TI-LFA is independent of network topology,
98	   enabling broader coverage across diverse network environments.  The
99	   applicability of this mechanism extends to PIM networks, such as
100	   scenarios where PIM operates over native IP.

<major> TI-LFA works only in SR networks. The solution specificies a solution
for PIM over native IP, however, this works only in an SR network. This
applicablity part is not stated very clearly. This should also result in the
references to the SR RFCs becoming normative reference (based on the solution
using the SR information from the IGP LSDB).


119	   The approach does not alter the existing management and operation of
120	   LFA, RLFA, and TI-LFA [RFC7916] [RFC8102]
121	   [I-D.ietf-rtgwg-segment-routing-ti-lfa].  Also, this approach is not
122	   affected by micro-loops [RFC5715] occurring during the network re-
123	   converges.

<major> Please check
https://www.ietf.org/archive/id/draft-ietf-rtgwg-segment-routing-ti-lfa-21.html#section-2
regarding micro-loops. Would you still like to claim that this solution is not
affected at all by micro-loops?


125	   Note that this document introduces an optional approach for backup
126	   join paths, designed to enhance the protection scope of existing
127	   multicast systems.  It is fully compatible with current protocol
128	   implementations and does not necessitate any changes to the protocols
129	   or forwarding functions on intermediate nodes.  If there is a choice

<minor> The solution requires support specific PIM protocol extensions and
support for RFC5496 and RFC7891 to be support pretty much across all routers
in the IGP area/level where this solution is to be deployed. This is not
specifically listed in an applicability section (ideally) or at least
covered in the text above.


178	                 10           20
179	            [S1]----(R1)-------------(R4)
180	                     |                |
181	                     |                |
182	                     |10              |10
183	                 10  |                |
184	            [S2]----(R2)-------------(R3)----[R]
185	                     |        10      |   10
186	                     |                |
187	                     |10              |10
188	                 10  |                |
189	            [S3]----(R5)-----(R6)----(R7)
190	                            100      10

<nit> Please update the ASCII art to place the metric values 100 and 10 in the
center of the R5-R6 and R6-R7 links respectively.

192	                     Figure 1: Example Network Topology


194	2.2.  RLFA for MoFRR

196	   The Remote Loop-Free Alternate (RLFA), as defined in [RFC7490],
197	   extends the LFA mechanism, to accommodate a broader range of network
198	   deployments by utilizing a tunnel as an alternate path.  The RLFA
199	   requires that there exists at least one node, denoted as node N, in
200	   the network where the fault node is neither on the path from the
201	   source node to node N nor on the path from node N to the destination
202	   node.  The source node and the destination node are the tunnel
203	   endpoints of the RLFA repair path.

<minor> Isn't is better to direct the reader to the RLFA RFC than trying to
oversimply with a couple of sentences?


326	4.  Illustration

<major-editorial> Any reason why the same topology in Figure 1 with the source
as S3 is not being used as an illustration instead of a new one? Seems very
odd to me when there is a TI-LFA solution for that. Instead, the document
introduces an entirely new topology for TI-LFA.

328	   This section provides an illustration of MoFRR based on TI-LFA.  The
329	   example topology is depicted in Figure 2.  The metric for the R3-R4
330	   link is 100, while the metrics for the other links are 10.  All link
331	   metrics are bidirectional.


470	5.  Join Conflict Considerations

472	   This section illustrates the resolution of PIM Join conflicts.  When
473	   intermediate nodes must choose between PIM Join messages with an RPF

<major> I believe this is already covered/specified in RFC7891. A reference to
the specific section and some text saying ... this is nothing new ... would be
helpful.