Hi Carlos,
> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) > <[email protected]>: > > Hi, Mirja, > > What is an uncontrolled packet in an IP network, and what entity controls > controlled ones? :-) Questions over questions… :-) See below... > > More seriously, please see inline. > >> On May 3, 2016, at 5:35 AM, Mirja Kuehlewind <[email protected]> wrote: >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-bfd-seamless-base-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-seamless-base/ >> >> >> >> ---------------------------------------------------------------------- >> 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: >> > > We have called out the misconfiguration — however: > >> 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). >> > > This can result in a deadlock situation, if an S-BFD Reflector is enabled > much later. I’m very hesitant to cap the packets sent. We can, and I think it > is useful, MAY log an error for multiple timeouts. Okay, I understand that a hard limit probably does make sense. An error log seems definitely useful. Another proposal for consideration: Currently the draft says an initiator should only send one packet per second if the target is in ADMINDOWN state. In this case there this state is explicit announced. However if the other end just disappears or was never/not yet there, one could use an exponential back off instead, starting with a smaller intervals than one second but then increase it exponentially. Just an idea... > >> 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. >> > > This is no different than any other application that uses UDP; a > misconfigured DNS server will result in the same, and a traceroute is also > not too different. This seems too onerous of a requirement. An administrative > domain filters at ingress. First of all, just because other protocols might have such a problem, that does mean it’s okay. However, correctly me if I’m wrong, but there the situation seems slightly different because there is no termination criterium at all that means an s-bfd node would send useless data forever (… until manual change of the config). I still believe that egress filtering would be more appropriate here (than ingress) because the domain that is using s-bfd knows about it and therefor can set up the respective filters and should not spam others while hoping that filters are in place. > > Seems to me the logging will alert someone/something to take action, and > should be enough. Logging plus alerts is definitely a good thing. Mirja > > Thoughts? > > Thanks, > > — Carlos. > >> >> >> >
