Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky <gregimirsky@gmail.com> Mon, 14 August 2017 17:56 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 590781323BA; Mon, 14 Aug 2017 10:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-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 P9WjtYDqh7GJ; Mon, 14 Aug 2017 10:56:17 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 A31731243F6; Mon, 14 Aug 2017 10:56:16 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id t128so42975943lff.2; Mon, 14 Aug 2017 10:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=thBwSSjmwkhPvj7Cf1SpY8JQsmC1HXDHnnUJG53VzoE=; b=EjpKeDvufn6s8Opd5enB1WhAn46nDeqk1VBBkT8g3oynXrn0DQGTT7Dfvgk082/6CF 4wK9NksVtibASbzEO9uZF9odxWD58YbvlHWQAz1o/4QIlRwrIRQdS3cfBv6wbIjmJFvw BQybXHCBWkL0+CyevK+hj/HfmhV7aRFDDZR4YKCorO2jnkxvh8xSIJIXmgki+38Gx1Gl VvePN9xegchFR/bxq2/9DMmlGEPZXxYH2WSHfQMTWNarW3Qx0N4eDlzwP3DposB19/cD izS+YIuDT52+z43TEt40YY25wC3rpICZF5yElfCIkwS76bEAyeNQxviTjL5oMfrcmrF3 J2JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=thBwSSjmwkhPvj7Cf1SpY8JQsmC1HXDHnnUJG53VzoE=; b=Zb2Ttb6KnlSSm0gIum522IXZVmvATC08tAuPOxSaZ6Rkoe9ALMeo5dEHVd5gUgbrPu YZD68/0T2thh73am0LQjbKNz3AUGLvp3ulXbnorqQwiUUSqm9USqbgsupzUhVkgYJc7l 1u37GM3yzHGeZfIg9tfh5BuzvlzRPdBvjxQozZu/vTrcp6I6s7Xu27U8O+4Q0AehkKC6 E6JNrGgcm9tJtcMRcadh3DsDeRbW7JgQZs+AbFOnBCbjSabrh/+QdbEbY2kTsLjclOCC /vWYD6B/t3dPQl/GGrVRTKDVFj66LjXyyN8cT1rFryoTMsCdriT3xIhv1DW58hLwPRSg xCcQ==
X-Gm-Message-State: AHYfb5i+PYOTdTRFkufwiaQ/tEpY2KzqpFX6x+dwO5DcW5XbihtiRjAp WUqp8j+8cO8fBOWOLVKmQDpiCCwB/w==
X-Received: by 10.46.69.87 with SMTP id s84mr9327679lja.129.1502733374682; Mon, 14 Aug 2017 10:56:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.88.81 with HTTP; Mon, 14 Aug 2017 10:56:13 -0700 (PDT)
In-Reply-To: <20170811173930.GJ24942@pfrc.org>
References: <20170811053550.27303B81263@rfc-editor.org> <20170811173930.GJ24942@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 14 Aug 2017 10:56:13 -0700
Message-ID: <CA+RyBmXcZzJnPTy6+oa8NNOM-m_KAXpRoZZ5xky_FGV+HN0B4A@mail.gmail.com>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Thomas Nadeau <tnadeau@lucidvision.com>, "kireeti@juniper.net" <kireeti@juniper.net>, Alia Atlas <akatlas@gmail.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114b0cdafd7a8a0556ba609f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/tBHORQeHEqSpSkw75mbls6pKpCk>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 14 Aug 2017 17:56:19 -0000

Hi Jeff, et al,
greatly appreciate the most detailed analysis that explains the reasoning
of the filed Errata. Please consider my in-lined and tagged with GIM>>
notes. And since in the center of this discussion is LSP Ping, I've added
MPLS WG.

Best regards,
Greg

On Fri, Aug 11, 2017 at 10:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:

