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

"Carlos Pignataro (cpignata)" <> Thu, 22 March 2018 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FB2012EAA4; Thu, 22 Mar 2018 12:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.53
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RWqOFgAtMVJ4; Thu, 22 Mar 2018 12:00:20 -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 1A02312EB10; Thu, 22 Mar 2018 12:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=63806; q=dns/txt; s=iport; t=1521745216; x=1522954816; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yj1CsXlcTelf+x6wFtcrDjrGUwUdf6t8gWROgN+WzLA=; b=EqqwrdWnOTd1y2L9emfamYDtgm/YdBZGoq005XlyLpPiUcVdNuIrhzgx S58zhNgCWSYb8DDx0a7G6fnvMztqgNKTPX/7gvbo2o31rhPQ1lOimpohr XrehjKb/rWZbJTY9LNISbKojPRGfeZuVOWxw6y039nNel+KLWcwvXp5b6 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.48,345,1517875200"; d="scan'208,217";a="371281572"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Mar 2018 19:00:14 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2MJ0EI0024475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Mar 2018 19:00:14 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 22 Mar 2018 15:00:13 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 22 Mar 2018 15:00:13 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Greg Mirsky <>, "Reshad Rahman (rrahman)" <>
CC: "" <>, "" <>
Thread-Topic: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt
Thread-Index: AQHTSA/EphK3ALfV0kCp1VTG3OCNZaLtCMyAgAAoWACA7TbbgIADQ5qA///6OAD//+oQgA==
Date: Thu, 22 Mar 2018 19:00:13 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_06E104E8DC844BD887D9DFE96938E70Eciscocom_"
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 19:00:25 -0000

Hi, Greg,

That, to me, reads like over-specifying. Are you aware of any implementation attempting to do that?

There’s no text for that comparison – why would an implementation do that?



From: Greg Mirsky <>
Date: Thursday, March 22, 2018 at 12:18 PM
To: "Reshad Rahman (rrahman)" <>
Cc: Carlos Pignataro <>om>, "" <>rg>, "" <>
Subject: Re: [mpls] New Version Notification for draft-mirsky-mpls-bfd-bootstrap-clarify-00.txt

Hi Reshad,
your analysis of the text is absolutely correct. My concern is the possible analysis of the Discriminator by ingress LER and it comparing to My Discriminator of the received BFD control packets. According to the RFC 5884 both must match but because LSP Echo reply does not provide sufficient information the most likely outcome will be - no matching BFD session found and thus the text fails. (Yes, it would be rather naive implementation but ...). Thus I propose to add explicit statement for ingress LER not to use information if received Discriminator TLV in Echo reply.


On Thu, Mar 22, 2018 at 3:39 PM, Reshad Rahman (rrahman) <<>> wrote:

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 <<>>, "Carlos Pignataro (cpignata)" <<>>

Cc: "<>" <<>>, "<>" <<>>
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: "<>" <<>>, "<>" <<>>
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<>