Re: A question about RFC5884
"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Sun, 16 July 2017 22:57 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 01F14129B61 for <rtg-bfd@ietfa.amsl.com>; Sun, 16 Jul 2017 15:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, 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 S2W_8wJOPkvP for <rtg-bfd@ietfa.amsl.com>; Sun, 16 Jul 2017 15:57:54 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090F712009C for <rtg-bfd@ietf.org>; Sun, 16 Jul 2017 15:57:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10434; q=dns/txt; s=iport; t=1500245873; x=1501455473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MPzlz+lbcxj3pgFIxFERKqfGEcm+vUiDVkzsLblNZuk=; b=fgMnf+k2IJ+uO5UNvoQXH7gLBzhzdg1P/RA8nZZ8uTuTqByosqDqvxe7 RMffOQpgTvk5RdQGr0HKLBvbrwnm/M5T4Bp4q0t8DsNfsSfYHmE1Qff1g US924Kt4jOnUS+fcKr38D2SsRkjB9UUW+IXzb9dG3Z52eOsQxcxgmJC8p 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CAAQB27mtZ/5FdJa1cGwEBAQMBAQEJAQEBgy8rZIEBE4RViTaRPJB6hSyCESyFGwKDcT8YAQIBAQEBAQEBayiFGQZnEhACAQg/BzIUEQEBBA4FiAk2gQxMAxUQsD2LEgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgyiDTYFhKwuCboE8hnGCMQWXQodyAodIjEyCDIlFhl6VVgEfOBMsS3UVWwGFDIF3dgGGGCuCEgEBAQ
X-IronPort-AV: E=Sophos;i="5.40,371,1496102400"; d="scan'208,217";a="454325895"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 22:57:53 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v6GMvqlu007617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 22:57:52 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 18:57:51 -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; Sun, 16 Jul 2017 18:57:51 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
CC: Mach Chen <mach.chen@huawei.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
Date: Sun, 16 Jul 2017 22:57:51 +0000
Message-ID: <1E6F72A4-2141-42CB-932A-88FD93EB6B94@cisco.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com> <MWHPR01MB2768DA6F22D6F8CDF11700E8FAA30@MWHPR01MB2768.prod.exchangelabs.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291843FC3@dggeml508-mbx.china.huawei.com>, <D5915F0F.2C0CF5%rrahman@cisco.com>
In-Reply-To: <D5915F0F.2C0CF5%rrahman@cisco.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_1E6F72A4214142CB932A88FD93EB6B94ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/DPZKioIQGBf8I8I-HFijmnMsTrk>
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 22:57:56 -0000
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
- A question about RFC5884 Mach Chen
- Re: A question about RFC5884 Ashesh Mishra
- Re: A question about RFC5884 Mach Chen
- Re: A question about RFC5884 Reshad Rahman (rrahman)
- Re: A question about RFC5884 Carlos Pignataro (cpignata)
- Re: A question about RFC5884 Greg Mirsky
- 答复: A question about RFC5884 Mach Chen
- RE: A question about RFC5884 Mach Chen
- Re: A question about RFC5884 Santosh P K
- Re: A question about RFC5884 Carlos Pignataro (cpignata)
- Re: A question about RFC5884 Carlos Pignataro (cpignata)
- Re: A question about RFC5884 Greg Mirsky
- Re: A question about RFC5884 Carlos Pignataro (cpignata)
- Re: A question about RFC5884 Greg Mirsky
- Re: A question about RFC5884 Ashesh Mishra
- RE: A question about RFC5884 Mach Chen
- Re: A question about RFC5884 Carlos Pignataro (cpignata)
- RE: A question about RFC5884 Mach Chen
- Re: A question about RFC5884 Jeffrey Haas