Subscription to
Distributed NotificationsHuawei156 Beiqing Rd., Haidian DistrictBeijingChinazhoutianran@huawei.comHuawei101 Yu-Hua-Tai Software RoadNanjingJiangsuChinazhengguangying@huawei.comCisco SystemsUnited States of Americaevoit@cisco.comSwisscomBinzring 17Zuerich 8045Switzerlandthomas.graf@swisscom.comINSA-LyonLyonFrancepierre.francois@insa-lyon.frNETCONFThis document describes extensions to the YANG notifications
subscription to allow metrics being published directly from
processors on line cards to target receivers, while subscription
is still maintained at the route processor in a distributed
forwarding system.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in BCP 14 when, and only when, they appear in all
capitals, as shown here.The mechanism to support a subscription of a continuous and
customized stream of updates from a YANG datastore is defined in and
. Requirements for Subscription to YANG
Datastores are defined in .By streaming YANG-Push notifications from publishers to
receivers, much better performance and fine-grained sampling can
be achieved than with a polling-based mechanism. In a distributed
forwarding system, the packet forwarding is delegated to multiple
processors on line cards. To not to overwhelm the route processor
resources, it is not uncommon that data records are published
directly from processors on line cards to target Receivers to
further increase efficiency on the routing system.This document complements the general subscription requirements
defined in section 4.2.1 of by the
paragraph: A Subscription Service MAY support the ability to
export from multiple software processes on a single routing system
and expose the information which software process produced which
message to maintain data integrity.The following terms are defined in and
are not redefined here:SubscriberPublisherReceiverSubscriptionIn addition, this document defines the following terms:Global Subscription: The Subscription requested by the
subscriber. It may be decomposed into multiple Component
Subscriptions.Component Subscription: The Subscription that defines a data
source which is managed and controlled by a single Publisher.Global Capability: The overall subscription capability that the
group of Publishers can expose to the Subscriber.Component Capability: The subscription capability that each
Publisher can expose to the Subscriber.Publisher Master: The Publisher that interacts with the
Subscriber to deal with the Global Subscription. It decomposes the
Global Subscription to multiple Component Subscriptions and
interacts with the Publisher Agents.Publisher Agent: The Publisher that interacts with the
Publisher Master to deal with the Component Subscription and
pushing the data to the Receiver.Node: The Publisher that obtains and pushes the data to the
Receiver.Message Publisher: The Publisher that pushes the message to the
Receiver.Message Publisher ID: A 32-bit identifier of the publishing
process that is locally unique to the publisher node. With this
identifier the publishing process from where the message was
published from can be uniquely identified. Receivers SHOULD use
the transport session and the Publisher ID field to separate
different publisher streams originating from the same network
node.Lost and corrupt YANG notification messages need to be
recognized at the receiver to ensure data integrity even when
multiple publisher processes publishing from the same transport
session.To preserve data integrity down to the publisher process, the
Message Publisher ID in the transport message header of the YANG
notification message is introduced. In case of UDP transport,
this is described in Section 3.2 of UDP-based transport.
below shows the distributed data export
framework.A collector usually includes two components,the Subscriber generates the subscription instructions to
express what and how the Receiver wants to receive the data;
the Receiver is the target for the data publication.For one subscription, there can be one or more Receivers. And
the Subscriber does not necessarily share the same IP address as
the Receivers.In this framework, the Publisher pushes data to the Receiver
according to the subscription. The Publisher is either in the
Master or Agent role. The Publisher Master knows all the
capabilities that his Agents can provide and exposes the Global
Capability to the collector. The Subscriber maintains the Global
Subscription at the Publisher Master and disassembles the Global
Subscription to multiple Component Subscriptions, depending which
source data is needed. The Component Subscriptions are then
distributed to the corresponding Publisher Agents on route and
processors on line cards.Publisher Agents collects metrics according to the Component
Subscription, add its metadata, encapsulates, and pushes data to
the Receiver where packets are reassembled and decapsulated.Publisher Master and Publisher Agents interact with each other
in several ways: Publisher Agents need to register at the Master at the
beginning of their process life cycle.Contracts are created and maintained throughout the
subscription lifecycle between the Publisher Master and each
Agent on the Component Capability, and the format for
notification data structure.The Publisher Master relays the component subscriptions to
the Publisher Agents.The Publisher Agents announce the status of their Component
Subscriptions to the Publisher Master. The status of the
overall subscription is maintained by the Publisher Master.
The Publisher Master is responsible for notifying the
subscriber in case of problems with the Component
Subscriptions.The technical mechanisms or protocols used for the
coordination of operational information between Publisher Master
and Agent is out of scope of this document.The Collector can only subscribe to the Master. This requires
the Publisher Master to:expose the Global Capability that can be served by multiple
Publisher Agents;disassemble the Global Subscription to multiple Component
Subscriptions, and distribute them to the Publisher Agents of
the corresponding metric sources so that they do not overlap;
notify changes related to the existing subscriptions to the
different Publisher Agents.And the Publisher Agent to:Inherit the Global Subscription properties from Publisher
Master for its Component Subscription;share the same life-cycle as the Global Subscription;share the same Subscription ID as the Global Subscription.
The Publisher Agent collects data and encapsulates the packets
per Component Subscription. The format and structure of the data
records are defined by the YANG schema, so that the decomposition
at the Receiver can benefit from the structured and hierarchical
data records.The Receiver can associate the YANG data records with
Subscription ID to the subscribed
subscription. Additionally, it can use the Message Publisher ID to
determine the corresponding publisher process, ensuring message
integrity.For the dynamic subscription, the output of the
"establish-subscription" RPC defined in
MUST include a list of Message Publisher IDs to indicate how the
Global Subscription is decomposed into several Component
Subscriptions.The "subscription-started" and "subscription-modified"
notification defined in and "push-update"
and "push-change-update" notification defined in MUST also include a list of Message Publisher
IDs to notify the current Publishers for the corresponding Global
Subscription.In addition to sending event records to Receivers, the Master
MUST also send subscription state change
notifications when events related to subscription
management have occurred. All the subscription state change
notifications MUST be delivered by the Master.When the subscription decomposition result changed, the
"subscription-modified" notification MUST be sent to indicate the
new list of Publisher Agents.This document assumes that all Publisher Agents are
preconfigured to push data. The actual working Publisher Agents
are selected based on the subscription decomposition result.All Publisher Agents share the same source IP address for data
export. For connectionless data transport such as UDP based transport the
same Layer 4 source port for data export can be used. For
connection based data transport such as HTTPS based transport,
each Publisher Agent MUST be able to acknowledge packet retrieval
from Receivers, and therefore requires a dedicated Layer 4 source
port per software process.The specific configuration on transports is described in the
responsible documents. file "ietf-distributed-notif@2024-04-14.yang"
module ietf-distributed-notif {
yang-version 1.1;
namespace
"urn:ietf:params:xml:ns:yang:ietf-distributed-notif";
prefix dn;
import ietf-subscribed-notifications {
prefix sn;
}
import ietf-yang-push {
prefix yp;
reference
"RFC 8641: Subscription to YANG Notifications for Datastore
Updates";
}
organization "IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web:
WG List:
Authors: Guangying Zheng
Tianran Zhou
Thomas Graf
Pierre Francois
Eric Voit
";
description
"Defines augmentation for ietf-subscribed-notifications to
enable the distributed publication with single subscription.
Copyright (c) 2025 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 Simplified 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 2024-04-21 {
description
"Initial version";
reference
"RFC XXXX: Subscription to Distributed Notifications";
}
grouping message-publisher-id {
description
"Provides a reusable leaf of te message-publisher-id.";
leaf message-publisher-id {
type uint32;
config false;
description
"Identifies the software process which publishes the
message (e.g., processor 1 on line card 1). This field
is used to notify the receiver which publisher process
published which message.";
}
}
grouping message-publisher-ids {
description
"Provides a reusable leaf-list of message-publisher-id-list.";
leaf-list message-publisher-ids {
type uint32;
config false;
description
"Identifies the software process which publishes the
message (e.g., processor 1 on line card 1). This field
is used to notify the receiver which publisher processes
are going to publish.";
}
}
augment "/sn:subscriptions/sn:subscription" {
description
"This augmentation allows the Message
Publisher ID to be exposed for a subscription.";
uses message-publisher-ids;
}
augment "/sn:subscription-started" {
description
"This augmentation adds the Message Publisher ID to the
subscription-started subscription change notifications.";
uses message-publisher-ids;
}
augment "/sn:subscription-modified" {
description
"This augmentation adds the Message Publisher ID to the
subscription-modified subscription change notifications.";
uses message-publisher-ids;
}
augment "/sn:establish-subscription/sn:output" {
description
"This augmentation adds the Message Publisher ID to the
dynamic establish-subscription output.";
uses message-publisher-ids;
}
augment "/yp:push-update" {
description
"This augmentation adds the Message Publisher ID in the
push-update notification.";
uses message-publisher-id;
}
augment "/yp:push-change-update" {
description
"This augmentation adds the Message Publisher ID in the
push-change-update notification.";
uses message-publisher-id;
}
}
]]>This document registers the following namespace URI in the
IETF XML Registry:URI: urn:ietf:params:xml:ns:yang:ietf-distributed-notifRegistrant Contact: The IESG.XML: N/A; the requested URI is an XML namespace.This document registers the following YANG module in the
YANG Module Names registry:Name: ietf-distributed-notifNamespace:
urn:ietf:params:xml:ns:yang:ietf-distributed-notifPrefix: dnReference: RFC XXXXNote to the RFC-Editor: Please remove this section before
publishing.INSA Lyon implemented this document for a YANG Push publisher
on UDP-based Transport
for Configured Subscriptions in an example
implementation.The open source code can be obtained here: .INSA Lyon implemented this document for a YANG Push receiver
on UDP-based Transport
for Configured Subscriptions as a library.The open source code can be obtained here: .The open source YANG push receiver library has been
integrated into the Pmacct open source Network Telemetry data
collection.The open source code can be obtained here: .Huawei implemented this document for a YANG Push publisher on
UDP-based Transport
for Configured Subscriptions in their VRP platform.6WIND implemented this document for a YANG Push publisher on
UDP-based Transport
for Configured Subscriptions in their VSR platform.The YANG module specified in this document defines a schema for
data that is designed to be accessed via network management
protocols such as NETCONF or RESTCONF. The lowest NETCONF layer is the
secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH). The
lowest layer is HTTPS, and the mandatory-to-implement secure
transport is TLS.The NETCONF Access Control Model (NACM)
provides the means to restrict access particulary for
NETCONF or RESTCONF users to a preconfigured subset of all
available NETCONF or RESTCONF protocol operations and content.The new data nodes introduced in this YANG module may be
considered sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g., via get-config
or notification) to this data nodes. These are the subtrees and
data nodes and their sensitivity/vulnerability:/subscriptions/subscription/message-publisher-idsThe entries in the two lists above will show where
subscribed resources might be located on the publishers. Access
control MUST be set so that only someone with proper access
permissions has the ability to access this resource.Other Security Considerations is the same as those discussed in
.We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund,
Tim Carey, Qin Wu, Robert Wilton, Benoit Claise, Alex Huang Feng
and Camilo Cardona for their constructive suggestions for
improving this document.INSA Lyon, YANG Push publisher example
implementationINSA Lyon, YANG Push receiver library
implementationPaolo Lucente, Pmacct open source Network Telemetry
Data CollectionThis appendix is non-normative. shows a typical dynamic
subscription to the network node with distributed data export
capability.+ component |
| | subscription |
| RPC Reply: OK, id #22 +-------------->+
| Message Publisher ID [#1,#2] | |
+<------------------------------+ |
| | |
| notif-mesg, id #22 | |
| Message Publisher ID #1 | |
+<------------------------------+ |
| | |
| notif-mesg, id#22 | |
| Message Publisher ID #2 | |
+<----------------------------------------------+
| | |
| modify-subscription (id#22) | |
+------------------------------>+ component |
| | subscription |
| RPC Reply: OK, id #22 +-------------->+
+<------------------------------+ |
| | |
| subscription-modified, id#22 | |
| Message Publisher ID [#1] | |
+<------------------------------+ |
| | |
| notif-mesg, id #22 | |
| Message Publisher ID #1 | |
+<------------------------------+ |
| | |
| | |
+ + +
]]>A "establish-subscription" RPC request as per is sent to the Master with a successful
response. An example of using NETCONF:
ds:operational
/ex:foo
500
]]>As the network node is able to fully satisfy the
request, the request is given a subscription ID of 22. The
response as in indicates that
the subscription is decomposed into two component
subscriptions which will be published by two message
Message Publisher ID: #1 and #2.
22
1
2
]]>Then, both Publishers send notifications with the
corresponding piece of data to the Receiver.The subscriber may invoke the "modify-subscription" RPC for a
subscription it previously established. The RPC has no
difference to the single publisher case as in [RFC8641].
provides an example where a
subscriber attempts to modify the period and datastore XPath
filter of a subscription using NETCONF.22
ds:operational
/ex:bar
250
]]>If the modification is successfully accepted, the
"subscription-modified" subscription state notification is sent
to the subscriber by the Master. The notification, for example, indicates the modified
subscription is decomposed into one component subscription which
will be published by message Message Publisher ID #1.2007-09-01T10:00:00Z22
ds:operational
/ex:bar
250
1
]]> shows a typical configured
subscription to the network node with distributed data export
capability.Before starting to push data, the "subscription-started"
subscription state notification is sent to the Receiver. The
following example assumes the NETCONF transport has already
established. The notification indicates that the configured
subscription is decomposed into two component subscriptions
which will be published by two message Message Publisher IDs:
#1 and #2.2007-09-01T10:00:00Z39
ds:operational
/ex:foo
250
2
]]>Then, both Publishers send notifications with the
corresponding data record to the Receiver.