Re: [Technical Errata Reported] RFC5884 (5085)

Greg Mirsky <gregimirsky@gmail.com> Wed, 23 August 2017 02:21 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 782401327EC for <rtg-bfd@ietfa.amsl.com>; Tue, 22 Aug 2017 19:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, 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 8odPrCauvYzI for <rtg-bfd@ietfa.amsl.com>; Tue, 22 Aug 2017 19:21:16 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 D85B81323F9 for <rtg-bfd@ietf.org>; Tue, 22 Aug 2017 19:21:15 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id g77so1699841lfg.1 for <rtg-bfd@ietf.org>; Tue, 22 Aug 2017 19:21:15 -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=xnqmaLim6ZRCY7m7Mrr/Nrxg/QZi/C6tGIo2wGjid1Y=; b=V75SZKIERzUYD6Jo3E/BpVLRsjTgPIw9T54+gWYeXCAAC24/+OdTBJWwpv1YXPJBjg 5WEV+ENu7q+kE03RP1hePy3iH5mtYdK3lv5rTu8/JMiPIvH71RkshIEwRhbiNiWHs4R5 NMkh8JVceHhlYV0VT7FqsUD9Q8dGRJnhOSJnhuX5ojYrAeWxxiMR+pllCSipvmde1VQi NG3+DoUCdp1VDPWkTZp5MnCBD/FtoxsMMYRzswf+hTxmJ/tOkP+Et+kFR2ZusiO7cHyh s/pCGHT6E3dN7NLAtUtIVFK3O7cRD5CLOJzY3y3xh0um+9TnlgtvuvHkaMIk9PCI5NBG l79w==
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=xnqmaLim6ZRCY7m7Mrr/Nrxg/QZi/C6tGIo2wGjid1Y=; b=Pr4X5pgcMDclLR3ppbLyfqs4xAmkwnWcjDHUwg/yBnCMgwDLpZbjWRCU69ivLUdRCL BRhjFkr40F9o2/hZWtDPR/zoh/Mo1FLyPy02b93xz6PuH2BU3Q+qkfclUeynSLBO1s1Y wydsXH/mdLK6ZoH0I5YoOaAeYISL5qE7QW7lc1EgwVXIUuiE/dYncw2fPWhHH7KerAC4 zkqstPcrLNHoAKdiEZEZG7YoqvURc8X4SIanLzDXveFfcLxqNzdGRmKHCFLFsNlcnh01 4qOVmScl6NXeLiNCLbMjMILE2ymNxNnGprYCZ2PbHal7Xmbxf7JT2aHCCYetbXuUNdJi 8B8w==
X-Gm-Message-State: AHYfb5j7FvIqj+YW7ASidUuvxiOkrWNlhd9CVZDrZtZm3lfdkRB/WkQL aOspA0nYrkoz8tcH7bWoJyoBAwTJHQ==
X-Received: by 10.46.9.16 with SMTP id 16mr460223ljj.155.1503454873915; Tue, 22 Aug 2017 19:21:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.88.81 with HTTP; Tue, 22 Aug 2017 19:21:12 -0700 (PDT)
In-Reply-To: <6F83D826-CF7F-462A-BE54-35F46D76A9A8@juniper.net>
References: <20170811053550.27303B81263@rfc-editor.org> <20170811173930.GJ24942@pfrc.org> <CA+RyBmWYRAT3g=zCN+ot9mFDYuPCOGCwyPQJp-+9AfA6oJjttA@mail.gmail.com> <DDFD74A7-D09D-43AE-9BAD-24273A53C55B@juniper.net> <705BEEE3-BC31-42CA-BE0F-06EB6E529A65@cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE29188220B@dggeml508-mbx.china.huawei.com> <6F83D826-CF7F-462A-BE54-35F46D76A9A8@juniper.net>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 22 Aug 2017 19:21:12 -0700
Message-ID: <CA+RyBmVjBBXGh3DaR0vB90HwNjKxMw850e_bY1QSHuycyNP85g@mail.gmail.com>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
To: Balaji Rajagopalan <balajir@juniper.net>
Cc: Mach Chen <mach.chen@huawei.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, Kireeti Kompella <kireeti@juniper.net>, Thomas Nadeau <tnadeau@lucidvision.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Alia Atlas <akatlas@gmail.com>
Content-Type: multipart/alternative; boundary="001a114b12f4b215c50557625de4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/axxIB1q1b3S1-Ot40k7u2IxMxbk>
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: Wed, 23 Aug 2017 02:21:19 -0000

Hi Balaji,
I've been thinking about the value of including BFD Discriminator TLV in
echo reply sent by egress. What we'd expect ingress to do upon receiving
the reply? Match to bfd.remoteDiscr? I think that then echo reply must
include the value from the original BFD Discriminator TLV so that ingress
uses it to demux BFD sessions. Or ingress doesn't validate the value in BFD
Discriminator TLV but only that the TLV is included in reply? If we leave
actions of the ingress upon receipt of the reply with BFD Discriminator
underspecified it may result in another set of interoperability issues.
Perhaps the simplest way to avoid that would be to not allow BFD
Discriminator TLV in the reply.

