[mpls] [Technical Errata Reported] RFC6428 (6296)

RFC Errata System <rfc-editor@rfc-editor.org> Tue, 29 September 2020 06:40 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C7F3A08AF for <mpls@ietfa.amsl.com>; Mon, 28 Sep 2020 23:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnecdzpbeiiB for <mpls@ietfa.amsl.com>; Mon, 28 Sep 2020 23:40:38 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42AEF3A08AE for <mpls@ietf.org>; Mon, 28 Sep 2020 23:40:38 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 8A490F406C4; Mon, 28 Sep 2020 23:40:35 -0700 (PDT)
To: david.i.allan@ericsson.com, swallow@cisco.com, jdrake@juniper.net, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, loa@pi.nu, n.leymann@telekom.de, tsaad.net@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: in.sudipta.das@gmail.com, mpls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200929064035.8A490F406C4@rfc-editor.org>
Date: Mon, 28 Sep 2020 23:40:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/I7axC0dLgjdjv4ngEDMaRHpoYDg>
Subject: [mpls] [Technical Errata Reported] RFC6428 (6296)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 06:40:40 -0000

The following errata report has been submitted for RFC6428,
"Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6296

--------------------------------------
Type: Technical
Reported by: Sudipta Das <in.sudipta.das@gmail.com>

Section: 3.7

Original Text
-------------
In coordinated mode, an implementation SHOULD NOT reset
bfd.RemoteDiscr until it is exiting the DOWN state.

Corrected Text
--------------
In coordinated mode, an implementation SHOULD reset
bfd.RemoteDiscr upon transitioning to the DOWN state, 
due to period of a Detection Time passing without the
receipt of a valid, authenticated BFD packet from the
remote system.

Notes
-----
This section seems to imply that when a BFD session, running in coordinated mode, experiences Control Detection Timer expiry, then it SHOULD retain the remote discriminator value *and* SHOULD also transmit the same value in Down packets.
However, in the case when the remote system, configured in Passive role, has its discriminator gets changed (say, after a system reboot which had caused the Detection Timer expiry), it may reject these packets as the received Your Discriminator value is no longer valid for the current session.
So the BFD session would never come back to Up state.

In a second scenario (unrelated to above one), if the local system is configured in Passive role and experiences Control Detection Timer expiry, it may continue transmitting Down packets since the bfd.RemoteDiscr is not reset to zero.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06)
--------------------------------------
Title               : Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile
Publication Date    : November 2011
Author(s)           : D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.
Category            : PROPOSED STANDARD
Source              : Multiprotocol Label Switching
Area                : Routing
Stream              : IETF
Verifying Party     : IESG