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

Thanks, Sany, inline

On Sat, Feb 28, 2026 at 04:59:33PM +0800, [email protected] wrote:
> 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.

Just write it out what that means to make the document easier stand-alone.

> 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.

Sure, write it out. Can different (S1,G), (S2,G) have different TAD ? Or only in SSM ? Write it out.

> 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.

I understand that, but i find no text arguing why it would be beneficial for the intermediate routers
to get the TAD info from PIM instead of config. Especially as i think you imply,
many routers especially in aggregation/access networks are always PE because they have
some edge interface, even though they are simultaneously intermediate hops of the PIM path.
(e.g.: in rings).

> 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.

And again: I am missing justifications of the benefit in the text even though in this
option i do see a beneefit.
>  
> 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.

Sure. Another good detail to write. But in the first place the question that the operator
wanting to deploy this will have is what exactly is the minimum type of configuration
needed so that this will be flexible enough.

> 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.

It doesn't have two sources using two failure disjoint paths. that's live-live and
IMHO that would be the biggest beneficial use of this technology.

Cheers
    Toerless

> 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]



-- 
---
[email protected]

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