Hi Mirja, thank you for the review and your comments. Please find my answers in-line and tagged GIM>>.
Regards, Greg On Tue, Jul 3, 2018 at 11:31 AM, Mirja Kühlewind <i...@kuehlewind.net> wrote: > 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). > 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 <https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/> and PIM-SM <https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/?include_text=1> 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. > > 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. " > GIM>> I couldn't find this in RFC 8085 and had to broaden my search. I believe that thsi quote is from RFC 7880 Seamless BFD. I'm puzzled why this specification, when talking about challenges S-BFD may face, switches to requirement for BFD. Doesn't look right. And more, increasing transmission interval to avoid packet drop defeats the purpose of using proactive defect detection mechanism. The purpose of the fault management is to detect failures, not to avoid the detection. If active OAM generates excess of traffic, then other OAM mechanisms can be considered and used. But loosening OAM is not, in my view, proper way to address network problem as it rather hides them, not detets and reports as it intended to do. > 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.. > GIM>> For VRRP and PIM-SM use cases TTL will be set to one as that is mandated by the use cases. But making this generic requirement may be too restrictive. As Martin noted, this specification, as BFD base specification in RFC 5880, is centered on protocol, not encapsulation (with exception of the last paragraph in section 5.8 with details of IP/UDP over MPLS encapsulation). > 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.
