Re: [Technical Errata Reported] RFC7880 (5211)

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 20 December 2017 04:39 UTC

Return-Path: <cpignata@cisco.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 E51D5124D85 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 20:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 UNuInrPZGOOe for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 20:39:51 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4D212025C for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 20:39:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22872; q=dns/txt; s=iport; t=1513744791; x=1514954391; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N1cmvY4kVpABPgOyN5kdrjEsZA79YQEp6WL0IVVLXHM=; b=jYb4xrA60g7Y/c54iXB8OAnn1TWSTLdTJq6VqBRtAkwJgesocrn0+z+L b9g+l4lS4l49Llg2ObNFiW3GKpNR2lujlLEl3Kx64htbIVZdcNYrO/NKr b8wx+oyFKXu5eJHzo7fnotnq7q+Ni/lou1C6HEk7BEyOOsccy3HfYsH3t 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B3AQC76Dla/4ENJK1bGQEBAQEBAQEBAQEBAQcBAQEBAYM+ZnQnB4N/iiGPDIMAiAaIUIVQghUKJYM4gV4CGoR0PxgBAQEBAQEBAQFrKIUkBiNWEAIBCD8DAgICHxEUEQIEDgWJR0wDFRCjbIInhz8NgyYBAQEBAQEBAQEBAQEBAQEBAQEBAQEdg26CEoFWgWgBKYJNNoFJgSJEAYIsglgxgjIFik4YhzaBco54PQKHfogwhH6CFoYVi0uKTYJPPoVxgwECERkBgToBHzmBT28VGE4BgX4JghJFgXYBeAEBiSCBFQEBAQ
X-IronPort-AV: E=Sophos;i="5.45,430,1508803200"; d="scan'208,217";a="334273367"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2017 04:39:50 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vBK4doDI015674 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Dec 2017 04:39:50 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 19 Dec 2017 23:39:49 -0500
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1320.000; Tue, 19 Dec 2017 23:39:49 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.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>
Subject: Re: [Technical Errata Reported] RFC7880 (5211)
Thread-Topic: [Technical Errata Reported] RFC7880 (5211)
Thread-Index: AQHTdqxug6tWe79ZEUuB3ZH478d1gqNKSIEAgAG0HACAAAL+gA==
Date: Wed, 20 Dec 2017 04:39:49 +0000
Message-ID: <7456A97B-CD06-40D8-9FE7-63A9E39194D1@cisco.com>
References: <20171216202755.55553B80CC9@rfc-editor.org> <296B021A-8C19-4915-A292-9D348B6BA9B9@cisco.com> <CA+RyBmVsxHFY+b9AXSws0xmsqGmSq=Y2Ep0p+mwHdCoVEEckqg@mail.gmail.com>
In-Reply-To: <CA+RyBmVsxHFY+b9AXSws0xmsqGmSq=Y2Ep0p+mwHdCoVEEckqg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.116.133]
Content-Type: multipart/alternative; boundary="_000_7456A97BCD0640D89FE763A9E39194D1ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/URle8af6iC6EK0-C7mnhSvHMUWA>
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:39:54 -0000

Hi, Greg,

The bfd.SessionType is really a core state variable to the original BFD spec — just implicitly defined. This is made explicit by the “PointToPoint” value from draft-ietf-bfd-multipoint-11, but that does not mean that RFC 7880 and RFC 5880 need to be revised to add this.

Using SBFDNone (or something like it) is harmful, because that covers a set of multiple values (PointToPoint and MultipoitntHead are both SBFDNone).

Net-net, I still do not believe, on technical grounds, that there’s any change needed to RFC 7880 or RFC 5880.

The one change to consider is to have draft-ietf-bfd-multipoint-11 update RFC 5880 by saying that no value means PointToPoint.

Thanks,

—
Carlos Pignataro, carlos@cisco.com<mailto:carlos@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."

On Dec 19, 2017, at 11:29 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Carlos, et.al<http://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<mailto: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<mailto: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<mailto: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<mailto: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