Re: Correcting BFD Echo model

Greg Mirsky <gregimirsky@gmail.com> Mon, 27 February 2017 06:08 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 7AC2F129B5C; Sun, 26 Feb 2017 22:08:00 -0800 (PST)
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 94vDWWTUTvQq; Sun, 26 Feb 2017 22:07:59 -0800 (PST)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 31665129B0C; Sun, 26 Feb 2017 22:07:59 -0800 (PST)
Received: by mail-ot0-x232.google.com with SMTP id k4so45612802otc.0; Sun, 26 Feb 2017 22:07:59 -0800 (PST)
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=ZgYC6vkA4YHQFtLRg5B9FhJ7CIUhAdtqDG9OLHvWrvA=; b=nP6rpDiR8h4K45HVwVgIlwpMY4Fn+hpA+FB88yl4zSQIS7JQ7ZFFxR3kQyYG3XvdGR FPcibvcvUOwAXt9AKrsCTbnwd/2piTgFD1Vtr4bsOzo4uKBVxEex16WRA4/Yg/pOu7gs wkEQfc7AGXtlzKVPBawChN9LomP3I/AMmMMjtWWtuC6g7N9n8+SiYGU5VCu25++oI4ju diEIhlOlTHiVmsGDbwp7gV5zbUHuA6C5/oqiNST4twyr9v65PBArkgZXDuxI4buafkSs 1rCDsdl23y3MfV+qBiQOvekREV9O+CLNO4BlrvPQFwVerrgt5/Lh+DRbfBoHxyKnQCnR 2q+A==
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=ZgYC6vkA4YHQFtLRg5B9FhJ7CIUhAdtqDG9OLHvWrvA=; b=doa/jwJbnX5QhEgfdfNPP0XzB0HHmC/P6xaU6thL00HOiHlNQcdQesqvCEESLqapCj fOh00J/YsGta5spWxBPOkxWQS78qzVyOIDrIztWWT37ensDAXSvlNwYGwmQobEAK2G5T pj7aZkfQF2eDb9VzGY1ST0Ed7+G4/5+DLltfTVbuoG89IPeM+d303pLu/bca8z7xlS+2 X+qZ8pMgjZo9Is01eBv3yD/62xLM6bKozqb0xAtYcYVUSL4SyXMZN7g7BZVyJoZ6O114 WaDb9GgCe0TcESk7y5o8qPCD/OKldncJubSao6xq5s+FFCKBWWwzN4h5BDAoy4pZ81Hk yJbw==
X-Gm-Message-State: AMke39ldafBaYpU/e6DTMOEPk37YS5DhHOZljn3Pyda8IEmtlbPlA+o9Kj0fGF9Vc0GAlAbpUjH6rcy+HJJF8w==
X-Received: by 10.157.1.229 with SMTP id e92mr6917009ote.40.1488175678493; Sun, 26 Feb 2017 22:07:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Sun, 26 Feb 2017 22:07:58 -0800 (PST)
In-Reply-To: <E308FD25-A695-498C-8E34-756250776CE4@gmail.com>
References: <CA+RyBmWcU79iCBYM_bi__Ce1RpWwNn_jZCkPHv3Sc+qtybt_pg@mail.gmail.com> <D4D8BE31.25AE5C%rrahman@cisco.com> <CA+RyBmWyQZs5B3LG8x=ZoVXTkiHhGPzbZwRX70jCyT_MpQwzCA@mail.gmail.com> <E308FD25-A695-498C-8E34-756250776CE4@gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 26 Feb 2017 22:07:58 -0800
Message-ID: <CA+RyBmW=t0DH5H_UVau8t5rS_1A8Qpsh478ayVUN=Se6qqKHyg@mail.gmail.com>
Subject: Re: Correcting BFD Echo model
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c03c39aae19a005497ce6a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/UiXHpk6Bh9hjU1P7xRffR-HVEws>
Cc: "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.17
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, 27 Feb 2017 06:08:00 -0000

Hi Mahesh,
BFD Echo transmit interval is not part of RFC 5880, only Rx interval is.
And Rx interval is sufficent to reflect whether local system is willing to
receive BFD Echo messages from the particular BFD peer. Introduced
desired-min-echo-tx-interval functionally overlaps with the
standard-defined required-min-echo-rx-interval. Hence my suggestion to
remove desired-min-echo-tx-interval from grouping
bfd-grouping-echo-cfg-parms. But operators need a way to specify transmit
interval for on-demand OAM command like BFD Echo, IP ping or LSP ping. I
couldn't find YANG model proposal for IP ping but in
draft-zheng-mpls-lsp-ping-yang-cfg
transmit interval used in RPC, not as part of configuration.

Regards,
Greg


On Sun, Feb 26, 2017 at 8:33 PM, Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

>
> On Feb 26, 2017, at 4:39 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Reshad,
> thank you for the question. Here's my reasoning:
>
>    - only Required Min Echo RX Interval is present in RFC 5880 and it
>    allows to indicate not only the smallest interval between consecutive BFD
>    Echo packets but whether system supports BFD Echo function at all;
>    - since BFD Echo may be transmitted only when the session state is Up,
>    operator is fully equipped to learn the value of Required Min Echo RX
>    Interval of its BFD peer and to set Echo transmit interval accordingly;
>    - requesting BFD Echo, in my opinion, is no different from requesting
>    IP ping or LSP ping.
>
> Hence my conclusion - transmit interval for BFD Echo is more suitable in
> RPC then as configuration parameter.
>
>
> I do not think that is reason enough for it to be a RPC.
>
> A RPC is an operation one defines in the YANG model specifying both input
> and output parameters. There are no operations to be had here.
>
> And the definition and desired behavior of desired-min-echo-tx-interval is
> not very different from required-min-echo-x-interval. It is as the
> definition says, a configuration parameter that can be set, with zero
> having a special meaning in both cases.
>
>
> Regards,
> Greg
>
> On Sun, Feb 26, 2017 at 2:52 PM, Reshad Rahman (rrahman) <
> rrahman@cisco.com> wrote:
>
>> Hi Greg,
>>
>> Can you please explain why you believe this should go in RPC?
>>
>> Regards,
>> Reshad.
>>
>> From: Greg Mirsky <gregimirsky@gmail.com>
>> Date: Saturday, February 25, 2017 at 6:48 PM
>> To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org"
>> <draft-ietf-bfd-yang@ietf.org>
>> Subject: Correcting BFD Echo model
>> Resent-From: <alias-bounces@ietf.org>
>> Resent-To: <vero.zheng@huawei.com>, Reshad <rrahman@cisco.com>, <
>> mjethanandani@gmail.com>, <santosh.pallagatti@gmail.com>, <
>> gregimirsky@gmail.com>
>> Resent-Date: Saturday, February 25, 2017 at 6:48 PM
>>
>> Dear All,
>> I've reviewed the BFD YANG model and now I'm thinking that desired-min-echo-tx-interval
>> and attributing to it the behavior, i.e. when the value is 0, of Required
>> Min Echo RX Interval are not in the right place. I think that definition of
>> desired transmit interval of BFD Echo should be in corresponding RPC
>> definition, not in configuration part of the model.
>> Appreciate your comments.
>>
>> Regards,
>> Greg
>>
>
>
>