Telechat Review of draft-ietf-pim-source-discovery-bsr-08
review-ietf-pim-source-discovery-bsr-08-tsvart-telechat-black-2018-01-23-00

• Status
• Email expansions
• History

• Versions
• 00

This document uses flooding and therefore should be checked overload considerations. Thx!

Review
review-ietf-pim-source-discovery-bsr-08-tsvart-telechat-black-2018-01-23

I've reviewed this document as part of TSV-ART's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised.  When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

This draft describes an experimental PFM (PIM Flooding Mechanism) mechanism for flooding PIM information among multicast routers that is a generalized form of the RFC 5059 PIM BSR (BootStrap Router) mechanism, and applies this mechanism to distribution of source group mappings (PFM-SD).

Early implementation experience with PFM-SD on low bandwidth radio links (described Section 2) suggests that the mechanism is able to work better than PIM-SM without starving other traffic in the fashion that PIM-DM may.  This is promising and (in this reviewer's opinion) justifies experimentation at larger scale and in other network environments.  In general, this is a well-written document and the authors should be commended for including the "running code" implementation experience report in Section 2.

Flooding mechanisms are very useful, but the time periods that govern sending of flooding messages are crucial to avoid excessive consumption of network resources.  Section 5 of RFC 5059 has a solid discussion of the time periods that apply to use of flooding by the BSR mechanism.   The discussion in this draft is somewhat weaker, raising a couple of minor issues:

1) For PFM-SD, Section 4.2 provides a reasonable discussion of time periods that apply, but appears to be missing a minimum time period between sending messages.   Section 5 of RFC 5059 recommends a default of 10 seconds for that minimum time period by comparison to a default PIM BSR sending interval of 60 seconds.  That 10 second minimum default should be added to this draft, as the same default sending interval of 60 seconds is used.

2) For future use of PFM for other purposes, Section 3.3 provides the following guidance:

   Each TLV definition will need to define when a triggered PFM message needs to be originated,
   and also whether to send periodic messages, and how frequent.

That guidance is correct as far as it goes, but it's not particularly helpful to future protocol designers.   Text should be added to at least point to the examples in section 4.2 of this draft and/or part of Section 5 of RFC 5059 to suggest the sorts of values that have proven to be workable, and perhaps also strongly encourage (SHOULD use) a default minimum time between messages of at least 10 seconds.

Understanding this draft requires that the reader be familiar with multicast and PIM, which is reasonable.  In addition, an understanding of PIM BSR is also required, which is perhaps somewhat less reasonable.  An example that this reviewer tripped over is that Section 3 of this draft states that "Like BSR, messages are forwarded hop by hop."  There is no further explanation or definition of "forwarded hop by hop," making it necessary to consult RFC 5059 to understand that term, e.g., this has nothing to do with IPv6 hop-by-hop options.  A sentence or two of explanation of this hop by hop forwarding concept ought to be copied and adapted from RFC 5059, and it would be good to check for other concepts that rely on RFC 5059 for definitions.