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

[Greg Mirsky <[e-mail]>]

Hi Mirja,
thank you for the review and your comments. Please find my answers in-line
and tagged GIM>>.

Regards,
Greg

On Tue, Jul 3, 2018 at 11:31 AM, Mirja Kühlewind <[e-mail]>
wrote:

> 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).
>
GIM>> I believe that such limit will negatively impact applicability of
this method to detect defects in networks. Analysis of BFD transmission
intervals provided in RFC 7419. The conclusion was:
   This document defines the set of Common Interval values to be: 3.3
   msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.
I believe that systems that intended to use mpBFD should use RFC 7419 as
guidance.
Also, consider two proposals to use mpBFD in VRRP
<https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/> and
PIM-SM
<https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/?include_text=1>
that been discussed by RTGWG and PIM WGs. The goal is to ensure sub-second
detection of head's failure by tails - Master in case of VRRP, DR in PIM-SM
case.

>
> 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. "
>
GIM>> I couldn't find this in RFC 8085 and had to broaden my search. I
believe that thsi quote is from RFC 7880 Seamless BFD. I'm puzzled why this
specification, when talking about challenges S-BFD may face, switches to
requirement for BFD. Doesn't look right. And more, increasing transmission
interval to avoid packet drop defeats the purpose of using proactive defect
detection mechanism. The purpose of the fault management is to detect
failures, not to avoid the detection. If active OAM generates excess of
traffic, then other OAM mechanisms can be considered and used. But
loosening OAM is not, in my view, proper way to address network problem as
it rather hides them, not detets and reports as it intended to do.


> 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.
>
GIM>> For VRRP and PIM-SM use cases TTL will be set to one as that is
mandated by the use cases. But making this generic requirement may be too
restrictive. As Martin noted, this specification, as BFD base specification
in RFC 5880, is centered on protocol, not encapsulation (with exception of
the last paragraph in section 5.8 with details of IP/UDP over MPLS
encapsulation).


> 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).
>
GIM>> Perhaps we can recomend limit the overall number of active sessions
so that distribution can be decided by implementation and operator. I think
that text suggested by Martin clearly communicates such recomendation to be
added to the list in the Security Considerations section:
      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.