RE: BFD stability follow-up from IETF-91

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

Manav,
    This is good question. 

> Can the authors add some text on how this debugging mechanism would
> work if somebody employs BFD authentication?

Right now we have considered without authentication (we are setting A bit). We should add some text on how we can use both Auth and de bug TLV. Is there any suggestion you have? I will get back to you on this. 


Thanks
Santosh P K

> > -----Original Message-----
> > From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Mach Chen
> > Sent: Thursday, November 27, 2014 2:13 PM
> > To: Marc Binderberger
> > Cc: [e-mail]
> > Subject: RE: BFD stability follow-up from IETF-91
> >
> > Hi Marc,
> >
> >> -----Original Message-----
> >> From: Marc Binderberger [mailto:[e-mail]]
> >> Sent: Thursday, November 27, 2014 1:43 AM
> >> To: Mach Chen
> >> Cc: Manav Bhatia; [e-mail]
> >> Subject: RE: BFD stability follow-up from IETF-91
> >>
> >> Hello Mach,
> >>
> >> > 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.
> >>
> >> I remember some discussion on NVO3 about how many bits it takes ;-) -
> >> could you send the links/draft names you are working on to this list?
> >> May be useful for further discussions.
> >
> > Sure, here is the link(http://tools.ietf.org/html/draft-chen-ippm-coloring-
> based-ipfpm-framework-02) for the reference.
> >
> > But here I want to say is that since we have sequence number, we may not
> need the marking based solution. Suppose that someone want to monitor
> the delay of a BFD packet , just record and save the timestamp at the Tx side,
> which indexed by the sequence number. Similarly, do the same at the Rx
> side. Then based on the timestamps from both Tx and Rx, and using the
> sequence number to correlate the timestamps, it can also provide a way to
> monitor the delay of the BFD packet.
> >
> > That means, only if there is sequence number, even if without carrying the
> timestamp in the BFD packet, BFD packet delay can be measured.
> >
> > Best regards,
> > Mach
> >
> >>
> >>
> >> Thanks & Regards,
> >> Marc
> >>
> >>
> >>
> >> On Wed, 26 Nov 2014 09:17:32 +0000, Mach Chen wrote:
> >> > 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]
> >> >> 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]>
> 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
> >> >>>>
> >> >>>
> >> >
> >