Re: A question about RFC5884

Greg Mirsky <gregimirsky@gmail.com> Mon, 17 July 2017 16:02 UTC

Return-Path: <gregimirsky@gmail.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 023CA131C95 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 09:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1Eg-TT4_Upy3 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 09:02:16 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E44131C91 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 09:02:16 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id b40so109905603qtb.2 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 09:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jyL9MxwGTcMzRxcn3+3au0spB92Wo7Lt8J2bpSumIhE=; b=Vn1zHs9oAewX7AzXR6+0RDAjKKXf4ZU/ZSLzVV5+7tZSPQzYxQc4GrpQKIlPD04ReH D5oTt+K2YAohB44rAPlzPfSe3vIwk+ef1HEImX9my64xJjZmLlIwce6vRXZv6yeLWgDY HNDdnDHv1bWJhXxArhig0nZBCwIlXphRGkWI39en0IssUj3bfNV4JWWm0p/oA3XGwVdD 51ncMYurLMEm8goYXufV3PXkQ0pK37zyT+rtKoPohMQkRt1rkhwlSUxyEWhCs1lX15Pb BkpQU1GgI/9CpvUKtrvmWVnOAUcteUXI+2AUjqvUcAgOR38tpibKYlVwXiVXaKtWN+FE HTdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jyL9MxwGTcMzRxcn3+3au0spB92Wo7Lt8J2bpSumIhE=; b=cOjCj3S3lIEgfcLYmOT483jbeo8sUB7fe182j0DG+IKyA/XInPa6i0DcfrZHrD8RGR O3uinp0XLcO9qc1PoP456V9VThS5wIa/z+NUmpRSNKR8owqJxS/ZscYWfeuUi6q3y0cN sLqqMLqXruAoGW/LRzHBOSlpxROlH1dIL5I8AHSLUcui9DpWXSzneittQqDPqq+4Zsve kSJ79QFZkR6Q4zpyGdDBGaZbAhJnSOkfwqJmWcYD3DhN5pQmjJ1eaG02y3bNZmNwa7xj o6yR5fDF4R4qi4dQwULFmd+7yQxXkiO7VXx1Tjgn1RSfLfIMc/I2oFkpcldjyuXN+NwC y8Gg==
X-Gm-Message-State: AIVw11069nAWm4ZhpePzbc0XOPPqIi64sGeOJPV6n9uqwme0JEtPxrI4 g0o+a3GNO8/U6bg4oQ4Rt/Hwsjhhag==
X-Received: by 10.237.62.240 with SMTP id o45mr5362103qtf.233.1500307334999; Mon, 17 Jul 2017 09:02:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.227 with HTTP; Mon, 17 Jul 2017 09:02:14 -0700 (PDT)
In-Reply-To: <0AC77509-6F04-4C6F-A6EF-EC9098048C84@cisco.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>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 17 Jul 2017 09:02:14 -0700
Message-ID: <CA+RyBmVXJYpM7xUKrUKtKX3gbm3M6Rj_ebS2qL6GDA_qrcjoUw@mail.gmail.com>
Subject: Re: A question about RFC5884
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: Mach Chen <mach.chen@huawei.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142a4eac1b0960554858574"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/xpDVH5tE3YTz0st2ONzs6mavVXA>
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:02:18 -0000

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>; 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>; 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>; wrote:
>
>> Greg,
>>
>> Pointer?
>>
>> Thanks,
>>
>> Sent from my iPad
>>
>> On Jul 17, 2017, at 9:34 AM, Greg Mirsky <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>; 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
>>>
>>>
>>
>