Guiseppe,

 Did you review the "YANG Alarm Module” 
(https://tools.ietf.org/html/draft-vallin-alarm-yang-module-00)? Perhaps there 
are some concepts in there that you might find applicable and useful.

> On Oct 20, 2015, at 12:35 PM, De Noia Giuseppe 
> <[email protected]> wrote:
> 
> Hi,
> thank you Juergen for your reply.
> For an interface alarm the standardized YANG module already provide what is 
> needed.
> Nevertheless my question addressed a broader scope. SNMP alarms or other type 
> of notifications could regard many parts of the network element, so in my 
> opinion, we need a more generic approach to the problem.
> 
> Regards,
> Giuseppe
> 
> -----Messaggio originale-----
> Da: Juergen Schoenwaelder [mailto:[email protected]] 
> Inviato: venerdì 16 ottobre 2015 16:19
> A: De Noia Giuseppe
> Cc: [email protected]
> Oggetto: Re: [netmod] About correlation between snmp alarms and yang 
> structures
> 
> Hi,
> 
> if you implement the ietf-interfaces YANG module including the if-mib 
> feature, then /interfaces-state/interface/if-index provides you the ifIndex 
> value that MIB modules usually use to identify an interface.
> 
> /js
> 
> On Fri, Oct 16, 2015 at 02:04:38PM +0000, De Noia Giuseppe wrote:
>> Hi guys,
>> I have a question about Yang language support for snmp alarm correlation.
>> It could be nice if a device supplier, specifying the Yang model of his 
>> network element, could also specify the correspondence between snmp alarms 
>> produced and affected part of the yang model of its device. This will allow 
>> for correlation between snmp traps (or other events) affecting a given 
>> object  and the service instance created (through Netconf/yang) on that 
>> object.
>> 
>> As for example, let's say a device send the following trap
>> 
>> xx: snmpTraps.3 notification received from: 163.162.185.239 at 18/06/2015 
>> 14:13:27
>>  Time stamp: 0 days 00h:00m:40s.15th
>>  Agent address: 163.162.185.239 Port: 54835 Transport: IP/UDP Protocol: 
>> SNMPv2c Notification
>>  Manager address: 163.162.107.184 Port: 162 Transport: IP/UDP
>>  Community: public
>>  Enterprise: enterprises.8072.3.2.10
>>  Bindings (8)
>>    Binding #1: sysUpTime.0 *** (timeticks) 0 days 00h:00m:40s.15th
>>    Binding #2: snmpTrapOID.0 *** (oid) snmpTraps.3
>>    Binding #3: ifIndex.6 *** (int32) 6
>>    Binding #4: ifDescr.6 *** (octets) dp0s3 [64.70.30.73.34 (hex)]
>>    Binding #5: ifType.6 *** (int32) ethernet-csmacd(6)
>>    Binding #6: ifAdminStatus.6 *** (int32) down(2)
>>    Binding #7: ifOperStatus.6 *** (int32) down(2)
>>    Binding #8: snmpTrapEnterprise.0 *** (oid) enterprises.8072.3.2.10
>> 
>> On the same device I created a service instance, which consists on an 
>> interface configuration . The interface, described through the YANG 
>> model is the following 
>> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.='dp0s3']
>> 
>> Actually the SNMP trap impacts on the same interface where I configured my 
>> service instance, but I have no means to understand it.
>> 
>> How can I enrich my YANG model to support the information that a trap with 
>> oid= snmpTraps.3 and ifDescr = dp0s3 affect the same interface described in 
>> Yang by the xpath expression 
>> /tns:data/tnsA:interfaces/tnsB:dataplane/tnsB:tagnode[.='dp0s3']?
>> 
>> Do I need to define a new YANG extension statement to carry on such a 
>> correspondence, or can I rely on existing structures?
>> 
>> Regards,
>> Giuseppe De Noia
>> 
>> 
>> 
>> 
>> ------------------------------------------------------------------
>> Telecom Italia
>> Giuseppe De Noia
>> T.TG.NM.OSI,
>> Via Reiss Romoli, 274  10148 Torino
>> 011 2288887
>> 331 6001197
>> 
>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle 
>> persone indicate. La diffusione, copia o qualsiasi altra azione derivante 
>> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora 
>> abbiate ricevuto questo documento per errore siete cortesemente pregati di 
>> darne immediata comunicazione al mittente e di provvedere alla sua 
>> distruzione, Grazie.
>> 
>> This e-mail and any attachments is confidential and may contain privileged 
>> information intended for the addressee(s) only. Dissemination, copying, 
>> printing or use by anybody else is unauthorised. If you are not the intended 
>> recipient, please delete this message and any attachments and advise the 
>> sender by return e-mail, Thanks.
>> 
>> [rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ? 
>> necessario.
>> 
> 
> 
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> -- 
> 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 protected]
> https://www.ietf.org/mailman/listinfo/netmod

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

Reply via email to