< draft-ietf-netconf-distributed-notif-00.txt   draft-ietf-netconf-distributed-notif-01.txt >
NETCONF T. Zhou NETCONF T. Zhou
Internet-Draft G. Zheng Internet-Draft G. Zheng
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: April 6, 2021 E. Voit Expires: May 6, 2021 E. Voit
Cisco Systems Cisco Systems
T. Graf T. Graf
Swisscom Swisscom
P. Francois P. Francois
INSA-Lyon INSA-Lyon
October 3, 2020 November 02, 2020
Subscription to Distributed Notifications Subscription to Distributed Notifications
draft-ietf-netconf-distributed-notif-00 draft-ietf-netconf-distributed-notif-01
Abstract Abstract
This documents describes extensions to the YANG notifications This documents describes extensions to the YANG notifications
subscription to allow metrics being published directly from subscription to allow metrics being published directly from
processors on line cards to target receivers, while subscription is processors on line cards to target receivers, while subscription is
still maintained at the route processor in a distributed forwarding still maintained at the route processor in a distributed forwarding
system. system.
Requirements Language Requirements Language
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Subscription Decomposition . . . . . . . . . . . . . . . . . 6 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Publication Composition . . . . . . . . . . . . . . . . . . . 6 5. Subscription Decomposition . . . . . . . . . . . . . . . . . 6
6. Subscription State Change Notifications . . . . . . . . . . . 7 6. Publication Composition . . . . . . . . . . . . . . . . . . . 6
7. Publisher Configurations . . . . . . . . . . . . . . . . . . 7 7. Subscription State Change Notifications . . . . . . . . . . . 7
8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Publisher Configurations . . . . . . . . . . . . . . . . . . 7
9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
14.1. Normative References . . . . . . . . . . . . . . . . . . 11 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
14.2. Informative References . . . . . . . . . . . . . . . . . 12 15.1. Normative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 15.2. Informative References . . . . . . . . . . . . . . . . . 12
A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
A.2. Configured Subscription . . . . . . . . . . . . . . . . . 16 A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 A.2. Configured Subscription . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The mechanism to support a subscription to a continuous and The mechanism to support a subscription to a continuous and
customized stream of updates from a YANG datastore is defined in customized stream of updates from a YANG datastore is defined in
[RFC8639] and [RFC8641]. Requirements for Subscription to YANG [RFC8639] and [RFC8641]. Requirements for Subscription to YANG
Datastores are defined in [RFC7923] Datastores are defined in [RFC7923]
By streaming data from publishers to receivers, much better By streaming data from publishers to receivers, much better
performance and fine-grained sampling can be achieved than with performance and fine-grained sampling can be achieved than with
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Component Capability: is the subscription capability that each Component Capability: is the subscription capability that each
Publisher can expose to the Subscriber. Publisher can expose to the Subscriber.
Master: is the Publisher that interacts with the Subscriber to deal Master: is the Publisher that interacts with the Subscriber to deal
with the Global Subscription. It decomposes the Global Subscription with the Global Subscription. It decomposes the Global Subscription
to multiple Component Subscriptions and interacts with the Agents. to multiple Component Subscriptions and interacts with the Agents.
Agent: is the Publisher that interacts with the Master to deal with Agent: is the Publisher that interacts with the Master to deal with
the Component Subscription and pushing the data to the collector. the Component Subscription and pushing the data to the collector.
3. Solution Overview Observation Domain: An Observation Domain is the largest set of
Observation Points for which metrics can be collected by a metering
process. For example, a router line card may be an Observation
Domain if it is composed of several interfaces, each of which is an
Observation Point. In the YANG notification messages it generates,
the Observation Domain includes its Observation Domain ID, which is
unique per publisher process. That way, the collecting process can
identify the specific Observation Domain from the publisher that
sends the YANG notification messages. Every Observation Point is
associated with an Observation Domain.
Observation Domain ID: A 32-bit identifier of the Observation Domain
that is locally unique to the publisher process. The publisher
process uses the Observation Domain ID to uniquely identify to the
collecting process the Observation Domain that meters the metrics.
Receivers SHOULD use the transport session and the Observation Domain
ID field to separate different publisher streams originating from the
same publisher.
3. Motivation
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
Observation Domain 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
[I-D.ietf-netconf-udp-notif].
4. Solution Overview
Figure 2 below shows the distributed data export framework. Figure 2 below shows the distributed data export framework.
A collector usually includes two components, A collector usually includes two components,
o the Subscriber generates the subscription instructions to express o the Subscriber generates the subscription instructions to express
what and how the collector want to receive the data; what and how the collector want to receive the data;
o the Receiver is the target for the data publication. o the Receiver is the target for the data publication.
skipping to change at page 6, line 5 skipping to change at page 6, line 16
o The Agents announce the status of their Component Subscriptions to o The Agents announce the status of their Component Subscriptions to
the Master. The status of the overall subscription is maintained the Master. The status of the overall subscription is maintained
by the Master. The Master is responsible for notifying the by the Master. The Master is responsible for notifying the
subscriber in case of problems with the Component Subscriptions. subscriber in case of problems with the Component Subscriptions.
The technical mechanisms or protocols used for the coordination of The technical mechanisms or protocols used for the coordination of
operational information between Master and Agent is out-of-scope of operational information between Master and Agent is out-of-scope of
this document. this document.
4. Subscription Decomposition 5. Subscription Decomposition
The Collector can only subscribe to the Master. This requires the The Collector can only subscribe to the Master. This requires the
Master to: Master to:
1. expose the Global Capability that can be served by multiple 1. expose the Global Capability that can be served by multiple
Publisher Agents; Publisher Agents;
2. disassemble the Global Subscription to multiple Component 2. disassemble the Global Subscription to multiple Component
Subscriptions, and distribute them to the Publisher Agents of the Subscriptions, and distribute them to the Publisher Agents of the
corresponding metric sources so that they not overlap; corresponding metric sources so that they not overlap;
skipping to change at page 6, line 29 skipping to change at page 6, line 40
And the Agent to: And the Agent to:
o Inherit the Global Subscription properties from Publisher Master o Inherit the Global Subscription properties from Publisher Master
for its Component Subscription; for its Component Subscription;
o share the same life-cycle as the Global Subscription; o share the same life-cycle as the Global Subscription;
o share the same Subscription ID as the Global Subscription. o share the same Subscription ID as the Global Subscription.
5. Publication Composition 6. Publication Composition
The Publisher Agent collects data and encapsulates the packets per The Publisher Agent collects data and encapsulates the packets per
Component Subscription. The format and structure of the data records Component Subscription. The format and structure of the data records
are defined by the YANG schema, so that the decomposition at the are defined by the YANG schema, so that the decomposition at the
Receiver can benefit from the structured and hierarchical data Receiver can benefit from the structured and hierarchical data
records. records.
The Receiver is able to associate the YANG data records with The Receiver is able to associate the YANG data records with
Subscription ID [RFC8639] to the subscribed subscription and with Subscription ID [RFC8639] to the subscribed subscription and with
Message Generator ID [I-D.ietf-netconf-notification-messages] to one Message Observation Domain ID
of the Publisher Agents software processes to enable message [I-D.ietf-netconf-notification-messages] to one of the Publisher
integrity. Agents software processes to enable message integrity.
For the dynamic subscription, the output of the "establish- For the dynamic subscription, the output of the "establish-
subscription" RPC defined in [RFC8639] MUST include a list of Message subscription" RPC defined in [RFC8639] MUST include a list of Message
Generator IDs to indicate how the Global Subscription is decomposed Observation Domain IDs to indicate how the Global Subscription is
into several Component Subscriptions. decomposed into several Component Subscriptions.
The "subscription-started" and "subscription-modified" notification The "subscription-started" and "subscription-modified" notification
defined in [RFC8639] MUST also include a list of Message Generator defined in [RFC8639] MUST also include a list of Message Observation
IDs to notify the current Publishers for the corresponding Global Domain IDs to notify the current Publishers for the corresponding
Subscription. Global Subscription.
6. Subscription State Change Notifications 7. Subscription State Change Notifications
In addition to sending event records to Receivers, the Master MUST In addition to sending event records to Receivers, the Master MUST
also send subscription state change notifications [RFC8639] when also send subscription state change notifications [RFC8639] when
events related to subscription management have occurred. All the events related to subscription management have occurred. All the
subscription state change notifications MUST be delivered by the subscription state change notifications MUST be delivered by the
Master. Master.
When the subscription decomposition result changed, the When the subscription decomposition result changed, the
"subscription-modified" notification MUST be sent to indicate the new "subscription-modified" notification MUST be sent to indicate the new
list of Publishers. list of Publishers.
7. Publisher Configurations 8. Publisher Configurations
This document assumes that all Publisher Agents are preconfigured to This document assumes that all Publisher Agents are preconfigured to
push data. The actual working Publisher Agents are selected based on push data. The actual working Publisher Agents are selected based on
the subscription decomposition result. the subscription decomposition result.
All Publisher Agents share the same source IP address for data All Publisher Agents share the same source IP address for data
export. For connectionless data transport such as UDP based export. For connectionless data transport such as UDP based
transport [I-D.unyte-netconf-udp-notif] the same Layer 4 source port transport [I-D.ietf-netconf-udp-notif] the same Layer 4 source port
for data export can be used. For connection based data transport for data export can be used. For connection based data transport
such as HTTPS based transport [I-D.ietf-netconf-https-notif], each such as HTTPS based transport [I-D.ietf-netconf-https-notif], each
Publisher Agent MUST be able to acknowledge packet retrieval from Publisher Agent MUST be able to acknowledge packet retrieval from
Receivers, and therefore requires a dedicated Layer 4 source port per Receivers, and therefore requires a dedicated Layer 4 source port per
software process. software process.
The specific configuration on transports is described in the The specific configuration on transports is described in the
resposible documents. resposible documents.
8. YANG Tree 9. YANG Tree
module: ietf-distributed-notifications module: ietf-distributed-notifications
augment /sn:subscriptions/sn:subscription: augment /sn:subscriptions/sn:subscription:
+--ro message-generator-id* string +--ro message-observation-domain-id* string
augment /sn:subscription-started: augment /sn:subscription-started:
+--ro message-generator-id* string +--ro message-observation-domain-id* string
augment /sn:subscription-modified: augment /sn:subscription-modified:
+--ro message-generator-id* string +--ro message-observation-domain-id* string
augment /sn:establish-subscription/sn:output: augment /sn:establish-subscription/sn:output:
+--ro message-generator-id* string +--ro message-observation-domain-id* string
9. YANG Module 10. YANG Module
<CODE BEGINS> file "ietf-distributed-notifications@2020-05-09.yang" <CODE BEGINS> file "ietf-distributed-notifications@2020-05-09.yang"
module ietf-distributed-notif { module ietf-distributed-notif {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-distributed-notifications"; "urn:ietf:params:xml:ns:yang:ietf-distributed-notifications";
prefix mso; prefix mso;
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
} }
skipping to change at page 8, line 45 skipping to change at page 9, line 15
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
revision 2020-05-09 { revision 2020-05-09 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Subscription to Distributed Notifications"; "RFC XXXX: Subscription to Distributed Notifications";
} }
grouping message-generator-ids { grouping message-observation-domain-ids {
description description
"Provides a reusable list of message-generator-ids."; "Provides a reusable list of message-observation-domain-ids.";
leaf-list message-generator-id { leaf-list message-observation-domain-id {
type string; type string;
config false; config false;
ordered-by user; ordered-by user;
description description
"Software process which created the message (e.g., "Software process which created the message (e.g.,
processor 1 on linecard 1). This field is processor 1 on linecard 1). This field is
used to notify the collector the working originator."; used to notify the collector the working originator.";
} }
} }
augment "/sn:subscriptions/sn:subscription" { augment "/sn:subscriptions/sn:subscription" {
description description
"This augmentation allows the message generators to be "This augmentation allows the message
exposed for a subscription."; Observation Domain ID to be exposed for a subscription.";
uses message-generator-ids; uses message-observation-domain-ids;
} }
augment "/sn:subscription-started" { augment "/sn:subscription-started" {
description description
"This augmentation allows MSO specific parameters to be "This augmentation allows MSO specific parameters to be
exposed for a subscription."; exposed for a subscription.";
uses message-generator-ids; uses message-observation-domain-ids;
} }
augment "/sn:subscription-modified" { augment "/sn:subscription-modified" {
description description
"This augmentation allows MSO specific parameters to be "This augmentation allows MSO specific parameters to be
exposed for a subscription."; exposed for a subscription.";
uses message-generator-ids; uses message-observation-domain-ids;
} }
augment "/sn:establish-subscription/sn:output" { augment "/sn:establish-subscription/sn:output" {
description description
"This augmentation allows MSO specific parameters to be "This augmentation allows MSO specific parameters to be
exposed for a subscription."; exposed for a subscription.";
uses message-generator-ids; uses message-observation-domain-ids;
} }
} }
<CODE ENDS> <CODE ENDS>
10. IANA Considerations 11. IANA Considerations
This document registers the following namespace URI in the IETF XML This document registers the following namespace URI in the IETF XML
Registry [RFC3688]: Registry [RFC3688]:
URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace. XML: N/A; the requested URI is an XML namespace.
skipping to change at page 10, line 23 skipping to change at page 10, line 37
Name: ietf-subscribed-notifications Name: ietf-subscribed-notifications
Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed- Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed-
notifications notifications
Prefix: mso Prefix: mso
Reference: RFC XXXX Reference: RFC XXXX
11. Security Considerations 12. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC5246]. [RFC5246].
The NETCONF Access Control Model (NACM) [RFC6536] provides the means The NETCONF Access Control Model (NACM) [RFC6536] provides the means
to restrict access for particular NETCONF or RESTCONF users to a to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. operations and content.
The new data nodes introduced in this YANG module may be considered The new data nodes introduced in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get-config or important to control read access (e.g., via get-config or
notification) to this data nodes. These are the subtrees and data notification) to this data nodes. These are the subtrees and data
nodes and their sensitivity/vulnerability: nodes and their sensitivity/vulnerability:
o /subscriptions/subscription/message-generator-ids o /subscriptions/subscription/message-observation-domain-ids
The entries in the two lists above will show where subscribed The entries in the two lists above will show where subscribed
resources might be located on the publishers. Access control MUST be resources might be located on the publishers. Access control MUST be
set so that only someone with proper access permissions has the set so that only someone with proper access permissions has the
ability to access this resource. ability to access this resource.
Other Security Considerations is the same as those discussed in YANG- Other Security Considerations is the same as those discussed in YANG-
Push [RFC8641]. Push [RFC8641].
12. Contributors 13. Contributors
Alexander Clemm Alexander Clemm
Futurewai Futurewai
2330 Central Expressway 2330 Central Expressway
Santa Clara Santa Clara
California California
United States of America United States of America
Email: ludwig@clemm.org Email: ludwig@clemm.org
13. Acknowledgements 14. Acknowledgements
We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim
Carey and Qin Wu for their constructive suggestions for improving Carey and Qin Wu for their constructive suggestions for improving
this document. this document.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 12, line 23 skipping to change at page 12, line 42
[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
E., and A. Tripathy, "Subscription to YANG Notifications", E., and A. Tripathy, "Subscription to YANG Notifications",
RFC 8639, DOI 10.17487/RFC8639, September 2019, RFC 8639, DOI 10.17487/RFC8639, September 2019,
<https://www.rfc-editor.org/info/rfc8639>. <https://www.rfc-editor.org/info/rfc8639>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>. September 2019, <https://www.rfc-editor.org/info/rfc8641>.
14.2. Informative References 15.2. Informative References
[I-D.ietf-netconf-https-notif] [I-D.ietf-netconf-https-notif]
Jethanandani, M. and K. Watsen, "An HTTPS-based Transport Jethanandani, M. and K. Watsen, "An HTTPS-based Transport
for Configured Subscriptions", draft-ietf-netconf-https- for Configured Subscriptions", draft-ietf-netconf-https-
notif-04 (work in progress), July 2020. notif-05 (work in progress), October 2020.
[I-D.ietf-netconf-notification-messages] [I-D.ietf-netconf-notification-messages]
Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
Clemm, "Notification Message Headers and Bundles", draft- Clemm, "Notification Message Headers and Bundles", draft-
ietf-netconf-notification-messages-08 (work in progress), ietf-netconf-notification-messages-08 (work in progress),
November 2019. November 2019.
[I-D.unyte-netconf-udp-notif] [I-D.ietf-netconf-udp-notif]
Zhou, T., Zheng, G., Lucente, P., Graf, T., and P. Zhou, T., Zheng, G., Lucente, P., Graf, T., and P.
Francois, "UDP-based Transport for Configured Francois, "UDP-based Transport for Configured
Subscriptions", draft-unyte-netconf-udp-notif-00 (work in Subscriptions", draft-ietf-netconf-udp-notif-01 (work in
progress), July 2020. progress), July 2020.
Appendix A. Examples Appendix A. Examples
This appendix is non-normative. This appendix is non-normative.
A.1. Dynamic Subscription A.1. Dynamic Subscription
Figure 3 shows a typical dynamic subscription to the device with Figure 3 shows a typical dynamic subscription to the device with
distributed data export capability. distributed data export capability.
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Subscriber/ | | Publisher | | Publisher | | Subscriber/ | | Publisher | | Publisher |
| Receiver | | (Master) | | (Agent) | | Receiver | | (Master) | | (Agent) |
+-------------+ +------+------+ +------+------+ +-------------+ +------+------+ +------+------+
| | | | | |
| establish-subscription | | | establish-subscription | |
+------------------------------>+ component | +------------------------------>+ component |
| | subscription | | | subscription |
| RPC Reply: OK, id #22 +-------------->+ | RPC Reply: OK, id #22 +-------------->+
| message generator ID [#1, #2] | | | Observation Domain ID [#1,#2] | |
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| notif-mesg, id #22 | | | notif-mesg, id #22 | |
| message generator ID #1 | | | Observation Domain ID #1 | |
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| notif-mesg, id#22 | | | notif-mesg, id#22 | |
| message generator ID #2 | | | Observation Domain ID #2 | |
+<----------------------------------------------+ +<----------------------------------------------+
| | | | | |
| modify-subscription (id#22) | | | modify-subscription (id#22) | |
+------------------------------>+ component | +------------------------------>+ component |
| | subscription | | | subscription |
| RPC Reply: OK, id #22 +-------------->+ | RPC Reply: OK, id #22 +-------------->+
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| subscription-modified, id#22 | | | subscription-modified, id#22 | |
| message generator ID [#1] | | | Observation Domain ID [#1] | |
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| notif-mesg, id #22 | | | notif-mesg, id #22 | |
| message generator ID #1 | | | Observation Domain ID #1 | |
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| | | | | |
+ + + + + +
Fig. 3 Call Flow for Dynamic Subscription Fig. 3 Call Flow for Dynamic Subscription
A "establish-subscription" RPC request as per [RFC8641] is sent to A "establish-subscription" RPC request as per [RFC8641] is sent to
the Master with a successful response. An example of using NETCONF: the Master with a successful response. An example of using NETCONF:
skipping to change at page 14, line 29 skipping to change at page 15, line 29
<yp:period>500</yp:period> <yp:period>500</yp:period>
</yp:periodic> </yp:periodic>
</establish-subscription> </establish-subscription>
</netconf:rpc> </netconf:rpc>
Fig. 4 "establish-subscription" Request Fig. 4 "establish-subscription" Request
As the device is able to fully satisfy the request, the request is As the device is able to fully satisfy the request, the request is
given a subscription ID of 22. The response as in Figure 5 indicates given a subscription ID of 22. The response as in Figure 5 indicates
that the subscription is decomposed into two component subscriptions that the subscription is decomposed into two component subscriptions
which will be published by two message generators: #1 and #2. which will be published by two message Observation Domain ID: #1 and
#2.
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<id <id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"> xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">
22 22
</id> </id>
<message-generator-id <message-observation-domain-id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications> xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
1 1
</message-generator-id> </message-observation-domain-id>
<message-generator-id <message-observation-domain-id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications> xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
2 2
</message-generator-id> </message-observation-domain-id>
</rpc-reply> </rpc-reply>
Fig. 5 "establish-subscription" Positive RPC Response Fig. 5 "establish-subscription" Positive RPC Response
Then, both Publishers send notifications with the corresponding piece Then, both Publishers send notifications with the corresponding piece
of data to the Receiver. of data to the Receiver.
The subscriber may invoke the "modify-subscription" RPC for a The subscriber may invoke the "modify-subscription" RPC for a
subscription it previously established. The RPC has no difference to subscription it previously established. The RPC has no difference to
the single publisher case as in [RFC8641]. Figure 6 provides an the single publisher case as in [RFC8641]. Figure 6 provides an
skipping to change at page 15, line 38 skipping to change at page 16, line 38
</yp:periodic> </yp:periodic>
</modify-subscription> </modify-subscription>
</rpc> </rpc>
Fig. 6 "modify-subscription" Request Fig. 6 "modify-subscription" Request
If the modification is successfully accepted, the "subscription- If the modification is successfully accepted, the "subscription-
modified" subscription state notification is sent to the subscriber modified" subscription state notification is sent to the subscriber
by the Master. The notification, Figure 7 for example, indicates the by the Master. The notification, Figure 7 for example, indicates the
modified subscription is decomposed into one component subscription modified subscription is decomposed into one component subscription
which will be published by message generator #1. which will be published by message Observation Domain #1.
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-modified <subscription-modified
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<id>22</id> <id>22</id>
<yp:datastore <yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational ds:operational
</yp:datastore> </yp:datastore>
<yp:datastore-xpath-filter <yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0"> xmlns:ex="https://example.com/sample-data/1.0">
/ex:bar /ex:bar
</yp:datastore-xpath-filter> </yp:datastore-xpath-filter>
<yp:periodic> <yp:periodic>
<yp:period>250</yp:period> <yp:period>250</yp:period>
</yp:periodic> </yp:periodic>
<message-generator-id <message-observation-domain-id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificationss> xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificationss>
1 1
</message-generator-id> </message-observation-domain-id>
</subscription-modified> </subscription-modified>
</notification> </notification>
Fig. 7 "subscription-modified" Subscription State Notification Fig. 7 "subscription-modified" Subscription State Notification
A.2. Configured Subscription A.2. Configured Subscription
Figure 8 shows a typical configured subscription to the device with Figure 8 shows a typical configured subscription to the device with
distributed data export capability. distributed data export capability.
+-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+
| Receiver | | Publisher | | Publisher | | Receiver | | Publisher | | Publisher |
| | | (Master) | | (Agent) | | | | (Master) | | (Agent) |
+------+------+ +------+------+ +------+------+ +------+------+ +------+------+ +------+------+
| | | | | |
| subscription-started, id#39 | | | subscription-started, id#39 | |
| message generator ID [#1, #2] | | | Observation Domain ID [#1,#2] | |
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| notif-mesg, id#39 | | | notif-mesg, id#39 | |
| message generator ID #1 | | | Observation Domain ID #1 | |
+<------------------------------+ | +<------------------------------+ |
| | | | | |
| notif-mesg, id#39 | | | notif-mesg, id#39 | |
| message generator ID #2 | | | Observation Domain ID #2 | |
+<----------------------------------------------+ +<----------------------------------------------+
| | | | | |
| | | | | |
| | | | | |
Fig. 8 Call Flow for Configured Subscription Fig. 8 Call Flow for Configured Subscription
Before starting to push data, the "subscription-started" subscription Before starting to push data, the "subscription-started" subscription
state notification is sent to the Receiver. The following example state notification is sent to the Receiver. The following example
assumes the NETCONF transport has already established. The assumes the NETCONF transport has already established. The
notification indicates that the configured subscription is decomposed notification indicates that the configured subscription is decomposed
into two component subscriptions which will be published by two into two component subscriptions which will be published by two
message generators: #1 and #2. message Observation Domain: #1 and #2.
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<subscription-started <subscription-started
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<identifier>39</identifier> <identifier>39</identifier>
<yp:datastore <yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"> xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational ds:operational
</yp:datastore> </yp:datastore>
<yp:datastore-xpath-filter <yp:datastore-xpath-filter
xmlns:ex="https://example.com/sample-data/1.0"> xmlns:ex="https://example.com/sample-data/1.0">
/ex:foo /ex:foo
</yp:datastore-xpath-filter> </yp:datastore-xpath-filter>
<yp:periodic> <yp:periodic>
<yp:period>250</yp:period> <yp:period>250</yp:period>
</yp:periodic> </yp:periodic>
<message-generator-id <message-observation-domain-id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications> xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
1 1
</message-generator-id> </message-observation-domain-id>
<message-generator-id <message-observation-domain-id
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications> xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications>
2 2
</message-generator-id> </message-observation-domain-id>
</subscription-started> </subscription-started>
</notification> </notification>
Fig. 9 "subscription-started" Subscription State Notification Fig. 9 "subscription-started" Subscription State Notification
Then, both Publishers send notifications with the corresponding data Then, both Publishers send notifications with the corresponding data
record to the Receiver. record to the Receiver.
Authors' Addresses Authors' Addresses
 End of changes. 59 change blocks. 
85 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/