Re: A question about RFC5884

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 17 July 2017 15:30 UTC

Return-Path: <cpignata@cisco.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 B21C7131C7D for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 08:30:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 lEvrx3E_yu90 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 08:30:50 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D73131C80 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 08:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9531; q=dns/txt; s=iport; t=1500305449; x=1501515049; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UVnx+JTbIGkdggRUeRACiYqfNR2jMyZViGPsAE338HM=; b=FTs7jpUyUWxog1mV4Zb/IeDXSerFKxlFmgufP2dE7nILbEDMVZ753JQU eu6u5Tj3QTx+nTwngJABZngojvrleGil3oUektyXenPekvdSGzNUHEX37 4MIsHdE6KYoeL7DUEJ8SI6k7I+jFwocAlPq/hPCbH8LhF5J8XCuONkF2o g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DiAADa1mxZ/5hdJa1cGgEBAQECAQEBAQgBAQEBgm9rgXiOC5oNiCqFLIIRhUcCg0Q/GAECAQEBAQEBAWsohRkGZxIQAgEIPwchERQRAQEEDgWJS0wDFbFlhy0Ng10BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiDTYFhK4J5gTyBG4VWgjEFnnk7AosShBKEcJIvjAqJTAEfOIEKdRVbAYUMgXd2hk8rghIBAQE
X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208,217";a="456862888"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 15:30:48 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v6HFUm0g025065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2017 15:30:48 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 11:30:48 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Mon, 17 Jul 2017 11:30:48 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Mach Chen <mach.chen@huawei.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884
Thread-Topic: A question about RFC5884
Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAtQzYAAAdCXesACMs6gP//wZ16
Date: Mon, 17 Jul 2017 15:30:47 +0000
Message-ID: <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com> <CA+RyBmUvLPm1qUi+_JvGWHHvGKBECOdccfnUdtkeCDAA-_L=vw@mail.gmail.com> <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com>, <CA+RyBmWEnB3w4nNoafa233skG=veE6Tz1hrm+AzwQV4Todq9LQ@mail.gmail.com>
In-Reply-To: <CA+RyBmWEnB3w4nNoafa233skG=veE6Tz1hrm+AzwQV4Todq9LQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_0AC775096F044C6FA6EFEC9098048C84ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/GvJXZCSnZP9wsc_wzHtAMpyes4Q>
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, 17 Jul 2017 15:30:52 -0000

Greg,

I am sorry but I don't see how the paragraph supports what you say. Two issues:

1. LSP Ping is based on the Normative reference's spec, RFC 4379. It cannot go against it unless it updates its behavior. The following 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."

Also has the interpretation that Santosh shared, which is "MAY send a response including a TLV, but sending it is not optional"

2. You wrote a MUST in your reply with specific ordering of packet responses. MUSTs are for interoperability. The text does not talk about order of packets. Where is that coming from?

It is unhelpful to mention references without citing them, and in any case, I do not believe the text supports your conclusion.

Sent from my iPad

On Jul 17, 2017, at 5:14 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Carlos,
it would take me time to dig that old discussion. I strongly believe that the wording and the order of listing actions in this paragraph of Section 6 RFC 5884 supports my interpretation and recollection of the discussion:

   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.



Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
Greg,

Pointer?

Thanks,

Sent from my iPad

On Jul 17, 2017, at 9:34 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Mach, et. al,
I recall that this question was discussed some time ago and the clarification came from the original authors of the BFD protocol. The Echo Reply is optional if there's no error to report. But if the remote LER, acting as BFD node, does decide to send the Echo Reply it MUST send it after is sends the first BFD control message.

Regards,
Greg

On Sun, Jul 16, 2017 at 6:58 AM, Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:
Hi BFDers,

We met a multi-vendor interoperate issue recently, it's about whether an Echo reply is necessary.

In Section 6 of RFC5884, 2nd paragraph

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

>From the above text, my understanding is that an Echo reply is optional, the egress LSR can freely to return or not return an Echo reply, and the Ingress LSR should not expect there MUST be an Echo reply, but if there is one, it should handle it properly.

Is my understanding correct?

Thanks,
Mach