Re: A question about RFC5884

Mach Chen <mach.chen@huawei.com> Sun, 16 July 2017 20:29 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 530F21288B8 for <rtg-bfd@ietfa.amsl.com>; Sun, 16 Jul 2017 13:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 Lisw35atAI3j for <rtg-bfd@ietfa.amsl.com>; Sun, 16 Jul 2017 13:29:17 -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 A34C1124D37 for <rtg-bfd@ietf.org>; Sun, 16 Jul 2017 13:29:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKN91967; Sun, 16 Jul 2017 20:29:14 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 16 Jul 2017 21:29:14 +0100
Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0301.000; Mon, 17 Jul 2017 04:29:08 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Ashesh Mishra <mishra.ashesh@outlook.com>
CC: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884
Thread-Topic: A question about RFC5884
Thread-Index: AdL+O5gXoB9THAjbTKqm/tbSNMtZOwAA8z/LAAyvGMA=
Date: Sun, 16 Jul 2017 20:29:07 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291843FC3@dggeml508-mbx.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com> <MWHPR01MB2768DA6F22D6F8CDF11700E8FAA30@MWHPR01MB2768.prod.exchangelabs.com>
In-Reply-To: <MWHPR01MB2768DA6F22D6F8CDF11700E8FAA30@MWHPR01MB2768.prod.exchangelabs.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.64.247]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.596BCC9B.0044, 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: 11537aaad02321908c0cbfce0e48761f
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/NlhMqe-zKnt6TpqqC5mNrsrr8EI>
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: Sun, 16 Jul 2017 20:29:18 -0000

Hi Ashesh,

Thanks for your prompt response, we're on the same page!

Best regards,
Mach

> -----邮件原件-----
> 发件人: Ashesh Mishra [mailto:mishra.ashesh@outlook.com]
> 发送时间: 2017年7月16日 22:26
> 收件人: Mach Chen
> 抄送: rtg-bfd@ietf.org
> 主题: Re: A question about RFC5884
> 
> That's how I read it ... assuming that proper handling of the LSR echo includes
> gracefully dropping it on rx.
> 
> Ashesh
> 
> On Jul 16, 2017, at 3:58 PM, Mach Chen <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