Internet-Draft YANG Notifications Sequencing June 2024
Graf, et al. Expires 1 January 2025 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-tgraf-netconf-notif-sequencing-06
Published:
Intended Status:
Standards Track
Expires:
Authors:
T. Graf
Swisscom
J. Quilbeuf
Huawei
A. Huang Feng
INSA-Lyon

Support of Hostname and Sequencing in YANG Notifications

Abstract

This document specifies a new YANG module that augments the NETCONF Event Notification header to support the hostname and sequence number 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 messages.

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 1 January 2025.

▲

Table of Contents

1. Introduction

NETCONF Event Notifications [RFC5277] and YANG-Push [RFC8641] allow NETCONF [RFC6241] servers and YANG-Push publishers to send notifications to a data collection. In the metadata of the event notification header, only the eventTime is present indicating at which time the notification message was published. For YANG-Push notifications, the subscription ID is added to the "push-update" and "push-change-update" notification messages allowing the YANG-Push receiver to map and recognize which Xpath or subtree is bound to the subscription.

When the NETCONF event notification message is forwarded from the receiver to another system, such as a messaging system or a time series database, 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.

To correlate network data among different Network Telemetry planes as described in Section 3.1 of [RFC9232] or among different YANG-Push subscription types as defined in Section 3.1 of [RFC8641], a reference to the node streaming the data is needed. This is essential for understanding the timely relationship among these different planes and YANG-Push subscription types.

Today, network operators work around this impediment by preserving the transport source IP address and sequence numbers of the publishing process. However, this implies encoding this information 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 publisher 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.

To overcome these issues, this document proposes extending the YANG notification header with a sysName, the node's fully-qualified domain name, and a sequence number as described in [RFC9187]. This allows the downstream system to not only be able to identify from which network node, subscription, and time the message was published but also, the order of the published messages.

2. Extend the YANG Notification Header

NETCONF Event Notifications [RFC5277] and YANG-Push [RFC8641] uses the same notification header that is described in Section 2.2.1 of [RFC5277]. [I-D.ahuang-netconf-notif-yang] defines how these notifications should be encoded in JSON and CBOR.

Besides the eventTime described in Section 2.2.1 of [RFC5277] the following metadata objects are part of a 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 for each published message by the publisher process. The number counts up at every published notification message as described in [RFC9187].

2.1. Extension for NETCONF Event Notifications

The Notification of NETCONF Event Notifications [RFC5277] uses a XML structure that is defined in Section 2.2.1 of [RFC5277]. [RFC5277] also defines the capability "urn:ietf:params:netconf:capability:notification:1.0" allowing a NETCONF client to know that the NETCONF server supports sending notifications.

2.1.1. Notification header

An implementation supporting this document extends the notification defined in Section 2.2.1 of [RFC5277] adding a sysName and a sequenceNumber. Two more child nodes within the "notification" container are expected, representing the sysName and the sequenceNumber.

An example showing this extension in XML is provided in Figure 1:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2007-07-08T00:10:00Z</eventTime>
  <sysName xmlns="urn:ietf:params:xml:ns:yang:ietf-notification-sequencing">
    example-router
  </sysName>
  <sequenceNumber xmlns="urn:ietf:params:xml:ns:yang:ietf-notification-sequencing">
    187653
  </sequenceNumber>
  <event xmlns="http://example.com/event/1.0">
      <eventClass>state</eventClass>
      <reportingEntity>
          <card>Ethernet0</card>
      </reportingEntity>
      <operState>enabled</operState>
  </event>
</notification>
Figure 1: NETCONF Event Notification message

2.1.2. Capability exchange

This document also adds a new capability to NETCONF so that the NETCONF server can notify the support of the sysName and sequenceNumber to the NETCONF client.

When the NETCONF server supports this document, the following capability is advertised:

  urn:ietf:params:netconf:capability:notification-sysname-sequence:1.0

The capability identifier is requested to IANA in Section 6.

