Re: Tsvart last call review of draft-ietf-bfd-multipoint-16

"Carlos Pignataro (cpignata)" <> Tue, 26 June 2018 05:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AAA47130EC6; Mon, 25 Jun 2018 22:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rzQzbGI4ZEcN; Mon, 25 Jun 2018 22:17:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 20617130E9B; Mon, 25 Jun 2018 22:17:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13044; q=dns/txt; s=iport; t=1529990243; x=1531199843; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GunRYBQ79cwg8f4zHigWGKMRBSGtDmraRnDJnIneiXU=; b=LW7gFWTP7hOHTgMUckcG76oaXOabi+jFLy985+pyosajhjHnDSo6uD+1 sNA8SuuMTcOfsWFm+7zytG2GK9Kn0mGxKlW0B6h/rra7KBOtdED3wU+O9 MsMA2lqSW80ZC64A5RSB7BmMmK+tArBqCOSiQ3X0insFww9xqdiSOJlfI M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.51,273,1526342400"; d="scan'208,217";a="415295645"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2018 05:17:21 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w5Q5HKHC005023 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Jun 2018 05:17:21 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 26 Jun 2018 01:17:20 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 26 Jun 2018 01:17:20 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Greg Mirsky <>
CC: Bob Briscoe <>, "" <>, "" <>, "" <>, IETF list <>
Subject: Re: Tsvart last call review of draft-ietf-bfd-multipoint-16
Thread-Topic: Tsvart last call review of draft-ietf-bfd-multipoint-16
Thread-Index: AQHT/HRExw3CBwk62EGoYxhzIgZ7z6RyZA6A
Date: Tue, 26 Jun 2018 05:17:20 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_1A5DF3AAED834656AB1BE8CC9E721CE1ciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Jun 2018 05:17:26 -0000


Please find one late follow-up inline.

On Jun 4, 2018, at 10:23 PM, Greg Mirsky <<>> wrote:

8/ Incremental deployment

Section 4.4.1.  "New State Variable Values" defines bfd.SessionType =
PointToPoint as well as a couple of Multipoint alternatives. Presumably this
spec does not require all existing PointToPoint systems to support this state
value. Is the implication that only Multipoint systems that happen to be in
PointToPoint mode should use this state?
GIM>> You're aboultely right, existing implementations of BFD don't need to support bfd.SessionType variable. Only implementations that support the base BFD, single-hop or multi-hop, and this specification, mpBFD, should support bfd.SessionType and set it to PointToPoint value when BFD is in single-hop or multi-hop mode. When in mpBFD mode, bfd.SessionType will be set to either MultipointHead or MultipointClient.
[BB]: Doesn't something need to be written (or referenced) to clarify all this? AFAIR, this spec. never made clear that multipoint is a fork in implementations.
GIM2>> And so is S-BFD. (Note, bfd.SessionType introduced in RFC 7880 S-BFD but missed to define PointToPoint value).

I do not believe the question was whether S-BFD or any other protocol followed the behavior. It’s a question about this document.

For correctness, S-BFD (RFC 7880) did not miss to define PointToPoint value — it chose not to.

Back to this document, the question was whether something needs to be written to clarify.

The text in rev -18 still needs clarification. It reads:


         The type of this session as defined in [RFC7880].  Newly added
         values are:

            PointToPoint: Classic point-to-point BFD, as described in

            MultipointHead: A session on the head responsible for the
            periodic transmission of multipoint BFD Control packets
            along the multipoint path.

            MultipointTail: A multipoint session on a tail.

         This variable MUST be initialized to the appropriate type when
         the session is created.

Basically, the variable MUST be initialized, PointToPoint is used for RFC 5880, and this text effectively renders every implementation of RFC 5880 non compliant.

Could you please add some clarifying text that codifies what you described above (i.e., existing p2p traditional BFD only do not need to set the variable)


Carlos Pignataro,<>

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