[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