In the capability exchange between the NETCONF client and server, the server will announce this capability along with the supported capabilities by the server as shown in the example in Figure 2.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>
        urn:ietf:params:xml:ns:netconf:base:1.0
      </capability>
      <capability>
        urn:ietf:params:netconf:capability:startup:1.0
      </capability>
      <capability>
        urn:ietf:params:netconf:capability:notification:1.0
      </capability>
      <capability>
        urn:ietf:params:netconf:capability:notification-sysname-sequence:1.0
      </capability>
    </capabilities>
  <session-id>4</session-id>
</hello>
Figure 2: Example of a capability exchange.

2.2. Extension for YANG-Push

YANG-Push [RFC8641] uses the same structure defined in [RFC5277]. [RFC5277] defines the structure using XML encoding. For other YANG encodings, [I-D.ahuang-netconf-notif-yang] describes how notifications should be encoded in JSON and CBOR.

2.2.1. YANG-Push Notification header

An implementation supporting this document extends the notification defined in Section 4 of [I-D.ahuang-netconf-notif-yang] adding a sysName and a sequenceNumber. Two more child nodes within the "notification" root container are expected, representing the sysName and the sequenceNumber.

Figure 3 provides an example of a "push-update" notification with the sysName and sequenceNumber. This examples is encoded in XML [W3C.REC-xml-20081126].

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2023-02-04T16:30:11.22Z</eventTime>
  <sysName xmlns="urn:ietf:params:xml:ns:yang:ietf-notification-sequencing">
    example-router
  </sysName>
  <sequenceNumber xmlns="urn:ietf:params:xml:ns:yang:ietf-notification-sequencing">
    187653
  </sequenceNumber>
  <push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
    <id>1011</id>
    <datastore-contents>
        <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
        <interface>
          <name>eth0</name>
          <oper-status>up</oper-status>
        </interface>
      </interfaces>
    </datastore-contents>
  </push-update>
</notification>
Figure 3: YANG-Push Notification example encoded in XML

When the notifcation is encoded using JSON [RFC7951], the sysName and the sequenceNumber are encoded at root container. An example is shown in Figure 4.

{
    "ietf-notification:notification": {
        "eventTime": "2023-02-10T08:00:11.22Z",
        "ietf-notification-sequencing:sysName":"example-router",
        "ietf-notification-sequencing:sequenceNumber": 187653,
        "ietf-yang-push:push-update": {
            "id": 1011,
            "datastore-contents": {
                "ietf-interfaces:interfaces": [
                    {
                        "interface": {
                            "name": "eth0",
                            "oper-status": "up"
                        }
                    }
                ]
            }
        }
    }
}
Figure 4: YANG-Push Notification example encoded in JSON

When the notification is encoded in CBOR [RFC9254], the sysName and the sequenceNumber are encoded at root container. An example is shown in Figure 5 using CBOR diagnostic notation from Section 3.1 of [RFC9254].

{
    "ietf-notification:notification": {
        "eventTime": "2023-02-10T08:00:11.22Z",
        "ietf-notification-sequencing:sysName":"example-router",
        "ietf-notification-sequencing:sequenceNumber": 187653,
        "ietf-yang-push:push-update": {
            "id": 1011,
            "datastore-contents": {
                "ietf-interfaces:interfaces": [
                    {
                        "interface": {
                            "name": "eth0",
                            "oper-status": "up"
                        }
                    }
                ]
            }
        }
    }
}
Figure 5: YANG-Push Notification example in CBOR diagnostic notation.

2.2.2. YANG-Push capabilities

YANG-related system capabilites can be discovered by subscribing to the datastore defined in [RFC9196]. This document augments the "ietf-notification-capabilities" defined in Section 5 of [RFC9196] so that the YANG-Push receiver can learn the capabilities defined in this documents throught the datastore.

