< draft-zhou-netconf-multi-stream-originators-05.txt   draft-zhou-netconf-multi-stream-originators-06.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: December 27, 2019 E. Voit Expires: January 8, 2020 E. Voit
Cisco Systems Cisco Systems
A. Clemm A. Clemm
Futurewai Futurewai
A. Bierman A. Bierman
YumaWorks YumaWorks
June 25, 2019 July 07, 2019
Subscription to Multiple Stream Originators Subscription to Multiple Stream Originators
draft-zhou-netconf-multi-stream-originators-05 draft-zhou-netconf-multi-stream-originators-06
Abstract Abstract
This document describes the distributed data export mechanism that This document describes the distributed data export mechanism that
allows multiple data streams to be managed using a single allows multiple data streams to be managed using a single
subscription. Specifically, multiple data streams are pushed subscription. Specifically, multiple data streams are pushed
directly to the collector without passing through a broker for directly to the collector without passing through a broker for
internal consolidation. internal consolidation.
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 December 27, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Use Case 1: Data Collection from Devices with Main-board 2.1. Use Case 1: Data Collection from Devices with Main-board
and Line-cards . . . . . . . . . . . . . . . . . . . . . 3 and Line-cards . . . . . . . . . . . . . . . . . . . . . 3
2.2. Use Case 2: IoT Data Collection . . . . . . . . . . . . . 4 2.2. Use Case 2: IoT Data Collection . . . . . . . . . . . . . 4
3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
5. Subscription Decomposition . . . . . . . . . . . . . . . . . 8 5. Subscription Decomposition . . . . . . . . . . . . . . . . . 8
6. Publication Composition . . . . . . . . . . . . . . . . . . . 9 6. Publication Composition . . . . . . . . . . . . . . . . . . . 9
7. Subscription State Change Notifications . . . . . . . . . . . 10 7. Subscription State Change Notifications . . . . . . . . . . . 10
8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Transport Considerations . . . . . . . . . . . . . . . . . . 13 11. Transport Considerations . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 A.1. RESTCONF Establishing Dynamic Subscription . . . . . . . 17
A.2. HTTPS Configured Subscription . . . . . . . . . . . . . . 18
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Streaming telemetry refers to sending a continuous stream of Streaming telemetry refers to sending a continuous stream of
operational data from a device to a remote receiver. This provides operational data from a device to a remote receiver. This provides
an ability to monitor a network from remote and to provide network an ability to monitor a network from remote and to provide network
analytics. Devices generate telemetry data and push that data to a analytics. Devices generate telemetry data and push that data to a
collector for further analysis. By streaming the data, much better collector for further analysis. By streaming the data, much better
performance, finer-grained sampling, monitoring accuracy, and performance, finer-grained sampling, monitoring accuracy, and
bandwidth utilization can be achieved than with polling-based bandwidth utilization can be achieved than with polling-based
skipping to change at page 10, line 35 skipping to change at page 11, line 4
related to subscription management have occurred. All the 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 Publication Channel which is the session between the Master Master Publication Channel which is the session between the Master
Publisher and the Receiver. Publisher and the Receiver.
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.
8. YANG Tree 8. YANG Tree
module: ietf-multiple-stream-originators module: ietf-multiple-stream-originators
augment /sn:subscriptions/sn:subscription: augment /sn:subscriptions/sn:subscription:
+--ro message-generator-id* string +--ro message-generator-id* string
+--ro (transport-access) ?
+--: (restconf-access)
+--ro uri* inet:uri
augment /sn:subscription-started: augment /sn:subscription-started:
+--ro message-generator-id* string +--ro message-generator-id* string
augment /sn:subscription-modified: augment /sn:subscription-modified:
+--ro message-generator-id* string +--ro message-generator-id* string
augment /sn:establish-subscription/sn:output: augment /sn:establish-subscription/sn:output:
+--ro message-generator-id* string +--ro message-generator-id* string
+--ro (transport-access) ?
+--: (restconf-access)
+--ro uri* inet:uri
augment /sn:modify-subscription/sn:output: augment /sn:modify-subscription/sn:output:
+--ro message-generator-id* string +--ro message-generator-id* string
+--ro (transport-access) ?
+--: (restconf-access)
+--ro uri* inet:uri
9. YANG Module 9. YANG Module
<CODE BEGINS> file "ietf-multiple-stream-originators@2019-06-25.yang" <CODE BEGINS> file "ietf-multiple-stream-originators@2019-07-07.yang"
module ietf-multiple-stream-originators { module ietf-multiple-stream-originators {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-multiple-stream-originators"; "urn:ietf:params:xml:ns:yang:ietf-multiple-stream-originators";
prefix mso; prefix mso;
import ietf-subscribed-notifications { import ietf-subscribed-notifications {
prefix sn; prefix sn;
} }
import ietf-inet-types {
prefix inet;
}
organization "IETF NETCONF (Network Configuration) Working Group"; organization "IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <http:/tools.ietf.org/wg/netconf/> "WG Web: <http:/tools.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Editor: Tianran Zhou Editor: Tianran Zhou
<mailto:zhoutianran@huawei.com> <mailto:zhoutianran@huawei.com>
Editor: Guangying Zheng Editor: Guangying Zheng
<mailto:zhengguangying@huawei.com>"; <mailto:zhengguangying@huawei.com>";
skipping to change at page 11, line 36 skipping to change at page 12, line 19
Copyright (c) 2018 IETF Trust and the persons identified as authors Copyright (c) 2018 IETF Trust and the persons identified as authors
of the code. All rights reserved. of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the RFC This version of this YANG module is part of RFC XXXX; see the RFC
itself for full legal notices."; itself for full legal notices.";
revision 2019-06-25 { revision 2019-07-07 {
description description
"Initial version"; "Initial version";
reference reference
"RFC XXXX: Subscription to Multiple Stream Originators"; "RFC XXXX: Subscription to Multiple Stream Originators";
} }
grouping message-generator-ids { grouping message-generator-ids {
description description
"Provides a reusable list of message-generator-ids."; "Provides a reusable list of message-generator-ids.";
leaf-list message-generator-id { leaf-list message-generator-id {
type string; type string;
config false; config false;
ordered-by user; ordered-by user;
description description
"Software entity which created the message (e.g., "Software entity which created the message (e.g.,
linecard 1). This field is used to notify the linecard 1). This field is used to notify the
collector the working originator"; collector the working originator.";
}
}
grouping resource-access-list {
description
"Provides a reusable list of resource access information.";
choice transport-access {
description
"identify the transport used.";
case restconf-access {
description
"When the transport is RESTCONF";
leaf-list uri {
type inet:uri;
config false;
ordered-by user;
description
"Location of a subscription specific URI on the
publisher.";
}
}
} }
} }
augment "/sn:subscriptions/sn:subscription" { augment "/sn:subscriptions/sn:subscription" {
description description
"This augmentation allows the message generators to be exposed "This augmentation allows the message generators to be exposed
for a subscription."; for a subscription.";
uses resource-access-list;
uses message-generator-ids; uses message-generator-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-generator-ids;
} }
skipping to change at page 12, line 41 skipping to change at page 13, line 48
exposed for a subscription."; exposed for a subscription.";
uses message-generator-ids; uses message-generator-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 resource-access-list;
uses message-generator-ids; uses message-generator-ids;
} }
augment "/sn:modify-subscription/sn:output" { augment "/sn:modify-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 resource-access-list;
uses message-generator-ids; uses message-generator-ids;
} }
} }
<CODE ENDS> <CODE ENDS>
10. IANA Considerations 10. 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]:
skipping to change at page 14, line 5 skipping to change at page 15, line 14
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 one new data node introduced in this YANG module may be The new data nodes introduced in this YANG module may be considered
considered sensitive or vulnerable in some network environments. It sensitive or vulnerable in some network environments. It is thus
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-generator-ids
The entries in the list above will show where subscribed resources o /subscriptions/subscription/resource-access-list
might be located on the publishers. Access control MUST be set so
that only someone with proper access permissions has the ability to The entries in the two lists above will show where subscribed
access this resource. 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 YANG- Other Security Considerations is the same as those discussed in YANG-
Push [I-D.ietf-netconf-yang-push]. Push [I-D.ietf-netconf-yang-push].
13. Acknowledgements 13. Acknowledgements
TBD TBD
14. References 14. References
skipping to change at page 15, line 43 skipping to change at page 17, line 10
Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and
A. Tripathy, "Subscription to YANG Event Notifications", A. Tripathy, "Subscription to YANG Event Notifications",
draft-ietf-netconf-subscribed-notifications-26 (work in draft-ietf-netconf-subscribed-notifications-26 (work in
progress), May 2019. progress), May 2019.
[I-D.ietf-netconf-yang-push] [I-D.ietf-netconf-yang-push]
Clemm, A. and E. Voit, "Subscription to YANG Datastores", Clemm, A. and E. Voit, "Subscription to YANG Datastores",
draft-ietf-netconf-yang-push-25 (work in progress), May draft-ietf-netconf-yang-push-25 (work in progress), May
2019. 2019.
Appendix A. Change Log [I-D.mahesh-netconf-https-notif]
Jethanandani, M. and K. Watsen, "An HTTPS-based Transport
for Configured Subscriptions", draft-mahesh-netconf-https-
notif-00 (work in progress), June 2019.
Appendix A. Examples
A.1. RESTCONF Establishing Dynamic Subscription
This example shows how a RESTCONF dynamic subscription is
established. The request is given a subscription identifier of 22,
and decomposed into two component subsrciptions.
Firstly, an establish-subscription request is sent to the Master.
POST /restconf/operations
/ietf-subscribed-notifications:establish-subscription
{
"ietf-subscribed-notifications:input": {
"stream-xpath-filter": "/example-module:foo/",
"stream": "NETCONF",
"dscp": 10
}
}
Fig. 4 establish-subscription request
As publisher was able to fully satisfy the request, the Master sends
the subscription identifier of the accepted subscription, the URIs,
and the message generator IDs:
HTTP status code - 200
{
"id": 22,
"uri": [
"https://192.0.3.1/restconf/subscriptions/22",
"https://192.0.3.2/restconf/subscriptions/22"
],
"message-generator-id":["1","2"]
}
Fig. 5 establish-subscription success
Upon receipt of the successful response, the subscriber GET the
provided URIs to start the flow of notification messages.
GET https://192.0.3.1/restconf/subscriptions/22
GET https://192.0.3.2/restconf/subscriptions/22
Fig. 6 establish-subscription subsequent POST
A.2. HTTPS Configured Subscription
This example reuses the use case in [I-D.mahesh-netconf-https-notif]
and shows how two message originators associated to one subscription
can be configured to send https notifications to a receiver at
address 192.0.2.1, port 443 with server certificates, and the
corresponding trust store that is used to authenticate connections.
[note: '\' line wrapping for formatting only]
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<receivers
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif">
<receiver>
<name>foo</name>
<channel>
<tcp-params>
<remote-address>192.0.2.1</remote-address>
<remote-port>443</remote-port>
<local-address>192.0.3.1</local-address>
<local-port>63001</local-port>
</tcp-params>
<tls-params>
<server-authentication>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
<server-certs>explicitly-trusted-server-certs</server-ce\
rts>
</server-authentication>
</tls-params>
</channel>
<channel>
<tcp-params>
<remote-address>192.0.2.1</remote-address>
<remote-port>443</remote-port>
<local-address>192.0.3.2</local-address>
<local-port>63001</local-port>
</tcp-params>
<tls-params>
<server-authentication>
<ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
<server-certs>explicitly-trusted-server-certs</server-ce\
rts>
</server-authentication>
</tls-params>
</channel>
</receiver>
</receivers>
<subscriptions
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\
ns">
<subscription>
<id>6666</id>
<stream-subtree-filter>foo</stream-subtree-filter>
<stream>some-stream</stream>
<receivers>
<receiver>
<name>my-receiver1</name>
<receiver-ref
xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif">
foo
</receiver-ref>
</receiver>
</receivers>
</subscription>
</subscriptions>
<truststore xmlns="urn:ietf:params:xml:ns:yang:ietf-truststore">
<certificates>
<name>explicitly-trusted-server-certs</name>
<description>
Specific server authentication certificates for explicitly
trusted servers. These are needed for server certificates
that are not signed by a pinned CA.
</description>
<certificate>
<name>Fred Flintstone</name>
<cert>base64encodedvalue==</cert>
</certificate>
</certificates>
<certificates>
<name>explicitly-trusted-server-ca-certs</name>
<description>
Trust anchors (i.e. CA certs) that are used to authenticate\
server connections. Servers are authenticated if their
certificate has a chain of trust to one of these CA
certificates.
</description>
<certificate>
<name>ca.example.com</name>
<cert>base64encodedvalue==</cert>
</certificate>
</certificates>
</truststore>
</config>
Appendix B. Change Log
(To be removed by RFC editor prior to publication) (To be removed by RFC editor prior to publication)
v01 v01
o Minor revision on Subscription Decomposition o Minor revision on Subscription Decomposition
o Revised terminologies o Revised terminologies
o Removed most implementation related text o Removed most implementation related text
o Place holder of two sections: Subscription Management, and o Place holder of two sections: Subscription Management, and
Notifications on Subscription State Changes Notifications on Subscription State Changes
v02 v02
o Revised section 4 and 5. Moved them from apendix to the main o Revised section 4 and 5. Moved them from apendix to the main
text. text.
skipping to change at page 16, line 31 skipping to change at page 21, line 4
check the integrity of the data generated from different check the integrity of the data generated from different
Publishers at the same time period. Publishers at the same time period.
o Revised the solution overview for a more clear description. o Revised the solution overview for a more clear description.
v04 v04
o Added the YANG data model for the proposed augment. o Added the YANG data model for the proposed augment.
v05 v05
o Added the IANA considerations, transport considerations and o Added the IANA considerations, transport considerations and
security considerations. security considerations.
v06
o Added examples.
Authors' Addresses Authors' Addresses
Tianran Zhou Tianran Zhou
Huawei Huawei
156 Beiqing Rd., Haidian District 156 Beiqing Rd., Haidian District
Beijing Beijing
China China
Email: zhoutianran@huawei.com Email: zhoutianran@huawei.com
Guangying Zheng Guangying Zheng
Huawei Huawei
101 Yu-Hua-Tai Software Road 101 Yu-Hua-Tai Software Road
Nanjing, Jiangsu Nanjing, Jiangsu
China China
Email: zhengguangying@huawei.com Email: zhengguangying@huawei.com
Eric Voit Eric Voit
Cisco Systems Cisco Systems
 End of changes. 26 change blocks. 
29 lines changed or deleted 226 lines changed or added

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