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

[Ketan Talaulikar <[e-mail]>]

Hi Changwang,

Thanks for your quick response and the document updates. This is now good
to go for publication from my perspective.

For the part that was taken out, I hope the WG can take an "expedited"
process to progress that work quicker (assuming there is WG consensus on
this normative change).

Thanks,
Ketan


On Tue, Apr 8, 2025 at 7:47 PM linchangwang <[e-mail]>
wrote:

> Hi Ketan,
>
> I submitted version-14 to address the following comments:
>
> Link: https://datatracker.ietf.org/doc/draft-ietf-pim-mofrr-tilfa/14/
>
> Please see inline...
>
> Thanks,
> Changwang
>
>
> -----邮件原件-----
> 发件人: Ketan Talaulikar <[e-mail]>
> 发送时间: 2025年4月8日 13:07
> 收件人: linchangwang (RD) <[e-mail]>
> 抄送: The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> 主题: Re: Ketan Talaulikar's No Objection on draft-ietf-pim-mofrr-tilfa-12:
> (with COMMENT)
>
> 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.
>
> [Changwang-2]: Version-14 has been modified. The rLFA chapter has been
> removed, and the scope of this document is SR networks.
> Additionally, in the TI-LFA solution, I have added an explanation for a
> single PQ node as per your suggestion. Thanks.
>
> >
> >
> > 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.
>
> [Changwang-2]: Thanks.
>
>
> >
> > 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.
>
> [Changwang-2]: Version-14 has removed this chapter. We will discuss its
> handling on the WG as per your suggestion. Thank you.
>
> 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!
>