[pim] Re: draft-liu-pim-rpf-vector-conflict-resolution thoug hts

Should we not think what would cause such scenario ? if deployment really want to support each receiver trying to receive traffic from different path, why we want to consider it as conflict ?

Mankamana

From: Toerless Eckert <[email protected]>
Date: Monday, July 21, 2025 at 3:16 AM
To: [email protected] <[email protected]>
Subject: [pim] draft-liu-pim-rpf-vector-conflict-resolution thoughts
Dear authors, PIM-WG:

Thanks for the draft. I browsed through it and have a few quick thoughts:

1. I am not sure if/where this may have already been a problem. It might be useful to
   also ask MBoned about possible issues in deployments of RPF vector to get support
   for this draft.

2. If the draft proceeeds, i think it should declare itself to be an update to
   RFC7891 and RFC5496 in the header.

3. RFC4601 has been superceeded by RFC7761, please replace

4. The normative section 4 should probably be made to look a bit more normative:

   /Conflicting Resolution Principle/Conflicting Resolution Rules/

  If one with an RPF Vector and the other without, the join message
  without the RPF Vector MUST be given priority.

  If one join message only contains a type 0 RPF Vector (RPF Vector)
  and the other contains a type 4 RPF Vector (Explicit RPF Vector),
  the join message with only the type 0 RPF Vector MUST be given priority.
                                                    ^^^^^

5. I find the reasoning for the requirements could be improved:

   This procedure ensures deterministic resolution of attribute
   conflicts while maintaining backward compatibility with routers that
   do not support preference attributes.

   Maybe a better explanation would be

   These rules ensure that priority is given to the "oldest" or "most simple"
   method of picking RPF (no RPF vector being older than type 0 being older than type 4).
   When rolling out RPF vector or changing it from type 0 to type 4, that change
   will at large be used only after all active routers have been switched over
   to send the new RPF type.

   Note that RPF vector at large can only work well when all routers are
   configured consistently, and that these priority rules are primarily
   meant to make transition conditions predictable.

Thanks a lot for the work!

Toerless

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