答复: A question about RFC5884

Mach Chen <mach.chen@huawei.com> Mon, 17 July 2017 07:58 UTC

Return-Path: <mach.chen@huawei.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 C8848131794 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 00:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ZGeyhAZ_Wfw5 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 00:58:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F94131945 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 00:58:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKR07367; Mon, 17 Jul 2017 07:58:41 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 17 Jul 2017 08:58:08 +0100
Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 15:58:04 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: 答复: A question about RFC5884
Thread-Topic: A question about RFC5884
Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAUHekAABGQ11A=
Date: Mon, 17 Jul 2017 07:58:04 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844E6A@dggeml508-mbx.china.huawei.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, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.67.154]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844E6Adggeml508mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.596C6E32.0009, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.135, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 950f6d34fb8e98ec6810c3ff55445309
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/zjL0PEP9f4ciBIbUK0A0jFJCyfw>
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 07:58:48 -0000

Hi Greg,

Thanks for sharing this information!

Best regards,
Mach

发件人: Greg Mirsky [mailto:gregimirsky@gmail.com]
发送时间: 2017年7月17日 15:34
收件人: Mach Chen
抄送: rtg-bfd@ietf.org
主题: Re: A question about RFC5884

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