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
