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

[Ketan Talaulikar <[e-mail]>]

Hi Changwang,

Please find inline below my responses. I've skipped responses on those that
are addressed based on your updates/responses.

I see one challenge in proceeding with this document in its current form (I
had not picked it up clearly but your response to my comment does clarify).
Please see my response to the last comment below.


On Mon, Apr 7, 2025 at 10:19 PM linchangwang <[e-mail]>
wrote:

> Hi Ketan,
>
> Thank you for your review.
> We appreciate your thoughtful comments and suggestions.
>
> I submitted version-13 to address the following comments:
>
> Link:   https://datatracker.ietf.org/doc/draft-ietf-pim-mofrr-tilfa/13/
>
> Please see inline...
>
> Thanks,
> Changwang
>
> -----邮件原件-----
> 发件人: Ketan Talaulikar via Datatracker <[e-mail]>
> 发送时间: 2025年4月2日 20:54
> 收件人: The IESG <[e-mail]>
> 抄送: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 主题: Ketan Talaulikar's No Objection on draft-ietf-pim-mofrr-tilfa-12:
> (with COMMENT)
>
> 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.
>

KT> Any response to this one? Why would the rLFA (single PQ node) scenario
not be covered by TI-LFA. If the point is that the draft is also trying to
cover non-SR networks (where TI-LFA is not available), but there is say LDP
and so the rLFA can be used by multicast, then it is not coming out clearly.


>
>
> 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).
>
> [Changwang]: Version-13 adds the description of SR Network.
>
>
> 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?
> [Changwang]: Version-13 changed the description, this document does not
> address the PIM micro-loop issue.
>
>
> 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.
> [Changwang]: Version-13 adds a description stating that support for
> RFC5496 and RFC7891 is required on the backup path.
>
>
> 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
>
> [Changwang]: Version-13 has been modified.
>
> 1942.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?
>
> [Changwang]: Version-13 removed the redundant description.
>
>
> 3264.  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.
>
> [Changwang]: Let's discuss. Figure 1 is used to illustrate three
> protection methods.
>  When describing TI-LFA specifically, Figure 1 is simplified, and Figure 2
> is used for a detailed solution description.
>  Should we maintain the current writing style?
>

KT> This is an editorial comment. While I would have preferred to keep the
same figure/example through the document to make it easier for the reader
to understand the benefit of TI-LFA use by MoFRR, I will leave it to the
authors.


>
> 4705.  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.
> [Changwang]: Section 7 of RFC 7891 does not mention this situation, so it
> was added in the earlier WG discussion.
>

KT> I see your point now. Neither RFC7891 nor RFC5496 say "When
intermediate nodes must choose between PIM Join messages with an RPF Vector
attribute and those without, priority should be given to the Join messages
without the RPF Vector attribute." This is an update of the
behavior/specifications on both of those Standards track documents and
therefore cannot be done through this informational document. I would
suggest to take out this entire section from this document so it can move
forward and the WG can take care of this behavior change via a document
that "updates" those RFCs OR via a bis on those RFCs - choice is left to
the WG.

Thanks,
Ketan


>
>
>
> -------------------------------------------------------------------------------------------------------------------------------------
> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> 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!
>