Re: [mpls] Fwd: New Version Notification for draft-mirsky-spring-bfd-03.txt

"Carlos Pignataro (cpignata)" <> Tue, 05 December 2017 11:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB41212943C; Tue, 5 Dec 2017 03:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Status: No, score=-14.519 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, 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 fSbFQSFqVl26; Tue, 5 Dec 2017 03:54:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F881129438; Tue, 5 Dec 2017 03:54:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=16891; q=dns/txt; s=iport; t=1512474840; x=1513684440; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h3KBOUhHXPIoJUcLIsqSp0nmr6Fz0v5YrR0p9WmIQKQ=; b=j6/neUJvsj18FmjL8LfdQdSZ7VeXwlVvbxwVDf4TcN6lfqRSC93gtpVh 13JoyDqPLLOXYaL3faErg5Dw+XmZqq0r7UOhiG8+QHpBAVcNyoM6ANz4n DVfPsFVS7hPyNfy0deiW2mjDnxzMtve4ol6rRQjKPwK/ynINms+wcdVDc E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAABfiCZa/5hdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zm4nhACKII56gVcmflyHGohChUsUggEKGAEKhRgCGoUoPxg?= =?us-ascii?q?BAQEBAQEBAQFrKIUiAQEBAQMBASEERwkCEAIBCBEBAgECKAMCAgIfBgsUAwYIA?= =?us-ascii?q?gQOBYk/TAMVEKkmgW06hzsNgxgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdg0iCCoF?= =?us-ascii?q?WgWgBKQuCQTaCa0gYgR4FARIBJhkGEAiCVzGCMgWKRIdChzaIfT0Ch3SII4R6g?= =?us-ascii?q?hZjhS6LMIo+gkM9iGUCERkBgTkBDxA5YWxvFRYkKgGBfgmCEDkcgWd4AYdpgjg?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.45,363,1508803200"; d="scan'208,217";a="328633968"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 11:53:27 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id vB5BrRKI005503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 11:53:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Dec 2017 06:53:26 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Tue, 5 Dec 2017 06:53:26 -0500
From: "Carlos Pignataro (cpignata)" <>
To: Greg Mirsky <>
CC: "" <>, spring <>, "" <>
Thread-Topic: [mpls] Fwd: New Version Notification for draft-mirsky-spring-bfd-03.txt
Thread-Index: AQHTbTvYCzU8vdtbuUGL8ATjBcRcfqM0pNox
Date: Tue, 5 Dec 2017 11:53:26 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_DAA8C18F681846F9844920554F53D16Cciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] Fwd: New Version Notification for draft-mirsky-spring-bfd-03.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: Tue, 05 Dec 2017 11:54:04 -0000

Dear Greg,

Since there had been no responses to the few emails you had sent to the three lists (MPLS, SPRING, RTG-BFD) about various versions of this draft, here’s some high-level thoughts. I hope these are clear and useful.

In this email you mention BFD as the Target WG, the document file name implies Spring, and before I understood you said MPLS.

First, running BFD and S-BFD on Spring Tunnels is an important operational feature, where different implementations ought to inter-operate.

It is not clear to me, however, which areas need further specification for this to work. From the document:

Section 2 should basically be “use RFC 5884 for BFD on MPLS tunnels”. I do not believe there’s confusion about the tail end using the FEC it itself advertised and not a previous one in the stack.

Section 3+4 (previous Section 3 only) -> for SDN-provisioned tunnels, why would the headend signal something in band when the controller is already talking to both ends? I do not believe this is needed.

Section 4 ->

A. It is not clear what a non-FEC TLV is, or how it would be used in LSP ping. The document says it is used to specify the reverse path of a BFD session. But there are already reverse path TLVs. If someone is interested in the BFD reverse path specified, should that be defined in the other document bfd-directed?

B. I believe including Label values in this signaling element without context is dangerous (as the mapping to FECs can change and you end up leaking packets to the wrong place). Instead, Section 5 explains how to do this. It seems that this non FEC creation is to work around using this sub TLV in the Reply Path TLV from RFC 7110

C. Also, the paragraph just prior to Figure 2 says that the document specified “Static Routing MPLS Tunnel sub-TLV” but before it said “Segment Routing Static MPLS Tunnel TLV”.

D. Finally, is this TLV defined to nest just one type of sub-TLV. Seems over engineered.

Section 5 -> this says what bfd-directed already says (or should say)

Net net, I do not see this as useful.


Sent from my iPad

On Dec 4, 2017, at 3:09 PM, Greg Mirsky <<>> wrote:

Dear All,
the major part of the update is around new Non-FEC Path TLV registry to host Segment Routing MPLS Tunnel sub-TLV proposed in this document.
We appreciate your questions, comments and consideration by BFD WG to adopt the draft.


---------- Forwarded message ----------
From: <<>>
Date: Mon, Dec 4, 2017 at 2:02 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-03.txt
To: Ilya Varlashkin <<>>, Gregory Mirsky <<>>, Ilya Varlashkin <<>>, Jeff Tantsura <<>>, "Mach Chen (Guoyi)" <<>>

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

Name:           draft-mirsky-spring-bfd
Revision:       03
Title:          Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:  2017-12-04
Group:          Individual Submission
Pages:          10

   Segment Routing architecture leverages the paradigm of source
   routing.  It can be realized in the Multiprotocol Label Switching
   (MPLS) network without any change to the data plane.  A segment is
   encoded as an MPLS label and an ordered list of segments is encoded
   as a stack of labels.  Bidirectional Forwarding Detection (BFD) is
   expected to monitor any kind of paths between systems.  This document
   defines how to use Label Switched Path Ping to bootstrap and control
   path in reverse direction of a BFD session on the Segment Routing
   static MPLS tunnel.

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

The IETF Secretariat

mpls mailing list<>