Date: Mon, 17 Mar 2025 07:50:50 +0100
From: David 'equinox' Lamparter <equinox@diac24.net>
To: draft-ietf-pim-multicast-lessons-learned@ietf.org
Message-ID: <Z9fGSicgfJMIWGFm@eidolon.nox.tf>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID-Hash: SVUQT2WCWY56XDMGVFIMB7W5G2EION43
CC: pim@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bpim=5D_pim-multicast-lessons-learned=3A_MRIB=2C_RPF_as_=22secur?=
 =?utf-8?q?ity_feature=22=2C_data_driven_SPF_switchover?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/pim/7lRCMhTLLSWjDRWBvwIcMeL52X4>

Hi all,


this is the bits I mentioned on mic a few minutes ago:

3.3 Shared vs Source Trees:

It says "The path on the source tree is determined by the unicast
routing table and is also known as the 'RPF path'."  The "unicast
routing table" to me means the actual, specific table used for unicast
traffic.  But it's reasonably common (i.e. we've been asked to improve
support for this based on customer demand) to have a separate multicast
table (i.e. what is supported by BGP, OSPF and IS-IS as 'multicast
topology' or SAFI_MULTICAST).  I would suggest some wording along the
lines of:

"The path on the source tree is determined by routing table lookups for
the source's unicast address and is also known as the 'RPF path'.  These
lookups can use the actual unicast routing table, or include unicast
routing data specifically intended for determining the multicast RPF
path."

(In case it helps, this is our documentation for this:
https://docs.frrouting.org/en/latest/pim.html#clicmd-rpf-lookup-mode-MODE-group-list-PREFIX_LIST-source-list-PREFIX_LIST
)

Also (forgot this on mic), the paragraph/part starting with "What was
later realized was that source trees were needed which discover the
multicast source outside the network[... until end of paragraph]" is
very confusingly worded to me.  I kind of understand what it's trying to
say, but could it maybe be reworded?


3.5 Data Driven State Creation and RPF

This says "The RPF is a security feature".  I'd say it's a functional
requirement (in particular for a very typical setup with 2 routers
servicing an end-host subnet ala ECMP).  A functional requirement is
IMHO an even stronger requirement than security;  not adhering to a
security requirement might be bad but not in itself break things but
this one very much does.

And lastly, I didn't find anything in the document about the
bandwidth/packet rate threshold RPT-to-SPT switchover behavior commonly
implemented for PIM-SM, i.e. config knob "switch to SPT when exceeding
50kbit/s of traffic on this S,G".  It is incredibly annoying/costly to
implement (and we don't by default), but that's definitely a "lesson
learned" in multicast routing :).  But I might've just missed it in the
doc?

Cheers,


-equi
(David)