Manav, A router not configured for S-BFD can be more likely to receive S-BFD packets. We can call that out.
Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 3, 2016, at 05:43, Manav Bhatia <[email protected]<mailto:[email protected]>> wrote: Hi Mirja, ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- As S-BFD has no initiation process anymore it is not guarenteed that the receiver/responder actually exists. That means that packets could float (uncontrolled) in the network or even outside of the adminstrative domain (e.g. due to configuration mistakes). From my point of view this document should recommend/require two things: 1) A maximum number of S-BFD packet that is allow to be send without getting a response (maybe leading to a local error report). 2) Egress filtering at the adminstrative border of the domain that uses S-BFD to make sure that no S-BFD packets leave the domain. How different is this from having a regular BFD/OSPF/ISIS speaker misconfigured to to peer with a router that it is not supposed to peer with. In such cases OSPF/ISIS, etc will continue sending HELLOs. So why do anything different for S-BFD. Moreover, the whole idea of rate-limiting S-BFD packets is fundamentally incorrect. Its possible that the SBFD peer that router is trying to send S-BFD packets to may be down for some reason. In such cases you will NOT receive a response. Its only when it comes up that you will get a response. Am i missing something here? Cheers, Manav
