Subject: [MIB-DOCTORS] Modeling xDSL interface as linked to a port present in the entity stack

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Tue, 29 Mar 2016 14:50:09 +0000

Dear MIB Experts,

I would appreciate any suggestion for the way forward for the issue below.

Consider the following containment from a HW point of view:

/entity
    | contains
    + chassis
        |
        + board
            |
            + port

/interfaces
     | augmented for xdsl
     | other data leaves

We want to model the fact that this xDSL interface is linked to a port as present in the entity "stack".  AFAIK currently there is nothing available in the IETF modules to allow this and we're discussing what's the most logical way in doing so: from entity to interface of from interface to entity.

Normally in an interface stack the higher layer refers to the lower layer hence we would expect some referencing capability from the interfaces module.  But in that case there might be an issue for interfaces that are not immediately linked to some instance of the entity model.

What is typically done in this case?
Are there examples of models that have addressed this already?

Many Thanks in advance.

Cheers,
Mehmet

---

From: Michael MacFaden <[email-masked]>
Date: Tue, 29 Mar 2016 15:03:36 +0000

>Normally in an interface stack the higher layer refers to the lower layer hence we would expect some referencing capability from the interfaces module.
> But in that case there might be an issue for >interfaces that are not immediately linked to some instance of the entity model.
 >We want to model the fact that this xDSL interface is linked to a port as present in the entity "stack".  AFAIK currently there is nothing available in the IETF modules to allow this and we're >discussing what's the most logical way in doing so: from entity to interface of from interface to entity.

If I understand your question, you are looking for relation between an interface and  physical component?

https://tools.ietf.org/html/rfc2790 can provide one way to provide the relationto the "port", an entry might look like this:

HOST-RESOURCES-MIB::hrDeviceType.14 = OID: HOST-RESOURCES-TYPES::hrDeviceNetwork

HOST-RESOURCES-MIB::hrDeviceDescr.14 = STRING: NIC vmnic0, driver bnx2, version 2.2.3d.v55.2, 0000:003:00.0

HOST-RESOURCES-MIB::hrNetworkIfIndex.14 = INTEGER: 1

 And  https://tools.ietf.org/html/rfc6933 provides the details of the "chassis"

ENTITY-MIB::entPhysicalDescr.1 = STRING: HP ProLiant DL385 G6

ENTITY-MIB::entPhysicalClass.1 = INTEGER: backplane(4)

ENTITY-MIB::entPhysicalMfgDate.1 = STRING: 2010-2-9,0:0:0.0,

ENTITY-MIB::entPhysicalUris.1 = STRING: "urn:uuid:52a10f7b-48d7-af45-cc37-18a905540e64"

Regards,

Mike MacFaden

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2016 17:12:43 +0200

> Are there examples of models that have addressed this already?

The ENTITY-MIB can point to interfaces. See entAliasMappingIdentifier.
A program I wrote a while back to show the physical ports of an
interface simply grabs the mapping tables and then for each interface
looks up the corresponding entity objects. There is no back pointer
from the interfaces to the physical entities as far as I know.

/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: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Tue, 29 Mar 2016 15:25:34 +0000

Thanks Juergen! Your solution seems to work.

As you are online another quick point:

Why do we have actually a type (indentityref) in the ro *and* the rw part?  
I would expect the interface type to be (more or less) to be related to the underlying HW.  
So it would be plausible if it is either in ro or the rw part.  
But why in both?

Cheers, 
Mehmet 

-----Original Message-----
From: EXT Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 5:13 PM
To: Ersue, Mehmet (Nokia - DE/Munich) <[email-masked]>
Cc: [email-masked]
Subject: Re: [MIB-DOCTORS] Modeling xDSL interface as linked to a port present in the entity stack

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2016 18:05:40 +0200

I do not know what you mean with 'ro and the rw part'.

entAliasMappingIdentifier OBJECT-TYPE
    SYNTAX      RowPointer
    MAX-ACCESS  read-only
    STATUS      current

/js

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 29 Mar 2016 16:22:08 +0000

RO: read-only, RW: read/write.  

Best regards - Vriendelijke groeten,
Bart Bogaert
System Architect Data-Centric SW Architectures 
Fixed Networks - Broadband Access BU,  Nokia
Contact number +32 3 2408310 (+32 477 673952)

-----Original Message-----
From: EXT Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: 29 March 2016 18:06
To: Ersue, Mehmet (Nokia - DE/Munich)
Cc: [email-masked]; Bogaert, Bart (Nokia - BE)
Subject: Re: [MIB-DOCTORS] Modeling xDSL interface as linked to a port
present in the entity stack

/js

On Tue, Mar 29, 2016 at 03:25:34PM +0000, Ersue, Mehmet (Nokia - DE/Munich)

> From: EXT Juergen Schoenwaelder 
> [mailto:[email-masked]]
> > We want to model the fact that this xDSL interface is linked to a port
as present in the entity "stack".  AFAIK currently there is nothing
available in the IETF modules to allow this and we're discussing what's the
most logical way in doing so: from entity to interface of from interface to
entity.
> > 
> > Normally in an interface stack the higher layer refers to the lower
layer hence we would expect some referencing capability from the interfaces
module.  But in that case there might be an issue for interfaces that are
not immediately linked to some instance of the entity model.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2016 18:58:44 +0200

See, I quoted the definition of entAliasMappingIdentifier where it
says MAX-ACCESS read-only...

/js

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Wed, 30 Mar 2016 04:31:35 +0000

Jurgen,

I think there is little misunderstanding here.  I'm referring to the type
leaf of the interfaces YANG module: why is it existing in both the
read-onnly (operational data part) and the read-write (configuration data)?
Isn't the type derived from the HW and set by the device when creating the
interface?  Is there a need or the client to be able to change the interface
type? 

-----Original Message-----
From: EXT Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: 29 March 2016 18:59
To: Bogaert, Bart (Nokia - BE)
Cc: Ersue, Mehmet (Nokia - DE/Munich); [email-masked]
Subject: Re: [MIB-DOCTORS] Modeling xDSL interface as linked to a port
present in the entity stack

See, I quoted the definition of entAliasMappingIdentifier where it says
MAX-ACCESS read-only...

/js

On Tue, Mar 29, 2016 at 04:22:08PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> System Architect Data-Centric SW Architectures Fixed Networks - 
> Broadband Access BU,  Nokia Contact number +32 3 2408310 (+32 477 
> 673952)
> 
> > I would expect the interface type to be (more or less) to be related 
> > to
> the underlying HW.  
> > > I would appreciate any suggestion for the way forward for the 
> > > issue
> below.
> > > 
> available in the IETF modules to allow this and we're discussing 
> what's the most logical way in doing so: from entity to interface of 
> from interface to entity.
> > > 
> layer hence we would expect some referencing capability from the 
> interfaces module.  But in that case there might be an issue for 
> interfaces that are not immediately linked to some instance of the entity
model.
> > interface simply grabs the mapping tables and then for each 
> > interface looks up the corresponding entity objects. There is no 
> > back pointer from the interfaces to the physical entities as far as I
know.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Mar 2016 08:53:09 +0200

The MIB doctors list is probably not the best place to ask questions
about YANG modules. So please take this question to the NETMOD list.

/js

PS: As a hint for the answer, think about software interfaces.