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."
>
>>
>>> 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 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.
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.
>>
>>>
>>>
>>>
>>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
