Re: [pim] Fw: I-D Action: draft-ietf-pim-dr-improvement-10.txt

[Alvaro Retana <[e-mail]>]

On October 1, 2020 at 4:43:05 AM, [e-mail] wrote:

[Adding the other authors and the WG back in.]


Sandy:

Hi!

Thanks for working on this draft!

However, I don't think that significant progress has been made -- in
fact, none of my top-level questions have been completely resolved.
Also, the election algorithm, which should be the most important part
of this draft, is not properly specified.

The WG (along with the authors and the Shepherd/Chairs) need to
clearly come to consensus on a *PIM-based* election algorithm.  I am
then returning this document to the WG.


I have many comments below -- first on your answers to my top-level
questions, then then inline based on the -10 version.

Take care!

Alvaro.




> > (1) How does this document interact with rfc8775 (PIM DR Load
> > Balancing)?  Should be BDR always be a GDR? Can a BDR not be a GDR?
> > rfc8775 is not even mentioned.
>
> Sandy> A new section 3.4 is added for interaction with RFC8775.
>
> It doesn't matter whether BDR is a GDR, BDR only monitors DR and does
> switchover when DR becomes unavailable.
>
> If BDR is not one of the GDRs, duplicate flow is forwarded.

I put some comments and questions in-line.





> > (2) As far as I can see draft-mankamana-pim-bdr has not been adopted
> > yet. Assuming that is the plan, how would the two mechanisms interact?
> > Given that draft-mankamana-pim-bdr doesn't add options, and §5 says that
> > if no options are received then the routers MUST use rfc7761, how does a
> > router implementing this specification tell the difference?
>
> Sandy> I modified the description in section 5. IMO network administrator
> should do some configurations to keep the consensus.
>
> Please see if there is any other inconsistency.

Relaxing the requirement makes the text more confusing because there's
no clear action.  Also, it results in draft-mankamana-pim-bdr becoming
a Normative dependency (because the MUST NOT action points at it).


> > I realize that some of these questions may be better directed at
> > draft-mankamana-pim-bdr, but because the WG agreed that a statement
> > relating the two should be included in this document [1], then I'm
> > asking now. I would really like to understand what the WG expects.
>
> Sandy> The mention of draft-mankamana-pim-bdr is from chairs. I hope the
> new version has make it more clear. I added the informative reference for
> it.

