Re: [Technical Errata Reported] RFC7880 (5211)

Greg Mirsky <gregimirsky@gmail.com> Wed, 20 December 2017 04:29 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C058E12D948 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 20:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NovMFMlTRBil for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 20:29:09 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE3D12D7FB for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 20:29:08 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id f18so22495870lfg.8 for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 20:29:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mOCUHX+EDBKfDYpxe9/fImzkX19OlSol/GbE6kf8vpo=; b=cwz1opq5MaljWpgebg6uRGNq75B/H14B8IbdwQ3QnUt+6qDuyiR4vY4M+PAKvA5N38 KZnszXlA+63ePfSswYKJXif3HMdNZyX5rNbMzN0b51MGVaHdnthPj7XPp/aihq2DP0GH 6ZzLne72eyC/QTBWf9VAWeYvKpEbgZr1SLyCUP50/KgG9Bc1NGQUSAK3BgNmHY8dF7Fp j8Upn39l43XLifSnGkhR0ywDxcaSeq7Tg1z11k5NbS/IIVuqkT0fWtyhNACmg1Lt1UwX ygaXlxlfigJytcJuSJchfHklte/WZnznfXFWn8rp+SvUNHU4xV3OAxnjD68xSXg6I9bV nvww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mOCUHX+EDBKfDYpxe9/fImzkX19OlSol/GbE6kf8vpo=; b=S4SLZnOxWxlurYzjwWP2lWL/Y+4IV9q5dcQd+KAaoXj9rsE6RfbLO7CG6JqThjqrPE 3zbbqOKOWNjDHSe+f3zxMdnw3ie3DuIfDnw3T08QOIt7+lhdCQShgjJKtR6mK45rEZwq 9wcRPfuc/6h11eSAPldBK1xGGRQ9y/7x9LYgBn0xrhZ7KkDifoRm3pHi7TTicI3ARMLf QQayIkYrQ8SqVNeTqKpRSj3t2MzAaj8JYe1RJF/E5A4XeyNq9Lpmn0iX+vSCz/FkqIpT fidTOUuxXG88ZmCAHPimfl9pLmCIphlACCaW8oY6gFWkH62n4idjODawnvCcDdYqF7nY Q/Bg==
X-Gm-Message-State: AKGB3mKogZWdx7+KD8RtLr5/U8rBXP9X+v8w2cxoXm8eiyTUiAgECBnH IHVK2/r76IRzOmp4bKdr4hXmyVBmqhrU+qFzElY=
X-Google-Smtp-Source: ACJfBosgcLNa+/TtkFp26yV1unGUpp9Ch8BLvouHsF/j7SAU1nctPIGHoZlWzvtdtANEtt19RVECjbPj6n9WoOCgxNo=
X-Received: by 10.46.5.12 with SMTP id 12mr3530755ljf.116.1513744146732; Tue, 19 Dec 2017 20:29:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Tue, 19 Dec 2017 20:29:06 -0800 (PST)
In-Reply-To: <296B021A-8C19-4915-A292-9D348B6BA9B9@cisco.com>
References: <20171216202755.55553B80CC9@rfc-editor.org> <296B021A-8C19-4915-A292-9D348B6BA9B9@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 19 Dec 2017 20:29:06 -0800
Message-ID: <CA+RyBmVsxHFY+b9AXSws0xmsqGmSq=Y2Ep0p+mwHdCoVEEckqg@mail.gmail.com>
Subject: Re: [Technical Errata Reported] RFC7880 (5211)
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: RFC Editor <rfc-editor@rfc-editor.org>, "David Ward (wardd)" <wardd@cisco.com>, Nobo Akiya <nobo.akiya.dev@gmail.com>, "manav@ionosnetworks.com" <manav@ionosnetworks.com>, Santosh P K <santosh.pallagatti@gmail.com>, Alia Atlas <akatlas@gmail.com>, Deborah Brungard <db3546@att.com>, Alvaro Retana <aretana.ietf@gmail.com>, Jeff Haas <jhaas@pfrc.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="001a114a69b6259b750560be06ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/3bUBIXe6IRee7Hxvmp5xYN9VxTU>
X-Mailman-Approved-At: Wed, 20 Dec 2017 03:49:51 -0800
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2017 04:29:12 -0000

