Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

"Carlos Pignataro (cpignata)" <> Fri, 26 October 2018 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA853130DDA for <>; Fri, 26 Oct 2018 14:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, 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 emedIQ09xCIC for <>; Fri, 26 Oct 2018 14:28:21 -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 5CBEA124BAA for <>; Fri, 26 Oct 2018 14:28:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19494; q=dns/txt; s=iport; t=1540589301; x=1541798901; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zox/FNZGOYwz5VNj2wGTcCELYoohOBZlPXry5I0P/YY=; b=dctWvn9cEj+Bt4V/2qXLwL0t5J6xQv+mKRf+Nu9C0+zchPI3RC906LCp wOQIViE4I4e7zUwcT7yG8KPN+EPsq+XEkVEiUAg2yMCV2dOjrcK32FX8T sTHDocW2CyiGOx97irlf3axbRKGryUR75OJcL0LQVY/HbPHDml80JmiNc w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.54,429,1534809600"; d="scan'208,217";a="191609578"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 21:28:20 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w9QLSJts018928 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 21:28:20 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 17:28:18 -0400
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 17:28:18 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Greg Mirsky <>
CC: "" <>, rtg-bfd WG <>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Thread-Topic: WG Adoption request for draft-mirsky-bfd-mpls-demand
Thread-Index: AQHUZmhJiwqFodrsXU2xirocEt1c36Unp1uAgAmQ0oCAAL3cgIAAZdQA
Date: Fri, 26 Oct 2018 21:28:18 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.100.39)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_3078AF1C717E448E9DD1E5CDDD4F598Aciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Oct 2018 21:28:24 -0000

Hi, Greg,

Thanks for the quick response — please see inline, since I do not believe you were answering my actual points.

On Oct 26, 2018, at 11:23 AM, Greg Mirsky <<>> wrote:

Hi Carlos,
thank you for your interest in the draft and the questions. Please find my answers in-line tagged GIM>>.


On Thu, Oct 25, 2018 at 9:04 PM Carlos Pignataro (cpignata) <<>> wrote:

Scanning through the draft, two questions:

1. What is the underlying mechanism to check liveness such that Demand can be used?

   Demand mode requires that some other mechanism is used to imply
   continuing connectivity between the two systems.  The mechanism used
GIM>> The Poll sequence may also be used as such, and draft-ietf-bfd-multipoint-active-tail is the example of how the Poll sequence is used in BFD Demand mode.

This is not what the spec says. Quoting the same text again, but adding emphasis:

   Demand mode **requires** that **some other mechanism** is used to imply
   continuing connectivity between the two systems.  The mechanism used

What is the **some other mechanism** outside BFD, in this case? It is something that Demand mode **requires**

2. Is this draft testing liveness of a path or a node?

   In this state BFD peers MAY remain as long as the egress LER is in Up
   state.  The ingress LER MAY check liveness of the egress LER by
   setting the Poll flag.  The egress LER will respond by transmitting
GIM>> BFD does not differentiate between the path and, to certain extent, the node. From RFC 5880 Abstract:
   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.

The text you quote says nothing about the node. Only about the *path* and *forwarding* elements...

What is, for BFD, to "check liveness of the egress LER”?




— Carlos Pignataro

On Oct 19, 2018, at 9:59 PM,<> wrote:

I support WG adoption of this draft. Use of the demand mode for p2p LSP monitoring is feasible and required.

Best Regards,

Xiao Min

发件人:JeffreyHaas <<>>
收件人<> <<>>;
日 期 :2018年10月18日 06:24
主 题 :WG Adoption request for draft-mirsky-bfd-mpls-demand
Working Group,

The BFD chairs have received an adoption request for
"BFD in Demand Mode over Point-to-Point MPLS LSP"

The adoption call will end on the Friday after IETF 103, November 9.

Note that there is are existing IPR statements on this draft:

Please indicate to the mailing list whether you support adoption of this

-- Jeff & Reshad