[pim] Re: Mohamed Boucadair's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)

["Ananya Gopal (ananygop)" <[e-mail]>]

Hi Med,

I have addressed this concern in version 7. The updated figure in Section 2.1 now makes the field lengths clearer; please take a look.

 https://datatracker.ietf.org/doc/draft-ietf-pim-pfm-forwarding-enhancements/07/

Thanks,
Ananya


From: [e-mail] <[e-mail]>
Date: Thursday, June 18, 2026 at 1:07 AM
To: Ananya Gopal (ananygop) <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: Mohamed Boucadair's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)

Hi Ananya,

Thank you for the follow-up. The new version is really an enhancement. I will clear my DISCUSS right SOON.

There are some issues with the figure in 2.1 (type-dependent fields, Type Sub-TLV n layout). I suggest to consider the following changes:

OLD:
      …
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|         Type = TBD1         |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Group Address (Encoded-Group format)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Source Address (Encoded-Unicast format)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Holdtime           |        Type Sub-TLV 1         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length Sub-TLV 1        |       Value Sub-TLV 1         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                               .                               |
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      |                               .                               |
      |        Type Sub-TLV n         |       Length Sub-TLV n        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Value Sub-TLV n                                        |
      |                               .                               |
      |                               .                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     …
   Group Address:  The multicast group address encoded as specified in
      Section 4.9.1 of [RFC7761].  The length of this field depends on
      the address family: 64 bits for IPv4 native encoding, 160 bits for
      IPv6.  Figure represents the IPv4 native encoding format.

   Source Address:  The unicast source address encoded as specified in
      Section 4.9.1 of [RFC7761].  The length of this field depends on
      the address family: 48 bits for IPv4 native encoding, 160 bits for
      IPv6.  Figure represents the IPv4 native encoding format.

NEW:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|         Type = TBD1         |          Length               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~             Group Address (Encoded-Group format)              ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~             Source Address (Encoded-Unicast format)           ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Holdtime           |        Type Sub-TLV 1         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Length Sub-TLV 1        |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
      ~                         Value Sub-TLV 1                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                               …                               ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Type Sub-TLV n         |       Length Sub-TLV n        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                          Value Sub-TLV n                      ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      …
   Group Address:  The multicast group address encoded as specified in
      Section 4.9.1 of [RFC7761].  The length of this field depends on
      the address family: 64 bits for IPv4 native encoding, 160 bits for
      IPv6.

   Source Address:  The unicast source address encoded as specified in
      Section 4.9.1 of [RFC7761].  The length of this field depends on
      the address family: 48 bits for IPv4 native encoding, 160 bits for
      IPv6.

To avoid confusion, you may add a note saying that “~” is used for variable-length fields + there is not alignment requirements for these fields.

Cheers,
Med

De : Ananya Gopal (ananygop) <[e-mail]>
Envoyé : jeudi 18 juin 2026 01:03
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)

Hi Med,
Thank you for your detailed review and for the thoughtful comments.

On the RFC8364 consistency point, we have updated the introduction text to avoid implying unconditional flooding behavior and to make it explicit that forwarding is in accordance with RFC8364.

On the backward-compatibility wording, we have revised the scope of the requirement so that neighbor-capability tracking applies to routers that support GSI and have GSI usage enabled, rather than broadly to all PIM routers.

On operational control, we clarified support vs enablement behavior by specifying that GSI usage is operator-controlled, with an explicit disable model, and added operational guidance on when enabling GSI is justified (for Sub-TLV-based signaling and capable peers).

We clarified the requirement language and made mandatory behavior explicit with MUST statements, while retaining SHOULD/MAY only where recommendation or optional behavior is intended.
On capability advertisement when disabled, we clarified that when GSI usage is disabled, routers do not advertise the GSI Hello option and do not originate GSI TLVs.

On GSH/GSI conflict handling, we added explicit precedence: when both appear for the same (S,G), GSI takes precedence, with GSH as fallback for non-GSI-capable neighbors.

On your comment regarding normative language in examples, we removed normative wording from the Figure 1 narrative and kept it explanatory.

On figure readability, we added explanatory text under the topology figure to clarify that it is schematic and to describe the intended connectivity.

Thank you,
Ananya



From: Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Friday, June 12, 2026 at 1:55 AM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Mohamed Boucadair's Discuss on draft-ietf-pim-pfm-forwarding-enhancements-05: (with DISCUSS and COMMENT)
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



____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.