Subject: Re: [netmod] BBF extensions to ietf-entity

From: Athanasios Kyparlis <[email-masked]>
Date: Fri, 2 Sep 2016 14:49:08 +0000

>"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).  "
One possible solution is to have a list of top elements:

  augment "/ent:entity-state" {
    description "Adding the list of root nodes in HW hierarchy";
    leaf-list top-elems {
      type leafref {
        path "/ent:entity-state/ent:physical-entity/ent:name";
      }
      description "The list of root elements in the entity hierarchy";
    }
  }

  augment "/ent:entity" {
    description "Adding the list of root nodes in HW hierarchy";
    leaf-list top-elems {
      type leafref {
        path "/ent:entity/ent:physical-entity/ent:name";
      }
      description "The list of root elements in the entity hierarchy";
    }
  }

In addition, this allows one to traverse the HW hierarchy without a search.

Thanks,
Athanasios Kyparlis

From: netmod [mailto:[email-masked]] On Behalf Of Bogaert, Bart (Nokia - BE)
Sent: Friday, July 29, 2016 10:05 AM
To: [email-masked]
Subject: [netmod] BBF extensions to ietf-entity

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.

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

---

From: Athanasios Kyparlis <[email-masked]>
Date: Fri, 2 Sep 2016 15:19:21 +0000

Configuring hardware entities is the pre-provisioning use case. 
As Bart described, it's quite important for rollouts and field operations.

I support the addition of stacking capability in the config=true /entity branch.

Thanks,
Athanasios Kyparlis

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Monday, August 1, 2016 5:53 AM
To: William Lupton <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] BBF extensions to ietf-entity

On Mon, Aug 01, 2016 at 10:48:01AM +0100, William Lupton wrote:
> Sorry, I was talking only about the interface _stack_ configuration. Ref RFC 7223 Section 3.3:
> 
> While the interface layering is configured in interface-type-specific models, two generic state data leaf-lists, "higher-layer-if” and "lower-layer-if", represent a read-only view of the interface layering hierarchy.
> 
> I was just wondering whether configuration of entity relationships might be analogous.
> 

Once question is what does it means to configure hardware entities.

Or to ask the question differently, perhaps BBF really intents to configure interfaces instead of phsyical ports.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod