Subject: Re: (about BFD echo)

From: Lokesh Bevinamarad <[email-masked]>
Date: Wed, 21 Jan 2015 17:26:40 +0530

Hello All,
As per RFC 5880, if echo function is on, it means that device is willing to
loopback the peers echo packets and advertises this by setting non zero
echo-rx value in the control packet. But it is up to the other peer if it
wants to honour this advertisement by sending echo packets. Right?

I have a doubt here.
Does RFC mean that whether peer honours the advertisement or not should be
configured by admin?

Regards
-Lokesh

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 24 Jan 2015 01:16:34 -0800

Hello Lokesh,

you may have received unicast replies, haven't seen anything on the list 
though.

> wants to honour this advertisement by sending echo packets. Right?

Indeed, from RFC 5880, section 3.2:

   The Echo function may be enabled individually in each direction.  It
   is enabled in a particular direction only when the system that loops
   the Echo packets back signals that it will allow it, and when the
   system that sends the Echo packets decides it wishes to.

And section 6.8.9:

   The transmission of BFD Echo packets is otherwise outside the scope
   of this specification.

> Does RFC mean that whether peer honours the advertisement or not should be 

The RFC does not exclude this option and I guess that is what most 
implementations do - they have a config knob to turn on/off echo. If you come 
up with a different mechanism you are free to implement it.

I assume you understand that "honors the advertisement or not" is only an 
option when the peer sends control packets with the "Required Min Echo RX 
Interval" field being non-zero. In case the field is zero ...

      If the Required Min Echo RX Interval field is zero, the
      transmission of Echo packets, if any, MUST cease.

... you must stop sending echo; there is no option to honor or not.

Best regards,
Marc

---

From: Lokesh Bevinamarad <[email-masked]>
Date: Wed, 28 Jan 2015 15:23:49 +0530

Thanks Marc for your reply.

I understand that we can use one knob to turn on/off the Echo advertisement
(non zero value in echo-rx).

But I have 2 options regarding what should be my response to the
advertisement.

1. I can ignore the advertisement by not sending my echo packets to be
looped back by advertiser
2. I can accept (honour) advertisement by sending my echo packets to
advertiser.

Now my question is, does RFC mean that we need another knob to control the
options stated above?
I think RFC is not clear on this aspect.

Regards
-Lokesh

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Jan 2015 07:17:22 -0500

> I think RFC is not clear on this aspect.

The situation is really not much different than async mode.  In async, we
negotiate the max rate at which we wish to receive packets.  If a sender
violates that, BFD can't do much about it.  It's a form of DoS if you want
to look at it that way.

Similarly for echo, if a sender sends the packets too fast, the receiver
will have to deal with it.

The difference of course is in the response. In async, the receiver itself
has negotiated the sending rate in the other direction.  It need not be a
bad actor if the other party is.

In the case of echo, there are two likely outcomes:
- The device providing echo services requests a given rate to provide a
  level of fairness or resource control.  If echo packets come in too fast,
  then they *might* still get looped.  They may be dropped, but mostly due to
  resource exhaustion.
- The device may implement a rate limiter to proactively control the echo
  responses.

The implementation is free to choose whatever it wants to.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Thu, 29 Jan 2015 01:43:58 -0800

Hello Lokesh,

> (non zero value in echo-rx).

that's not what I said :-) I said "turn on/off echo".

Some implementations have a single knob that controls both the advertisement 
as well as the honoring. 

If you like to implement two knobs, one for advertisement and one for 
honoring - you are free to do so.

> I think RFC is not clear on this aspect.

To say the least :-) because it deliberately is not saying anything.

Again, section 6.8.9 says:

Regards, Marc