Re: [netmod] BBF extensions to ietf-entity

Martin Bjorklund <mbj@tail-f.com> Fri, 26 August 2016 08:50 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 C893412D53B for <netmod@ietfa.amsl.com>; Fri, 26 Aug 2016 01:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 wLbDYnDMzPCI for <netmod@ietfa.amsl.com>; Fri, 26 Aug 2016 01:50:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A794612D52F for <netmod@ietf.org>; Fri, 26 Aug 2016 01:50:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 573D31AE018C; Fri, 26 Aug 2016 10:50:50 +0200 (CEST)
Date: Fri, 26 Aug 2016 10:49:54 +0200
Message-Id: <20160826.104954.1973625521466218062.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <D62E05768DBAFF42A72B9F4954476D65010EA9ACC8@FR712WXCHMBA09.zeu.alcatel-lucent.com>
References: <D62E05768DBAFF42A72B9F4954476D65010EA9ACC8@FR712WXCHMBA09.zeu.alcatel-lucent.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / 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/1zE2meIS6JBxcYtb3jutQHVyoFI>
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-entity
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: Fri, 26 Aug 2016 08:50:57 -0000

Hi,

"Bogaert, Bart (Nokia - BE)" <bart.bogaert@nokia.com> wrote:
> I would like to bring this to the ietf-entity group.  Currently BBF is
> proposing to add new RW leafs to the entity object.  This is done in the
> context of plugable entities and hence it means that when an operator (via a
> NC client) configures a plugable item it is required to define the entity
> type.  For this reason additional RW attributes are needed.  Two of the new
> leafs are class and contained-in (same as the RO class leaf). 
> 
> -          class: we think that the class leaf needs to be mandatory but
> adding this via an augment is not possible as we can't add a mandatory leaf
> via an augment.  Making class implicit for the client based on "some
> information" exchanged between device vendors and management applications is
> maybe not such a sound approach.

Can you explain in more detail how this would be used?  The idea is
that 'class' is a property of the physical hw, and that the underlying
system provides this info.  I can see that it could be useful for the
client to set this if the system can't do the classification (i.e.,
the system-set value is 'unknown').  But that's probably not the use
case you had in mind?

> -          contained-in: for plugable items contained-in requires to be
> mandatory too as a plugable item can't be "floating" in the device.

Can you explain in more detail what this means, and provide some use
cases?


/martin

> But we
> then hit a problem for the 'top-level' entity which not contained in
> anything (and 'fooling' the model by having it pointing to itself is not
> allowed).  Contained-in can't be derived by the NC server: what to do if 2
> entities of the same class are preprovisioned (together with ports and
> interfaces related to subscribers)?  We need to be sure that the subscribers
> are on the intended ports.
> 
>  
> 
> This would mean that the ietf-entity model would require a revision to add
> leafs for these plugable items.  What is the best way to address this?
> 
>  
> 
> Best regards - Vriendelijke groeten,
> 
> Bart Bogaert
> 
> Broadband-Access System Architect Data
> 
> Contact number +32 3 2408310 (+32 477 673952)
> 
>  
> 
> NOKIA
> 
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> 
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
> >> 
> 
>  
>