Re: [spring] Pending work items on draft-ietf-spring-bfd

Greg Mirsky <> Fri, 31 March 2023 23:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 415D0C137394; Fri, 31 Mar 2023 16:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WD506TcNVFS9; Fri, 31 Mar 2023 16:56:36 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id EBCA8C151551; Fri, 31 Mar 2023 16:56:36 -0700 (PDT)
Received: by with SMTP id i6so29244301ybu.8; Fri, 31 Mar 2023 16:56:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1680306996; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rf7riL9HQFcJzHwrn+cIN+j2eZgicPXZI2TwE7jbd3o=; b=CZ0W7xu9EAhwkS+4wEsW0VkViSiNdtmjI9dYtByNnHwY2ga4wIpt2W2Uken21uYPOg 1M1DIMgkgoT9aSvgIGtIgt9SXNj+3aomai745Mx4aOKEhtiZo202tBH4cw+VCmJAg5QZ 4uzcwmnSNVs2Rz7DXt5xUjXmbaBJ4RIXkegumXgE1atiVkTwWrDzPBPB1I1IYHEwz4LD qo+Y56mN1LtkcSQTgSnbHNyrRqQflP2Q8dY2A9VF2PGieJUqGIL1aJ2Buk0UOWG7XZg/ 2WA7YjP4aLRapiDH1I4YX3uvkO1j7ECEMaJDee7uvqlTaWXaflA18HBRXcpK+2nPoYAT naTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; t=1680306996; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rf7riL9HQFcJzHwrn+cIN+j2eZgicPXZI2TwE7jbd3o=; b=C5LUVk44Rgpc2mm02d96hQh0CSrxTqgGINDeqIV4giB7SE5gVlUrNP6ugdeLqZ3ngF R8zF9srZ8Ucdld7IqLcnRVA7SFc3skXwatcdxXejjA2SVGSTVhnY932PYl8VXW34UH7B bLdnjeRviVeTP4zMnwzp7JqDpZMWQhNQdOOq1c0DNeiRvvDsKmnxB1p4BDqD8QOz5AQj LEKo6Q5iYomctYumKLHbKSDYdjc3gXybHvmqeJyDlBwdeZNF3XF5MdJsWl4XiQjGqHA6 pWLuZ6Tn75uRoZ6vAxJiEYp2pOwvV5Uzh7NT6Gl+hEFbDStCkOWTCuh7IiRdDgOaRbKp NJZw==
X-Gm-Message-State: AAQBX9drY0D4sAyEqqSQwCYliAVCoQkxZbuxPJp8oqUkuP/wGILLbKWE 9TP5raJchZXvEp/Zk3UNef/Zl9BG5TlY0zicxwpHBmY8/Y/Q/A==
X-Google-Smtp-Source: AKy350bEYhAPLNw28eEoTFTo3Pe1dsl5d7v1GWRENUPkCyMLbT+EnJXSKYp1cExjzNkVv61oG/cGA53oVBlXl6Mf1HA=
X-Received: by 2002:a25:680e:0:b0:b78:3a15:e6fe with SMTP id d14-20020a25680e000000b00b783a15e6femr14015824ybc.2.1680306996405; Fri, 31 Mar 2023 16:56:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Sat, 01 Apr 2023 08:56:25 +0900
Message-ID: <>
To: "Matthew Bocci (Nokia)" <>
Cc: Ketan Talaulikar <>, spring <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000a269b505f83af5b7"
Archived-At: <>
Subject: Re: [spring] Pending work items on draft-ietf-spring-bfd
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 Mar 2023 23:56:41 -0000

Hi Matthew,
thank you for sharing the information about the implementation of S-BFD in
segment routing. I hope that that can be also reflected in the
Implementation Status section as suggested in RFC 7942
<>. I would appreciate it if
other implementations will be reflected in the section.
I've re-read the definition of an SR Policy in RFC 8402

   A node steers a packet through an SR Policy instantiated as an ordered
   of instructions called "segments".  A segment can represent any
   instruction, topological or service based.

As I understand the definition, an SR Policy is a set of instructions. I
agree that a mechanism based on RFC 5880 can be used to monitor a sequence
of topological instructions. What I am trying to understand is to what
extent that mechanism, BFD or S-BFD, can be used to monitor a service
instruction, particularly at a BFD peer node. Furthermore, what can be
concluded regarding the state of an SR Policy that includes service
instructions when the corresponding BFD session changes its state from Up
to Down? Let us consider two SR Policies, one that includes topological and
service instruction, and one that includes the same topological
instructions but none of the service ones. Can a system that observes BFD
sessions over these two policies produce a certain and reliable indication
of the state of service instructions?
At the same time, I agree with you and Ketan, that S-BFd is a viable method
and its application in the Segment Routing must be included in the
document. I will work on the update.


