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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Jeff,

sorry for the very late reply. Please see below.

> Am 11.07.2018 um 02:13 schrieb 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?

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