Hi Carlos, see below.
> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) > <[email protected]>: > > Hi, Mirja, > >> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) <[email protected]> >> wrote: >> >> 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. > > OK, that sounds good. See below. > >> 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... > > Thanks for the proposal. Please have in mind however that this is a protocol > for detecting liveness (and lack of it), so increasing exponentially defeats > the purpose. > > Further, exponential back off may not be the best choice when interacting > with routing protocols. > > What we currently say is: > The criteria for declaring loss of > reachability and the action that would be triggered as a result > are outside the scope of this document. > > As much of these are implementation choices. > > But we can add at the end “, and MAY include logging an error.“ Please do so. >> >>> >>>> 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. > > I agree with this. I had a different point in mind though — trying to specify > this on every UDP application might not be the most effective way. Perhaps > there’s a UDP guideline you are uncovering. > >> 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). >> > > But as far as this doc is concerned, let me try to make some clarifications > (and a correction). > > There are termination criteria — the document says: > > An SBFDInitiator may be a persistent session on the initiator with a > timer for S-BFD control packet transmissions (stateful > SBFDInitiator). An SBFDInitiator may also be a module, a script or a > tool on the initiator that transmits one or more S-BFD control > packets "when needed" (stateless SBFDInitiator). > > For the case in which you have a “when needed” SBFDInitiator, the workflow is > like a “ping”. > > For the case in which you have a “persistent" SBFDInitiator, in theory this > can run forever (for some value of ever). However, please don’t loose track > of why this protocol exists. Having OAM failures and do nothing about it > defeats the purpose of having OAM. Meaning, a red alarm will blink, a honk > will horn, and the config state will be changed (manually or by some support > system). > > In other words, I do not think this is such a unique case (insofar as running > ad-infinutum). I still believe that the case where you have a misconfiguration and the initiator sends packets (forever) but never ever gest a reply (and never has seen a reply in the past), is a different case and can be detected and handled separately. > >> 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. >> > > To me, there is no insignificant operational complexity with requiring the > addition of filters throughout, for one particular application not leaking > (where the leak does not cause anything special), and when the leak might > happen because of a misconfiguration (or bug) but will be detected by the > operational support systems. The ROI does not seem to add up. Okay the document should probably not require egress filtering in any case but what’s about saying something like: „If S-BFD is used it SHOULD be ensured that S-BFD control packet do not propagate outside of the administrative domain that uses it.“ This is not an uncommon thing to specify also for other protocols. Mirja > > Does the explanation of the termination criteria help? > >>> >>> Seems to me the logging will alert someone/something to take action, and >>> should be enough. >> >> Logging plus alerts is definitely a good thing. >> > > I agree. > > Will add “, and MAY include logging an error.” as per above. > > Do you think we should expand on this somewhere else in the document? > > Thanks, > > — Carlos. > >> Mirja >> >> >>> >>> Thoughts? >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> >>>> >>>> >>> >> >
