Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)

[Martin Vigoureux <[e-mail]>]

Hello Mirja,

thanks for your review. Please see few reactions in-line. I'm not 
speaking for the authors so I'll let them chime in and agree/disagree.

-m

Le 2018-07-03 à 20:31, Mirja Kühlewind a écrit :
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-bfd-multipoint-18: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This mechanism has the potentially to easily overload the network as there is
> no handshake and therefore also no feedback mechanism (as already noted by the
> TSV-ART review of Bob - Thanks!). Regarding the base spec in RFC5880, this
> mechanism can only be used under certain constrains which should be clearly
> stated in this doc, which are:
> 
> 1) See sec 6.8.1 of RFC5880:
> "bfd.DesiredMinTxInterval
>        [...] The actual
>        interval is negotiated between the two systems.  This MUST be
>        initialized to a value of at least one second (1,000,000
>        microseconds) according to the rules described in section 6.8.3."
> As there no negotiation in this spec, bfd.DesiredMinTxInterval MUST always be
> at least one second. Actually RFC8085 even recommend 3 sec (see sec 3.1.3).
This spec does not change the base spec (5880) on that matter, so 
bfd.DesiredMinTxInterval will be initialized to at least 1 second and 
because there is no negotiation this will also be the effective transmit 
interval.
So, I'm not sure what should be added to the document.

> 
> 2) See sec 7 of RFC 8085
> "When BFD is used across multiple hops, a congestion control mechanism
>     MUST be implemented, and when congestion is detected, the BFD
>     implementation MUST reduce the amount of traffic it generates. "
> As there is no feedback and therefore no congestion control, this spec can only
> be used for one-hop scenarios and the TTL or Hop Count MUST be set to one.
5880 and this document make no assumption on the encapsulation of the 
BFD packet so it would be difficult to set a requirement on TTL/hop count.

> 
> 3) Also given the traffic load multipoint BFD generates depends on the number
> of active session, and there is no feedback mechanism, I recommend to also
> limit the number of active session of MultipointHead type to a small number
> (per link).
I'm not sure we'd be able to set anything else than a random number 
here. An upper limit might very well be meaningful in a given 
environment but not in an other. Also, if the rate is one packet per 
second I doubt that it would generate an important load compared to the 
actual traffic on the tree.
Yet, maybe it wouldn't hurt to have the following in the Security 
Considerations:
       The implementation should have a reasonable upper bound on the
       number of MultipointHead sessions that can be created, with the
       upper bound potentially being computed based on the load these
       would generate.



> 
> 
> 
> 
>