RE: A question about RFC5884

Mach Chen <mach.chen@huawei.com> Tue, 18 July 2017 07:14 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 ADA81131D8F for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Jul 2017 00:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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] 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 X4XfR7FfiA19 for <rtg-bfd@ietfa.amsl.com>; Tue, 18 Jul 2017 00:13:59 -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 07AF0131D8E for <rtg-bfd@ietf.org>; Tue, 18 Jul 2017 00:13:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRL30941; Tue, 18 Jul 2017 07:13:56 +0000 (GMT)
Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 18 Jul 2017 08:13:55 +0100
Received: from DGGEML508-MBX.china.huawei.com ([169.254.3.135]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0301.000; Tue, 18 Jul 2017 15:13:52 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
CC: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, Ashesh Mishra <mishra.ashesh@outlook.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/tbSNMtZOwAA8z/LAAyvGMAABhb8gP//+OwK//9kF8CAAaePmP/+7thA
Date: Tue, 18 Jul 2017 07:13:51 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918486DA@dggeml508-mbx.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com> <MWHPR01MB2768DA6F22D6F8CDF11700E8FAA30@MWHPR01MB2768.prod.exchangelabs.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291843FC3@dggeml508-mbx.china.huawei.com>, <D5915F0F.2C0CF5%rrahman@cisco.com> <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com>, <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291844EF6@dggeml508-mbx.china.huawei.com> <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com>
In-Reply-To: <6263E0A6-EE08-43BB-A845-BCF5788D2A14@cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.76.65]
Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE2918486DAdggeml508mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.596DB535.004E, 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: 86e97e8fe3821be016b9856e33b9f8ce
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/DmXPLLb9XFZiNsH4KrF7iSDM8TQ>
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, 18 Jul 2017 07:14:02 -0000

Hi Carlos,

Do you suggest to do a 5884-bis?

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 10:56 PM
To: Mach Chen
Cc: Reshad Rahman (rrahman); Ashesh Mishra; rtg-bfd@ietf.org
Subject: Re: A question about RFC5884

Hi Mach,

On Jul 17, 2017, at 10:42 AM, Mach Chen <mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:
Hi Carlos,

Thanks for sharing your thoughts.

IMHO, it may not be necessary to consider this LSP Ping based bootstrapping as normal LSP ping.

Would it be considered an abnormal LSP Ping? :-)


If RFC 5884 references RFC 4379, I'd expect it means an LSP Ping as specified in 4379, or those processes for LSP Ping be updated.

Sent from my iPad


And since both the ingress and egress LSR process the echo messages in the context of BFD session establishment, it should be no problem to process as described in RFC5884.

BTW, RFC5884 does not specify which reply mode will be used :)

Best regards,
Mach

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, July 17, 2017 6:58 AM
To: Reshad Rahman (rrahman)
Cc: Mach Chen; Ashesh Mishra; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: A question about RFC5884

Hi,

I also agree with the conclusion of this thread in regards to what RFC 5884 says. However, can that be in conflict with RFC 8029's procedures, in which the reply might be expected?
https://tools.ietf.org/html/rfc8029#section-4.4

There is certainly no need to carry any information in an MPLS LSP Ping reply, since at that point the discriminatory are already carried in BFD. The reply might be important only if FEC validation fails.

I wonder though if the text of "The egress LSR MAY respond with an LSP Ping Echo" intended to convey that whether to reply or not depends on the value of the Reply Mode field in the Echo request.

Sent from my iPad

On Jul 16, 2017, at 6:22 PM, Reshad Rahman (rrahman) <rrahman@cisco.com<mailto:rrahman@cisco.com>> wrote:
Hi,

My take too is that the RFC is pretty clear that Echo reply from egress
LSR is not mandatory.

Regards,
Reshad.



On 2017-07-16, 4:29 PM, "Rtg-bfd on behalf of Mach Chen"
<rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org> on behalf of mach.chen@huawei.com<mailto:mach.chen@huawei.com>> wrote:



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<mailto: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<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