Re: BFD stability follow-up from IETF-91

[Manav Bhatia <[e-mail]>]

Hi Santosh,

>> the seq numbers at the *end* of the BFD packet. This would not be covered
>> in the Length field carried in the BFD header but would be accounted for in
>> the length carried in the IP header. The concept of attaching a trailer is
>> documented well and is used in the IGPs. RFC 6506 describes one such trailer
>
> You are suggesting to add the debug trailer with or without authentication right?

without.

>
>
>> for OSPFv3. The catch however is that this debug trailer will NOT be covered
>> by the BFD authentication. Is this acceptable to the WG?
>
> I did not get this. Did you mean the length of the auth TVL will not include this length and will be only in IP header?

Yes, it would only be in the IP header.

Cheers, Manav

>
>> 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.
>
> 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
>> >> >> >>>>
>> >> >> >>>
>> >> >> >
>> >> >
>> >