Re: A question about RFC5884

Ashesh Mishra <mishra.ashesh@outlook.com> Mon, 17 July 2017 16:43 UTC

Return-Path: <mishra.ashesh@outlook.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 227F4131B4F for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 09:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.02
X-Spam-Level:
X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 MhHU8SPEhBeS for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 09:42:59 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002081.outbound.protection.outlook.com [40.92.2.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08924131B33 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 09:42:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1yzd+OGfAM1H/jbejr+tr46W3pwgzXkBFF7mMLOxAuc=; b=JF3JZoTHhcXEmCjLENyKBP3Uxog8ay9lw1g3h66ByNCiv7gOW0T+i3Eund7XCPLGwP5XHq0VFzXR1739QfB0Tyc9oH033M/SMQpf3KDjMPviIEQtqDNPSOJDwKrM/br/+MgCPwan3DTkcMbWyeuqaC8njH/n1i7pOTJdYhfJu/ii0suoMfoIxaVPB5UYHD8HObbD+BwYUqMTG7LOLU3ze5/lx3xR+KPdE0nwQMihyrOp2NHMw9bpMVe1ifBwdy6O2t7UQoWpvZ/4AaAw2ML76gjspv328aNswkKVdc6GeivYg24i/Xm4w/6Hc2PI2V1iq0r10qz73lAiV0/ToAit8A==
Received: from BN3NAM01FT009.eop-nam01.prod.protection.outlook.com (10.152.66.59) by BN3NAM01HT151.eop-nam01.prod.protection.outlook.com (10.152.67.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1240.9; Mon, 17 Jul 2017 16:42:57 +0000
Received: from MWHPR01MB2768.prod.exchangelabs.com (10.152.66.56) by BN3NAM01FT009.mail.protection.outlook.com (10.152.67.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.9 via Frontend Transport; Mon, 17 Jul 2017 16:42:57 +0000
Received: from MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) by MWHPR01MB2768.prod.exchangelabs.com ([10.172.165.146]) with mapi id 15.01.1261.022; Mon, 17 Jul 2017 16:42:57 +0000
From: Ashesh Mishra <mishra.ashesh@outlook.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "Carlos Pignataro (cpignata)" <cpignata@cisco.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/tbSNMtZOwAk4XEAAA+kGIAAAGmAgAAAlU+AAAEZLwAAAWv1XA==
Date: Mon, 17 Jul 2017 16:42:56 +0000
Message-ID: <MWHPR01MB276889C67A8EC60475562027FAA00@MWHPR01MB2768.prod.exchangelabs.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com> <CA+RyBmUvLPm1qUi+_JvGWHHvGKBECOdccfnUdtkeCDAA-_L=vw@mail.gmail.com> <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com> <CA+RyBmWEnB3w4nNoafa233skG=veE6Tz1hrm+AzwQV4Todq9LQ@mail.gmail.com> <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.com>, <CA+RyBmVXJYpM7xUKrUKtKX3gbm3M6Rj_ebS2qL6GDA_qrcjoUw@mail.gmail.com>
In-Reply-To: <CA+RyBmVXJYpM7xUKrUKtKX3gbm3M6Rj_ebS2qL6GDA_qrcjoUw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=outlook.com;
x-incomingtopheadermarker: OriginalChecksum:5CAD7B12E26243FCC98B7234948686DB99DB022489250325E47641F4880FBE25; UpperCasedChecksum:40223EE44845D52F77C0D04A076CC439FEA9569864EFF5E4E70C008BCCD5C126; SizeAsReceived:7605; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [tVPYjT2FBmJ0A1KfqXxARaoOFX/g0Ru6]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3NAM01HT151; 7:R9IeFxP/5ehb2HHia9AIebB1VcpmSjGF7AxFdfnXpFeOtdnZo+qex89A9yzOEGrL6GsA8LwbpwrzfvPVuJhq2khgSzCRvyaUiWRB1Xoo8M+qcTC51nq7bZcsJrFqAg629RwcyBq0x7Dllq8Hn2IiyQ8VXKBr9oodWQQXpkj5nkZ78ZQ5NBUAn8eCa9eGWd8vP0CSfZUpt0h61dUQEHQ9tMnsDm0SaOJzxkqqM2dkWHLwmOEsr8E8mndfnkdYBkCUtL1la/0jonUSfX8dlJmeWKYmNXWe3YVvdTFhIXH+MYyhucu+MVs+zEJupaGHxmjukW9xmpy3N2yF+yn5sSa9nzbZXpSEHu5pSFuxrKMUJEJfGeH6EeSOUJc1POnzW6Ip7tnAq/+YrSBC27wn5XaVHi/qu2tX3RFIFkW78jUYmRTmowz5l3D6UaiWEgDqVc+1RO40LWLfqo2Os84L5wAt97DrfeulU/GOvmUetUhTKliv0sNnjFxywwFIjtmW1Yz/uNKTE2G1L3zpPoBayOYWbFJTujXFahTakcCmv7WQQcfnV+4kmOLVSdPk1NxY39lXfpUJCOIaaQQxN3UxQo8q1NF+qnOw9M29sPhUJtcbKKuoC0bkqBOw/vYnlegBcFR0O2Dd1J04MojPZNv/UjSSGr9gNtblslIPM/AsBlSWg0J6uUbR15ZHulfOVnsdwLdVlZQbuDOKJgrRTFDdgWDYuKLtZQQd4mqTpMGjcGzoG4ZL+RvBp7nhYxOgFz4++1iieuj2meC9TtkCvHPw9r/snQ==
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT151; H:MWHPR01MB2768.prod.exchangelabs.com; FPR:; SPF:None; LANG:en;
x-ms-office365-filtering-correlation-id: ed223f61-1a87-4c73-7899-08d4cd32e0e6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322350)(1601125374)(1603101448)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3NAM01HT151;
x-ms-traffictypediagnostic: BN3NAM01HT151:
x-exchange-antispam-report-test: UriScan:(236129657087228)(50582790962513)(48057245064654)(95692535739014)(50300203121483)(247924648384137);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM01HT151; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM01HT151;
x-forefront-prvs: 0371762FE7
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR01MB276889C67A8EC60475562027FAA00MWHPR01MB2768prod_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 16:42:57.0091 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT151
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/S8s_bNnXQboOplF2UXMZfkuHQf4>
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 16:43:01 -0000

Greg,

Re: following section


On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.

GIM>> The LSP Ping Echo is validated. If the validation fails, then the LSP Echo Reply MUST be sent with the appropriate Return Code. If the validation succeeds, then the BFD control packet MUST be sent.

The MUST in the RFC is for the generation of a BFD control packet and not echo reply.

Ashesh

On Jul 17, 2017, at 6:02 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Carlos,
please find in-lined interpretation of RFC 5884 paragraph tagged GIM>>.

Regards,
Greg

On Mon, Jul 17, 2017 at 8:30 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
Greg,

I am sorry but I don't see how the paragraph supports what you say. Two issues:

1. LSP Ping is based on the Normative reference's spec, RFC 4379. It cannot go against it unless it updates its behavior. The following text:

"The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
   the BFD session."

Also has the interpretation that Santosh shared, which is "MAY send a response including a TLV, but sending it is not optional"

2. You wrote a MUST in your reply with specific ordering of packet responses. MUSTs are for interoperability. The text does not talk about order of packets. Where is that coming from?

It is unhelpful to mention references without citing them, and in any case, I do not believe the text supports your conclusion.

Sent from my iPad

On Jul 17, 2017, at 5:14 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Hi Carlos,
it would take me time to dig that old discussion. I strongly believe that the wording and the order of listing actions in this paragraph of Section 6 RFC 5884 supports my interpretation and recollection of the discussion:

   On receipt of the LSP Ping Echo request message, the egress LSR MUST
   send a BFD Control packet to the ingress LSR, if the validation of
   the FEC in the LSP Ping Echo request message succeeds.

GIM>> The LSP Ping Echo is validated. If the validation fails, then the LSP Echo Reply MUST be sent with the appropriate Return Code. If the validation succeeds, then the BFD control packet MUST be sent.

This BFD
   Control packet MUST set the Your Discriminator field to the
   discriminator received from the ingress LSR in the LSP Ping Echo
   request message.

GIM>> This describes how Your Discriminator field of the BFD control packet to be transmitted by the egress LSR MUST be populated as it will be used by the ingress LSR to demultiplex BFD sessions..

  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.

GIM>> After the egress LSR is done with sending the first BFD control packet it MAY send LSP Ping Echo reply with already allocated and included in BFD control packet My Discriminator as value of BFD Discriminator TLV.

The local discriminator assigned by the egress LSR
   MUST be used as the My Discriminator field in the BFD session packets
   sent by the egress LSR.



Regards,
Greg

On Mon, Jul 17, 2017 at 8:02 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
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