Re: [netmod] BBF Entity Augmentations

Martin Bjorklund <mbj@tail-f.com> Mon, 24 October 2016 17:58 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01335129962 for <netmod@ietfa.amsl.com>; Mon, 24 Oct 2016 10:58:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.332
X-Spam-Level:
X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431, 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 WTnn-Plcs2cG for <netmod@ietfa.amsl.com>; Mon, 24 Oct 2016 10:57:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6E71295DD for <netmod@ietf.org>; Mon, 24 Oct 2016 10:57:58 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id C34DB1AE039E; Mon, 24 Oct 2016 19:57:57 +0200 (CEST)
Date: Mon, 24 Oct 2016 19:57:57 +0200
Message-Id: <20161024.195757.2254520820491075199.mbj@tail-f.com>
To: timothy.carey@nokia.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <9966516C6EB5FC4381E05BF80AA55F77012A796BAA@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <9966516C6EB5FC4381E05BF80AA55F77012A796BAA@US70UWXCHMBA05.zam.alcatel-lucent.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/fmOz-LTtLI_pANCRzFcdz8nnxq8>
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF Entity Augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2016 17:58:01 -0000

Hi,

"Carey, Timothy (Nokia - US)" <timothy.carey@nokia.com> wrote:
> Reposting to fix formatting errors in the original message - still
> looking for comments.
> 
> Hello,
> 
> In using the Entity module within the BBF, we have made several
> enhancements to the module that we would like the IETF to consider for
> inclusion in the next draft of the module as we consider these
> enhancements to be of use to the wider YANG community.
> 
> I have included the tree definitions in this email thread. If you like
> the actual YANG files please let us know and we can provide those to
> the authors.
> 
> Specifically we have done the following enhancements:
> 
> 1    Added a new generic reset action for a physical entity
> module: bbf-entity-reset-action
> augment /ent:entity-state/ent:physical-entity:
> +---x reset
> +---w input
> +---w reset-type? identityref

I think it would help to see the YANG definition for this action.

> 2    Added a parent/child entity capability for physical entities

Is this different from contained-id/contains-child that already exist?

> 3 Added a couple of common attributes for the manufacturer name and
> model
> module: bbf-entity-extension
> augment /ent:entity/ent:physical-entity:
> +--rw class? identityref
> +--rw contained-in* -> ../../ent:physical-entity/name
> +--rw parent-rel-pos? int32

These were discussed in the ML thread starting with 
https://www.ietf.org/mail-archive/web/netmod/current/msg16458.html.
However, it was never clear (at least not to me) how this would
actually work.

> +--rw mfg-name? string
> +--rw model-name? string

I can see that these would be useful.  I assume these are intended to
be used like the configurable serial-num?

> 4 Introduced a new type of identity and container for a pluggable
> transceiver

Should this identity be registered with IANA?  If it is not a standard
class registered with IANA the augmentations should probably not be
done here.

> module: bbf-entity-pluggable-transceiver
> augment /ent:entity-state/ent:physical-entity:
> +--ro pluggable-transceiver-data
> augment /ent:entity/ent:physical-entity:
> +--rw pluggable-transceiver
> 
> 5    Introduced a new reference between the interface and the port
> module: bbf-interface-port-reference
> augment /if:interfaces/if:interface:
> +--rw port-layer-if entity-ref

I can see how a config false reference from interface to physical
entity makes sense.  If this is config true, I assume it works like
/interfaces/interface/type?


/martin