Hi Jeff,
please see below.
On 15.10.18 20:30, Jeffrey Haas wrote:
Mirja,
You keep waving around RFC 8085 as a panacea.
My discuss is actually based on what is specified in the BFD base spec
in RFC5880. I'm only pointing you to RFC8085 because this RFC gives
guidance how to resolve the issue. See further below.
Consider:
: 4.1. Multicast Congestion Control Guidelines
:
: Applications using multicast SHOULD provide appropriate congestion
: control.
Firstly, it's a SHOULD, and not a MUST. Also, I believe we've made the
point more than once that BFD is used by an application set and it's free as
part of using BFD in multipoint mode to tune BFD. BFD is intentionally not
self-tuning.
Yes, it's a SHOULD because for protocol usage guidance there is no
absolute thing. However, BFD as a user of UDP needs to care more
specifically about these issue. If there is also no absolute answer for
BFD, you must at least give further guidance on what to do in which
situation. What's the normal user behavior and what to do in that
situation and when is it okay to do something different...?
By analogy to the single hop unicast scenario, one doesn't expect BFD in the
face of congestion protecting the forwarding path for fast re-route
behaviors to slow down.
This is (more or less) inline with RFC8085 because the load is limited
to one message per second which is a low enough that it would be
overkill to require congestion control. This is not the case for
multipoint BFD, as the load is basically unlimited given it scales with
the the number of "points" and DesiredMinTxInterval can not be
dynamically negotiated/adapted.
The point is that it *starts dropping packets* and
the BFD session drops. Similarly, if a multipoint consumer of BFD sessions
starts having issues with forwarding, or something along the same path
(typically a multicast S,G), the expectation is that *it does something*.
Yes, but the multipoint BDF spec needs to define what this *something*
is. If you just say do something, people won't do anything because they
don't know what this something should be.
This may include switching to a different path.
This is also covered in section 4.1 of 8085:
: o Receiver-driven congestion control, which does not require a
: receiver to send explicit UDP control messages for congestion
: control (e.g., [RFC3738], [RFC5775]). Instead, the sender
: distributes the data across multiple IP multicast groups (e.g.,
: using a set of {S,G} channels). Each receiver determines its own
: level of congestion and controls its reception rate using only
: multicast join/leave messages sent in the network control plane.
: This method scales to arbitrary large groups of receivers.
Multicast networks will set the BFD configuration based on what their
expectations are for protection. IETF can't blanketly tell users "you're
not allowed ot use BFD protection greater than X" nor can we arbitrarily
tell them we won't let them use a protocol intended to run at a high rate
that they can't do that. In most cases, vendors are pushed to go for faster
detection times, not slower.
Regarding the text you cite from RFC8085 above, this is exactly the
problem. There is no way in the multiploint BFD set up for the tail to
tell the head to stop sending (or leave the multicast group using the
wording from above).
You can readily argue that BFD Multipoint shouldn't be used for generic
Internet multicast (e.g. mbone). Fine - don't use it there. But mbone
hasn't been the useful scenario for the deployment of multicast for the
majority of my career, nor is it the one that is the one funding the
vendors.
If BDF is restricted to certain scenarios where there is a different way
to make sure the tail and the network between the tail and head cannot
be permanently overload, then this need to be explicitly stated and
explained why that is the case in the draft (e.g. add an applicability
section).
I strongly request that if the above text from 8085 doesn't convince you to
clear your discuss that you help arrange for a voice call to iterate over
lingering concerns sooner than later. The chairs won't be attending IETF
103, sadly. We'll find an agreeable time.
Once again RFC8085 does not provide solutions; you cannot simply point
to RFC8085 and say do this. RFC8085 is a guidelines document that helps
you to design your UDP-based protocol in a safe way and the protocol
design that is using UDP needs to address the recommendations and
concerns raised in RFC8085. This is missing here and I can't help you to
find the right technical solution; i can only point you at RFC8085 for
further guidance. If that does not help you, I can try and find you
someone else with transport/UDP expertise (usually I would ask one of
the RFC8085 authors) and see if they have time to work with you. I
certainly unfortunately don't have the time to work on a technical
solution with you.
Mirja
-- Jeff
On Mon, Oct 15, 2018 at 01:59:30PM +0200, Mirja Kuehlewind (IETF) wrote:
Hi Martin,
please see below.
Am 05.10.2018 um 10:57 schrieb Martin Vigoureux <[email protected]>:
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.
I completely disagree. That’s what a spec is for.
The point here is, that if you would want a smaller value, the network and
system low gets higher and RFC8085 require congestion control. If no congested
control is used or cannot be used, a lower value is not safe.
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.
You can enforce people implementing the spec correctly but you can specify the
protocol correctly in order to make it safe to deploy it. If there are actual
environment where a lower is safe to use that can be explicitly stated in the
spec, however, if the talk about a part of the Internet (but not a data center
or another separated, fully controlled environment) I don’t an exception is
safe.
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.
One-hop is the constraint given in the base 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].
In this case it is really not enough to say „please read RFC8085“. RFC8085 are
consideration for the design of UDP based protocol and must be applied by the
spec/protocol designer not the user.
Mirja
I really hope that to be ok for the document to move forward.
Thank you
-m
