Hi Jeff, sorry for the very late reply. Please see below.
> Am 11.07.2018 um 02:13 schrieb Jeffrey Haas <jh...@pfrc.org>: > > 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? The IETF’s recommendation for this case in RFC8085 section 4 which refers to section 3.1.3 for your use case respectively. Section 3.1.1 recommends to not send more then one package per 3 sec. The BFD base spec already has a lower limit of 1 sec. Given this is a BFD extension this is the specified limit this spec needs to align to. If you want to send at a higher rate, RFC8085 recommend to implement some kind of congestion control. > >> 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? You would need to add some kind of congestion control/feedback multicast receiver to the sender to reduce the rate or determinate the connection to the congested receiver (circuit breaker). > >>> 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? The spec could specify a default value and explain when this default value is applicable or in which scenarios the default may be changed based on the given network conditions. Mirja > > -- Jeff
