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

[Martin Vigoureux <[e-mail]>]

Hello Mirja,

time has passed since the last exchanges on that. To reinitiate the 
discussion, I come back to your original points.


Le 2018-07-03 à 20:31, Mirja Kühlewind a écrit :
> 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).

There are two aspects to this.
First, draft-ietf-bfd-multipoint is consistent with 5880 on the 
initialization. So I think we are on the safe side.
Second, limiting a variable to only take certain values seems to me as 
being outside the scope of a protocol spec. We are touching there 
operational considerations.
If a user needs and wants to set a variable to a given value in a 
specific environment we can't forbid that. We can however raise his 
awareness on the potential consequences of a given choice.

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

Rather than limiting the use cases of bfd-multipoint, I think we should 
set the same constraints than in base BFD spec.

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

x.  Operational Considerations

    Use of BFD in multipoint networks, as specified in this document,
    over multiple hops requires consideration of the mechanisms to react
    to network congestion.  Requirements stated in Section 7 of the BFD
    base specification [RFC5880] equally apply to BFD in multipoint
    networks.

    Furthermore, because a tail does not transmit any BFD Control packets
    to the head of the BFD session, Min RX Interval cannot be used to
    control the BFD packet transmission rate at the MultipointHead.  The
    mechanism to control the load of BFD traffic MAY use BFD's
    configuration interface to control BFD state variable
    bfd.DesiredMinTxInterval. Details of the interface and the mechanism
    itself are outside the scope of this document.

    Also, enabling BFD in such environments should be done considering
    the recommendations laid out in RFC 8085 [RFC8085].


I really hope that to be ok for the document to move forward.

Thank you
-m