[pim] Re: draft-xz-pim-flex-algo adoption call

I have no opinion right now other than missing to understand a couple of basics
and explanations which would be great to add to the text in case this document gets adopted

1. Is PFM only applicable to PIM-SM (including 'PIM-SSM') or also to
   Bidir-PIM ? Or PIM-DM ? Sorry, can't remember.
   It would be good to explicitly state in this document which modes of 
   PIM are applicable to this draft, especially if it's simply just PIM-SM.

2. Is this document meant to support

   a) Each PIM state (S,G), (*,G), (S,G,RBit) (or Bidir-states)
      can only have one "topology/algo" associated with it. This
      mechanism only impacts RPF or accept elements of pre-existing
      forwarding states.

   b) There can be multiple instances of the same (S,G), (*,G),...
      for different "topology/algo", effectively creating (sel,S,G),
      for whatever additional selector is used in the forwarding plane.

   I would guess it is a), but please write it out explicitly, that
   this draft does only involve control-plane changes, no actual forwarding
   plane changes. 

3. I fail to see a strong example where this approach simplifies deploments,
   so it would be great to give such an example/explanation in the draft.

   From my understanding, this solution requires for all leaf PIM-routers
   to have consistent configuration for how to map G or (S,G) to a particular
   "topology/algo". Yes/no ?

   If every router in the network has the consistent configuration, then
   i would not need this extension, because then each router could determine
   the topology/algo for each G or (S,G) itself from this mapping
   configuration.

   So, the likely intended benefit of this approach is to allow for
   P routers that are never egress-PE to get away without this consisten
   configuratation. But in the best case, the number of such P vs. the
   totality of PE is probably just a small number. 10% ? So, where
   is the real benefit here - it requires some controller or rhe like to
   push the consistent mapping information to all egress-PE. How much more
   difficult is it to also push it into 10% more routers (P) ?

   Meaning: I am sceptical of this "benefit" option. But would be happy to
   hear persuasive reasons why it is significantly beneficial to justify
   the development cost of this feature.

4. Alternatively, the solution actually DOES EXPECT that all routers (including P)
   are configured with consistent mapping information and the inclusion
   of the topo/algo into the PIM joins is just a way to allow recognizing
   when there is an inconsistency. That would be an interesting option,
   but it would need to be written out as an intended benefit. To me,
   this approach would actually be easer to see as beneficial especially
   ffor live-live style deployments where you want to make sure there is
   never an unintended "leave" between topologies.

5. I know it's not tradition in PIM to do so, but it would be lovely to
   have an idea about some minimum requirements against the mapping that
   routers can be configured for, so that an operator is not later
   surprised between two vendors claiming to support this RFC - but
   having different mapping options . Could be something like
   requirements "Must allow to set for every ASM G an individual 
   set of topo/algo values", "Must allow to set for ever SSM (S,G) channel
   an individual set of topo/algo values". Or something even more helpful...

   I would certainly strongly advice to think about the impact of assigning
   different topo/algo to different S1, S2 for the same ASM G. With possible
   (*,G) forwarding and RPT/SPT switchover that sounds like a lot of pain
   to me. The example in 4.3  does not talk about SSM vs. ASM.

6. I would love to see an example with actual path diversity,
   aka: 2 sources using two different paths through the network - because
   that's ultimately what i'd hope to be one of the most beneficial
   solutions possible with multi-topo. 

Cheers
    Toerless

On Thu, Feb 26, 2026 at 09:56:12PM -0700, Mike McBride wrote:
> Hello pim,
> 
> Today begins a two week adoption call for
> https://datatracker.ietf.org/doc/draft-xz-pim-flex-algo/ which was
> discussed in Montreal. It lets trees follow flex algo or multi-topology
> paths by including a topology/algorithm identifier in pim messages.
> 
> Please review and speak up.
> 
> thanks,
> mike

-- 
---
[email protected]

_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]