The definition of this YANG augmentation is specified in Section 3.

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 Section 5 of [I-D.ahuang-netconf-notif-yang] adding the sysName and the sequenceNumber leaves and augments "ietf-notification-capabilities" defined in [RFC9196] to add a system level capability.

module: ietf-notification-sequencing

  augment /sysc:system-capabilities/notc:subscription-capabilities:
    +--ro sysname-sequence-supported?   notification-support {sysname-sequence}?

  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" structure:

module: ietf-notification

  structure notification:
    +-- eventTime                          yang:date-and-time
    +-- inotifseq:sysName                  inet:host
    +-- inotifseq:sequenceNumber           yang:counter32

The following YANG tree diagram [RFC8340] is the full tree of the "ietf-notification-capabilities" YANG model:

module: ietf-system-capabilities
  +--ro system-capabilities
     +--ro datastore-capabilities* [datastore]
     |  +--ro datastore
     |  |       -> /yanglib:yang-library/datastore/name
     |  +--ro per-node-capabilities* []
     |     +--ro (node-selection)?
     |     |  +--:(node-selector)
     |     |     +--ro node-selector?
     |     |             nacm:node-instance-identifier
     |     +--ro notc:subscription-capabilities
     |        +--ro notc:max-nodes-per-update?               uint32
     |        +--ro notc:periodic-notifications-supported?
     |        |       notification-support
     |        +--ro (notc:update-period)?
     |        |  +--:(notc:minimum-update-period)
     |        |  |  +--ro notc:minimum-update-period?        uint32
     |        |  +--:(notc:supported-update-period)
     |        |     +--ro notc:supported-update-period*      uint32
     |        +--ro notc:on-change-supported?
     |        |       notification-support {yp:on-change}?
     |        +--ro notc:minimum-dampening-period?           uint32
     |        |       {yp:on-change}?
     |        +--ro notc:supported-excluded-change-type*     union
     |                {yp:on-change}?
     +--ro notc:subscription-capabilities
        +--ro notc:max-nodes-per-update?               uint32
        +--ro notc:periodic-notifications-supported?
        |       notification-support
        +--ro (notc:update-period)?
        |  +--:(notc:minimum-update-period)
        |  |  +--ro notc:minimum-update-period?        uint32
        |  +--:(notc:supported-update-period)
        |     +--ro notc:supported-update-period*      uint32
        +--ro notc:on-change-supported?
        |       notification-support {yp:on-change}?
        +--ro notc:minimum-dampening-period?           uint32
        |       {yp:on-change}?
        +--ro notc:supported-excluded-change-type*     union
        |       {yp:on-change}?
        +--ro inotifseq:sysname-sequence-supported?
                notification-support {sysname-sequence}?

3.3. YANG Module

The "ietf-notification-sequencing" augments the "ietf-notification" and "ietf-notification-capabilities" YANG modules.

