Jeff - Inline - hopefully more readable than before...
> -----Original Message----- > From: Jeffrey Haas <jh...@pfrc.org> > Sent: Thursday, October 25, 2018 8:38 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Naiming Shen (naiming) <naim...@cisco.com>; Reshad Rahman > (rrahman) <rrah...@cisco.com>; rtg-bfd@ietf.org > Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets > > Les, > > I *think* the following text is yours. [Les:] Yes - it is. > > > 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 [Les:] I have read this draft - not sure how relevant it is. Naiming had suggested that MTU sized packets need not be sent all the time but only occasionally - and that a failure might not be used to take the BFD session down - rather it would be seen as a "soft-failure" and reported separately from the BFD session state. My response was in that context - which it seems was also in your mind in your BFD Echo proposal. This, however, seems not to be what Albert has in mind - as he has since commented that he really wants to have sub-second detection of MTU issues and he wants traffic rerouted "immediately". Les > > > > -- Jeff
