Re: [Tsv-art] Tsvart telechat review of draft-ietf-pim-source-discovery-bsr-08

Thanks for the quick review!

> Am 24.01.2018 um 00:40 schrieb David Black <david.black@dell.com>:
> 
> Reviewer: David Black
> Review result: Ready with Issues
> 
> 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.
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art