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