Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-seamless-base-09: (with DISCUSS)

["Carlos Pignataro (cpignata)" <[e-mail]>]

Thanks much for the response, Mirja!

I think we are converging, please see inline.

> On May 4, 2016, at 10:13 AM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
> 
> Hi Carlos,
> 
> see below.
> 
>> Am 03.05.2016 um 19:24 schrieb Carlos Pignataro (cpignata) <[e-mail]>:
>> 
>> Hi, Mirja,
>> 
>>> On May 3, 2016, at 12:31 PM, Mirja Kuehlewind (IETF) <[e-mail]> wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> 
>>>> Am 03.05.2016 um 15:40 schrieb Carlos Pignataro (cpignata) <[e-mail]>:
>>>> 
>>>> 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 <[e-mail]> 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.

Done.

> 
>>> 
>>>> 
>>>>> 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.
> 

Again, I would not qualify this as ‘forever’, but I understand what you mean.

>> 
>>> 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.“
> 

We can add an additional explanation of the problem before a statement, but I do not think that particular SHOULD is actionable. How’s something like:

Explain that without handshake, a persistent initiator can send blindly, to then add “In such case, operational measures SHOULD be taken to identify if S-BFD packets are not responded to for an extended period of time, and remediate the situation”

> This is not an uncommon thing to specify also for other protocols.
> 

I agree. Frankly, I am happy with either statement, but I think the latter might be more operationally actionable.

Preference?

Thanks,

— Carlos.

> 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.