RE: Couple comments on draft-ali-spring-bfd-sr-policy

"Ketan Talaulikar (ketant)" <> Wed, 21 March 2018 09:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAE6E12D86F; Wed, 21 Mar 2018 02:05:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Status: No, score=-14.529 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, 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 ngBrasGMQzpb; Wed, 21 Mar 2018 02:05:07 -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 229191205D3; Wed, 21 Mar 2018 02:05:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=29624; q=dns/txt; s=iport; t=1521623107; x=1522832707; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/tAj2HExAd2479B/SMEkWxsJ2c9PegctfXkT9dIUpB4=; b=VkWe3zSFU4l4x68yNcE9q6hO2UFW5Z2GCubCNkaseBVKA50n2riMDqqu qKVQLi6AqJTpb02Xk/8DVlEy1QVu6wvfwRVTyMakio2QGQuaLNNl82MIN y62tolEwVe2/EJQI/yCeUNdrknl4RKsrsfHkdxFsxW85TfQt/X7vPsFwp M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.48,339,1517875200"; d="scan'208,217";a="368716577"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 09:05:06 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w2L956dl003448 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2018 09:05:06 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Mar 2018 04:05:05 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 21 Mar 2018 04:05:05 -0500
From: "Ketan Talaulikar (ketant)" <>
To: Greg Mirsky <>
CC: "" <>, spring <>, "" <>
Subject: RE: Couple comments on draft-ali-spring-bfd-sr-policy
Thread-Topic: Couple comments on draft-ali-spring-bfd-sr-policy
Thread-Index: AQHTwCliZSgj8IC1WU62rDDDt8alhaPZThjQgABegoCAALkgIA==
Date: Wed, 21 Mar 2018 09:05:05 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5e282f2cae0d4d5f8f9d8950b0b7bec4XCHALN008ciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Mar 2018 09:05:09 -0000

Hi Greg,

S-BFD allows for continuous monitoring of the SR path corresponding to the SR Policy. The proposal is to use it for continuous monitoring. This is where there is perhaps a disconnect?

They key part is that the authors of draft-ali-spring-bfd-sr-policy do not propose to have ANY SR policy specific state on any router other than the head-end. The mechanism is otherwise stateless and does not involve any bootstrapping of state or such mechanism. This is entirely in sync with the spirit of SR and draft-filsfils-spring-segment-routing-policy.

Your proposals are very interesting and perhaps relevant to other signalled circuits and TE paths like RSVP-TE or MPLS-TP, but they do not seem appropriate for SR Policies to me.


From: Greg Mirsky <>
Sent: 20 March 2018 16:58
To: Ketan Talaulikar (ketant) <>
Cc:; spring <>;
Subject: Re: Couple comments on draft-ali-spring-bfd-sr-policy

Hi Ketan,
thank you for the most expedient and very detailed response. I'd note that using S-BFD leaves fault detection dependent on convergence time of the IP network. This problem discussed in details in draft-ietf-mpls-bfd-directed and draft-mirsky-spring-bfd.


On Tue, Mar 20, 2018 at 4:42 PM, Ketan Talaulikar (ketant) <<>> wrote:
Hi Greg,

Thanks for your review and comments. Please check inline below for responses.

From: Greg Mirsky <<>>
Sent: 20 March 2018 08:57
To:<>; spring <<>>;<>
Subject: Couple comments on draft-ali-spring-bfd-sr-policy

Dear Authors,
I've read the new draft and would appreciate your consideration of my comments and questions:

  *   if I understand correctly, you prefer using S-BFD in SR domain over use of the base BFD. Without arguing with your choice, I'll note that the title of the draft doesn't reflect your preference;
[KT] The choice of title seemed correct since the draft does analysis of the different BFD options for SR Policies before preferring SBFD.

  *   section 3.4 RFC 7882 already describes use of S-BFD in SR domain. What you is missing in the RFC 7882?
[KT] RFC7882 describes the SBFD use cases and its applicability to SR. This draft does comparison between the BFD modes that borrows from RSVP-TE tunnels usage against S-BFD mode to analyze what is more suitable for SR Policies. This analysis is important to document and to indicate why the authors propose S-BFD rather than BFD is more suitable for SR Policies.

  *   on more technical side. Use of S-BFD will still result in multiplicity of S-BFD packets reflected by egress to ingress. To avoid that we propose method to use BFD Demand mode in MPLS data plane as described in draft-mirsky-bfd-mlps-demand<>. It will be presented in BFD WG meeting and discussed in SPRING as part of BFD in SPRING presentation.
[KT] The BFD on-demand proposal along with the draft-mirsky-spring-bfd basically re-uses concepts like need for bootstrap with LSP ping, setup of state on the egress router from RSVP-TE and IMHO is not suitable for SR Policies unlike S-BFD which is a much simpler and scalable solution that does not setup a per SR Policy state on the egress node.