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 <gregimir...@gmail.com>: > > 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
