[pim] pim-multicast-lessons-learned: MRIB, RPF as "security feature", data driven SPF switchover
David 'equinox' Lamparter <equinox@diac24.net> Mon, 17 March 2025 06:50 UTC
Return-Path: <equinox@diac24.net>
X-Original-To: pim@mail2.ietf.org
Delivered-To: pim@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id AF95FC9E331; Sun, 16 Mar 2025 23:50:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptns3NhhvB23; Sun, 16 Mar 2025 23:50:57 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A81A9C9E32C; Sun, 16 Mar 2025 23:50:54 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.97.1) (envelope-from <equinox@diac24.net>) id 1tu4JG-000000040Io-3v1F; Mon, 17 Mar 2025 07:50:52 +0100
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
X-Message-ID-Hash: SVUQT2WCWY56XDMGVFIMB7W5G2EION43
X-MailFrom: equinox@diac24.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-pim.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: pim@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [pim] pim-multicast-lessons-learned: MRIB, RPF as "security feature", data driven SPF switchover
List-Id: Protocol Independent Multicast <pim.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/7lRCMhTLLSWjDRWBvwIcMeL52X4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Owner: <mailto:pim-owner@ietf.org>
List-Post: <mailto:pim@ietf.org>
List-Subscribe: <mailto:pim-join@ietf.org>
List-Unsubscribe: <mailto:pim-leave@ietf.org>
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)
- [pim] pim-multicast-lessons-learned: MRIB, RPF as… David 'equinox' Lamparter
- [pim] Re: pim-multicast-lessons-learned: MRIB, RP… Toerless Eckert
- [pim] Re: pim-multicast-lessons-learned: MRIB, RP… David 'equinox' Lamparter