RE: BFD stability follow-up from IETF-91

[Gregory Mirsky <[e-mail]>]

Dear All,
are we turning BFD into 1588? It does seem like that by the extent of our discussion of timestamping issue.
The PTP has two methods of measuring Resident Time, time a packet spent in a node (I feel that is what we're trying to measure by collecting timestamps):
*       one-step - resident time measured on a packet and reported in the same packet;
*       two-step - more elaborate as it requires source port identification, sequence number and proper type of a packet. Residence time measured on one packet but reported in the follow-up of appropriate type.
Does that sounds like what we're discussing?

        Regards,
                Greg

-----Original Message-----
From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Mach Chen
Sent: Wednesday, November 26, 2014 1:18 AM
To: Marc Binderberger; Manav Bhatia
Cc: [e-mail]
Subject: RE: BFD stability follow-up from IETF-91

Hi Marc and Manav,

> -----Original Message-----
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Marc
> Binderberger
> Sent: Wednesday, November 26, 2014 4:50 PM
> To: Manav Bhatia
> Cc: [e-mail]<mailto:[e-mail]>
> Subject: Re: BFD stability follow-up from IETF-91
>
> Hello Manav,
>
> > I believe the work is important and addresses something thats really
> > required (spent too much time debugging why BFD flapped!).
>
> agree :-) we should keep the discussion alive.
>
>
> > 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)
>
> well, I can see a point in having the Tx timestamps in the packet
> mainly for the purpose of knowing "this" packet was okay/not okay on
> the Tx side and to correlate it with your local Rx measurement.

Yes, this is one solution if people think BFD delay is needed. If allow to have Tx timestamps to be carried in the packets, seems it should be no problem to leave a seat for the Rx timestamps as well :-). After all, with both Tx and Rx timestamp, it may simplify the implementation.

>
> And even this point is less relevant with sequence numbers as this
> number allows the identification of packets and thus the correlation
> of information from the Tx and Rx system.

Indeed, the sequence number helps a lot for the correlation between the Tx and Rx system.

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.

Best regards,
Mach

>
>
> 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]<mailto:[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
> >>
> >