Hi,
Inline <RR>.
On 2018-10-25, 11:38 AM, "Jeffrey Haas" <jh...@pfrc.org> wrote:
Les,
I *think* the following text is yours.
On Mon, Oct 22, 2018 at 12:36:52AM +0000, Les Ginsberg (ginsberg) wrote:
> [Les:] So, this has some implications:
>
> We have both a transmit interval and a multiplier for a BFD session
because we allow that some BFD packets may be dropped for reasons which do not
represent a true loss of connectivity. Therefore up to N-1 consecutive packets
may be dropped w/o triggering a session state change. If large BFD packets are
“occasionally” inserted this means there are intervals during which N-2 packets
drops (not counting the BFD large packet) would be sufficient to trigger a BFD
session state change. Further, if the processing of the large BFD packets makes
it more likely that subsequent BFD packets will be dropped (e.g., because the
processing of the large BFD packet simply takes longer) then it is possible
that a BFD session state change might be triggered simply as a side effect of
the insertion of the large packet into the data stream.
>
> You also are now defining a “child session” which is embedded within the
parent session. BFD large packets are then not meant to influence the parent
BFD session state and therefore have to be processed separately. This – in many
ways – is equivalent to defining “another protocol”. I’ll grant it might be a
bit simpler as it can inherit some things from the parent session – but it
certainly is no longer simply a transparent part of existing BFD session
operation.
The draft I had previously worked on with Xiao Min discussing probing using
BFD Echo had the concept of probes that would happen wherein the session is
not torn down. The example carries similarly with the "send occasional".
<RR> We discussed use of echo at IETF102. The large-packets draft mentions that
echo can only be used for single-hop, hence the need for padding the control
packets. But isn't single-hop Albert's main use-case? I believe we should add
the echo option in the large-packets draft, it has the benefit that you get the
desired functionality even if only 1 side of the WAN link supports echo. I
realize not all implementations support echo so they might have to do pad
control packets instead.
Regards,
Reshad (no hat).
I suggest taking a look at a different draft that might help direct this
portion of the discussion:
https://tools.ietf.org/html/draft-ietf-bfd-stability-02
-- Jeff
