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

[Jeffrey Haas <[e-mail]>]

Mirja,

On Mon, Jul 09, 2018 at 04:01:22PM +0200, Mirja Kuehlewind (IETF) wrote:
> > Am 05.07.2018 um 21:27 schrieb Greg Mirsky <[e-mail]>:
> > 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 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.

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 there is not feedback what clearly indicated that there is a receiver listing at the other end. 

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

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