IETF Logo Mail Archive

Re: A question about RFC5884

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 17 July 2017 15:02 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 B9CC4131C43 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 08:02:20 -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 zoIZjM94-_wi for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 08:02:19 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459DD130019 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 08:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3818; q=dns/txt; s=iport; t=1500303739; x=1501513339; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cBp7tQYDVwU5YKK4mk2jleV6cUaFJNSz3PQDxwk5lEc=; b=HbyXPRz5kh/RUtbsFHkoruCm5fid//t4L4iPQuKVSaan/qO91kCWjOvy rTmRCsZGuCGmS2qnTPIq4/7s6NhgjF8X627HxUsNjcMJxjM/2Zaqebae1 hlTwIgCTorSyU3StXKYJ8MYwf3XFExiP7jXR0RG2yAK2H+wA7597v5D0G M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DiAADl0GxZ/4sNJK1cGgEBAQECAQEBAQgBAQEBg1qBeI4Lmg2IKoUsghGFRwKDRD8YAQIBAQEBAQEBayiFGQZnEhACAQgEOwchERQRAQEEDgWJS0wDFbFshywNg10BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgyiDTYFhK4J5gTyBG4VWgjEFnnk7Ao8khHCSL4wKiUwBHziBCnUVWwGFDIF3dokMAQEB
X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208,217";a="455017973"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2017 15:02:18 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v6HF2H40011702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 17 Jul 2017 15:02:18 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Jul 2017 11:02:17 -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:02:17 -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/tbSNMtZOwAtQzYAAAdCXes=
Date: Mon, 17 Jul 2017 15:02:17 +0000
Message-ID: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com>, <CA+RyBmUvLPm1qUi+_JvGWHHvGKBECOdccfnUdtkeCDAA-_L=vw@mail.gmail.com>
In-Reply-To: <CA+RyBmUvLPm1qUi+_JvGWHHvGKBECOdccfnUdtkeCDAA-_L=vw@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_983DC002121A48FA94A9D0FF68D07393ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/mWTvXeVXZjkCZXDHCsNZz7FU-sM>
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:02:21 -0000

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

v2.23.0 | Report a Bug | By Email