RE: BFD stability follow-up from IETF-91

[Santosh P K <[e-mail]>]

Manav,
   Thanks for your comments and sorry for late response. Please see inline. 

> I vividly remember the original intent of the stability draft was to help debug
> BFD failures -- to isolate the issue at the RX or the TX side Time stamping
> would have helped in debugging whether the BFD packet was sent late, or
> whether the packet was sent on time and also arrived on time but was
> delayed when passing it up the BFD stack/processor (lay in the RX buffer for
> tad too long), etc. But then time stamping came with its own set of issues,
> and was hence dropped from the original draft.
> Can the authors send a summary on the list on why time stamping was
> dropped so that we're all clear on that one.

Timestamp will  help but there were comments about BFD stepping in to other protocols which are already doing it. Also there were comments about timestamping for aggressive protocol like BFD would be feasible. We can make timestamping as optional, but we should be careful not step in to other protocols?

> The current proposal does help but is not complete.

For loss detection it will help but not for delay. I agree. 

> 
> I believe the work is important and addresses something thats really
> required (spent too much time debugging why BFD flapped!). Clearly what
> would help is putting a small section that describes how we can use the
> sequence numbers to debug what and where things went wrong.

I agree, we are planning to add use case and also how we sequence number can be useful. 



Thanks
Santosh P K

 

> On Wed, Nov 26, 2014 at 5:49 AM, Jeffrey Haas <[e-mail]> wrote:
> > draft-ashesh-bfd-stability-01 was presented again during IETF-91 in
> > Honolulu.  The slides can be viewed here:
> >
> > http://www.ietf.org/proceedings/91/slides/slides-91-bfd-4.pptx
> >
> > To attempt to simplify the presentation, the contentious portion of
> > the timers were removed from the proposal, leaving only the sequence
> > numbering for detecting loss of BFD async packets.
> >
> > When the room was polled to see whether the draft should be adopted as
> > a WG item, the sense of the room was very quiet.  As promised, this is
> > to inquire for support for this draft on the WG mailing list to make
> > sure the whole group has a voice.
> >
> > It should be noted that post-meeting discussion on the fate of this
> > draft noted that BFD authentication code points are plentiful and are
> > available with expert review.  Should the draft authors wish to
> > continue this work as Experimental, that is an option.
> >
> > -- Jeff
> >