Re: [Technical Errata Reported] RFC5884 (5085)

Kireeti Kompella <kireeti@juniper.net> Tue, 15 August 2017 15:20 UTC

Return-Path: <kireeti@juniper.net>
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 DD5CE1321D8 for <rtg-bfd@ietfa.amsl.com>; Tue, 15 Aug 2017 08:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 dH3rXl4fOJJ1 for <rtg-bfd@ietfa.amsl.com>; Tue, 15 Aug 2017 08:20:29 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0125.outbound.protection.outlook.com [104.47.42.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC7D1321EB for <rtg-bfd@ietf.org>; Tue, 15 Aug 2017 08:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zREvFTm9nE4CjDm/QY61pfFyGokRJ5nHEsn408zmuwc=; b=MOWhlHSENu9U2O7eSgCZaeSqTsgD7TkFgvueUxBInnlwrGhSH51/IlzJ99spCG6QB+jCTWd/PyS6GtEySANzn3JNV7E2PM7E3HfP2SwvCA0buW1ycxFkJ6jNa1PTbcGZaJcj41G9xU8AsfzXmPQSiSv1QULRvNVNIeaRwrVrcJM=
Received: from DM5PR05MB3498.namprd05.prod.outlook.com (10.174.242.139) by DM5PR05MB3355.namprd05.prod.outlook.com (10.174.191.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Tue, 15 Aug 2017 15:20:28 +0000
Received: from DM5PR05MB3498.namprd05.prod.outlook.com ([10.174.242.139]) by DM5PR05MB3498.namprd05.prod.outlook.com ([10.174.242.139]) with mapi id 15.01.1362.017; Tue, 15 Aug 2017 15:20:28 +0000
From: Kireeti Kompella <kireeti@juniper.net>
To: Jeffrey Haas <jhaas@pfrc.org>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "tnadeau@lucidvision.com" <tnadeau@lucidvision.com>, "swallow.ietf@gmail.com" <swallow.ietf@gmail.com>, "akatlas@gmail.com" <akatlas@gmail.com>, "db3546@att.com" <db3546@att.com>, "aretana@cisco.com" <aretana@cisco.com>, "rrahman@cisco.com" <rrahman@cisco.com>, Balaji Rajagopalan <balajir@juniper.net>
Subject: Re: [Technical Errata Reported] RFC5884 (5085)
Thread-Topic: [Technical Errata Reported] RFC5884 (5085)
Thread-Index: AQHTEmO7QRT6wc7bv0uPO3Akb5dPw6J/bMuAgAYieis=
Date: Tue, 15 Aug 2017 15:20:28 +0000
Message-ID: <FCABC3F4-90AD-417A-A124-A243E2A865B1@juniper.net>
References: <20170811053550.27303B81263@rfc-editor.org>, <20170811173930.GJ24942@pfrc.org>
In-Reply-To: <20170811173930.GJ24942@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [96.47.52.150]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3355; 6:S9xED6FH6fHyprvsyXSgkbp96/25H7aEC5Q7leH+hlp5YTHIN4/RWHqNf5XpT8QrE+SyVcMs+OPmII98ZCl4Czwehj2Tkl4uZLR1mc7XCWCl3EjDIMg3dXrIwl74JRt4T+7mGEiwkbLgMylwhd5DrtFAAGuiQe+n7oC8aMeaqiom9L2DtZPdQ1PCpDxg4v+BXyI0NVuYaM1QYDP0NwvdZfQDA2dG3zKFLnR083s2NEr9CcCvkywqUs1yIgF6ZH1HD+LQHte3lI6UPI5LD7CbU8p8YbNRoMbLVR7zcXdk+mUVT5geGV27rUQvYbrO75UhjYkmtcW0XkV/h0d8DtPeWQ==; 5:Od2az34KchR/YWg0OIWWW4Y77mzOtiEgGCATWduERzzCRZId1F1DVoMhAcnMqj72YSy8VEZc6HMkwRMUOIFufHE1DgltzI3AzWfdtGV2FphH2Rq42epBNPK4MlDgcB7kT7DPkAciZofd1zU7l7oZdg==; 24:5AwvhFxaILTNax5hRkWoxJxBHdqDjjwh7ERp2ZzSnPzlWoPoQ1/BLRP5odTX8LcF3Tm5c/fhZghAXSIpeWABef1ohfc4M8JWLpy0Le+OxHI=; 7:cuAJhG8w8b//ahUM+ZjjXJMCBVFFAV0EGpNNU7qvOzlnXopMgTNiP7hr9NL1aBSYkeZgVXlq4jwb/rlYkczcls1+KvFl9eNM/I8AvZIDadnlFM9Or4pXrr0ZGPVNm1ZcwE5EyN3bVHrBoUMPf/bVktNaHR3o3tE/o4Tzl0bTmhSUwElTpJKNkE2RAeWOee4hqOANDBkeImEaa7EGiCCiUPsbbVvkvsm9DBZg2S75qbc=
x-ms-office365-filtering-correlation-id: 13cd1251-7da5-42c2-1958-08d4e3f12919
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603144)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR05MB3355;
x-ms-traffictypediagnostic: DM5PR05MB3355:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: <DM5PR05MB335506A7E1CB360AE4330AD1B98D0@DM5PR05MB3355.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3355; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3355;
x-forefront-prvs: 04004D94E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(24454002)(199003)(189002)(36756003)(83716003)(229853002)(33656002)(77096006)(6506006)(53546010)(6486002)(6916009)(2950100002)(68736007)(81156014)(8676002)(81166006)(3846002)(97736004)(478600001)(6116002)(102836003)(3660700001)(305945005)(14454004)(3280700002)(7736002)(2906002)(86362001)(8936002)(5660300001)(6436002)(6246003)(107886003)(110136004)(4326008)(25786009)(53936002)(39060400002)(54906002)(66066001)(6512007)(101416001)(189998001)(82746002)(106356001)(99286003)(2900100001)(105586002)(50986999)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3355; H:DM5PR05MB3498.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kireeti@juniper.net;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 15:20:28.1246 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3355
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/I3tWTHFfDFldnDQru2aRO9t6hPA>
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: Tue, 15 Aug 2017 15:20:32 -0000

As a co-author, I can say that the intent was that the LSP ping reply be sent, but the BFD discriminator be optional.  Not sending an LSP ping reply could lead to the LSP being torn down.

The basic idea here is to use LSP ping to bootstrap a bfd session.  But the semantics of LSP ping don't change; not sending a reply indicates that the LSP is down. 

Kireeti

> On Aug 11, 2017, at 10:39, 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