> [Note that I have adjusted the addresses in the headers to try to catch the
> RFC authors' current accounts.]
>
>
> The 5884 interop issue keeps bubbling up.  Balaji submitted an errata,
> which
> provides us with a good place to start technical discussion.
>
> Please note I also spent some time off-list discussing this errata with
> Balaji.
>
>
> On Thu, Aug 10, 2017 at 10:35:50PM -0700, RFC Errata System wrote:
> > Section: 6
> >
> > Original Text
> > -------------
> > The egress LSR MAY respond with an LSP Ping Echo
> > reply message that carries the local discriminator assigned by it for
> > the BFD session.
> >
> > Corrected Text
> > --------------
> > The egress LSR MUST respond with an LSP Ping Echo reply message that
> > MAY carry the local discriminator assigned by it for the BFD session.
> >
>
GIM>> I'll list quotes from RFC 4379 that, in my view, indicate that the
echo reply is optional:

   - "... and returned unchanged by the receiver in the echo reply (if any)"
   - "When an MPLS echo request is received, the receiver is expected to verify
   that the control plane and data plane are both healthy (for the FEC
   Stack being pinged) and that the two planes are in sync."
   - " An LSR X that receives an MPLS echo request then processes it as
    follows."

In my interpretation of these quotes, not only echo reply is optional
(first quote) but even action by the echo request receiver (second). And
the third, from section 4.4, that leads to '7. Send Reply Packet:' does not
use normative language and thus we can interpret the whole section 4.4 as
an example, recomendation to implementer.

>
> > Notes
> > -----
> > It is not clear from the original text which of the following is
> optional:
> >   -  The egress MUST send a reply, but the discriminator in the reply is
> optional
> >   -  The reply itself is optional
> >
> > Technically, the reply cannot be optional, because the egress needs to
> report LSP-Ping verification status to the ingress.
>
GIM>> The purpose of the LSP Ping with BFD Discriminator TLV is to
bootstrap BFD session, not to verify consistency of the control plane and
the  data plane. That is why, I believe, RFC 5884 explicitly mandates
egress LSR to send BFD control packet first, before optionally sending echo
reply.

> >
> > The proposed text recommends to include BFD discriminator in the reply.
> This was the intent of the original text.
>
> My opinion follows:
>
> In section 6 -
>
> :    On receipt of the LSP Ping Echo request message, the egress LSR MUST
> :    send a BFD Control packet to the ingress LSR, if the validation of
> :    the FEC in the LSP Ping Echo request message succeeds.  This BFD
> :    Control packet MUST set the Your Discriminator field to the
> :    discriminator received from the ingress LSR in the LSP Ping Echo
> :    request message.  The egress LSR MAY respond with an LSP Ping Echo
> :    reply message that carries the local discriminator assigned by it for
> :    the BFD session.  The local discriminator assigned by the egress LSR
> :    MUST be used as the My Discriminator field in the BFD session packets
> :    sent by the egress LSR.
>
> In the text above, I consider it quite clear that the receipt of the BFD
> packet contains sufficient state to bring up the BFD session.  The receipt
> of the same Discriminator in the LSP Ping Echo Reply is optional.
>
> This makes sense partially because the reply may be dropped and we want the
> BFD session to come up as fast as possible.
>
> The point of contention appears to be what to do if we *never* get such
> replies.  It's worth pointing out additional text in RFC 5884, section 3.2.
>
> :    Hence, BFD is used in conjunction with LSP Ping for MPLS LSP fault
> :    detection:
> :
> :       i) LSP Ping is used for bootstrapping the BFD session as described
> :          later in this document.
> :
> :      ii) BFD is used to exchange fault detection (i.e., BFD session)
> :          packets at the required detection interval.
> :
> :     iii) LSP Ping is used to periodically verify the control plane
> :          against the data plane by ensuring that the LSP is mapped to
> :          the same FEC, at the egress, as the ingress.
>
> iii above reminds us that the LSP may be torn down because LSP Ping fails.
> Thus, it seems problematic that we do not get a reply ever.
>
GIM>> I believe that the suggested periodic LSP Ping SHOULD NOT include BFD
Discriminator TLV and thus their processing would not follow the RFC 5884.
As for the bootstrapping Echo requests, if the BFD control packets from
egress LSR never arrive to the ingress, then the ingress will continue
periodically send LSP ping with BFD Discriminator TLV for pre-defined time.

>
> However, with the BFD session in the Up state, we have information proving
> that the LSP is up.  Thus we have contradictory intent.
>
GIM>> I'd expect BFD session to go down if the LSP gets torn. If the data
plane remains in tact even though LSP expected to be removed, then the
suggested periodic verification of consistency between the control plane
and the data plane should help.

>
> ---
>
> My opinion is that the MAY in the RFC 5884 procedures is intended to have
> the BFD session come up by the most expedient means.  I do not believe the
> likely intent was to say "don't send Echo Reply".  Among other things, that
> seems contrary to the intent of the general LSP Ping procedures.

GIM>> RFC 5884 is clear in giving priority to BFD process not only by
stating "the egress LSR MUST send a BFD Control packet to the ingress LSR"
but by referring to this before mentioning Echo reply. And I agree with the
first part of your conclusion. But, as stated earlier in the thread, my
interpretation of the reference to Echo reply

"The egress LSR MAY respond with an LSP Ping Echo reply message that
carries the local discriminator assigned by it for  the BFD session"

is different. In my understanding, sending of Echo reply is optional but if
the egress LSR sends Echo reply, it MUST include BFD Discriminator TLV with
value set to the local discriminator. Which is redundant and unnecessary
for the ingress LSR.




> Having given my personal observations, we now get to the business of the
> Working Group: Debating intent and related text.
>
> -- Jeff
>
>