Regards,
Greg

On Tue, Aug 22, 2017 at 2:16 AM, Balaji Rajagopalan <balajir@juniper.net>
wrote:

> That sounds better. How about the following text?
>
>
>
> The egress LSR MUST follow the procedures described in [RFC4379] in
> processing the LSP Ping request. The LSP Ping reply generated by the egress
> MAY carry the local discriminator assigned by it for the BFD session.
>
>
>
> --
>
> Balaji Rajagopalan
>
>
>
> *From: *Mach Chen <mach.chen@huawei.com>
> *Date: *Thursday, 17 August 2017 at 8:45 AM
> *To: *"Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Balaji
> Rajagopalan <balajir@juniper.net>, Greg Mirsky <gregimirsky@gmail.com>,
> Jeffrey Haas <jhaas@pfrc.org>
> *Cc: *Kireeti Kompella <kireeti@juniper.net>, Thomas Nadeau <
> tnadeau@lucidvision.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Reshad
> Rahman (rrahman)" <rrahman@cisco.com>, Alia Atlas <akatlas@gmail.com>
> *Subject: *RE: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Indeed, I also like Les’s suggestion!
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] *On Behalf Of *Carlos
> Pignataro (cpignata)
> *Sent:* Wednesday, August 16, 2017 10:20 PM
> *To:* Balaji Rajagopalan <balajir@juniper.net>; Greg Mirsky <
> gregimirsky@gmail.com>; Jeffrey Haas <jhaas@pfrc.org>
> *Cc:* Kireeti Kompella <kireeti@juniper.net>; Thomas Nadeau <
> tnadeau@lucidvision.com>; rtg-bfd@ietf.org; Reshad Rahman (rrahman) <
> rrahman@cisco.com>; Alia Atlas <akatlas@gmail.com>
> *Subject:* Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> This sounds like a good summary of the tactical fix.
>
>
>
> (Although, like Les wrote down, saying “MUST follow [LSP-Ping]” is better
> than “MUST Send a Reply”)
>
>
>
> As an aside -- When it comes to Interop, I remember also issues around the
> UDP Port on the egress BFD Control packet, depending on whether the
> response is IP-based vs. over an MPLS LSP.  Tracking this down, this was
> identified at https://www.ietf.org/mail-archive/web/rtg-bfd/current/
> msg00447.html (comments on Sections 6 and 7), and it seems, we may have
> the right bug but a wrong fix.
>
>
>
> Thanks,
>
>
>
> -- Carlos.
>
>
>
> *From: *Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Balaji
> Rajagopalan <balajir@juniper.net>
> *Date: *Wednesday, August 16, 2017 at 1:23 AM
> *To: *Greg Mirsky <gregimirsky@gmail.com>, Jeff Haas <jhaas@pfrc.org>
> *Cc: *Kireeti Kompella <kireeti@juniper.net>, Tom Nadeau <
> tnadeau@lucidvision.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Reshad
> Rahman (rrahman)" <rrahman@cisco.com>, Alia Atlas <akatlas@gmail.com>
> *Subject: *Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> I’m aware of three different behaviours from three different vendors that
> I came across in the course of inter-op:
>
> -         Always respond to an LSP-Ping request carrying a BFD disc
>
> -         Never send a response to an LSP-Ping request carrying a BFD disc
>
> -         Don’t respond to the first LSP-Ping request carrying a BFD
> disc, but respond to the subsequent ones
>
>
>
> This experience leads me to believe that this procedure is NOT
> well-understood.  So, publication of errata on this issue is necessary.
>
>
>
> As some of the co-authors have clarified in further emails, inclusion of
> BFD discriminator in the LSP-Ping request does not change LSP-Ping’s basic
> function. So, the egress must send a reply. This is what the erratum
> clarifies.
>
>
>
> --
>
> Balaji Rajagopalan
>
>
>
>
>
>
>
> *From: *Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, 11 August 2017 at 11:42 PM
> *To: *Jeffrey Haas <jhaas@pfrc.org>
> *Cc: *Kireeti Kompella <kireeti@juniper.net>, Thomas Nadeau <
> tnadeau@lucidvision.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Reshad
> Rahman (rrahman)" <rrahman@cisco.com>, Alia Atlas <akatlas@gmail.com>
> *Subject: *Re: [Technical Errata Reported] RFC5884 (5085)
>
>
>
> Re-sending to the corrected list (apologies for duplicates).
>
>
>
> Dear All,
>
> I suggest to reject this proposal. The current text is clear and the
> mechanics of bootstrapping BFD session over MPLS LSP is well understood -
> remote peer MUST start sending BFD control packets first and BFD peer MAY
> send Echo Reply with its Local Discriminator as value in BFD Discriminator
> TLV.
>
>
>
> 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.
> >
> >
> > 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.
> >
> > 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.
>
> However, with the BFD session in the Up state, we have information proving
> that the LSP is up.  Thus we have contradictory intent.
>
> ---
>
> 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.
>
> Having given my personal observations, we now get to the business of the
> Working Group: Debating intent and related text.
>
> -- Jeff
>
>
>