[NMOP] Re: [External] Re: [**EXTERNAL**] Re: Unique device identifiers [Commercial - Anyone]

[Brad Peters <[e-mail]>]

Hi Sivakumar,

Here are my thoughts on this issue and challenges faced by vendors/operators over a long period of time.

You may find some references to the issue in RFC3535 20 years later: An update of Operators requirements on Network Management Protocols and modelling on the data tracker. RFC3444 defines how you enable information and understanding from heterogenous data models by using a common information model. The IETF Knowledge Graph Design Team has been examining ways in which these types of problems could potentially be solved. Ideally there would be a conceptual standard ontology that would enable mapping different data models to an overall network ontology. This could be derived from IETF SIMAP as an example. From a Network Management system aspect this challenge has existed for too long and in my opinion the solutions to date are fragile.

NMOP and possibly the ONIONS working groups are places where APIs, data models and management is discussed.

However, like yourself, I'd be interested in those that may have alternate solutions in the network for this data model aspect and how you may turn data into information and ultimately knowledge. There is a lot of discussions on autonomous networks but this issue, because its at a lower level, I find is often overlooked.


Cheers.


Brad

________________________________
From: Sundaravadivel, Sivakumar <sivakuma=[e-mail]>
Sent: Sunday, 21 September 2025 3:22 PM
To: Kristian Larsson <[e-mail]>; Thomas.Graf <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [External] [NMOP] Re: [**EXTERNAL**] Re: Unique device identifiers


EXTERNAL SENDER – Be cautious opening Links and Attachments

Dear Thomas Graf, Kristian Larsson,



Thank you for the insights and detailed explanation.



From an NMS functionality perspective, while the solution can rely on the Yang native data available in the data mesh, there are also use cases where the solution needs to perform certain activities directly on the device. This could be an ICMP ping operation, which can sometimes be useful to determine if the device itself is down completely or if the management interface has gone down, resulting in no data on the mesh or a lost subscription or connection. This helps us arrive at better RCA, which in turn helps our end users. An NMS solution can be integrated with an orchestration system that needs access to the device for closed-loop automation. There can be multiple use cases.

As we all know, OSS layer solutions tend to use different protocols for different use cases. An orchestrator probably depends on the TL1 protocol(where TID is the unique device identifier and not sysname) to perform certain control plane activities. Or a solution that depends on the IS-IS protocol to identify a path where FQDN is probably exchanged, while sysname just contains the device name and not FQDN. In general, we see that these solutions are being integrated with each other to solve bigger problems than working in silos. Leading to the problem how do we relate data across these platforms depending on multiple protocols.

Will adding an IP address to the envelope solve the problem? Probably not, as we have seen DHCP-enabled networks where the device IP address changes at any point. So this calls for ways to identify the devices uniquely. It can be by adding other supportive parameters to the envelope, like IP address, MAC address, domain, and more(to understand changes in real time, or having a periodic message push from the device that provides all these details more like a heartbeat or on change), which enables NMS system to decide the right parameter or combination of parameters to uniquely identify a device. Or having a unique identifier per device without dwelling much into the implementation complexities from OSS perspective.

Please let me know your thoughts. Apologies if the mail feels out of context.



Regards,

Sivakumar Sundaravadivel



From: Kristian Larsson <[e-mail]>
Date: Saturday, 20 September 2025 at 5:35 PM
To: Thomas.Graf <[e-mail]>
Cc: Sundaravadivel, Sivakumar <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [**EXTERNAL**] Re: [NMOP] Unique device identifiers

If hostname is underspecified, then that is solved by tightening the spec not be entirely shifting to an artificial ID like UUID. hostname is a natural and assignable ID (we, as the network operators decide what it should be and assign it, not the equipment / device vendor / something else / generated). Overall in the network space, the vast majority of keys and identifiers are user assigned, which gives a certain way of working. I know that when I set hostname=foo on a device and later receive telemetry for device=foo, then I can connect the dots. I think this is a very good property. It enables stateless declarative automation systems that can compute the entire configuration based on abstract intent. Contrast it with many cloud APIs where you create something and you receive the UUID as a return value. Now you must keep track of this ID, if not, you loose track of the instance.



UUID is no panacea. If you replace or reset equipment, it tends to be reset and then you have to deal with the problem of connecting data with UUID=1 to UUID=2 because the same logical node in the network had multiple UUID throughout its lifetime.



Kind regards,

   Kristian.







On 20 Sep 2025, at 11:49, [e-mail] wrote:



Dear Siva,



