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

Greg Mirsky <> Mon, 25 February 2019 17:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8CF9130F16 for <>; Mon, 25 Feb 2019 09:10:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8sBoFcJKZgaJ for <>; Mon, 25 Feb 2019 09:10:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B353D130F00 for <>; Mon, 25 Feb 2019 09:10:28 -0800 (PST)
Received: by with SMTP id a8so1659942lfi.7 for <>; Mon, 25 Feb 2019 09:10:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UFA6KfY102t49WBIicVlurd3Yc+pJVLVEQTEIsXfBwQ=; b=N8O4wJ5d+bcsW0fM+IRMz5E7qH1nVfWlZlUcrE/DDpoytXGoL+8En0994FK1d/Vl69 srv7avDv4WLDo07SO+zpyCqFgRZKFPQJESKwMlqNTfhDXRtIvXlxR/Az0mohnHWAWe06 /oegmPt2FlhI01ckgvYod/Nz35IPgB6td/SZNTkBydFfV1e9upe/pLutRQHo0CN2GPN9 sjcG+7KAFf9cUGffL+6JaPN3KApys1APPINEimuSXScET4ZntzJRLFV7H1cs0DrfXFMs USPLR7FtrtdJYyafysc5U3Kwi64jMGSTgPpa4UYGyE+Ve7LjvL8f54v9dwBSPglEw8u1 KAJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UFA6KfY102t49WBIicVlurd3Yc+pJVLVEQTEIsXfBwQ=; b=RB4/TnofHkVkMtSLy0pfBLaiIY7jeukkkebYetyI7jlyZBp0B6kFId3DG2d0yWqFqY 7jNMBx7pMoJqvEVXjF6BCqbAQylQeJ8t30Df3BORFiwWFM+zsAUwwasYrHaFcuZRVixM y2L1HVSJNKOFA0MTiZX7pnVpiuL9l+FeQYCTzR24pcRPvEzRyLnvphEFKdGXj5fxtTlO J9hB5aBqoZqhbExtgk2V68l9wcRDSSJR8kDkzfvitLP2NDCHXRtTgr3awLY9JuVfBeJV 7Jq96PAcjjfZHvHl5x1XvC4kvKuDlhD2kMY6gJIObDXbNfXlZY4bpG24LYD6fdDhA1LU ZMkQ==
X-Gm-Message-State: AHQUAuZ+Bg/ei6LTwGPUKXaFXxveR2pD99Zv+kLDPeNye7X4pWgfGOfI B4zZSctCZrJ5c1rIPE6+wXLrKa+o0vcsmzrB7yw=
X-Google-Smtp-Source: AHgI3IahKGA8gFJx7d1hnS2TVxPKc/8uhfjZLYnRiRjSH85yoMmDX+r7nEWQyveJ3xtyjRxPtrU0l54S/Ml7zT9fB8I=
X-Received: by 2002:ac2:5603:: with SMTP id v3mr1349845lfd.145.1551114626628; Mon, 25 Feb 2019 09:10:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Mon, 25 Feb 2019 09:10:16 -0800
Message-ID: <>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
To: Jeffrey Haas <>
Cc: "Reshad Rahman (rrahman)" <>, Martin Vigoureux <>, rtg-bfd WG <>
Content-Type: multipart/alternative; boundary="0000000000005384bd0582bb04d8"
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: Mon, 25 Feb 2019 17:10:32 -0000

Hi Jeff,
please find my answers in-line tagged GIM4>>.


On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas <> wrote:

> Greg,
> On Sun, Feb 24, 2019 at 09:53:20AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > I'm glad that you feel that our discussion is helpful. I want to point
> that
> > the use of the Poll sequence to communicate to the remote BFD system in
> the
> > Concatenated Paths section is to relay the failure detected in the
> > downstream segment of the multi-segment OAM domain. Also, section 6.8.17
> > does not specify how the upstream BFD system responds to the situation:
> >    Note that if the BFD session subsequently fails, the diagnostic code
> will
> >    be overwritten with a code detailing the cause of the failure.  It is
> >    up to the interworking agent to perform the above procedure again,
> >    once the BFD session reaches Up state, if the propagation of the
> >    concatenated path failure is to resume.
> Correct.  That is up to the upstream to determine its behavior.
> > And so far we were discussing RFC 5880 though the scope of the draft is
> on
> > the use of Demand mode over MPLS LSP.
> MPLS does not magically change the behavior of demand mode specified in the
> core RFC.
GIM4>> The draft defines how the head-end LER reacts to receiving the BFD
control message with Diag set to Control Detection Time Expired and the
Poll flag set:
   Reception of such BFD control packet by the ingress
   LER indicates that the monitored LSP has a failure and sending BFD
   control packet with the Final flag set to acknowledge failure
   indication is likely to fail.  Instead, the ingress LER transmits the
   BFD Control packet to the egress LER over the IP network with:

   o  destination IP address MUST be set to the destination IP address
      of the LSP Ping Echo request message [RFC8029];

   o  destination UDP port set to 4784 [RFC5883];

   o  Final (F) flag in BFD control packet MUST be set;

   o  Demand (D) flag in BFD control packet MUST be cleared.

   The ingress LER changes the state of the BFD session to Down and
   changes rate of BFD Control packets transmission to one packet per
   second.  The ingress LER in Down mode changes to Asynchronous mode
   until the BFD session comes to Up state once again.  Then the ingress
   LER switches to the Demand mode.

> > And the draft does describe how the
> > BFD system acts after it receives the control message with Diag field set
> > to Control Detection Time Expired, a.k.a. RDI, and the Poll flag set. In
> > that, I consider, the draft is complimentary to RFC 5884 whose scope is
> on
> > the Asynchronous mode only.
> I continue to have problems understanding how the text in your draft is
> intended to be different than 6.8.4 of RFC 5880.  Simply saying "we're
> allowed to use demand mode" can't be it?
GIM4>> Section 6.8.4 does not specify that if the BFD system is in Demand
mode and the bfd.LocalDiag is set to 1 (Control Detection Time Expired) the
Poll sequence MAY, SHOULD or MUST be used to notify the remote BFD system.

> It will help clear this conversation if you simply state your changes in
> behavior vs. 5880 and 5884.
GIM4>> I've never stated or hinted that the draft is to update RFC 5884.
The scope of RFC 5884 is the use of BFD in the Asynchronous mode over MPLS
LSPs. As stated in section 6 RFC 5884:

BFD demand mode is outside the scope of this specification.

> > I believe that the draft addresses practical scenario with the technical
> > and innovative solution. And it was recognized as such by several WG
> > participants during the WG AP. Much appreciate your consideration.
> A reminder that we don't vote.  C.f. RFC 7282, section 6.
GIM4>> I'm confused to differentiate when you raise the objection as the
individual contributor and evaluate them and the consensus as the WG chair.

> -- Jeff