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

The RPF mechanism can not support more than one choice, so we need to pick one.
If multiple receivers signal different desires but we can only serve one, i think
that's what we linguistically call conflict.

Cheers
    Toerless

On Mon, Jul 21, 2025 at 10:45:48AM +0000, Mankamana Mishra (mankamis) wrote:
> 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]

-- 
---
[email protected]

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