[RTG-DIR]Re: RE： RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05

[Susan Hares <[e-mail]>]

Yisong:

Your document indicated these facts (see my report) you indicated in your reply.

However, my question is very basic.  What is your assumption on the assignment and distribution of SIDs?  Are you distributing the SIDS via IGP or BGP?  If BGP, are you using BGP-LS or SR extensions? If you are using IGP only, are these SIDS being reported via BGP-LS or transported via I-BGP to other segments.

The document is unclear about these facts.  The document (and therefore my evaluation) needs to consider how the SIDs are assigned and distributed.

Sue

From: Yisong Liu <[e-mail]>
Sent: Wednesday, September 18, 2024 3:19 AM
To: Susan Hares <[e-mail]>; Gunter van de Velde (Nokia) <[e-mail]>; draft-ietf-pim-mofrr-tilfa <[e-mail]>
Cc: pim <[e-mail]>; rtg-dir <[e-mail]>
Subject: RE： RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05

Hi Sue, Thank you for your comments. I will try to explain for this document and we will update a new version to add some clarification. This document provides a solution of optimization for PIM MoFRR
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzg4YjNlNTcxZWEwMzc1MDgyMzM4YTllYTA5OTRhZTZiLzE3MjY2NDM5NDUuMg==#key=5cac94840eae78506e979e5caaf6c61a>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Hi Sue,

Thank you for your comments. I will try to explain for this document and we will update a new version to add some clarification.
This document  provides a solution of optimization for PIM MoFRR, which relies on TILFA,  and still need to use the PIM join to establish multicast trees hop by hop, but not  with SIDs.
PIM uses the backup path provided by TILFA as a secondary upstream multicast hop (UMH) for hop by hop for sending PIM secondary join.  In other words, the node SIDs and adjacency SIDs of the TILFA SR path can only be used to provide  secondary upstream nodes and upstream neighbors for PIM join packets sending, but not be used to establish multicast trees or forward multicast traffic.
The original MoFRR based on LFA  per RFC7431 only looks at IGP, and this document will not extend the scope and only add a method for secondary UMH selection based on TILFA.

If you have any further comments, please let us know.

Best Regards
Yisong

发件人: Susan Hares<mailto:[e-mail]>
时间: 2024/09/17(星期二)20:51
收件人: Gunter van de Velde (Nokia)<mailto:[e-mail]>;draft-ietf-pim-mofrr-tilfa<mailto:[e-mail]>;
抄送人: pim<mailto:[e-mail]>;rtg-dir<mailto:[e-mail]>;
主题: RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05
Gunter and Authors:

If you will clarify the text, I will review this document again.

Cheers,

Sue

From: Gunter van de Velde (Nokia) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, September 17, 2024 3:11 AM
To: draft-ietf-pim-mofrr-tilfa <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Subject: RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05



Hi Folks,



Please look this observation from Sue. The document should clarify and update scope and potentially technical procedures especially about:



* Are you looking at IGP's only?  If so, what are the restrictions on SIDs?

* If you are looking at Tunnels that use BGP Tunnel Encapsulation to pass SIDs and candidate routes, what is the link here



When looking at TILFA (https://datatracker.ietf.org/doc/draft-ietf-rtgwg-segment-routing-ti-lfa/<https://shared.outlook.inky.com/link?domain=datatracker.ietf.org&t=h.eJxdjMsOgyAQRX-lYV1ExQe48ldGGZGo0MCYpm3675Vtl_fk3PNhZ9zZcGMr0SMNQhggoAjzhrFwSEsRohUmzMJEWIhnxCPZp-UJ7YGeeAwnOW85Ob4vINj9xrZc9EjXtypb1emqFmmFiGn05r0WcziEUpPEtq8QStm3paqlVKCvpXUD2E2i6uuua6Ru2qLOUczR3Z0vl4K347w6D0eY3I65lw2TjX_-_QFjc0i2.MEYCIQDo395Fj_BtcjqXCgizlafASnST8SuGdpdE0fQwNcVg3AIhAJIS-FTsjJFRotAAwqV0_U04QE4h8ktrJhqGZZDSqh4M>) the draft explicitly mentions Link-state IGP scope:



" This Fast

   Reroute (FRR) behavior builds on proven IP Fast Reroute concepts

   being LFAs, remote LFAs (RLFA), and remote LFAs with directed

   forwarding (DLFA).  ***It extends these concepts to provide guaranteed

   coverage in any two-connected networks using a link-state IGP.***

"



From editorial perspective, one additional observation when looking at section 1. At first instance of mentioning TI-LFA the reference to relevant draft is not inserted:



OLD:

   This document introduces a new mechanism for Multicast-only Fast

   Reroute using Topology Independent Loop-Free Alternate (TI-LFA) fast

   reroute. Unlike traditional methods, TI-LFA is independent of



NEW:

   This document introduces a new mechanism for Multicast-only Fast

   Reroute using Topology Independent Loop-Free Alternate (TI-LFA)

   [ietf-rtgwg-segment-routing-ti-lfa] fast reroute. Unlike traditional

   methods, TI-LFA is independent of



Kind Regards,

G/



-----Original Message-----

From: Susan Hares via Datatracker <[e-mail]<mailto:[e-mail]>>

Sent: Tuesday, September 17, 2024 1:30 AM

To: [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Subject: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05





CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext<https://shared.outlook.inky.com/link?domain=nok.it&t=h.eJxdjMsOgyAUBX_FsG5A3uDKX0G9ESJCA5j0kf57y7bLM2cyb3SViKYB-dbuEyEpHzg0Ao-GbgM6-pOg5bLTURplKSPVuwJ1TtvL4zWfxJiFg9QU3Mi1HA3j3Dj7W9YKB2ohVDOlBLdCYtaj0KMxXM9Qc9rn1YfkzryECL3Xja0b__zzBRFqM4Q.MEQCIFNpAtvEMqF9enUIHmC5tDqxy-IqnvgGoiFDshc2C_PXAiARRAc59Xm3ckiysvlkHYxvOLlDUtHfGc1crl4VlSXrcw> for additional information.







Reviewer: Susan Hares

Review result: Has Issues



This is a Routing Directorate Review.

It should be treated as any other WG LC.



Summary: This is an informational draft suggesting an TI-LFA for MoFRR.



Section 1 states that this document considers:

a) PIM over Native IP

2) MDT SAFI multicast VPN [RFC6037] and [RFC6514] - covering PIM-SSM, PIM-SM Tree, and BIDR TREe.



My concern is this draft does not consider the Segment List work in inter-domain cases for P2MP situations.



The text references Segment IDs and Segment lists and tunnels without giving enough detail to determine if the proposals in the draft-ietf-idr-sr-p2mp-policy might solve the case in a clear way.



I am filing this immediate report to ask the authors and AD charge what the exact scope of this document.



Are you looking at IGP's only?  If so, what are the restrictions on SIDs?

If you are looking at Tunnels that use BGP Tunnel Encapsulation to pass SIDs and candidate routes, what is the link here.



I will re-review if I can determine the context.

I apologize, but the basic interaction with SIDs are unclear.