[pim] Mohamed Boucadair's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)
Mohamed Boucadair via Datatracker <noreply@ietf.org> Fri, 12 June 2026 08:54 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: pim@ietf.org
Delivered-To: pim@mail2.ietf.org
Received: from [10.244.21.151] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id EAFD1FFED6DA; Fri, 12 Jun 2026 01:54:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781254490; bh=sAVKugP+dv/UPtNT5VMJnw8ow8opfQhniW/NzuCKABM=; h=From:To:Cc:Subject:Reply-To:Date; b=r5IAWz+NBFRqjYsPbQhukjTMzQBAns89OTfKjY8b1P4AEQAeuWw7CWgzVDrW3Xjo9 Cgq/h/ZTIF296KNFbUORDuWUDdd5uqysietZR8tl5uTWAMki9ADJ+D+OUkaWrVsG5s 83xiS/T/AbTlS8Gf/jgB6JBbIkpjP3Q3xQTDGsX0=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mohamed Boucadair via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <178125448988.584.6888478959480090207@dt-datatracker-f9b87776f-8pmmg>
Date: Fri, 12 Jun 2026 01:54:49 -0700
Message-ID-Hash: HTR5JN37FEHNTIOGFFXP4YUPLMEAQBPO
X-Message-ID-Hash: HTR5JN37FEHNTIOGFFXP4YUPLMEAQBPO
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-pim-pfm-forwarding-enhancements@ietf.org, mmcbride7@gmail.com, pim-chairs@ietf.org, pim@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Mohamed Boucadair <mohamed.boucadair@orange.com>
Subject: [pim] Mohamed Boucadair's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Nn7aPkBjQEzYQSsEYWdHcePp8z4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>
Mohamed Boucadair has entered the following ballot position for draft-ietf-pim-pfm-forwarding-enhancements-05: Discuss 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-pfm-forwarding-enhancements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Ananya, Stig, and Francesco, Thank you for the effort put into this specification. Please find below some comments for DISCUSSion: # Conflict with RFC8364 CURRENT: All PIM neighbors then process this PFM message and flood it further on their PIM-enabled links. I read this as that flooding is by default, while it seems to me this conflicts with the provisions in 8364 about boundaries, forwarding bit, etc. I found RFC8364 to be more rigorous. # Backward compatibility CURRENT: All PIM routers MUST track which neighbors advertise support for the GSI TLV via the Hello option Section 2.2. Are we sure that we want to impose this on any PIM router? As I’m there, s/ Hello option Section 2.2/ Hello option (Section 2.2) # Operational matters CURRENT: If GSI TLV is supported, use of the GSI TLV (Type TBD1) is RECOMMENDED. ## I don’t think that it is a great design that the use of a feature like this one is not controlled by ac configuration know + explicit activation by operators. ## Rather than recommending use of an experimental feature, I’d recommend you elaborate (in an Operational Considerations, typically) conditions under which this is operationally justified. # Inconsistency How to reconcile the MUST in the preamble with the SHOULD/MAYs in the bullet? CURRENT: A router that supports the GSI TLV MUST: * Advertise its capability by including the Hello option (OptionType TBD2) in PIM Hello messages. * Track, per PIM interface, whether all neighbors support the GSI TLV. The scope and persistence of this state are implementation- specific. An implementation MAY retain this state even if local capability is disabled. * If acting as a First Hop Router (FHR), originate a Type TBD1 TLV when all neighbors on the outgoing interface support Type TBD1. * If acting as an FHR, originate a Type 1 TLV [RFC8364] when any neighbor on the outgoing interface does not support Type TBD1. * Upon receipt of a Type TBD1 TLV, MUST forward the PFM message unchanged on interfaces where all neighbors support Type TBD1. * For interfaces with at least one neighbor that does not support Type TBD1, convert each Type TBD1 TLV to a Type 1 TLV [RFC8364] and forward only on those interfaces. The conversion MUST preserve the group, source, and holdtime fields, and MUST ignore Sub-TLVs. Multiple (S,G) entries for the same group SHOULD be aggregated into a single Type 1 TLV. However, it MUST still send Type TBD1 TLV on all interfaces where the neighbors do support it. * A PFM message MAY contain both Type 1 and Type TBD1 TLVs. When forwarding to neighbors that do not support Type TBD1, all Type TBD1 TLVs MUST be converted to Type 1 TLVs. # Why a router has to announce the capability even if the feature is explicitly disabled by an operator? CURRENT: A router that supports the GSI TLV MUST: * Advertise its capability by including the Hello option (OptionType TBD2) in PIM Hello messages. # GSH/GSI Conflict Unless I misunderstood the procedures, it is allowed to have both GSH and GSI covering both (S,G) in the same message. Mis-configuration (including stale info) may happen. Which information takes precedence in such case? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Normative language for examples CURRENT: Referring to Figure 1, when Router A originates or forwards a PFM message, it MUST transmit the message on exactly one of links L1, L2, or L3. This behavior reduces processing overhead on point-to-point links. The selection of the interface from the PFM_OPT_IF set is implementation-specific. Router A also MUST send the message on both LAN 1 and LAN 2 to ensure Routers C and D receive the message. I don’t think that it is appropriate to use normative language with examples to illustrate the intended behavior. Cheers, Med
- [pim] Mohamed Boucadair's Discuss on draft-ietf-p… Mohamed Boucadair via Datatracker
- [pim] Re: Mohamed Boucadair's Discuss on draft-ie… Ananya Gopal (ananygop)
- [pim] Re: Mohamed Boucadair's Discuss on draft-ie… mohamed.boucadair
- [pim] Re: Mohamed Boucadair's Discuss on draft-ie… Ananya Gopal (ananygop)
- [pim] Re: Mohamed Boucadair's Discuss on draft-ie… mohamed.boucadair
- [pim] Re: Mohamed Boucadair's Discuss on draft-ie… Ananya Gopal (ananygop)