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

Greg Mirsky <gregimirsky@gmail.com> Wed, 04 September 2019 11:57 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8D1200F8 for <rtg-bfd@ietfa.amsl.com>; Wed, 4 Sep 2019 04:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB3y-JDzHD7q for <rtg-bfd@ietfa.amsl.com>; Wed, 4 Sep 2019 04:57:29 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 150D21200F6 for <rtg-bfd@ietf.org>; Wed, 4 Sep 2019 04:57:29 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id l20so4867121ljj.3 for <rtg-bfd@ietf.org>; Wed, 04 Sep 2019 04:57:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IKXpvDrPn4peTtQ9aeMkOSaToKjKIvky+PGDaT5OvWc=; b=Ulj3AaznqjwjJ50Pc72A22UmtToTIWHCXd/kRCno2GYL1cvQyMdp7PoF7I+iqQr+cr GjfX0XIJAUul0X2HqfnDoAOyTKuK4yQ0OhRjR9Jx0n5eCxL5vo8KWrd7pBA9XqStP2xx 9dVNbhe8ebnmY86dKTUDPNyS5tHnwlri5suheIEwUuhylsI3Rhz7knP35YNfrVp2xN9L 4hQeqT3Y+XPWVFYdobBp1tk4z/euSPuCQZPCOtR+qPhp0Gwhr3bR+QbPC5VqhU+et9pP zsRQgq1luIozwZ6Hfr5NY7fDy89eseKdlOR4k49F1rSHjgKK+5Der1uOVmjb3YDkrZAP +9lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IKXpvDrPn4peTtQ9aeMkOSaToKjKIvky+PGDaT5OvWc=; b=sDOwXmER6mD4nH+60lgHbV91jvDrilLg59yWFSbBY8knuPgPIacUEkv9ANbBP3ZW5y L9CYSCS3gwJg32LJGXiB5EZ/gXU05SRF7DrcXR5zTnPCWNPUWMPjRmFCXL6tv9WABmPm LTFdZSAP9a4fyyGncPkb/T24KpVbM6tHPXc4phT8f8xlK5NM9RL3BZxs9MEJdPl61aHR OmagiC9AtkyH0f8L1FcxX32F8sXEq4BSk67ETsTH/bjk5JUnCfcDOVa0cESKau2wX4HP zQqTt8tA0fppMNGv9G6tqvOcZ25pZKFCKymx6arvIAz6BvyZJYSne93NyqB5AKDBwzNb lf0Q==
X-Gm-Message-State: APjAAAWrOYv3/mR69gyihMJU4M7OrFzQX6gv9midUfN7AeRhd+eNaLMI IYHCeq0zcQh3E3L3SekXUPqEtP/XFVvL7dRj5gs=
X-Google-Smtp-Source: APXvYqxwvaM1RwBa+s4uTtk/l+8rdpHlwQn3n0DwEJtNepbrAzRFoUIivDTyJy8ofsNx3YL5fay2nY4j34dkVYKKVhs=
X-Received: by 2002:a2e:6101:: with SMTP id v1mr20885133ljb.42.1567598247188; Wed, 04 Sep 2019 04:57:27 -0700 (PDT)
MIME-Version: 1.0
References: <20190218173351.GI28950@pfrc.org> <CA+RyBmXN=0FYoHWt4TzPg05_ZoC9RbsOSvoFAte9doDY8_JDgg@mail.gmail.com> <542FBF1D-4D61-4E45-8CD2-CE9EC8BF6A38@cisco.com> <CA+RyBmVtLXSZfADQ9YgBEWj+d_X=zXh6SwSfqrUSNWiVNTwNXA@mail.gmail.com> <20190219174109.GN28950@pfrc.org> <CA+RyBmXresOc+i75O7=u5COG3q70s_fX4rK0mQw5LLdak6dxug@mail.gmail.com> <20190220044330.GA14326@pfrc.org> <CA+RyBmWhd7SDArpcrXABnm2GXGd2f3+jWOG2x2+Dgi_VNcWm0g@mail.gmail.com> <20190225032316.GA28974@pfrc.org> <CA+RyBmXi3DVb2KOfuFwCZcGT89cQ-E-C5dQ=-CAf7mq4W1db=Q@mail.gmail.com> <20190225172544.GA17563@pfrc.org>
In-Reply-To: <20190225172544.GA17563@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 4 Sep 2019 13:57:16 +0200
Message-ID: <CA+RyBmXdiT709iYc5idhR=OEiV086yAMDt2r7N90DC2X2dsBeA@mail.gmail.com>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Martin Vigoureux <martin.vigoureux@nokia.com>, rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ac9cd90591b8e88d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/q4CbUpEf_57OCo-nFDdmXUA7NE4>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2019 11:57:32 -0000

Dear Jeff, Reshad, et al.,
after more discussions and analyzing our discussion I'm accepting your
arguments regarding that the behavior of a system in the Demand mode
already sufficiently covered in RFC 5880. What I'd like us to discuss is
the note by Jeff:

If you're also saying that the ingress is NOT receiving a Down state change
from the egress as part of this and that the ingress moves to down just
because the Diag changes, that at least is clear, and is worth further
discussion.


Much appreciate your consideration and advise on how to proceed further.

Regards,
Greg

On Mon, Feb 25, 2019 at 6:26 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

> On Mon, Feb 25, 2019 at 09:10:16AM -0800, Greg Mirsky wrote:
> > Hi Jeff,
> > please find my answers in-line tagged GIM4>>.
> >
> > Regards,
> > Greg
> >
> > On Sun, Feb 24, 2019 at 7:24 PM Jeffrey Haas <jhaas@pfrc.org> 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.
>
> I shall paste this one last time:
>
> :   If Demand mode is active on either or both systems, a Poll Sequence
> :   MUST be initiated whenever the contents of the next BFD Control
> :   packet to be sent would be different than the contents of the
> :   previous packet, with the exception of the Poll (P) and Final (F)
> :   bits.  This ensures that parameter changes are transmitted to the
> :   remote system and that the remote system acknowledges these changes.
>
> If you've changed diag, you've changed the contents.  If you are running in
> demand mode, you will send a poll.
>
> If you're also saying that the ingress is NOT receiving a Down state change
> from the egress as part of this and that the ingress moves to down just
> because the Diag changes, that at least is clear, and is worth further
> discussion.
>
> > > 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.
>
> You seem to be confused about how this boilerplate text is used.
>
> If there are no changes to procedure, existing procedure applies - it is
> simply not discussed in this document.
>
> If there is changes to procedure (what we are trying to determine), then
> further discussion is warranted.
>
> > > 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.
>
> Chairs are not prohibited from offering technical feedback.  If you remain
> confused on this issue, I suggest you discuss this with Martin at the
> upcoming IETF.
>
> -- Jeff
>