On Sat, Apr 1, 2023 at 2:23 AM Matthew Bocci (Nokia) <> wrote:

> Hi Greg
> I see S-BFD as the most prevalent flavour of BFD for monitoring SR
> Policies,  avoiding the need for LSP Ping bootstrapping. Nokia has an
> implementation for both MPLS and SRv6 SR Policies, and I am aware of others
> out there.
> Given the widespread implementation of S-BFD for SR Policy, it would make
> sense to incorporate S-BFD as a mechanism in the SPRING BFD draft.
> Regards
> Matthew
> ------------------------------
> *From:* spring <> on behalf of Greg Mirsky <
> *Sent:* Wednesday, March 29, 2023 3:19:47 AM
> *To:* Ketan Talaulikar <>
> *Cc:* spring <>; <
> *Subject:* Re: [spring] Pending work items on draft-ietf-spring-bfd
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See for additional
> information.
> Hi Ketan,
> thank you for sharing your comments about the state of
> draft-ietf-spring-bfd. Please find my notes in-line below under the GIM>>
> tag.
> Regards,
> Greg
> On Wed, Mar 29, 2023 at 11:11 AM Ketan Talaulikar <>
> wrote:
> Hi Greg/Authors,
> I believe this draft still needs work before it is ready for WGLC.
> Specifically, it does not cover the use of S-BFD for the monitoring of SR
> Policies and AFAIK this is the more widely used than the mechanism
> specified in the draft currently (i.e. than the bootstrap via LSP Ping to
> setup a "normal" BFD session).
> GIM>> Can you clarify how BFD or S-BFD can monitor an SR Policy? As
> defined in RFC 5880, the scope of BFD is:
>    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.
> At the same time, I believe that an SR policy can be monitored using LSP
> Ping with the corresponding Target FEC.
> I am not saying that the mechanism in the draft cannot be used, but
> progressing this document toward publication without reflecting the other
> alternate mechanism that IMO is far more widely implemented and
> deployed will provide a somewhat misleading picture.
> My request to the authors is to consider inclusion of text from
> in this
> WG document. We can discuss f2f during this week if you agree.
> GIM>> Thank you for your suggestion. Let us discuss the applicability of a
> BFD-based mechanism in monitoring an SR policy.
> I would like us to seek inputs from implementers and operators on which of
> these two mechanisms they prefer/use. Including this in the document would
> also be helpful.
> GIM>> I wholeheartedly agree and welcome anyone to share their experiences
> of monitoring SR policies with MPLS OAM tools.
> Thanks,
> Ketan
> On Mon, Mar 27, 2023 at 6:04 PM Greg Mirsky <> wrote:
> Refresh and to update author's contact information.
> Dear All,
> the draft is stable and the authors believe it is ready for the WG LC. We
> appreciate the WG Chairs' consideration for starting the WG LC.
> Regards,
> Greg (on behalf of the authors)
> ---------- Forwarded message ---------
> From: <>
> Date: Mon, Mar 27, 2023 at 6:00 PM
> Subject: New Version Notification for draft-ietf-spring-bfd-06.txt
> To: Mach Chen (Guoyi) <>, Greg Mirsky <
>>, Ilya Varlashkin <>, Jeff Tantsura <
>>, Jiang Wenying <>
> A new version of I-D, draft-ietf-spring-bfd-06.txt
> has been successfully submitted by Greg Mirsky and posted to the
> IETF repository.
> Name:           draft-ietf-spring-bfd
> Revision:       06
> Title:          Bidirectional Forwarding Detection (BFD) in Segment
> Routing Networks Using MPLS Dataplane
> Document date:  2023-03-27
> Group:          spring
> Pages:          14
> URL:
> Status:
> Html:
> Htmlized:
> Diff:
> Abstract:
>    Segment Routing (SR) 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 existing path between systems.  This document
>    defines how to use Label Switched Path Ping to bootstrap a BFD
>    session, control an SR Policy in the reverse direction of the SR-MPLS
>    tunnel, and applicability of BFD Demand mode in the SR-MPLS domain.
>    Also, the document describes the use of BFD Echo with BFD Control
>    packet payload.
> The IETF Secretariat
> _______________________________________________
> spring mailing list