Re: BFD stability follow-up from IETF-91

[Manav Bhatia <[e-mail]>]

Yes, it will work for both with and without Auth.

Cheers, Manav

On Fri, Nov 28, 2014 at 6:41 PM, Santosh P K <[e-mail]> wrote:
> Hi Manav,
>       Thanks. Please see inline.
>
>> >> 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.
>
> If we can go with trailer method then it can be applicable to both with and without Auth right? I was thinking having two solution might complicate things :)?
>
>
> 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
>> >> >> >> >>>>
>> >> >> >> >>>
>> >> >> >> >
>> >> >> >
>> >> >