Stig/Mike:  I looked at the archive [1] and the minutes [3], and it
looks (in the minutes) like I said "clearly state why there are two
different drafts for the same problem and why they aren't combined".
:-(  The text in §5 does mention the difference, but it simply opens
up more questions...and there is not a clear differentiation of when
to use one or the other.  At first glance, they just seem to be two
different solutions for the same problem.

draft-mankamana-pim-bdr hasn't been adopted -- what is the current
status?  Note that the minutes is the only place where I can find any
discussion about it.

The other question in the minutes is about whether the 2 drafts should
be merged, or even if that was discussed.  Was it considered?  What
are the WG expectations when defining two solutions?  Are there really
different use cases, or is the intent to simply let the market choose?
 This document is on the Standards Track, but draft-mankamana-pim-bdr
is marked as Informational -- are those the right statuses to use?
Should they be Experimental instead?

I hate to be asking questions about drafts that have not even been
adopted...  Note that I would be ok if the answer to all these
questions came down to letting draft-mankamana-pim-bdr deal with them;
after all, this document is in the Standards Track, has already been
sent for publication, etc.  But it concerns me that I'm missing more
context; am I?


[1] mailarchive.ietf.org/arch/msg/pim/hWi6rDIbbhcEjEuQ_y3z1o6Wulw
[3] https://datatracker.ietf.org/doc/minutes-104-pim/



> > (3) The Shepherd writeup [2] says that there is an implementation and
> > deployment of this specification. *But* the IANA Considerations section
> > lists the code points as TBD. What's the status of the implementation?
> > Are there specific code points that should be suggested to IANA? An
> > rfc7942-type section would be useful to justify specific code points, if
> > needed.
>
> Sandy> In our product implementation, private values (>65001) are used.
> Since this draft is standarded, we'd like to use two specific values
> 37/38.

I noticed you added these values to the draft; please go back to TBDx.

Note that the registry has a FCFS policy, so you could request these
values from IANA.  If IANA assigns the values then you can include
them.



...
> > (4) The election algorithm (§4.2) is a word-by-word copy from rfc2328!
> > It is good to reuse technology, but in this case (1) the description is
> > out of context, and (2) the election function from rfc7761 would make a
> > much better (and familiar) base for the description (and, as far as I
> > can tell, should yield the same result). Please update the description.
>
> Sandy> The copy was used for somebody didn't want to look at RFC2328. I
> updated the description, and only keep the differences.

[major] The result still doesn't work.  A couple of examples: rfc2328
uses the Router ID as a tie breaker, and OSPF has the concept of
two-way communication, but there are no such concepts in PIM.  I
strongly suggest that you write the election algorithm from scratch,
even if inspired by rfc2328, to avoid any confusion.  Also, again,
please consider trying to reuse the functions already defined in
rfc7761.



==== Comments based on draft-ietf-pim-dr-improvement-10 ==

[idnits line numbers from -10.]


...
16	Abstract

18	   Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely
19	   deployed multicast protocol.  As deployment for the PIM protocol is
20	   growing day by day, a user expects lower packet loss and faster
21	   convergence regardless of the cause of the network failure.  This
22	   document defines an extension to the existing protocol, which
23	   improves the PIM protocol's stability with respect to packet loss and
24	   convergence time when the PIM Designated Router (DR) role changes.

[nit] s/the PIM protocol's/PIM's


...
81	1.  Introduction

83	   Multicast technology, with PIM-SM ([RFC7761]), is used widely in
84	   modern services like IPTV and Net-Meeting.  Some events, such as
85	   changes in unicast routes, or a change in the PIM-SM DR, may cause
86	   the loss of multicast packets.

[minor] IPTV and Net-Meeting are used to generically refer to
services.  It would be very nice if a generic description is included
in the Terminology section.  Or maybe change them to s/used widely in
modern services like IPTV and Net-Meeting/used widely in real time
services


88	   The PIM DR has two responsibilities in the PIM-SM protocol.  For any
89	   active sources on a LAN, the PIM DR is responsible for registering
90	   with the Rendezvous Point (RP) if the group is operating in PIM-SM.
91	   Also, the PIM DR is responsible for tracking local multicast
92	   listeners and forwarding data to these listeners if the group is
93	   operating in PIM-SM.

[minor] The first part of the paragraph already says that the text
applies to PIM-SM.   s/ if the group is operating in PIM-SM//g


...
111	   (a) Both routers are on the network, and RouterB is elected as the
112	   DR.  If RouterB then fails, multicast packets are discarded until
113	   RouterA is elected as DR and it assumes the multicast flows on the
114	   LAN.  As detailed in [RFC7761], a DR's election is triggered after
115	   the current DR's Hello_Holdtime expires.  When the DR (RouterB) is
116	   deemed unavailable, as the result of DR failure detection, RouterA is
117	   elected as the DR.  Then RouterA joins the multicast trees, starts
118	   receiving the flows and proceeds with the multicast forwarding.  All
119	   the procedures usually take several seconds.  That is too long for
120	   modern multicast services.

[] Suggestion:

   (a) Both routers are on the network, and RouterB is elected as the DR.
   If RouterB then fails, multicast packets are discarded until RouterA is
   elected as DR, and it assumes the multicast flows on the LAN.  As
   detailed in [RFC7761], a DR's election is triggered after the current
   DR's Hello_Holdtime expires.  The failure detection and election
   procedures may take several seconds.  That is too long for modern
   multicast services.


122	   (b) Only RouterA is initially on the network, making it the DR.  If
123	   RouterB joins the network with a higher DR Priority.  Then it will
124	   then be elected as DR.  RouterA will stop forwarding multicast
125	   packets, and the multicast flows will not recover until RouterB
126	   assumes the multicast flows on the LAN.

[nit] s/Then it will then be elected as DR./Then it will be elected as DR.


[nit] s/RouterA will stop forwarding multicast packets, and the
multicast flows will not recover until RouterB assumes the multicast
flows on the LAN./RouterA will stop forwarding multicast packets, and
the flows will not recover until RouterB assumes them.


128	   In either of the situations listed, many multicast packets are lost,
129	   and the quality of multicast services noticeably affected.  To
130	   increase the stability of the network, this document introduces the
131	   Designated DR (DR) and Backup Designated Router (BDR) options and
132	   specifies how its identity is explicitly advertised.

[] Suggestion>

   In either of the situations listed, many multicast packets may be lost,
   and the quality of the services noticeably affected.  To increase the
   stability of the network this document introduces the Designated DR (DR)
   and Backup Designated Router (BDR) options, and specifies how the
   identity of these nodes is explicitly advertised.


...
155	3.  Protocol Specification

157	   The router follows the following procedures:

[minor] These steps are to be used when a router starts, or the
interface is enabled, right?  Please say so explicitly.


159	   (a).  A router first starts sending Hello messages with the values of
160	   DR and BDR Address options are all set to 0x0, after its interface is
161	   enabled in PIM on a shared-media LAN.  The router treats itself as
162	   DROther role, and starts a timer which value is set to
163	   Hello_Holdtime.

[] Suggestion>

  (a) When a router first starts or its interface is enabled, it includes
  the DR and BDR Address options with the OptionValue set to 0x0 in its
  Hello messages (Section 4.2).  At this point the router considers itself a
  DROther, and starts a timer set to Hello_Holdtime [rfc7761].


[major] I think you mean Default_Hello_Holdtime instead of
Hello_Holdtime, right?


165	   (b).  When the router receives Hello messages from other routers on
166	   the same shared-media LAN, the router checks the value of DR/BDR
167	   Address option.  If the value is filled with a non-zero IP address,
168	   the router stores the IP addresses.

170	   (c).  When a Hello message with a non-zero DR Address option is
171	   received or after the timer expires, the router first executes the
172	   algorithm defined in section 3.1.  After that, the router first one
173	   of the roles in the LAN: DR, BDR, or DROther.

[minor] s/non-zero DR Address option/non-zero DR address


[] "After that, the router first one of the roles in the LAN: DR, BDR,
or DROther."  I don't know what you meant to say here. :-(


[major] If the election is done when the first non-zero address is
received, then that may be the only neighbor information present -- in
fact, the DR address may not point to a known neighbor (see questions
about this in §4.3).

I think there are holes in the logic -- I would be happy to be
corrected, but the definition of the election algorithm by reference
doesn't help.  OSPF uses two-way neighbors when determining the DR/BDR
-- maybe PIM should wait until the Default_Hello_Holdtime timer
expires.

Note that §3.2 specifies that the election happens "when the timer expires".


175	   If the role of the router first starts changes to BDR, the following
176	   steps are:

178	   o  The BDR takes on all the functions of a DR as specified in
179	      [RFC7761], except that it SHOULD NOT actively forward multicast
180	      flows or send a register message to avoid duplication.

182	   o  If the DR becomes unreachable on the LAN, the BDR MUST take over
183	      all the DR functions, including multicast flow forwarding or send
184	      the register message.  Mechanisms outside the scope of this
185	      specification, such as [I-D.ietf-pim-bfd-p2mp-use-case] or BFD
186	      Asynchronous mode [RFC5880] can be used for faster failure
187	      detection.

[] Suggestion>

   If the router is elected the BDR, it takes on all the functions of a DR
   as specified in [RFC7761], except that it SHOULD NOT actively forward
   multicast flows or send a register message to avoid duplication.

   If the DR becomes unreachable on the LAN, the BDR MUST take over all the
   DR functions, including multicast flow forwarding and sending the
   Register messages.  Mechanisms outside the scope of this specification,
   such as [I-D.ietf-pim-bfd-p2mp-use-case] or BFD Asynchronous mode
   [RFC5880] can be used for faster failure detection.



189	   For example, there are three routers: A, B, and C.  If all three were
190	   in the LAN, then their DR preference would be A, B, and C, in that
191	   order.  Initially, only C is on the LAN, so C is DR.  Later, A joins;
192	   C is still the DR, and A is the BDR.  Later B joins, and if B is
193	   better than A, then B becomes the BDR, and A is simply DROther.

[minor]  This example feels out of place because this is not where the
algorithm is defined.  It is also wrong: the second sentence talks
about A being preferred, but the last one prefers B.


...
229	3.2.  Sending Hello Messages

231	   When PIM is enabled on an interface or a router first starts, Hello
232	   messages MUST be sent with the values of the DR Address option filled
233	   with 0x0.  The BDR Address option SHOULD be sent, if the option is
234	   carried, the value MUST be filled with 0x0.  Then the interface
235	   starts a timer which value is set to Hello_Holdtime.  When the timer
236	   expires, the DR and BDR will be elected on the interface according to
237	   the DR election algorithm (Section 3.1).

[minor] s/the values of the DR Address option filled with 0x0/the
OptionValue of the DR Address option set to 0x0


[minor] s/The BDR Address option SHOULD be sent, if the option is
carried, the value MUST be filled with 0x0./The BDR Address option
SHOULD also be sent, the OptionValue MUST be set to 0x0.


[major] I think you mean Default_Hello_Holdtime instead of
Hello_Holdtime, right?


[major] "When the timer expires..."  Note that this is different from
what is described in §3.


[major] "The BDR Address option SHOULD be sent..."   I understand that
this paragraph is talking about the case when a router first starts,
so it doesn't know about a BDR.  Once the election algorithm is run,
should the routers always send the BDR Address option, or is it still
optional?  This section doesn't specify the "steady state" behavior.


...
254	   When a router first starts (RouterC) elects itself as the BDR after
255	   it running the election algorithm, the router sends Hello messages
256	   with the value of DR is set to the IP address of current DR (RouterA)
257	   and the value of BDR is set to the IP address of the router first
258	   starts itself (RouterC).

[minor] It is not clearly indicated why RouterC would become the BDR.


260	   A current BDR (RouterB) may find that it can not be the BDR after it
261	   running the election algorithm, it MUST set itself DROther and stop
262	   sending the BDR Address options with its IP address.  It MUST send
263	   Hello messages with the value of DR is set to current DR and the
264	   value of BDR is set to the newly elected BDR.

[major] Please don't use Normative language in an example.  If you
want to specify the behavior of the DROther, please do so explicitly.

Suggestion>

   A DROther router MUST NOT use its IP addresses in the DR/BDR Address
   options.


266	3.3.  Receiving Hello Messages

268	   When a Hello message is received, if the DR/BDR Address option
269	   carried in the message is different from the previous message.  The
270	   election algorithm MUST be rerun.  As a result, the associate actions
271	   should be taken according to the role changing.

[] It's hard to comment without the details of the election algorithm...


[major] "different from the previous message"  Did you mean different
from the currently elected DR/BDR?  Or are you requiring that the
router keeps track of individual settings?


[major] "if the DR/BDR Address...is different...election algorithm
MUST be rerun."  As par as I can tell, the intent is for the algorithm
to be non-preemptive for the DR.  If so, then this paragraph
contradicts the specification!


[major] Does 0x0 count as "different"?  I guess that if the DR router
starts advertising 0x0 as the DR address, then it probably means that
it resigned its role (same for the BDR), so the algorithm would need
to run again.  But if a DROther starts advertising 0x0, then it looks
like the local router wouldn't need to.  BTW, there's no text in this
document about the DR/BDR resigning.


273	3.4.  Working with the DRLB function

275	   The DRLB function defined in [RFC8775] can work with the mechanism
276	   defined in this document.  The routers advertise the DR/BDR Address
277	   options and the DRLB-Cap Hello Option defined in [RFC8775].  After
278	   running the election algorithm defined in section 3.1, the elected DR
279	   advertises the DRLB-List Hello Option to carry the GDR candidates.

281	   When the current DR is unavailable, the BDR MUST send the DRLB-List
282	   Hello Option to carry the GDR candidates.  The BDR starts forwarding
283	   the multicast flows, but there may be duplicated flows because the DR
284	   may not be the same as the GDR.

[] After looking at the new text, I have the following suggestion to replace it:

   A network can use the enhancement described in this document with the DR
   Load Balancing (DRLB) mechanism [rfc8775].  If the DR becomes
   unreachable, the BDR will take over all the multicast flows on the link,
   which may result in duplicated traffic as it may not have been a Group DR
   (GDR).  The new DR MUST then follow the procedures in [rfc8775].


[major] What about the case where some routers support this
specification but not rfc8775?  Is this support required?  Consider
the case where the BDR doesn't support rfc8775.

[major] If not...  Please include some text explaining what happens if
the BDR doesn't support rfc8775.  Take a look at §5.8/rfc8775 for an
example.



...
301	4.1.  DR Address Option format
...
307	   o  OptionValue: IP address of the DR.  If the IP version of the PIM
308	      message is IPv4, the value MUST be the IPv4 address of the DR.  If
309	      the IP version of the PIM message is IPv6, the value MUST be the
310	      link-local address of the DR.

[major] Throughout the text phrases similar to "DR and BDR Address
options are all set to zero" are used.  It is obvious that the intent
is for the OptionValue to be set to 0x0, and not for the whole option
to include 0s; but the text feels sloppy.  Please either change the
phrases to refer to the "OptionValue in the DR/BDR Address option", or
maybe better the "IP address in the DR/BDR Address option."   Another
alternative would be to give the OptionValue a name ("DR address" for
example), and then refer to that field ("the DR address field").


...
323	4.3.  Error handling

325	   The DR and BDR addresses MUST be the same with the addresses which
326	   are used to send PIM Hello message.

[major] When the DR/BDR is not the router sending the message, how can
this requirement be verified?  Assuming multiple routers on a LAN (A,
B, C, D), the DR/DBR address must correspond to the address of A, B, C
or D, right?  How can the receiver verify that?  What if the receiver
has not yet received a Hello from router A, for example, but the other
routers advertise A as the DR/BDR, then what?  I'm assuming you can
either accept the Option and wait Hello_Holdtime to verify, or ignore
the option and eventually wait for a new Hello -- what is the action
taken?

Suggestion>

   The DR and BDR addresses MUST correspond to an address used to send PIM
   Hello messages by one of the PIM neighbors on the interface .  If that is
   not the case then...


328	   Unknown options MUST be ignored, which conforms to the format defined
329	   in section 4.9.2 in [RFC7761], and the options MUST be ignored that
330	   include unexpected values.  For example, when a DR Address option
331	   with IPv4 address is received while the interface supports IPv6 only,
332	   the option MUST be ignored.

[major] No need to respecify what is already in rfc7761.

Suggestion>

   An option with unexpected values MUST be ignored.  For example, a DR
   Address option with an IPv4 address received while the interface only
   supports IPv6 is ignored.


[major] If an option with an IPv4 address is received on an IPv6 PIM
Hello, should it be accepted if the interface also supports
IPv4...OR...should the contents of the options use the same address
family as the source of the packet?


[minor] Are there other examples of unexpected values?


334	5.  Compatibility

[minor] s/Compatibility/Backwards Compatibility


336	   If at least one router on a LAN doesn't send a Hello message,
337	   including the DR Address Options, then the specification in this
338	   document MUST NOT be used.  Any router using the DR and BDR Address
339	   Options MUST set the corresponding OptionValues to 0x0.  This action
340	   results in all routers using the DR election function defined in
341	   [RFC7761] or [I-D.mankamana-pim-bdr].

[minor] s/DR Address Options/DR Address Option


343	   This draft allows the DR election to be sticky by not unnecessarily
344	   changing the DR when routers go down or come up.  That is done by
345	   introducing new PIM Hello options.  Both this draft and the draft
346	   [I-D.mankamana-pim-bdr], introduce a backup DR.  The latter draft
347	   does this without introducing new options but does not consider the
348	   sticky behavior.

[minor] The use of "sticky" may not be clear to all readers.  Maybe
use something like "not pre-emptive", or, even better, put a
definition in the Terminology section.


350	   A router that does not support this specification ignores unknown
351	   options According to section 4.9.2 defined in [RFC7761].  So the new
352	   extension defined in this draft will not influence the stability of
353	   neighbors.

[minor] s/According to section 4.9.2 defined in [RFC7761]/according to
section 4.9.2 in [RFC7761]


355	   The DR election mechanism selection would depend on deployment
356	   scenario.

[major] This is exactly the point I was trying to make at the
beginning: there don't seem to be differences in the applicability of
this draft and I-D.mankamana-pim-bdr.  IOW, that are the different
deployment scenarios?  I guess you mean: it is a local decision which
mechanism to use -- which take us back to the questions at the top.


358	6.  Security Considerations

360	   [RFC7761] describes the security concerns related to PIM-SM, the
361	   potential BFD session attack can be used as the security function in
362	   section 9 [RFC5880] mentioned.

[major] BFD is not a Normative reference, so we don't need to mention
this here.  Please take the second part of the sentence out.

364	   If an attacker wants to hijack the DR role, it may send PIM Hello
365	   message with the altered DR/BDR Address options.  The attacker sends
366	   the Hello message with the DR Address option set to itself as DR
367	   except for the highest priority or IP address.  Or the attacker sends
368	   the Hello message without the DR/BDR Address option except for the
369	   highest priority or IP address.

371	   If an attacker wants to take the BDR role, it simply sends PIM Hello
372	   message with BDR Address options except for the higher priority or IP
373	   address than the current BDR.

[] "except" is used in a couple of places, apparently, to indicate a
condition, not an exception.  That makes the text unclear.

Suggestion>

   A rogue router can become the DR/BDR by appropriately crafting the
   Address options to include a more desirable IP address or priority.
   Because the election algorithm makes the DR role be non-preemptive, an
   attacker can then take control for long periods of time.  The effect of
   these actions can result in multicast flows not being forwarded (already
   considered in [rfc7761]).


375	   Some security measures, such as IP address filtering for the
376	   election, may be taken to avoid these situations.  For example, the
377	   Hello message received from an unknown neighbor is ignored by the
378	   election process.

[major] When is a neighbor unknown?  Then a router first starts, all
the neighbors are unknown!  This type of filtering can't stop an
attacker who takes over a known neighbor.


380	7.  IANA Considerations

382	   IANA is requested to allocate two new code points from the "PIM-Hello
383	   Options" registry.

385	               +------+--------------------+---------------+
386	               | Type | Description        | Reference     |
387	               +------+--------------------+---------------+
388	               | 37   | DR Address Option  | This Document |
389	               | 38   | BDR Address Option | This Document |
390	               +------+--------------------+---------------+

[major] As mentioned above, please don't include values that haven't
been assigned by IANA!


...
401	9.1.  Normative References
...
412	   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
413	              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
414	              <https://www.rfc-editor.org/info/rfc5880>.

[] This reference can be Informative.