Re: I-D Action: draft-ietf-bfd-yang-06.txt

Jeffrey Haas <jhaas@pfrc.org> Tue, 01 August 2017 16:33 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 0A0C8131EC3; Tue, 1 Aug 2017 09:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 QYkrdtA3pBLl; Tue, 1 Aug 2017 09:33:26 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8AE131C28; Tue, 1 Aug 2017 09:33:26 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 573231E345; Tue, 1 Aug 2017 12:33:40 -0400 (EDT)
Date: Tue, 1 Aug 2017 12:33:40 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Yingzhen Qu <yingzhen.qu@huawei.com>, "Acee Lindem (acee)" <acee@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-yang@ietf.org" <draft-ietf-bfd-yang@ietf.org>, "draft-ietf-ospf-yang@ietf.org" <draft-ietf-ospf-yang@ietf.org>, Reshad Rahman <rrahman@cisco.com>
Subject: Re: I-D Action: draft-ietf-bfd-yang-06.txt
Message-ID: <20170801163340.GD24942@pfrc.org>
References: <C71CC69E-DAE4-49E0-983A-9B2EE9B4CD46@gmail.com> <D5A12762.2D4DB5%rrahman@cisco.com> <E4E310A2-A79C-403E-B68E-A39B76E2C5E0@gmail.com> <773E4FFC-D66A-49E5-A03A-58B7DBA82D90@gmail.com> <20170731170550.GO24942@pfrc.org> <BAF4C9E6-ED02-4E25-89DD-2FA181AF3B72@gmail.com> <3637B198-8F82-4A85-A4A1-4383AF98088D@pfrc.org> <D26CB257-E4B2-42FA-940E-BF77C8BC1751@gmail.com> <20170801144129.GC24942@pfrc.org> <F319C69C-3A4E-4C5C-ADA4-37BDFD97E91A@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F319C69C-3A4E-4C5C-ADA4-37BDFD97E91A@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/BYBGHQ4zeroTyXQ_XICqqGw6n74>
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: Tue, 01 Aug 2017 16:33:28 -0000

On Tue, Aug 01, 2017 at 08:33:38AM -0700, Mahesh Jethanandani wrote:
> > I'm ambivalent.  This depends really on real world behavior.
> > 
> > As we saw from some brief googling yesterday on Cisco IOS/IOS-XR docs, that
> > implementation doesn't appear to expose echo intervals as a separably
> > configurable item.  It did, however, expose a boolean to disable echo.
> 
> True. But the standard seems to imply the ability to configure echo values separately. Worst case implementations would have to set both the values to be the same. 

The protocol does. But that doesn't mean the config model should.

> > This minimally suggests that there should be a "use echo mode" flag.
> 
> Will add a boolean to enable/disable echo mode.

I think that's a good start.

> > The remaining homework is to figure out whether we should expose
> > configuration state for echo directly in this version of the yang.
> 
> Per NMDA guidelines, unless the configuration state values are different from config, we do not need to model them as separate attributes.

Right.  So, again need to check real world implementations.

If it's the case that implementations supporting echo only use a single set
of the intervals for echo or not, then we only need that in the model.  

If it becomes the case that an implementation supports echo intervals
differently, a vendor *could* augment the model to support such values.
However, since this is imported via grouping, it means that the augmentation
has to be done in each module that uses the grouping.

I hate yang grouping augmentation rules. :-P

-- Jeff