RE: BFD stability follow-up from IETF-91

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

Mach,
   Thanks for your comments. Please see inline. 

> 
> This triggers me think out there should be another solution for getting the Tx
> and Rx timestamps without encoding the timestamps in the BFD packets. For
> example, the Tx and Rx systems could just save timestamps locally or send
> them to a centralized entity and then use the sequence numbers to correlate
> them for further analyzing.

This will help but it won't really tell where was the delay right? And it looks more like a implementation? 


Thanks
Santosh P K 

> >
> >
> > Regards, Marc
> >
> >
> >
> >
> >
> >
> > On Wed, 26 Nov 2014 12:26:41 +0530, Manav Bhatia wrote:
> > > Hi Jeff,
> > >
> > > 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.
> > >
> > > The current proposal does help but is not complete.
> > >
> > > Assume that the RX end loses a BFD session and learns later that it
> > > did eventually receive the missing BFD packets (based on the seq #).
> > > How would it know which end was misbehaving? Was it a delay at the
> > > TX side, or was it the RX that delayed passing the packets to the
> > > BFD process(or). This is usually what we want to debug and i want to
> > > understand how this draft with sequence numbers can unequivocally
> > > tell me that.
> > >
> > > 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.
> > >
> > > Cheers, Manav
> > >
> > >
> > > 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
> > >>
> > >