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

From: William Lupton <[email-masked]>
Date: Mon, 1 Aug 2016 10:13:38 +0100

Maybe configuration of the entity tree for pluggable items should be handled via augmentations that are specific to pluggable items?

There seems to be an analogy with interfaces here. The ietf-interfaces module provides only a read-only view of the interface stack, and interface type-specific modules are expected to provide a means of configuring the stack for interfaces of that type (where necessary).

William

> On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE) <[email-masked]> 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.
> -          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.
> >>
>  
> _______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 1 Aug 2016 09:30:37 +0000

William,

Not sure how this can be done in all cases.  Assume we have a box that allows ‘n’ boards to be plugged in slots 1..n.  During pre-provisioning we configure 2 boards of the same type, one in slot 1 and another in slot 2.  We also pre-provision the ports and allocate subscriber interfaces and assign data specific to these subscribers (so in a way this will be related to e.g. how the ports are wired via an MDF).  The device is not really able to determine by itself which board is contained in slot 1 (supporting the subscribers that are wired via MDF to terminate on this board) and the other to the board in slot 2.  The only way the device would be able to do so autonomously would be when e.g. a serial number related to the boards is provided by the operator when pre-provisioning the board.  The serial number is retrievable from the inventory information present in the board and hence the device could relate a board to a specific slot.  However… when the board gets broken it is temporarily (or even permanently in case the board is really broken) replaced by another board of the same type but with a different serial number.  This would then mean that the operator also needs to modify that serial number since the serial number in the inventory no longer matches the one entered by the operator when configuring the board (it is not really expected/allowed that the NC server would modify the RW data for that board).

Not really sure this is an elegant way of exposing this serial number management to a network operator.  So don’t we need a mechanism via configuration (i.e. R/W leafs) to configure this “containment” ?

Bart Bogaert

NOKIA

<<

From: William Lupton [mailto:[email-masked]] 
Sent: 01 August 2016 11:14
To: Bogaert, Bart (Nokia - BE)
Cc: [email-masked]
Subject: Re: [netmod] BBF extensions to ietf-entity

William

Bart Bogaert

NOKIA

<<

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Aug 2016 11:42:12 +0200

> There seems to be an analogy with interfaces here. The ietf-interfaces module provides only a read-only view of the interface stack, and interface type-specific modules are expected to provide a me…

This is not correct. The ietf-interfaces modules allows you to
configure/create interfaces, including interfaces that are not
currently present.

/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/>

---

From: William Lupton <[email-masked]>
Date: Mon, 1 Aug 2016 10:48:01 +0100

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.

> On 1 Aug 2016, at 10:42, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Aug 2016 11:52:31 +0200

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Aug 2016 10:49:54 +0200 (CEST)

Hi,

"Bogaert, Bart (Nokia - BE)" <[email-masked]> 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?
> 
>  
> 
> 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: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 29 Aug 2016 06:55:23 +0000

HI Martin,

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> 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).
> 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?

[Bart Bogaert] Assume you have a system with a number of slots that can hold
several different cards and the system was deployed in the field with some
cards inserted and some other slots that were still left empty.  When an
operator wants to extend the system we can have 2 ways of doing this:
1. a field engineer goes 'on-site' and plugs cards in the system.  If done
this way, the system itself can detect what has been inserted and we do not
really need the RW leafs.  However in this case an operator has to wait
configuring user services on these cards until they are inserted.
2. the network operator determines that a node will "run out" of available
ports and hence wants to start planning new configuration and hence he wants
to configure some boards in the empty slots and even may want to start to
pre-configure certain data of the ports contained by these boards.  In that
case we need the RW leaf to indicate which board type will be inserted as
the service that can be offered depends on the board being inserted.  When
the board is inserted, the planned configuration can directly be applied to
the newly inserted board (given the fact that the detected class is the same
as the planned class).

There are customers using method 1 and other customers use method 2.

> 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?

[Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple
through" to the MDF.  So assume we again have a system with plugable slots.
If we have 2 slots containing the same type of board (same class) and the
operator is applying the pre-configuration mode of working (method 2 in
above), we have to be sure that user A, connected to the first port of the
board plugged in the first slot will really be in slot 1.  If the NC client
has no means to detect which board is plugged in which slot (they are both
of the same class) we need other means to ensure the containment is as
intended (and user A being connected to the first port of the board in slot
A is also visualized as such on the GUI of the NC client).  Using the serial
number of the board seems not very practical as board may break and are sent
to repair or replaced by another board of the same type but with a different
serial number.  I do not think operators will like it a lot to manage a
system in a manual way based on these attributes hence also a need to plan a
board in a specific slot.

Hope this clarifies a bit more.

Best regards,

> 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.
> >> 
> 
>  
>