RE: [Errata Held for Document Update] RFC5880 (5205)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 15 March 2018 05:18 UTC

From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "dkatz@juniper.net" <dkatz@juniper.net>, "dkatz@juniper.net" <dkatz@juniper.net>, "dward@juniper.net" <dward@juniper.net>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: RE: [Errata Held for Document Update] RFC5880 (5205)
Thread-Topic: [Errata Held for Document Update] RFC5880 (5205)
Thread-Index: AQHTu8qrZ/c0qBIVX0mQIO4tuCXkeKPQv7OA
Date: Thu, 15 Mar 2018 05:18:26 +0000
Message-ID: <1d83c141ad6a4bc18f546e8e18c6fb18@XCH-ALN-001.cisco.com>
References: <20180314192822.D731EB81A29@rfc-editor.org>
In-Reply-To: <20180314192822.D731EB81A29@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_1d83c141ad6a4bc18f546e8e18c6fb18XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/NCCsX74qSms4qdAqCArI3WYB0K0>
Precedence: list

The motivations for this errata puzzle me.

In the Notes you say:



“This turns out to be problematic in the case where system "A" signals AdminDown, causing system "B" to respond with Down state.  If the link then fails, the existing verbiage implies that "B" will not report the detection timeout, even locally.”



[Les:] If A has signaled AdminDown then it is expected that A will (after a prudent number of retransmissions of the AdminDown state as specified in Section 6.8.16) stop transmission. So why is there a need to report what is expected to happen after receiving AdminDown? It also isn’t clear how you could determine that the link has failed given that it is expected that A will stop transmissions.



“If the link fails in a unidirectional manner (such that "B" is deaf), B will give no indication of a timeout in its outgoing Control packets back to A (which can in fact hear them).”



[Les:] If B is deaf, how would it have received AdminDown?


The suggested change would also seem to violate Section 4.1 (emphasis added):

Diagnostic (Diag)

      A diagnostic code specifying the local system's reason for the
      last change in session state.  Values are:
…

      This field allows remote systems to determine the reason that the
      previous session failed, for example.

???

   Les







> -----Original Message-----

> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of RFC Errata

> System

> Sent: Wednesday, March 14, 2018 12:28 PM

> To: dkatz@juniper.net; dkatz@juniper.net; dward@juniper.net

> Cc: rtg-bfd@ietf.org; rfc-editor@rfc-editor.org; iesg@ietf.org

> Subject: [Errata Held for Document Update] RFC5880 (5205)

>

> The following errata report has been held for document update for RFC5880,

> "Bidirectional Forwarding Detection (BFD)".

>

> --------------------------------------

> You may review the report below and at:

> http://www.rfc-editor.org/errata/eid5205

>

> --------------------------------------

> Status: Held for Document Update

> Type: Technical

>

> Reported by: Dave Katz <dkatz@juniper.net<mailto:dkatz@juniper.net>> Date Reported: 2017-12-14

> Held by: Alvaro Retana (IESG)

>

> Section: 6.8.4

>

> Original Text

> -------------

> If Demand mode is not active, and a period of time equal to the Detection

> Time passes without receiving a BFD Control packet from the remote system,

> and bfd.SessionState is Init or Up, the session has gone down -- the local

> system MUST set bfd.SessionState to Down and bfd.LocalDiag to 1 (Control

> Detection Time Expired).

>

> Corrected Text

> --------------

> If Demand mode is not active, and a period of time equal to the Detection

> Time passes without receiving a BFD Control packet from the remote system,

> the session has gone down -- the local system MUST set bfd.SessionState to

> Down and bfd.LocalDiag to 1 (Control Detection Time Expired).

>

> Notes

> -----

> This is based on an email I received from Anil Kumar of Nokia

> (anil.kumar_t_v@nokia.com<mailto:anil.kumar_t_v@nokia.com>).

>

> The language as originally written made a session timeout a no-op when in

> Down state.  This was a gratuitous attempt to avoid a null state transition, but

> had the side effect of not setting the diag code (and otherwise is no

> different).

>

> This turns out to be problematic in the case where system "A" signals

> AdminDown, causing system "B" to respond with Down state.  If the link then

> fails, the existing verbiage implies that "B" will not report the detection

> timeout, even locally.

>

> If the link fails in a unidirectional manner (such that "B" is deaf), B will give no

> indication of a timeout in its outgoing Control packets back to A (which can in

> fact hear them).

>

> Making the suggested change should ensure that the diagnostic code is

> always set to Detection Time Expired when Control packets stop arriving,

> even if the far end system was previously reporting AdminDown.

>

> --------------------------------------

> RFC5880 (draft-ietf-bfd-base-11)

> --------------------------------------

> Title               : Bidirectional Forwarding Detection (BFD)

> Publication Date    : June 2010

> Author(s)           : D. Katz, D. Ward

> Category            : PROPOSED STANDARD

> Source              : Bidirectional Forwarding Detection

> Area                : Routing

> Stream              : IETF

> Verifying Party     : IESG

[Errata Held for Document Update] RFC5880 (5205) RFC Errata System
Re: [Errata Held for Document Update] RFC5880 (52… Ashesh Mishra
RE: [Errata Held for Document Update] RFC5880 (52… Les Ginsberg (ginsberg)