Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

"Reshad Rahman (rrahman)" <> Thu, 22 March 2018 15:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 899A5127419; Thu, 22 Mar 2018 08:39:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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_RP_MATCHES_RCVD=-0.01, 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 aYj0PpBHMSOe; Thu, 22 Mar 2018 08:39:28 -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 6D092127076; Thu, 22 Mar 2018 08:39:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=41304; q=dns/txt; s=iport; t=1521733168; x=1522942768; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o3RtldV0kppszmum5piK07hj1oGCpwPmjQPwYUE2PpE=; b=l8hADfUaA9JwbqxoCPjXyXSDVIOTgqdapELm3u8xAFJccltu9oUlwF7h 3q9KvxL7U5rNr4vPEneEUJQHysY/LUrpDrifRyyjahzujOPmYESg1naaW 4we4PqBGxiCqn5OFzC8clRErL18l4daFQoJBSYLz/BgizHRFFw1pGNMla k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAQBezbNa/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJJRS9hcCgKg1KHf40NgXOBEYZqi3cUgW8DCxgBDIRgAhqDSSE?= =?us-ascii?q?0GAECAQEBAQEBAmsohSUBAQEEAQEhRAcJAhACAQgRAwECIQEGAwICAh8GCxQJC?= =?us-ascii?q?AIEAQ0FhCpMAxUPqlWCIIRYgi8NgSyCDoUvghGBVECBDCKCZIJRQgEBAgEBgSJ?= =?us-ascii?q?YFgiCQzCCJAOHNWiDe4RyhkYuCAKFXIV+gxaBOD+DNYdWiR47hgwCERMBgSQBD?= =?us-ascii?q?BA4JoEscBUZISoBghgJgkKOBG8BjzmBFgEB?=
X-IronPort-AV: E=Sophos; i="5.48,345,1517875200"; d="scan'208,217"; a="87864479"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 15:39:27 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2MFdRPo013529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Mar 2018 15:39:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Mar 2018 10:39:26 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 22 Mar 2018 10:39:26 -0500
From: "Reshad Rahman (rrahman)" <>
To: Greg Mirsky <>, "Carlos Pignataro (cpignata)" <>
CC: "" <>, "" <>
Thread-Topic: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
Date: Thu, 22 Mar 2018 15:39:26 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_15EBD5DA382A448C945D8C3B1ACFAA88ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Mar 2018 15:39:32 -0000


In the BFD meeting yesterday there was discussion about lack of clarity on what the spec says wrt to the discriminator TLV being sent by the egress node in the echo reply and that this causes interop issues. From RFC 5884:

The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.

In the errata:

The LSP Ping

Echo reply message generated by the egress LSR MAY carry the local

discriminator assigned by it for the BFD session, as specified in

section 6.1.
So I think it’s clear that this cannot be the discriminator of the ingress node. I agree that this information is useless but still don’t see how it can cause any harm, and any implementation which interprets the discriminator in the echo reply differently is buggy IMHO.

Reshad (hat off).

From: Rtg-bfd <> on behalf of "Reshad Rahman (rrahman)" <>
Date: Tuesday, March 20, 2018 at 5:49 PM
To: Greg Mirsky <>om>, "Carlos Pignataro (cpignata)" <>
Cc: "" <>rg>, "" <>
Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt


While I agree that the echo reply is not needed to bootstrap BFD, and that the BFD Disc TLV is not needed in the reply, doing this doesn’t break anything. So I don’t see the proposed changes as being necessary.

Does anyone remember why RFC5884  has the echo reply, was it to potentially save an echo request from egress for bidirectional case?

Also, if we do go ahead with the proposed changes in this draft, we’ll have to fix this errata<>85>.

Reshad (speaking as individual contributor).

From: Rtg-bfd <> on behalf of Greg Mirsky <>
Date: Friday, October 20, 2017 at 4:19 PM
To: "Carlos Pignataro (cpignata)" <>
Cc: "" <>rg>, "" <>
Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Hi Carlos,
thank you for taking interest in the proposal, much appreciated. Please find my notes in-line and tagged GIM>>.


On Fri, Oct 20, 2017 at 5:54 AM, Carlos Pignataro (cpignata) <<>> wrote:

This document seems to say “use “Do not Reply” reply mode, and even if you reply do not use the BFD Disc TLV, because it is not used.
GIM>> To be precise it says "SHOULD use "Do not Reply" thus preserving compliance of implementations that do otherwise.

Wouldn’t it be simpler to say “follow RFC 8029, and the ingress does not care about the BFD Disc TLV in the reply”? This would not suddenly make uncompliant existing implementations, potentially.
GIM>> I agree that normative language on handling echo reply is bit restrictive. My goal is to have good discussion and see what others think.

Also I wonder if this should be bfd-mpls instead of mpls-bfd, given where RFC 5884 was advanced.
GIM>> Probably it should be the way you've suggested. Hope it is not a big problem for individual draft.


Carlos Pignataro,<>

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

On Oct 18, 2017, at 8:50 AM, Greg Mirsky <<>> wrote:

Dear All,
this new document proposes clarification of two questions brought up in course of recent discussion of RFC 5884:

  *   use of Return mode values in bootstrapping BFD session echo request;
  *   inclusion of BFD Discriminator TLV in echo response to the bootstrapping echo request.
Your comments, questions are always welcome and greatly appreciated.


---------- Forwarded message ----------
From: <<>>
Date: Wed, Oct 18, 2017 at 5:46 AM
Subject: New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
To: Gregory Mirsky <<>>, Yanhua Zhao <<>>

A new version of I-D, draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-mirsky-mpls-bfd-bootstrap-clarify
Revision:       00
Title:          Clarifying Use of LSP Ping to Bootstrap BFD over MPLS LSP
Document date:  2017-10-18
Group:          Individual Submission
Pages:          4

   This document, if approved, updates RFC 5884 by clarifying procedures
   for using MPLS LSP ping to bootstrap Bidirectional Forwarding
   Detection (BFD) over MPLS Label Switch Path.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>g/>.

The IETF Secretariat

mpls mailing list<>