Welcome to the NMOP mailing list. Its great that YANG Message Broker Consumer (https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-08#section-4.6 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-08*section-4.6__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWgSPOTqE$>) implementors are joining the NMOP mailing list.



Indeed you are raising a very valid point on network node and network node component identification.



The IVY (Network Inventory YANG) working group has a key document https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08#section-3.1 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08*section-3.1__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWeqnG_Yo$> which defines unique identifiers for network nodes and network node components generically.



With https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02#section-3.4.1 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02*section-3.4.1__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWf-EILaM$> at the NETCONF (Network Configuration) working group we have an Extensible YANG Model for YANG-Push Notifications which includes the hostname. As you are well aware, the hostname in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02#section-5.1.2 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02*section-5.1.2__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWNZ3ECW8$>



    leaf hostname {

      type inet:host;

      description

        "The hostname of the network node according to

         [RFC1213]. This value is usually configured on the node

         by the administrator to identify the node in

         the network uniquely.";

    }



Using the typdef host from ietf-inet-types.yang defined in RFC 6991 (see below). This in turn has typdefs ip-address and domain-name. Where ip-address has typedefs in ipv4-address and ipv6-address. Considering all these combinations and the ambiguous semantics of domain-name, fully qualified vs not, shows the Internet old problem that the hostname is not a real unique identifier for a network node.



With https://datatracker.ietf.org/doc/html/draft-ietf-nmop-rfc3535-20years-later-00#section-4.10 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-nmop-rfc3535-20years-later-00*section-4.10__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW79A54pA$> at NMOP we are raising the point that the Network Telemetry RFC 9232 protocols developed at IETF don't have a common level of entities. I believe what you are saying is that one of the items should be the UUID (https://datatracker.ietf.org/doc/html/rfc9562 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9562__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWkRCWNtg$>) of the network node as defined in https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08#section-3.1 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-08*section-3.1__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWeqnG_Yo$> and for YANG-Push, as one of the Network Telemetry applications, a YANG-Push header extensionhttps://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02#appendix-B [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02*appendix-B__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW__6wC_g$> should be proposed. Correct?



I cross posted to the IVY and NETCONF mailing lists to see wherever this makes sense and wherever others have interest.



To the draft-ietf-ivy-network-inventory-yang authors. I see that implementation status section being empty. Are there already any implementations?



I published today a new document where the hostname among others is used to generate a unique YANG indexhttps://datatracker.ietf.org/doc/html/draft-netana-nmop-yang-message-broker-message-key-00#section-3.1 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-netana-nmop-yang-message-broker-message-key-00*section-3.1__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWRNiQPKY$>. Here the uniqueness of the hostname in the YANG-Push notifications are coming into play as well.



Therefore, your are raising a very valid, Internet old problem. As you see, the IETF community is moving at several fronts forward to resolve that problem. Looking forward for comments and feedback.



With best wishes

Thomas



As a side note: Another related approach are COSE Signatures https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWh1j6L_0$> which proposing extensions to the data manifest and the "ietf-yp-notification" https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance-01#section-4.2.2 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance-01*section-4.2.2__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWZx07tvs$>.





     typedef host {

       type union {

         type inet:ip-address;

         type inet:domain-name;

       }

       description

        "The host type represents either an IP address or a DNS

         domain name.";

     }



     typedef ip-address {

       type union {

         type inet:ipv4-address;

         type inet:ipv6-address;

       }

       description

        "The ip-address type represents an IP address and is IP

         version neutral.  The format of the textual representation

         implies the IP version.  This type supports scoped addresses

         by allowing zone identifiers in the address format.";

       reference

        "RFC 4007 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4007__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWLlvVmUw$>: IPv6 Scoped Address Architecture";

     }



     typedef ipv4-address {

       type string {

         pattern

           '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'

         +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'

         + '(%[\p{N}\p{L}]+)?';

       }

       description

         "The ipv4-address type represents an IPv4 address in

          dotted-quad notation.  The IPv4 address may include a zone

          index, separated by a % sign.



          The zone index is used to disambiguate identical address

          values.  For link-local addresses, the zone index will

          typically be the interface index number or the name of an

          interface.  If the zone index is not present, the default

          zone of the device will be used.



          The canonical format for the zone index is the numerical

          format";

     }



     typedef ipv6-address {

       type string {

         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'

               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'

               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'

               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'

               + '(%[\p{N}\p{L}]+)?';

         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'

               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'

               + '(%.+)?';

       }

       description

        "The ipv6-address type represents an IPv6 address in full,

         mixed, shortened, and shortened-mixed notation.  The IPv6

         address may include a zone index, separated by a % sign.



         The zone index is used to disambiguate identical address

         values.  For link-local addresses, the zone index will

         typically be the interface index number or the name of an

         interface.  If the zone index is not present, the default

         zone of the device will be used.

         The canonical format of IPv6 addresses uses the textual

         representation defined in Section 4 of RFC 5952 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5952*section-4__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWAP6llbU$>.  The

         canonical format for the zone index is the numerical

         format as described in Section 11.2 of RFC 4007 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4007*section-11.2__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWx_qLjUY$>.";

       reference

        "RFC 4291 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4291__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW1sOrxBI$>: IP Version 6 Addressing Architecture

         RFC 4007 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc4007__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWLlvVmUw$>: IPv6 Scoped Address Architecture

         RFC 5952 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5952__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWndeWtXk$>: A Recommendation for IPv6 Address Text

                   Representation";

     }



     typedef domain-name {

       type string {

         pattern

           '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'

         + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'

         + '|\.';

         length "1..253";

       }

       description

        "The domain-name type represents a DNS domain name.  The

         name SHOULD be fully qualified whenever possible.



         Internet domain names are only loosely specified.  Section [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc1034*section-3.5__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW-4D8U-s$>

         3.5 of RFC 1034 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc1034*section-3.5__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW-4D8U-s$> recommends a syntax (modified in Section [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc1123*section-2.1__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW-i0s_jA$>

         2.1 of RFC 1123 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc1123*section-2.1__;Iw!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW-i0s_jA$>)  The pattern above is intended to allow

         for current practice in domain name use, and some possible

         future expansion.  It is designed to hold various types of

         domain names, including names used for A or AAAA records

         (host names) and other records, such as SRV records.  Note

         that Internet host names have a stricter syntax (described

         in RFC 952 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc952__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWSvpn9Y0$>) than the DNS recommendations in RFCs 1034 and

         1123, and that systems that want to store host names in

         schema nodes using the domain-name type are recommended to

         adhere to this stricter standard to ensure interoperability.

         The encoding of DNS names in the DNS protocol is limited

         to 255 characters.  Since the encoding consists of labels

         prefixed by a length bytes and there is a trailing NULL

         byte, only 253 characters can appear in the textual dotted

         notation.



         The description clause of schema nodes using the domain-name

         type MUST describe when and how these names are resolved to

         IP addresses.  Note that the resolution of a domain-name value

         may require to query multiple DNS records (e.g., A for IPv4

         and AAAA for IPv6).  The order of the resolution process and

         which DNS record takes precedence can either be defined

         explicitly or may depend on the configuration of the

         resolver.



         Domain-name values use the US-ASCII encoding.  Their canonical

         format uses lowercase US-ASCII characters.  Internationalized

         domain names MUST be A-labels as per RFC 5890 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5890__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWGJCZz94$>.";

       reference

        "RFC  952: DoD Internet Host Table Specification

         RFC 1034 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc1034__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWsG9aF1M$>: Domain Names - Concepts and Facilities

         RFC 1123 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc1123__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWjEr1Ty8$>: Requirements for Internet Hosts -- Application

                   and Support

         RFC 2782 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc2782__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrW-rtuOBw$>: A DNS RR for specifying the location of services

                   (DNS SRV)

         RFC 5890 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5890__;!!OSsGDw!LMDpJfQ4wPYx1XCkJgeWKuVCCkP-KTqKdItEoShDwGaS6TYmrbnvZBbmCCrNQzD2cpE19wOEfBW1APrWGJCZz94$>: Internationalized Domain Names in Applications

                   (IDNA): Definitions and Document Framework";

     }





From: Sundaravadivel, Sivakumar <sivakuma=[e-mail]<mailto:sivakuma=[e-mail]>>
Sent: Monday, September 15, 2025 5:22 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [NMOP] Unique device identifiers



Be aware: This is an external email.



Dear Team,



My name is Sivakumar, and I am an Architect of BPUAA, an NMS solution.

While reviewing recent documents on “Netconf notif envelope,” I came across the following information that Devices are uniquely identified based on Sysname.

I wanted to bring the following to your notice. Based on my experience, I would like to highlight a specific scenario, one of our customer equipment’s Sysname retrieved over snmp by our system did not match with the name retrieved by Netconf used by another system, with which we had to integrate for certain information. Basically, one of the two had an FQDN while the other had just the name. And also, my understanding is that sysnames can be modified from the device.

In order to ensure that data continuity is not lost when the sysname changes, or for effective integration across different solutions, it appears the envelope should have more than Sysname information to handle various lookups. Please let me know if this is a valid concern.



Regards,

Sivakumar Sundaravadivel

--
Nmop mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]