Hi Carlos, et.al,
I agree that for a BFD node that in addition to RFC 7880 supports
draft-ietf-bfd-multipoint bfd.SessionType will not be left unset when the
BFD session is other than of S-BFD type (PointToPoint, MultipointHead or
Multipoint Tail). But if the BFD node only supports base BFD [RFC5880] and
S-BFD [RFC7880] specifications bfd.SessionType is unspecified if the
session type is neither SBFDInitiator, nor SBFDReflector. Making resolution
of this issue to be dependent on support of BFD for Multipoint Networks
doesn't seem as prudent approach. I'm open to suggestions of the better
name for the new value of bfd.SessionType, other than SBFDNone.

Regards,
Greg

On Mon, Dec 18, 2017 at 6:28 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com>; wrote:

> As a co-author of RFC 7880, I disagree with the report below, and
> recommend Rejecting this Erratum.
>
> S-BFD uses the BFD state variables, and “bfd.SessionType” is applicable
> with finer granularity than “Not S-BFD”.
>
> Some details at. https://mailarchive.ietf.org/arch/msg/rtg-bfd/
> HxHT6Nxhpxot4baDag7cW6gm_ZQ
>
> Further:
>
> The proposed value of “SBFDNone” is covered at https://tools.ietf.org/
> html/draft-ietf-bfd-multipoint-11#section-4.4.1 with the values of either
> “PointToPoint” (classing, p2p, BFD), “MultipointHead”, and “MultipointTail”
> (plus “MultipointClient”)
>
> Including a new state variable and new values for the bfd.SessionType adds
> unnecessary complexity.
>
> —
> Carlos Pignataro, carlos@cisco.com
>
> *“Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."*
>
> On Dec 16, 2017, at 3:27 PM, RFC Errata System <rfc-editor@rfc-editor.org>;
> wrote:
>
> The following errata report has been submitted for RFC7880,
> "Seamless Bidirectional Forwarding Detection (S-BFD)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5211
>
> --------------------------------------
> Type: Technical
> Reported by: Greg Mirsky <gregimirsky@gmail.com>;
>
> Section: 6.1
>
> Original Text
> -------------
>   o  bfd.SessionType: This is a new state variable that describes
>      the type of a particular session.  Allowable values for S-BFD
>      sessions are:
>
>      *  SBFDInitiator - an S-BFD session on a network node that
>         performs a continuity test to a target entity by sending S-BFD
>         packets.
>
>      *  SBFDReflector - an S-BFD session on a network node that listens
>         for incoming S-BFD Control packets to local entities and
>         generates response S-BFD Control packets.
>
>   The bfd.SessionType variable MUST be initialized to the appropriate
>   type when an S-BFD session is created.
>
>
> Corrected Text
> --------------
>   o  bfd.SessionType: This is a new state variable that describes
>      the type of a particular session.  Allowable values for S-BFD
>      sessions are:
>
>      *  SBFDNone - indicates that the BFD session is not of S-BFD type.
>
>      *  SBFDInitiator - an S-BFD session on a network node that
>         performs a continuity test to a target entity by sending S-BFD
>         packets.
>
>      *  SBFDReflector - an S-BFD session on a network node that listens
>         for incoming S-BFD Control packets to local entities and
>         generates response S-BFD Control packets.
>
>   The bfd.SessionType variable MUST be set to SBFDNone when a BFD
>   session other than S-BFD. The bfd.SessionType variable MUST be
>   initialized to the appropriate type when an S-BFD session is created.
>
>
> Notes
> -----
> The original text leaves value of the new variable bfd.SessionType
> unspecified if the type of BFD session is other than S-BFD.
>
> 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.
>
> --------------------------------------
> RFC7880 (draft-ietf-bfd-seamless-base-11)
> --------------------------------------
> Title               : Seamless Bidirectional Forwarding Detection (S-BFD)
> Publication Date    : July 2016
> Author(s)           : C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S.
> Pallagatti
> Category            : PROPOSED STANDARD
> Source              : Bidirectional Forwarding Detection
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
>
>
>