Re: BFD stability follow-up from IETF-91

[Manav Bhatia <[e-mail]>]

I am not sure what the confusion is Greg.

Assume i have a BFD session thats up. At some point in time it flaps. Now i
need to know whether the issue was at the TX or the RX.

Please tell me how TWAMP can help me here. Also tell me how what tool i can
use if its a uBFD session that flapped.

Cheers, Manav

On Thu, Dec 4, 2014 at 9:09 PM, Gregory Mirsky <[e-mail]>
wrote:

>  Hi Santosh,
>
> but that is what can be called “feature creep”. BFD is continuity check
> mechanism and for active performance measurement, even occasional, there
> are TWAMP in IP and RFC 6374/6375 in MPLS/MPLS-TP. It may be tempting to
> expand scope of BFD but, I believe, it is successful exactly because it was
> simple, light-weight and designed to do exactly one thing – continuity
> check.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Santosh P K [mailto:[e-mail]]
> *Sent:* Thursday, December 04, 2014 7:02 AM
> *To:* Gregory Mirsky; Mahesh Jethanandani
>
> *Cc:* [e-mail]
> *Subject:* RE: BFD stability follow-up from IETF-91
>
>
>
> Hello Greg,
>
>   Debugging BFD is one of the use case. I also want to bring up one of the
> use case that Jeff suggested in his earlier  mail. Operator might NOT want
> to run OAM which does loss and delay measurement all the time due to its
> overhead. With the extension to BFD (sequence number) we can detect if
> there is any loss but BFD still stays up. This loss detection can be used
> as a trigger for loss and delay measurement. Echo can be used only in case
> of singlehop and in one direction only.
>
>
>
> Thanks
>
> Santosh P K
>
>
>
> *From:* Rtg-bfd [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Gregory Mirsky
> *Sent:* Thursday, December 04, 2014 12:12 PM
> *To:* Mahesh Jethanandani
> *Cc:* [e-mail]
> *Subject:* RE: BFD stability follow-up from IETF-91
>
>
>
> Hi Mahesh,
>
> indeed, LSP Ping is part of MPLS OAM tool set as BFD itself that intended
> to monitor operational state of the network, path continuity between two
> nodes. And LSP Ping, as primarily on-demand troubleshooting tool, helps
> localize and, to certain degree, diagnose the problem. But the ultimate
> debugging is proprietary. This proposal, in my view, helps not monitor
> behavior of the network but BFD itself, quality of BFD implementation. I’m
> not saying that it is not useful for implementers and operators, one can
> find that too many BFD sessions or at too short intervals being  ran. I
> don’t agree to loading this as extension of the widely used standard.
> Perhaps we can look into using BFD Echo as self-debugging instrument.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Mahesh Jethanandani [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Wednesday, December 03, 2014 10:23 PM
> *To:* Gregory Mirsky
> *Cc:* Fan, Peng; MALLIK MUDIGONDA (mmudigon); [e-mail]
> *Subject:* Re: BFD stability follow-up from IETF-91
>
>
>
> Greg,
>
>
>
> I believe we have a disagreement here. I do not believe that issue of
> debug ability are outside the scope of a standardized protocol.
>
>
>
> Look at MPLS ping and traceroute (RFC 4379) . They are ultimately debug
> tools used to establish viability of a path and they are very much part of
> the standardized protocol.
>
>
>
>  On Dec 3, 2014, at 3:25 PM, Gregory Mirsky <[e-mail]>
> wrote:
>
>
>
> Hi Mahesh,
>
> I consider issues of debugability, not of just BFD but any other
> standardized protocol, to be outside of Standard track, at most to be
> suitable for Informational or Experimental track. If we agree on that, then
> we can discuss scenarios that present problem and investigate whether
> anything in the protocol requires clarification to help vendors in building
> well-performing, scalable and interoperable implementations and provide
> operational guidelines for operators.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Mahesh Jethanandani [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Tuesday, December 02, 2014 8:46 PM
> *To:* Gregory Mirsky
> *Cc:* Fan, Peng; MALLIK MUDIGONDA (mmudigon); [e-mail]
> *Subject:* Re: BFD stability follow-up from IETF-91
>
>
>
> Greg,
>
>
>
> What is Peng referring to is a way to figure out why a particular BFD
> session flapped, particularly if the packet(s) for that session arrive
> late. I do not see how that can be performance measurement. It is basic BFD
> debug ability. Running a separate DM does tell you why a particular BFD
> session flapped.
>
>
>
> Now we can debate what methods can be employed to measure that delay and I
> am open to ways to doing it, including local loopback to measure transmit
> delays or time stamping of packets in hardware. But in cases, where there
> is no support for either of the capabilities, one of the suggested
> solutions is to use the time stamps carried in the BFD payload.
>
>
>
> Cheers.
>
>
>
>  On Dec 1, 2014, at 9:38 AM, Gregory Mirsky <[e-mail]>
> wrote:
>
>
>
> Hi Peng,
>
> and still, you’re looking for a tool to measure BFD performance. Then
> you’ll be looking for a tool to verify the BFD performance measurement, and
> on, and on. Operators do need complete set of FCAPS tools, including
> performance measurement. Note that passive performance measurement through
> marking method that Mach Chen referred to can monitor BFD flow(s) and be
> used to do Loss and/or Delay Measurement. And active Synthetic Loss
> Measurement may simulate flow of small packets as well as relatively large
> packets. And the same goes for active measurement method of Delay
> Measurement. I like Swiss Army knives but let us not turn BFD into one.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Fan, Peng [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Monday, December 01, 2014 4:44 AM
> *To:* Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; [e-mail]
> *Subject:* RE: BFD stability follow-up from IETF-91
>
>
>
> Hi Gregory,
>
>
>
> I was just giving an example :) Application traffic usually cannot stand
> small packet loss, not to say 30% loss.
>
>
>
> I am actually asking for a debug function that could give us some useful
> hints of poor connection with small protocol change, besides the basic
> connectivity information. If it measures something, it measures packets of
> BFD itself. So I don’t expect it to be considered as a performance
> measurement tool.
>
>
>
> Best regards,
>
> Peng
>
>
>
> *From:* Gregory Mirsky [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Saturday, November 29, 2014 3:37 AM
> *To:* Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; [e-mail]
> *Subject:* RE: BFD stability follow-up from IETF-91
>
>
>
> Hi Peng,
>
> this is very interesting scenario. I think that if BFD experiences ~30%
> packet loss, then highly likely so are affected other applications. Then it
> is not just BFD issue but condition that should be detected  by performance
> measurement method, whether active or passive packet loss measurement.
>
> I’m convinced that overloading BFD with performance measurement provisions
> is counter-productive and is inappropriate.
>
>
>
>                 Regards,
>
>                                 Greg
>
>
>
> *From:* Rtg-bfd [mailto:[e-mail]
> <[e-mail]>] *On Behalf Of *Fan, Peng
> *Sent:* Friday, November 28, 2014 4:34 AM
> *To:* 'MALLIK MUDIGONDA (mmudigon)'; [e-mail]
> *Subject:* RE: BFD stability follow-up from IETF-91
>
>
>
> Hi Mallik,
>
>
>
> Exactly. Packets may be experiencing slight loss, but the link can hardly
> be regarded as connected. More importantly, the experience of upper-level
> applications can be degraded severely (e.g. TCP traffic is not able to go
> fast in face of even small continuous loss). But what if one BFD frame is
> lost every three frames? Then the loss rate is 30% on average, which is
> already a very severe value.
>
>
>
> Best regards,
>
> Peng
>
>
>
> *From:* MALLIK MUDIGONDA (mmudigon) [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Friday, November 28, 2014 7:53 PM
> *To:* Fan, Peng; [e-mail]
> *Subject:* Re: BFD stability follow-up from IETF-91
>
>
>
> Hi Peng,
>
>
>
> If the BFD packets are lost, doesn’t the BFD session go DOWN? Are you
> saying that packet loss is not big enough to make BFD session go DOWN?
>
>
>
> Thanks
>
>
>
> Regards
>
> Mallik
>
>
>
> *From: *<Fan>, Peng <[e-mail]>
> *Date: *Friday, 28 November 2014 4:20 pm
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *RE: BFD stability follow-up from IETF-91
>
>
>
> Hi Jeff, all,
>
>
>
> I have been following this stability extension from the beginning, and as
> an
>
> operator I would like to express that this draft enables the "advanced
>
> feature" we desire for BFD to provide additional useful information that
>
> helps operators understand network issues. A relevant use case is detecting
>
> lossy or "quasi-disconnected" links or member LAG links. An example of such
>
> situation we experienced was a loosely connected fiber link resulting in
>
> continuous, small amount of packet loss. BFD could get the information of
>
> lost BFD frames on such unstable link, and probably report when a target
>
> level is reached, say a certain number of frames are lost over a period or
>
> among a total number of frames.
>
>
>
> Best regards,
>
> Peng
>
>
>
> Mahesh Jethanandani
>
> Co-chair, NETCONF WG
>
> [e-mail]
>
>
>
> Mahesh Jethanandani
>
> Co-chair, NETCONF WG
>
> [e-mail]
>
>
>
>
>
>
>