[pim] [Shepherding AD review] review of draft-ietf-pim-light-03

["Gunter van de Velde (Nokia)" <[e-mail]>]

# Gunter Van de Velde, RTG AD, comments for draft-ietf-pim-light-03

Hi All,

Please find here a shepherding AD review of draft-ietf-pim-light-03

I started reviewing this document before we kick off the IETF Last Call process and have some shepherding AD comments and observations. 
Once we address these points, we can move forward with the document through the IESG chain.

A big thank you to Sandy for the Shepherd document discussion.

I noticed that there has been no Routing Directorate review yet, and as result i requested (30 July 2024)
(https://datatracker.ietf.org/doc/draft-ietf-pim-light/reviewrequest/20052/)

In my review, I've noted some final observations while going through the document. 
For better readability, I've suggested some numereous edits. 
The line numbering has been rendered from the earlier mentioned idnits tool.


#GENERIC COMMENTS
#================
## The idnits tool spits out some comments on badly used normative language. Please correct where required:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-light-03.txt

## The detailed review mainly has lots of revised textblob proposed updates

## IANA section says N/A but we should consider updating the existing IANA PIM Message Types with an additional column to display validity of the message for PLI

## Security section is rather light. When a router starts processing packets from unauthenticated peers, then that increases risk. How can this be mitigated? Is there some operational process or could these messages be exchanged using other security mechanisms?

## After reading the full document in great detail, i missed a section that decsribes the formal procedure of what makes a PIM system a PIM Light system? 

## Interop with non PIM Light systems is not discussed in the PIM light when brownfield deployments are expected


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

17	Abstract

19	   This document specifies a new Protocol Independent Multicast
20	   interface which does not need PIM Hello to accept PIM Join/Prunes.

[major]
The abstract for this document is rather short and can use slightly more details about the document intent.
This document can do better and be more meaningful for consumers of the draft.

What about using something as follows as abstract:

"
This document specifies a new type of Protocol Independent Multicast (PIM) interface called PIM Light (PLI). Unlike traditional PIM interfaces, PLI does not require PIM Hello messages for accepting Join/Prune messages. PLI supports multicast state signaling over networks that do not support or need full PIM neighbor discovery, such as BIER networks. 

It ensures efficient multicast routing without the need for full adjacency, making it suitable for specific deployment scenarios. The document outlines PLI configuration, message handling, and considerations for ensuring non-duplicative multicast traffic.
"

78	   It might be desirable to create a PIM interface between routers where
79	   only PIM Join/Prunes packets are signaled over it without having a
80	   full PIM neighbor discovery.  This type of PIM interface can be
81	   useful in some scenarios where the multicast state needs to be
82	   signaled over a network or medium which is not capable of or has no
83	   need for creating full PIM neighborship between its peer Routers.
84	   These type of PIM interfaces are called PIM Light Interfaces (PLI).

[minor]
I do not feel that the word desirable fits properly in this context. 
This document is providing formal procedures for PIM light and the text should reflect this.
I did not add refereces to PIM and the Join/Prune message. Please add such references in the updated document.

What about following rewrite:

"
This document specifies the Protocol Independent Multicast (PIM) Light Interface (PLI), a new type of PIM interface that allows signaling of PIM Join/Prune packets without full PIM neighbor discovery. PLI is useful in scenarios where multicast state needs to be signaled over networks or media that do not support or require full PIM neighborship between routers. The document details PLI configuration, message handling, and considerations to prevent duplicate multicast traffic, offering an efficient multicast routing solution for specific deployment environments.
"

94	2.1.  Definitions
95
96	   This draft uses definitions used in [RFC7761]

[minor]
It would not hurt and make the document better readable to indicate thet RFC7761 is "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification"

100	   RFC [RFC7761] section 4.3.1 describes the PIM neighbor discovery via
101	   Hello messages.  In section 4.5 it describes that If a router
102	   receives a Join/Prune message from a particular IP source address and
103	   it has not seen a PIM Hello message from that source address, then
104	   the Join/Prune message SHOULD be discarded without further
105	   processing.

[minor]
sections 4.3.1and 4.5 formally specify the procedure used by PIM Sparse Mode.

"
RFC 7761, Section 4.3.1, outlines the PIM neighbor discovery mechanism using Hello messages. Section 4.5 specifies that if a router receives a Join/Prune message from an IP source address without having previously received a PIM Hello message from that source, the router SHOULD discard the Join/Prune message without further processing. This procedure ensures that only messages from authenticated PIM neighbors are processed, maintaining the integrity and reliability of the multicast routing infrastructure.
"

107	   In some scenarios it is desirable to communicate and build multicast
108	   states between two L3 adjacent routers without establishing a PIM
109	   neighborship.  There could be many reasons for this desired, but one
110	   example is the desired to signal multicast states upstream, between
111	   two or more PIM Domains via a network or medium that is not optimized
112	   for PIM or does not require PIM Neighbor establishment.  An example
113	   is a BIER network connecting multiple PIM domains.  In these BIER
114	   networks PIM Join/prune messages are tunneled via bier as per
115	   [draft-ietf-bier-pim-signaling].

[minor]
Slightly rewriting to help readability. What about:

"
In certain scenarios, it is desirable to establish multicast states between two Layer 3 adjacent routers without forming a PIM neighborship. This can be necessary for various reasons, such as signaling multicast states upstream between multiple PIM domains over a network that is not optimized for PIM or does not necessitate PIM Neighbor establishment. For example, in a Bit Index Explicit Replication (BIER) [RFC8279] network connecting multiple PIM domains, PIM Join/Prune messages are tunneled via BIER as specified in [draft-ietf-bier-pim-signaling].
"

117	   A PIM Light Interface (PLI) ONLY accepts Join/Prune messages from an
118	   unknown PIM router and it accepts these messages without receiving a
119	   PIM Hello message form the router.  Lack of Hello Messages on a PLI
120	   means there is no mechanism to learn about the neighboring PIM
121	   routers on each interface and their capabilities or run some of the
122	   basic algorithms like DR Election between the routers.  As such the
123	   PIM Light router doesn't create any General-Purpose state for
124	   neighboring PIM and it only process Join/Prune message from
125	   downstream routers in its multicast routing table.

[major]
This is weirdly written. what does the upper case ONLY eactly intent to explain? 
Why is it upper case? Does this mean that when the PIM neighbor is not unknown it must ignore these messages?
There are more typos in this paragraph.

"
A PIM Light Interface (PLI) accepts Join/Prune messages from an unknown PIM router without requiring a PIM Hello message from the router. The absence of Hello messages on a PLI means there is no mechanism to discover neighboring PIM routers or their capabilities, nor to execute basic algorithms such as Designated Router (DR) election [RFC7761]. Consequently, the PIM Light router does not create any general-purpose state for neighboring PIM routers and only processes Join/Prune messages from downstream routers in its multicast routing table.
"

In the above, i was wondering if the PIM LIght Router does introduce state due to the Join/Prune messages. If the answer is yes, then that should be explicit mentioned to complete the paragraph.

127	   Because of this, a PLI needs to be created in very especial cases and
128	   the application that is using these PLIs should ensure there is no
129	   multicast duplication of packets.  As an example, multiple upstream
130	   routers sending the same multicast stream to a single downstream
131	   router.

[minor]
The following rewrite may be more clear for consumers of the document.
The fact that with PIM Light there is processing of packets from an unauthenticated neighbor seems as a serious security concern. This shoul dbe mentioned as a concern and operational guidelines to reduce the risk vector

"
Due to these constraints, a PLI should be deployed in very specific scenarios. The application using these PLIs must ensure there is no multicast packet duplication, such as multiple upstream routers sending the same multicast stream to a single downstream router.
"

133	3.1.  PLI supported Messages

135	   As per IANA [iana_pim-parameters] PIM supports more than 12 message
136	   types, PIM Light only supports message type 3 (Join/Prune) from the
137	   ALL-PIM-ROUTERS message types listed in RFC7761, other unicast
138	   destination message types are supported by PIM light.  All other
139	   message types are not supported for PIM Light and SHOULD not be
140	   process if received on a PLI.

[major]
The URL reference to the IANA "PIM Message Types" registery is missing. Can the following wbe added:
https://www.iana.org/assignments/pim-parameters/pim-parameters.xhtml#message-types

I am not sure what the value is in saying that there are more as 12 message types. It would be more correct that there are multiple message types, but that PIM light only supports "3	Join/Prune	0-7: Unassigned	[RFC3973][RFC7761]" to ALL-PIM-ROUTERS to be specific. 

Please condider the following (fixing few remaining typos):

"
According to IANA [iana_pim-parameters], PIM supports numerous message types. However, PIM Light only supports message type 3 (Join/Prune) from the ALL-PIM-ROUTERS message types listed in RFC 7761. Other unicast destination message types are supported by PIM Light. All other message types are not supported for PIM Light and SHOULD NOT be processed if received on a PLI.
"

Would it make sense to explicit call out all Message Types supported by PIM light in the above text blob? does this impact IANA registery and maybe the existing table needs to be updated to become an extended table with a column specifying suport in PIM Light, so that in future it becomes easierto track what is supported in PIM Light and what is not supported in PIM Light?

142	3.2.  Lack of Hello Message consideration
143
144	   The following should be considered on a PIM Light domain since Hello
145	   messages are not processed.

[minor]
The section title is slightly misleading. Hello messages still exist, but are abscent or not processed.

"
3.2. Considerations for Absence of Hello Messages

In a PIM Light domain, the following considerations should be taken into account due to the lack of processing Hello messages
"

147	3.2.1.  Join Attribute

149	   Since PLI does not process the PIM Hello message, processing of the
150	   join attributes option in PIM Hello as per [RFC5384] is also not
151	   supported, leaving PIM Light unaware of its neighbor capability of
152	   processing the join attribute.  A PIM Light Router that does not
153	   understand the type 1 Encoded-source Address and per [RFC7761] SHOULD
154	   not process a join message that contains it.  Otherwise the PLI can
155	   process the Join Attribute accordingly.

[major]
This text blob can use some formal style BCP14 language. I added one single SHOULD and hope that this did not break the WG consensus? s/can/SHOULD/

"
3.2.1. Join Attribute

Since a PLI does not process PIM Hello messages, it also does not support the join attributes option in PIM Hello as specified in [RFC 5384]. Consequently, PIM Light is unaware of its neighbor's capability to process join attributes. A PIM Light router that does not recognize the type 1 Encoded-source Address, as per [RFC 7761], SHOULD NOT process a join message containing it. Otherwise, the PLI SHOULD process the join attribute accordingly.
"


157	3.2.2.  DR Selection
158
159	   Since DR Election is not supported on PIM Light because of lack of
160	   Hello messages, the network design should ensure that DR Election is
161	   achieve on the PIM domain, assuming the PIM Light domain is
162	   connecting PIM domains.
163


[minor]
Slightly re-edited to help readability.

"
3.2.2. DR Selection
Due to the absence of Hello messages, DR Election is not supported on a PLI. 
Consequently, network design must ensure DR Election occurs within the PIM domain, assuming the PIM Light domain interconnects PIM domains.
"

164	   As an example, in a BIER domain which is connecting 2 PIM networks, a
165	   PLI can be used between the BIER edge routers.  The PLI will be only
166	   used for multicast states communication, by transmitting ONLY PIM
167	   Join/prunes over the BIER domain.  In this case to ensure there is no
168	   multicast stream duplication the PIM routers attached on each side of
169	   the BIER domain might want to establish PIM Adjacency via [RFC7761]
170	   to ensure DR election on the edge of the BIER router, while PLI is
171	   used in the BIER domain, between BIER edge routers.  When the Join or
172	   Prune message arrives from a PIM domain to the down stream BIER edge
173	   router, it can be send over the BIER tunnel to the upstream BIER edge
174	   router only via the selected designated router.

[minor]
To help readability this textblob could be as follows: 

"
For instance, in a BIER domain connecting two PIM networks, a PLI can be used between BIER edge routers solely for multicast state communication, transmitting only PIM Join/Prune messages. To prevent multicast stream duplication, PIM routers on either side of the BIER domain should establish PIM adjacency as per [RFC 7761] to ensure DR election at the BIER edge. Join or Prune messages from a PIM domain to the downstream BIER edge router can then be sent over the BIER tunnel to the upstream BIER edge router only via the designated router.
"
[major]
However, this leaves room for confusion. Is the above intending to outline that each PIM side must have a DR at the BIER edge?
This example may need some additional clarification on the topology intended. A simple diagram or more elaborate explanation would help reader understand the intended objective from the usecase description.

176	3.2.3.  PIM Assert
177
178	   Where multiple PIM routers peer over a shared LAN or a Point-to-
179	   Multipoint medium, it is possible for more than one upstream router
180	   to have valid forwarding state for a packet, which can lead to packet
181	   duplication.  When this is detected PIM Assert is used to select one
182	   transmitter.  That said as per [RFC7761] PIM Assert should only be
183	   accepted if it comes from a known PIM neighbor.  With PIM LIGHT the
184	   implementation SHOULD ensure there is no duplicate streams arriving
185	   from upstream PIM Light routers to a single downstream PIM LIGHT
186	   router.  If this condition is not possible to be met because of
187	   network design, the implementation should ensure there is no
188	   duplication of stream.  As an example in PIM LIGHT over a BIER domain
189	   implementation, for IBBR (Down stream PIM LIGHT router) in a BIER
190	   domain to find the EBBRs closes to the source (upstream PIM LIGHT
191	   routes), SPF can be use with a post processing as per
192	   [draft-ietf-bier-pim-signaling] Appendix A.1.  With this post
193	   processing if 2 EBBRs are found by the downstream IBBR, then this
194	   downstream IBBR router can choose one of the EBBRs with a unique IP
195	   selection algorithm.  As an example the EBBR with lowest IP address
196	   or largest IP address can be the EBBR that the downstream PIM LIGHT
197	   (IBBR) router sends the join/prune message to.  When this EBBR goes
198	   offline the downstream router can send the join to the next EBBR
199	   based on the IP selection algorithm.  This IP selection algorithm is
200	   outside of scope of this draft.

[minor]
SUggested readability revised textblob suggestion. In this section it may be useful for a reader to explicit say that assert is not supported with PIM Light.

[major]
This section introduces new abbreviations. This can use a reference to the RFC where these are specified and explained.

[major]
Is the use of 'implementation' in "the implementation should ensure no stream duplication" seems incorrect. Is this trying to say that the network architecture must ensure no stream duplication? The examplethat follows was to me as a first time reader slightly confusing on the exact objective. In addition the usage of the word 'downstream IBBR' confused me. Is it not just the IBBR that intended, and is the IBBR from the stream perspective not the upstream router? Why is the tie breaking mechanism not formally defined in the the pim-signalling draft as either the highest ip or lowest ip address? This section is pointing to the  

"
3.2.3. PIM Assert

In scenarios where multiple PIM routers peer over a shared LAN or a Point-to-Multipoint medium, more than one upstream router may have valid forwarding state for a packet, potentially causing packet duplication. PIM Assert is used to select a single transmitter when such duplication is detected. According to [RFC 7761], PIM Assert should only be accepted from a known PIM neighbor. In PIM Light implementations, care must be taken to avoid duplicate streams arriving from upstream PIM Light routers to a single downstream PIM Light router.

If network design constraints prevent this, the implemented network architecture should take measures to avoid traffic duplication. For example, in a PIM Light over a BIER domain scenario, downstream IBBR (Ingress BIER Border Router) in a BIER domain can identify the nearest EBBRs (Egress BIER Border Routers) to the source using SPF with post-processing as described in [draft-ietf-bier-pim-signaling] Appendix A.1. If the downstream IBBR identifies two EBBRs, it can select one using a unique IP selection algorithm, such as choosing the EBBR with the lowest or highest IP address. If the selected EBBR goes offline, the downstream router can use the next EBBR based on the IP selection algorithm, which is beyond the scope of this draft.
"

202	3.3.  PLI Configuration
203

[major]
To me this section should make it more clear that there are operational considerations to embrace with PLI.
Could be good to spell it all explicit out to avoid readers of this PIM Light document to make assumptions

204	   Since a PLI doesn't require PIM Hello Messages and PIM neighbor
205	   adjacency is not checked for join/prune messages, there needs to be a
206	   mechanism to enable PLI on interfaces for security purpose, while on
207	   some other interfaces this may be enabled automatically.  An example
208	   of the latter is the logical interface for a BIER sub-domain
209	   [draft-ietf-bier-pim-signaling].

[major]
To enable PLI may be not only be tied to security. It could also be that it is not required for the system?
The text implies that the only reason to not enable PLI is for security.

210
211	   If a system explicitly needs a PLI to be configured, then this system
212	   SHOULD not accept the Join/Prune messages on interfaces that the PLI
213	   is not configured on, and it should drop these messages on a non PLI
214	   interface.  If the system automatically enables PLI on some special
215	   interfaces, as an example interfaces facing a BIER domain, then it
216	   should accept Join/Prune messages on these interfaces only.

[minor]
Is the text here not duplicated in the sentense?

First "If a system explicitly needs a PLI to be configured, then this system SHOULD not accept the Join/Prune messages on interfaces that the PLI is not configured on" and then the next text says in different words "and it should drop these messages on a non PLI interface."

[minor]
"on some special interfaces" is that correct? maybe you are saying 'interfaces with a specific function'?

218	3.4.  Failures in PLR domain
219
220	   Because the Hello messages are not processed on the PLI, some
221	   failures may not be discovered in PLI domain and multicast routes
222	   will not be pruned toward the source on the PIM domain, leaving the
223	   upstream routers continuously sending multicast streams until the out
224	   going interface (OIF) expires.
225
226	   Other protocols can be used to detect these failures in the PIM Light
227	   domain and they can be implementation specific.  As an example, the
228	   interface that PIM Light is configured on can be protected via BFD or
229	   similar technology.  If BFD to the far-end PLI goes down, and the PIM
230	   Light Router is upstream and is an OIF for a multicast route <S,G>,
231	   PIM should remove that PLI from its OIF list.  In addition if
232	   upstream PLI is configured automatically, as an example in BIER case,
233	   when the downstream BFR is no longer reachable, the upstream PIM
234	   Light Router can prune the <S,G> advertised by that BFR, toward the
235	   source to stop the transmission of the multicast stream.

[minor]
What are 'some failures'? which faiures exactly are not discovered?
Is BFD the only mechanism that is used to detect peer livelyness?

237	3.5.  Reliable Transport Mechanism for PIM LIGHT
238
239	   [RFC6559] defines a reliable transport mechanism for PIM transmission
240	   of Join/Prune messages.  PIM over reliable transport (PORT) uses TCP
241	   port 8471 which is assigned by IANA.  [RFC6559] mandates that if a
242	   router is configured to use PIM over TCP or SCTP on a given interface
243	   it must include the PIM-over-TCP-Capable or PIM-over-SCTP-Capable
244	   Hello option in its Hello messages for that interface.  These options
245	   also communicate the connection ID of TCP for the appropriate address
246	   family.  PIM Light lacking Hello messages, can be configured to use
247	   PORT under a PLI.  That said the TCP connection ID of local router
248	   and peer router has to be configured manually under each side of the
249	   PLI.  The PLI uses these local and peer connection ID to setup a TCP
250	   connection.  As per [RFC6559] section 4 the routers use the
251	   connection IDs to figure out which side will do a passive transport
252	   open and which side of the PLI with do a active open.  If TCP
253	   connection failed to open then PLI will revert back to Datagram mode.

[major]
TCP with port 8471 is mentioned, however later SCTP is mentioned. 
This section may need some BCP14 language to prescribe exactly what is supproted and how the PIM Light must behave under condition of using reliable transport.

255	3.6.  PIM Variants not supported
256
257	   The following PIM variants are not supported with PIM Light and not
258	   covered by this draft:
259
260	   1.  Protocol Independent Multicast - Dense Mode (PIM-DM)[RFC3973]
261
262	   2.  Bidirectional Protocol Independent Multicast (BIDIR-PIM)
263	       [RFC5015]

[minor]
For completeness what about PIM-SSM? PIM Dense-Sparse Mode? PIM-Any-source-multicast?

265	4.  IANA Considerations
266
267	   NA

[major]
The existing IANA registery for "PIM Message Types" may not be sufficient for PIM Light and may need update.
The existing table may need a new column, used explicit for PIM Light to show which of the PIM Message Types is supported.
It would be to lock the Message types currently supported and allows a framework for the future, unless through WG consensus the expectation is never any message ar eto be supported for PLI?

269	5.  Security Considerations
270
271	   Since PIM Light can be used for signaling Source-Specific and Sparse
272	   Mode Join/Prune messages, security considerations of [RFC7761] and
273	   [RFC4607] SHOULD be considered.
274
275	   It should be noted a PIM Light can also use [RFC5796] as indicated in
276	   [RFC7761] for authentication.

[major] 
in the text security was mentioned, but the same topc is not discussed in this section.
Processing Join/Prune from non-neighbors could be a DOS attack vector.

Is there any other PIM threat that can exploited now that PIM routers start processing packets received from unauthenticated PIM peers?

325	Authors' Addresses

[minor] 
the names of authors are not 100% correct and miss family names


Brgds,
G/