[RTG-DIR]RE: RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05
Yisong Liu <liuyisong@chinamobile.com> Wed, 18 September 2024 07:19 UTC
Return-Path: <liuyisong@chinamobile.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3152BC14F71D; Wed, 18 Sep 2024 00:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.053
X-Spam-Level:
X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HDRS_MISSP=1.85, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBELwlN_gSzb; Wed, 18 Sep 2024 00:19:00 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta6.chinamobile.com [111.22.67.139]) by ietfa.amsl.com (Postfix) with ESMTP id DFB65C14F5FC; Wed, 18 Sep 2024 00:18:58 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app01-12001 (RichMail) with SMTP id 2ee166ea7ee1f9e-208a0; Wed, 18 Sep 2024 15:18:57 +0800 (CST)
X-RM-TRANSID: 2ee166ea7ee1f9e-208a0
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-PC (unknown[10.2.51.74]) by rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id 2ee266ea7edc7c3-60417; Wed, 18 Sep 2024 15:18:57 +0800 (CST)
X-RM-TRANSID: 2ee266ea7edc7c3-60417
MIME-Version: 1.0
x-PcFlag: b13b5a4a-87b7-43f4-87bc-c996428d2e65_5_184204
X-Mailer: PC_RICHMAIL 2.9.57
Date: Wed, 18 Sep 2024 15:18:52 +0800
From: Yisong Liu <liuyisong@chinamobile.com>
To: Susan Hares <shares@ndzh.com>, "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>, draft-ietf-pim-mofrr-tilfa <draft-ietf-pim-mofrr-tilfa@ietf.org>
Message-ID: <202409181518524577781@chinamobile.com>
Content-Type: multipart/Alternative; boundary="----=_001_NextPart4577781_=----"
Message-ID-Hash: HSKA5Q6REJFSXBJFQEL64EVXYVMDVFQS
X-Message-ID-Hash: HSKA5Q6REJFSXBJFQEL64EVXYVMDVFQS
X-MailFrom: liuyisong@chinamobile.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: pim <pim@ietf.org>, rtg-dir <rtg-dir@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [RTG-DIR]RE: RE: Rtgdir last call review of draft-ietf-pim-mofrr-tilfa-05
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/cqUAVIZ5uUARFm0hHsge27ZIEfA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>
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) <gunter.van_de_velde@nokia.com> Sent: Tuesday, September 17, 2024 3:11 AM To: draft-ietf-pim-mofrr-tilfa <draft-ietf-pim-mofrr-tilfa@ietf.org> Cc: pim@ietf.org; rtg-dir@ietf.org; Susan Hares <shares@ndzh.com> 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 <noreply@ietf.org> Sent: Tuesday, September 17, 2024 1:30 AM To: rtg-dir@ietf.org Cc: draft-ietf-pim-mofrr-tilfa.all@ietf.org; last-call@ietf.org; pim@ietf.org 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.