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

[Yisong Liu <[e-mail]>]

Hi Sue,




I will try to explain again.  There is no assignment or distribution of SIDs in this document.  This docoment provides a option that PIM can establish a secondary multicast tree hop by hop to protect the primary multicast tree based on TILFA in SR networks. In this scenario, SR MPLS or SRv6 is used for unicast and PIM is used for multicast. Because the TILFA  mechanism is often used for unicast local protection and TILFA repair path need SR-based path,  PIM can use the existing TILFA repair path for secondary UMH selection and send join hop by hop to establish the secondary multicast tree. 

In this process, PIM only used the TILFA calculation results for secondary UMH selection. If unicast does not use SR or TILFA, PIM does not have a mechanism to trigger the generation of TILFA repair paths, so it does not involve the assignment and distribution of SIDs in this document.




Based on the above explanation, we have updated a new version of this document in the attatched files, please check them. 








Best Regards

Yisong








 



发件人: Susan Hares

时间: 2024/09/18(星期三)21:07

收件人: Yisong Liu;Gunter van de Velde (Nokia);draft-ietf-pim-mofrr-tilfa;

抄送人: pim;rtg-dir;

主题:  RE: RE： RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05       

 

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, 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  

 

时间: 2024/09/17(星期二)20:51  

 

收件人: Gunter van de Velde (Nokia);draft-ietf-pim-mofrr-tilfa;  

 

抄送人: pim;rtg-dir;  

 

主题: 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]> 
 Sent: Tuesday, September 17, 2024 3:11 AM
 To: draft-ietf-pim-mofrr-tilfa <[e-mail]>
 Cc: [e-mail];  [e-mail]; Susan Hares <[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/)  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]>  

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

To: [e-mail] 

Cc:  [e-mail];  [e-mail]; [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 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.