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

Hi Toerless,
thank you for your comments. 
please find in line with Sandy>.












Original


From: ToerlessEckert <[email protected]>
  
To: Mike McBride <[email protected]>;
  
Cc: [email protected] <[email protected]>;
Date: 2026年02月28日 09:24
  
Subject: [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.
Sandy> This draft is aligned with the scope of the RFC8364 and the draft-ietf-pim-pfm-forwarding-enhancements.
 
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.  
 Sandy> Different groups can choose different TADs for the same source.
There are no changes at the forwarding plane.

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.

Sandy> Please read the example in section 4.3, which describes a method for traffic that needs to be forwarded via a specific TAD.
Signaling can be avoided on all routers through configuration, but this may not be a good option.
In multicast stream forwarding, all routers except the FHR and LHR are intermediate routers; this concept is not the same as that of a P router.
 
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.

Sandy> Same as above.
 
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.

Sandy> This scheme relies on IGP source address path lookup calculation.
Deploying this solution does not require configuration for all multicast streams; it is only for traffic that needs to be forwarded using a specific MT/FA.
For traffic that can be forwarded via the shortest path, there is no need to bind it to a TAD.
 
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. 

Sandy> Please refer to the example in section 4.3.
This method relies on source address path lookup calculation using IGP.
Different MT/FAs can be selected for the same source in different groups, and different MT/FAs can be selected for different sources in different groups.
Thanks,
Sandy
 
 
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]

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