RE: BFD WG adoption for draft-haas-bfd-large-packets

["Les Ginsberg (ginsberg)" <[e-mail]>]

Jeff -

Inline - hopefully more readable than before...

> -----Original Message-----
> From: Jeffrey Haas <[e-mail]>
> Sent: Thursday, October 25, 2018 8:38 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Naiming Shen (naiming) <[e-mail]>; Reshad Rahman
> (rrahman) <[e-mail]>; [e-mail]
> 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