Greg, All good questions. Let me preface my comments by saying that we know what the issue is, we do not quite know what the right solution is. This is an attempt to first establish what we know or understand of a BFD session.
The issue as articulated in the draft is that BFD has worked well for fixed, predictable link characteristics. It does not do as well for links whose characteristics change all the time. > On Mar 17, 2018, at 6:00 PM, Greg Mirsky <gregimir...@gmail.com> wrote: > > Dear Authors, > I've read the new draft and have some questions that I would like us to > discuss: > which of BFD modes, Async, Demand or Echo, you envision to be used by this > new TLV; See below. > what interval between the BFD control packets with BFD Performance TLV would > you use; To begin with the idea is to take the highest interval. Then study how the actual time it takes to traverse the link, changes. > the BFD Performance TLV has space for four timestamps. Should that suggest > that only Echo mode will be used to measure delay? That would be the natural conclusion. And to your point below, we do not know whether the other end is interested in the study. > Because if you use Asunc or Demand, then I don't see the need for four > timestamp as two will be sufficient. In these modes you can only perform > one-way measurement (of course, one can envision implementation that will > read timestamp from the remote peer and copy them into the outgoing control > packet). Thus, how useful to have measurement result at the far end when it > is the sender that is interested in it? Why not to use one of existing PM OAM > tools, TWAMP, TWAMP Light or STAMP? If we need to study the behavior of BFD, it cannot be out-of-band. > Regards, > Greg Mahesh Jethanandani mjethanand...@gmail.com
