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

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 03 Jul 2018 11:31:40 -0700

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).

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.

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).

---

From: Martin Vigoureux <[email-masked]>
Date: Wed, 4 Jul 2018 17:54:55 +0200

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

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
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.

> 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.

> limit the number of active session of MultipointHead type to a small number
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.

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jul 2018 12:27:49 -0700

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

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/
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.

>    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.

> 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).

> limit the number of active session of MultipointHead type to a small number
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.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 5 Jul 2018 22:26:09 +0200

Hi Greg,

just one thing quickly

> Am 05.07.2018 um 21:27 schrieb Greg Mirsky <[email-masked]>:
> 
> 2) See sec 7 of RFC 8085
> 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. 
This quote is from RFC5880. The BFD base spec. Sorry that was copy and past error!

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jul 2018 14:15:33 -0700

Hi Mirja,
thank you for the clarification. I believe that the required action and use
of MUST, in this case, is too strong as it defeats the purpose of FM OAM by
hiding the problem rather than detecting and signaling it.

Regards,
Greg

On Thu, Jul 5, 2018 at 1:26 PM, Mirja Kuehlewind (IETF) <[email-masked]

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 9 Jul 2018 16:01:22 +0200

Hi Greg,

please see below.

> 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 <[email-masked]> wrote:
> 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:
> I believe that systems that intended to use mpBFD should use RFC 7419 as guidance.
> Also, consider two proposals to use mpBFD in VRRP and PIM-SM 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.

I understand that this makes failure detection harder, however, the BFD base spec has a feedback mechanism that can be used to limit the rate, e.g. if the receiver is overloaded. This is not the case for multipoint BFD and therefore a higher interval than 1 sec is not permitted by the BFD base spec.

> 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).

Again, I understand the concern here about being very restrictive, however, this is what is specified in the BFD base spec in RFC5880 and you would need to update the base spec if you would like to change this.

However, even if you update/remove the restriction, you would still need to specify additional safety measures to ensure that no BFD packets overflow the whole network or leak to other networks, as there is not feedback what clearly indicated that there is a receiver listing at the other end. 
> 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:

More guidance is needed to specify what „reasonable“ means here. 

All these point were also discussed with Martin at the last telechat. Please consult further with him.

Thanks!
Mirja

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jul 2018 20:13:29 -0400

Mirja,

> I understand that this makes failure detection harder, however, the BFD base spec has a feedback mechanism that can be used to limit the rate, e.g. if the receiver is overloaded. This is not the ca…

Let me pose the issue a different way: 
What is the general text the IESG wants out of multicast senders (ASM,
SSM, e.g.) with potentially passive receivers to avoid such overload?

> However, even if you update/remove the restriction, you would still need to specify additional safety measures to ensure that no BFD packets overflow the whole network or leak to other networks, as…

What is the text the IESG wants out of multicast signaling protocols and
senders  to avoid this concern?

> More guidance is needed to specify what „reasonable“ means here. 

What is the text the IESG wants out of multicast signaling protocols to
restrict the numbers of joins to either a source in source-specific
protocols, or to rendezvous points in such mechanisms?

-- Jeff