Re: BFD stability follow-up from IETF-91

[Abhishek Verma <[e-mail]>]

Hi,


> > I think the problem of diagnosing a BFD flap becomes all the more
> important
> > with BFD authentication turned on since then we have more points where a
> > delay can be inserted.
>
> I agree with this and as a developer have seen this happening.
>

Agree with Santosh. This mechanism would be most needed when authentication
is turned on.

Abhishek


>
> Thanks
> Santosh P K
>
> > On Thu, Nov 27, 2014 at 8:32 PM, Santosh P K <[e-mail]>
> > wrote:
> > > 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.ppt
> > >> >> >>>> x
> > >> >> >>>>
> > >> >> >>>> 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
> > >> >> >>>>
> > >> >> >>>
> > >> >> >
> > >> >
> > >
>