Network Working Group T. Graf Internet-Draft Swisscom Intended status: Standards Track J. Quilbeuf Expires: 30 October 2024 Huawei A. Huang Feng INSA-Lyon 28 April 2024 Support of Hostname and Sequencing in YANG Notifications draft-tgraf-netconf-notif-sequencing-04 Abstract This document specifies a new YANG module that augment the NETCONF Event Notification header to support hostname and sequence numbers to identify from which network node and at which time the message was published. This allows the collector to recognize loss, delay and reordering between the publisher and the downstream system storing the message. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 October 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Graf, et al. Expires 30 October 2024 [Page 1] Internet-Draft YANG Notifications Sequencing April 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Extend the NETCONF Event Notification Header . . . . . . . . 3 3. YANG Module for Event Notifications . . . . . . . . . . . . . 4 3.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 4 3.2. Full Tree View . . . . . . . . . . . . . . . . . . . . . 4 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 5 4. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 4.1. 6WIND VSR . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6.1. IETF XML Registry . . . . . . . . . . . . . . . . . . . . 7 6.2. YANG Module Name . . . . . . . . . . . . . . . . . . . . 7 7. Operational Considerations . . . . . . . . . . . . . . . . . 7 7.1. SysName Correlation . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Section 4 of [RFC5277] describes the NETCONF event notification header using a XML Schema. In the metadata of the event notification header, only the eventTime is present indicating at which time the notification message was published. For other encodings, the same schema is implemented using a YANG module in [I-D.ahuang-netconf-notif-yang]. Furthermore, in Section 3.7 of [RFC8641], the subscription ID is added to the "push-update" and "push-change-update" notification messages allowing to recognize to which xpath or sub-tree the node was subscribed to. When the NETCONF event notification message is forwarded from the receiver to another system, such as a messaging system or a time series database where the message is stored, the transport context is lost since it is not part of the NETCONF event notification message metadata. Therefore, the downstream system is unable to associate the message to the publishing process (the exporting router), nor able to detect message loss or reordering. Graf, et al. Expires 30 October 2024 [Page 2] Internet-Draft YANG Notifications Sequencing April 2024 Today, network operators workaround this impediment by preserving the transport source IP address and sequence numbers of the publishing process. However, this implies that this information needs to be encoded in the NETCONF event notification message which impacts the semantic readability of the message in the downstream system. On top of that, the transport source IP address might not represent the management IP address by which the YANG push server should be known. In other terms, the source-host [RFC6470], which is the "Address of the remote host for the session" might not be the management IP address. By extending the NETCONF Event Notification header with sysName, the node's fully-qualified domain name, a reference to the YANG push publisher process and a sequence number as described in [RFC9187], the downstream system is not only able to identify from which network node, subscription, and time the message was published but also, the order of the published messages. To correlate network data among different Network Telemetry planes as described in Section 3.1 of [RFC9232] or among different YANG push subscription types defined in Section 3.1 of [RFC8641], sysName describes from which network node the state change was observed or from when to when the data was accounted. This is essential for understanding the timely relationship among these different planes and YANG push subscription types. 2. Extend the NETCONF Event Notification Header Besides the eventTime described in Section 2.2.1 of [RFC5277] the following metadata objects are part of a "push-update" and "push- change-update" notification message. sysName: Describes the node's fully-qualified domain name according to the 'sysName' object definition in [RFC1213] from where the message was published from. This value is usually configured on the node by the administrator to uniquely identify the node in the network. sequenceNumber: Generates a unique sequence number as described in [RFC9187] for each published message. Figure 1 provides an example of a "push-change-update" message with the sysName and sequenceNumber. This "push-change-update" message is encoded in XML [W3C.REC-xml-20081126] over the Network Configuration Protocol (NETCONF) as per [RFC8640]. Graf, et al. Expires 30 October 2024 [Page 3] Internet-Draft YANG Notifications Sequencing April 2024 2023-02-04T16:30:11.22Z example-router 187653 1011 eth0 up Figure 1: XML Push Example for a subscription-modified notification message 3. YANG Module for Event Notifications 3.1. YANG Tree Diagram This ietf-notification-sequencing YANG module augments the ietf- notification YANG module specified in [I-D.ahuang-netconf-notif-yang] adding the sysName and the sequenceNumber leaves as described in Section 2 of this document. module: ietf-notification-sequencing augment-structure /inotif:notification: +-- sysName inet:host +-- sequenceNumber yang:counter32 3.2. Full Tree View The following is the YANG tree diagram [RFC8340] for the ietf- notification-sequencing augmentation within the ietf-notification. Graf, et al. Expires 30 October 2024 [Page 4] Internet-Draft YANG Notifications Sequencing April 2024 module: ietf-notification structure notification: +-- eventTime yang:date-and-time +-- inotifseq:sysName inet:host +-- inotifseq:sequenceNumber yang:counter32 3.3. YANG Module file "ietf-notification-sequencing@2023-03-25.yang" module ietf-notification-sequencing { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-notification-sequencing"; prefix inotifseq; import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-notification { prefix inotif; reference "draft-ahuang-netconf-notif-yang: NETCONF Event Notification YANG"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791: YANG Data Structure Extensions"; } organization "IETF NETCONF (Network Configuration) Working Group"; contact "WG Web: WG List: Authors: Thomas Graf Jean Quilbeuf Alex Huang Feng "; Graf, et al. Expires 30 October 2024 [Page 5] Internet-Draft YANG Notifications Sequencing April 2024 description "Defines NETCONF Event Notification structure with the sysName and the sequenceNumber. Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2023-04-28 { description "First revision"; reference "RFC XXXX: YANG Notifications Sequencing"; } sx:augment-structure "/inotif:notification" { leaf sysName { type inet:host; mandatory true; description "Fully-qualified domain name of the node according to [RFC1213]. This value is usually configured on the node by the administrator to uniquely identify the node in the network."; } leaf sequenceNumber { type yang:counter32; mandatory true; description "Unique sequence number as described in [RFC3339] for each published message."; } } } 4. Implementation Status Note to the RFC-Editor: Please remove this section before publishing. Graf, et al. Expires 30 October 2024 [Page 6] Internet-Draft YANG Notifications Sequencing April 2024 4.1. 6WIND VSR 6WIND implemented this document for a YANG Push publisher on UDP-based Transport for Configured Subscriptions [I-D.ietf-netconf-udp-notif] in their VSR platform. 5. Security Considerations The security considerations for the NETCONF Event notifications are described in [RFC5277]. This documents adds no additional security considerations. 6. IANA Considerations 6.1. IETF XML Registry This document registers the following URIs in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-notification-sequencing Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. 6.2. YANG Module Name This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]: name: ietf-notification-sequencing namespace: urn:ietf:params:xml:ns:yang:ietf-notification-sequencing prefix: inotifseq reference: RFC XXXX 7. Operational Considerations 7.1. SysName Correlation In order to allow data correlation among BGP Monitoring Protocol (BMP) [RFC7854] and YANG push, the same hostname value should be used as described in section 4.4 of [RFC7854] for the information TLV in the init BMP message type. 8. Acknowledgements The authors would like to thank Rob Wilton, Nick Corran, Pierre Francois, Benoit Claise, Ahmed Elhassany and Ignacio Dominguez Martinez-Casanueva for their review and valuable comments. Graf, et al. Expires 30 October 2024 [Page 7] Internet-Draft YANG Notifications Sequencing April 2024 9. References 9.1. Normative References [I-D.ahuang-netconf-notif-yang] Feng, A. H., Francois, P., Graf, T., and B. Claise, "YANG model for NETCONF Event Notifications", Work in Progress, Internet-Draft, draft-ahuang-netconf-notif-yang-04, 21 January 2024, . [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC9187] Touch, J., "Sequence Number Extension for Windowed Protocols", RFC 9187, DOI 10.17487/RFC9187, January 2022, . [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . 9.2. Informative References Graf, et al. Expires 30 October 2024 [Page 8] Internet-Draft YANG Notifications Sequencing April 2024 [I-D.ietf-netconf-udp-notif] Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H., and P. Lucente, "UDP-based Transport for Configured Subscriptions", Work in Progress, Internet-Draft, draft- ietf-netconf-udp-notif-12, 21 January 2024, . [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) Base Notifications", RFC 6470, DOI 10.17487/RFC6470, February 2012, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Dynamic Subscription to YANG Events and Datastores over NETCONF", RFC 8640, DOI 10.17487/RFC8640, September 2019, . [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, . [RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, . Authors' Addresses Thomas Graf Swisscom Binzring 17 CH-8045 Zurich Switzerland Email: thomas.graf@swisscom.com Jean Quilbeuf Huawei Email: jean.quilbeuf@huawei.com Graf, et al. Expires 30 October 2024 [Page 9] Internet-Draft YANG Notifications Sequencing April 2024 Alex Huang Feng INSA-Lyon Lyon France Email: alex.huang-feng@insa-lyon.fr Graf, et al. Expires 30 October 2024 [Page 10]