Hi, Mirja, What is an uncontrolled packet in an IP network, and what entity controls controlled ones? :-)
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. > 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. Seems to me the logging will alert someone/something to take action, and should be enough. Thoughts? Thanks, — Carlos. > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