<CODE BEGINS> file "[email protected]"

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-system-capabilities {
    prefix sysc;
    reference
      "RFC 9196: YANG Modules Describing Capabilities for
       Systems and Datastore Update Notifications";
  }
  import ietf-notification-capabilities {
    prefix notc;
    reference
      "RFC 9196: YANG Modules Describing Capabilities for
       Systems and Datastore Update Notifications";
  }
  import ietf-yang-structure-ext {
    prefix sx;
    reference
      "RFC 8791: YANG Data Structure Extensions";
  }

  organization "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <http:/tools.ietf.org/wg/netconf/>
     WG List:  <mailto:[email protected]>

     Authors:  Thomas Graf
               <mailto:[email protected]>
               Jean Quilbeuf
               <mailto:[email protected]>
               Alex Huang Feng
               <mailto:[email protected]>";

  description
    "Defines NETCONF Event Notification structure with the sysName and
    the sequenceNumber.

    Copyright (c) 2024 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-05-29 {
    description
      "First revision";
    reference
      "RFC XXXX: YANG Notifications Sequencing";
  }

  feature sysname-sequence {
    description
      "This feature indicates that sysName and sequenceNumber are
      supported in notifications.";
  }

  typedef notification-support {
    type bits {
      bit config-changes {
        description
          "The publisher is capable of sending
          notifications for 'config true' nodes for the
          relevant scope and subscription type.";
      }
      bit state-changes {
        description
          "The publisher is capable of sending
          notifications for 'config false' nodes for the
          relevant scope and subscription type.";
      }
    }
    description
      "Redefition of the type 'notification-support' from
      'ietf-notification-capabilities' module to be reusable in
      other YANG modules.

      Type for defining whether 'on-change' or
      'periodic' notifications are supported for all data nodes,
      'config false' data nodes, 'config true' data nodes, or
      no data nodes.

      The bits config-changes or state-changes have no effect
      when they are set for a datastore or for a set of nodes
      that does not contain nodes with the indicated config
      value.  In those cases, the effect is the same as if no
      support was declared.  One example of this is indicating
      support for state-changes for a candidate datastore that
      has no effect.";
    reference
      "RFC XXXX: YANG Notifications Sequencing
      RFC 9196: YANG Modules Describing Capabilities for
      Systems and Datastore Update Notifications";
  }

  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.";
    }
  }

  augment "/sysc:system-capabilities/notc:subscription-capabilities" {
    description
      "Add system level capabilities";
    leaf sysname-sequence-supported {
      if-feature "sysname-sequence";
      type notification-support;
      description
        "Specifies whether the publisher supports exporting a
        sysName and a sequenceNumber in notifications.";
      reference
        "RFC XXXX: YANG Notifications Sequencing";
    }
  }
}

<CODE ENDS>

4. Implementation Status

Note to the RFC-Editor: Please remove this section before publishing.

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

6.3. NETCONF Capability URNs Registry

This document registers the following NETCONF capability in the "Network Configuration Protocol (NETCONF) Capability URNs" registry:

  Capability: :notification-sysname-sequence:1.0
  Capability Identifier: urn:ietf:params:netconf:capability:notification-sysname-sequence:1.0
  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.

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-05, , <https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-05>.
[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, , <https://www.rfc-editor.org/info/rfc1213>.
[RFC3688]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, , <https://www.rfc-editor.org/info/rfc3688>.
[RFC5277]
Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, DOI 10.17487/RFC5277, , <https://www.rfc-editor.org/info/rfc5277>.
[RFC6020]
Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, , <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC7951]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, , <https://www.rfc-editor.org/info/rfc7951>.
[RFC8340]
Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, , <https://www.rfc-editor.org/info/rfc8340>.
[RFC8641]
Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, , <https://www.rfc-editor.org/info/rfc8641>.
[RFC9187]
Touch, J., "Sequence Number Extension for Windowed Protocols", RFC 9187, DOI 10.17487/RFC9187, , <https://www.rfc-editor.org/info/rfc9187>.
[RFC9196]
Lengyel, B., Clemm, A., and B. Claise, "YANG Modules Describing Capabilities for Systems and Datastore Update Notifications", RFC 9196, DOI 10.17487/RFC9196, , <https://www.rfc-editor.org/info/rfc9196>.
[RFC9254]
Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)", RFC 9254, DOI 10.17487/RFC9254, , <https://www.rfc-editor.org/info/rfc9254>.
[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, , <https://www.w3.org/TR/2008/REC-xml-20081126>.

9.2. Informative References

[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-13, , <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-13>.
[RFC6470]
Bierman, A., "Network Configuration Protocol (NETCONF) Base Notifications", RFC 6470, DOI 10.17487/RFC6470, , <https://www.rfc-editor.org/info/rfc6470>.
[RFC7854]
Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, , <https://www.rfc-editor.org/info/rfc7854>.
[RFC9232]
Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, , <https://www.rfc-editor.org/info/rfc9232>.

Authors' Addresses

Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Jean Quilbeuf
Huawei
Alex Huang Feng
INSA-Lyon
Lyon
France