IETF Logo Mail Archive

Re: A question about RFC5884

Greg Mirsky <gregimirsky@gmail.com> Mon, 17 July 2017 15:14 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 A0CC0126D73 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 08:14:17 -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 MK2TkqeUQcK8 for <rtg-bfd@ietfa.amsl.com>; Mon, 17 Jul 2017 08:14:16 -0700 (PDT)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 049BF131C4D for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 08:14:07 -0700 (PDT)
Received: by mail-qt0-x22c.google.com with SMTP id 21so33340709qtx.3 for <rtg-bfd@ietf.org>; Mon, 17 Jul 2017 08:14:06 -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=haXW2egrPA2VbzSUI6WsMrQGt9A4ZS34ftjR5cR2DJk=; b=ubjTj+LB3IoXHM1bQjZo3mkwaQpg30vW43hJh0349l/Y/HgpsE4dHLrj2u7URe9aO5 L4QM3eE4tpjrdi8yh7W+8Xz7A5vs6X0xFNppnY3b7LgkeDx+T+Hv0QsVG1XzXLz6QBnS 6nL09DWJIcbs1svz0HHDMhFHu5XNgSJWqN/iJ5jCggIDsSpaymIBlfM6QXLGg7hiHYqe 9BFTSeoR5HrNUo/vv40Ru7j7XX1bK596WWb+dXGN8YShuZlxo7aDCKxnE9/+E4gLaisa SfdkevAYJIbw8PX4ZkKIdxzvxhfn1DLxeWFoC8fGGtWSGv+zPbbm04pUQ0FQKFk9cuw+ DPlg==
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=haXW2egrPA2VbzSUI6WsMrQGt9A4ZS34ftjR5cR2DJk=; b=L73FzYtYEciOnu2sVeCPoFlwCQwgr9seDKgto56HPTzJTCWEVY9C9sChgeDm+o+9L8 mntbitr6NUMI4a5qVKed1vMM9PVppm4LQt2v71PoGou1ngbsjr+GC6YDG++Tv64/bVRg LkaDfVIT0gLqnRC8qYrO5DYB6/7uISjZ1Dj7081c//YJCqVzQ8jwoYIg9TlWv2tES7dI b/ywycI+olCO2arUUdT1mX9annripmRPPk4HbvH8ZuG8pog7z3OW7kSDiU1Nc5I3rJoj 1hMZu7jcsGCWkVbtS/2uRh/VJ52ioHltPebxQ84KpwMhNqJwhUhVctVbCXjrBGMJ9KfU BcMw==
X-Gm-Message-State: AIVw110kWsAECJI6t04fy7ByHpSp9AG2HPa9kuoqsYTxK7KMJxZ5xO2T bZp596/B04ntiquTOrQx+0F8ktCxlQ==
X-Received: by 10.237.45.67 with SMTP id h61mr27170674qtd.246.1500304445931; Mon, 17 Jul 2017 08:14:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.227 with HTTP; Mon, 17 Jul 2017 08:14:05 -0700 (PDT)
In-Reply-To: <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE291842ADE@dggeml508-mbx.china.huawei.com> <CA+RyBmUvLPm1qUi+_JvGWHHvGKBECOdccfnUdtkeCDAA-_L=vw@mail.gmail.com> <983DC002-121A-48FA-94A9-D0FF68D07393@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 17 Jul 2017 08:14:05 -0700
Message-ID: <CA+RyBmWEnB3w4nNoafa233skG=veE6Tz1hrm+AzwQV4Todq9LQ@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="94eb2c124a888e0687055484d905"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nFUnpRBnL4ANeyInw5MmOJ7RZQE>
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 15:14:18 -0000

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.  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.  The egress LSR MAY respond with an LSP Ping Echo
   reply message that carries the local discriminator assigned by it for
   the BFD session.  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
>>
>>
>

v2.23.0 | Report a Bug | By Email