idnits 2.17.1 draft-unyte-netconf-distributed-notif-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 365 has weird spacing: '...used to notif...' -- The document date (July 10, 2020) is 1357 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) ** Downref: Normative reference to an Informational RFC: RFC 7923 == Outdated reference: A later version (-15) exists of draft-ietf-netconf-https-notif-02 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF T. Zhou 3 Internet-Draft G. Zheng 4 Intended status: Standards Track Huawei 5 Expires: January 11, 2021 E. Voit 6 Cisco Systems 7 T. Graf 8 Swisscom 9 P. Francois 10 INSA-Lyon 11 July 10, 2020 13 Subscription to Distributed Notifications 14 draft-unyte-netconf-distributed-notif-00 16 Abstract 18 This documents describes extensions to the YANG notifications 19 subscription to allow metrics being published directly from 20 processors on line cards to target receivers, while subscription is 21 still maintained at the route processor in a distributed forwarding 22 system. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 11, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Subscription Decomposition . . . . . . . . . . . . . . . . . 6 68 5. Publication Composition . . . . . . . . . . . . . . . . . . . 6 69 6. Subscription State Change Notifications . . . . . . . . . . . 7 70 7. Publisher Configurations . . . . . . . . . . . . . . . . . . 7 71 8. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 14.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 81 A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 12 82 A.2. Configured Subscription . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 The mechanism to support a subscription to a continuous and 88 customized stream of updates from a YANG datastore is defined in 89 [RFC8639] and [RFC8641]. Requirements for Subscription to YANG 90 Datastores are defined in [RFC7923] 92 By streaming data from publishers to receivers, much better 93 performance and fine-grained sampling can be achieved than with 94 polling. In a distributed forwarding system, the packet forwarding 95 is delegated to multiple processors on line cards. To not to 96 overhelm the route processor resources, it is not uncomon that data 97 records are published directly from processors on line cards to 98 target Receivers to further increase efficency on the routing system. 100 This documents complement the general subscription requirements 101 defined in section 4.2.1 of [RFC7923] by the paragraph: A 102 Subscription Service MAY support the ability to export from multiple 103 software processes on a single routing system and expose the 104 information which software process produced which message to maintain 105 data integrity. 107 2. Terminologies 109 The following terms are defined in [RFC8639] and are not redefined 110 here: 112 Subscriber 114 Publisher 116 Receiver 118 Subscription 120 In addition, this document defines the following terms: 122 Global Subscription: the Subscription requested by the subscriber. 123 It may be decomposed into multiple Component Subscriptions. 125 Component Subscription: is the Subscription that defines a data 126 source which is managed and controlled by a single Publisher. 128 Global Capability: is the overall subscription capability that the 129 group of Publishers can expose to the Subscriber. 131 Component Capability: is the subscription capability that each 132 Publisher can expose to the Subscriber. 134 Master: is the Publisher that interacts with the Subscriber to deal 135 with the Global Subscription. It decomposes the Global Subscription 136 to multiple Component Subscriptions and interacts with the Agents. 138 Agent: is the Publisher that interacts with the Master to deal with 139 the Component Subscription and pushing the data to the collector. 141 3. Solution Overview 143 Figure 2 below shows the distributed data export framework. 145 A collector usually includes two components, 147 o the Subscriber generates the subscription instructions to express 148 what and how the collector want to receive the data; 150 o the Receiver is the target for the data publication. 152 For one subscription, there are one or more Receivers. And the 153 Subscriber does not necessarily share the same IP address as the 154 Receivers. 156 In this framework, the Publisher pushes data to the Receiver 157 according to the subscription. The Publisher is either in the Master 158 or Agent role. The Master knows all the capabilities that his Agents 159 are able to provide and exposes the Global Capability to the 160 collector. The Subscriber maintains the Global Subscription at the 161 Master and disassembles the Global Subscription to multiple Component 162 Subscriptions, depending from which source data is needed. The 163 Component Subscriptions are then distributed to the corresponding 164 Publisher Agents on route and processors on line cards. 166 Publisher Agents collects metrics according to the Component 167 Subscription, add its metadata, encapsulate and pushes data to the 168 Receiver where packets are reassembled and decapsulated. 170 +-----------------------------------------+ 171 | Collector |-------------+ | 172 | +------------+ | | 173 | +------------+ || Receiver | | | 174 | | Subscriber | |--------------+ | 175 | +-----^-+----+ +------------^ | 176 | | | | | 177 +-----------------------------------------+ 178 Global | | Global | 179 Capability| | Subscription | 180 +-----------------------------------------+ 181 | | | | | 182 | +--------+-v-------------------+ | | 183 | | Publisher(Master) | | | 184 | +--------^-+-------------------+ | | 185 | | | | | 186 | | | | | 187 | Component | | Component Push | | 188 | Capability| | Subscription | | 189 | +--------+-v-------------------+ | | 190 | | Publisher(Agent) +--+ | 191 | +------------------------------+ | 192 | | 193 | Device | 194 +-----------------------------------------+ 196 Fig. 2 The Distributed Data Export Framework 198 Master and Agents interact with each other in several ways: 200 o Agents need to register at the Master at the beginning of their 201 process life-cycle 203 o Contracts are created between the Master and each Agent on the 204 Component Capability, and the format for streaming data structure. 206 o The Master relays the component subscriptions to the Agents. 208 o The Agents announce the status of their Component Subscriptions to 209 the Master. The status of the overall subscription is maintained 210 by the Master. The Master is responsible for notifying the 211 subscriber in case of problems with the Component Subscriptions. 213 The technical mechanisms or protocols used for the coordination of 214 operational information between Master and Agent is out-of-scope of 215 this document. 217 4. Subscription Decomposition 219 The Collector can only subscribe to the Master. This requires the 220 Master to: 222 1. expose the Global Capability that can be served by multiple 223 Publisher Agents; 225 2. disassemble the Global Subscription to multiple Component 226 Subscriptions, and distribute them to the Publisher Agents of the 227 corresponding metric sources so that they not overlap; 229 3. notify on changes when portions of a subscription moving between 230 different Publisher Agents over time. 232 And the Agent to: 234 o Inherit the Global Subscription properties from Publisher Master 235 for its Component Subscription; 237 o share the same life-cycle as the Global Subscription; 239 o share the same Subscription ID as the Global Subscription. 241 5. Publication Composition 243 The Publisher Agent collects data and encapsulates the packets per 244 Component Subscription. The format and structure of the data records 245 are defined by the YANG schema, so that the decomposition at the 246 Receiver can benefit from the structured and hierarchical data 247 records. 249 The Receiver is able to associate the YANG data records with 250 Subscription ID [RFC8639] to the subscribed subscription and with 251 Message Generator ID [I-D.ietf-netconf-notification-messages] to one 252 of the Publisher Agents software processes to enable message 253 integrity. 255 For the dynamic subscription, the output of the "establish- 256 subscription" RPC defined in [RFC8639] MUST include a list of Message 257 Generator IDs to indicate how the Global Subscription is decomposed 258 into several Component Subscriptions. 260 The "subscription-started" and "subscription-modified" notification 261 defined in [RFC8639] MUST also include a list of Message Generator 262 IDs to notify the current Publishers for the corresponding Global 263 Subscription. 265 6. Subscription State Change Notifications 267 In addition to sending event records to Receivers, the Master MUST 268 also send subscription state change notifications [RFC8639] when 269 events related to subscription management have occurred. All the 270 subscription state change notifications MUST be delivered by the 271 Master. 273 When the subscription decomposition result changed, the 274 "subscription-modified" notification MUST be sent to indicate the new 275 list of Publishers. 277 7. Publisher Configurations 279 This document assumes that all Publisher Agents are preconfigured to 280 push data. The actual working Publisher Agents are selected based on 281 the subscription decomposition result. 283 All Publisher Agents share the same source IP address for data 284 export. For connectionless data transport such as UDP based 285 transport [I-D.unyte-netconf-udp-notif] the same Layer 4 source port 286 for data export can be used. For connection based data transport 287 such as HTTPS based transport [I-D.ietf-netconf-https-notif], each 288 Publisher Agent MUST be able to acknowledge packet retrieval from 289 Receivers, and therefore requires a dedicated Layer 4 source port per 290 software process. 292 The specific configuration on transports is described in the 293 resposible documents. 295 8. YANG Tree 297 module: ietf-distributed-notifications 298 augment /sn:subscriptions/sn:subscription: 299 +--ro message-generator-id* string 300 augment /sn:subscription-started: 301 +--ro message-generator-id* string 302 augment /sn:subscription-modified: 303 +--ro message-generator-id* string 304 augment /sn:establish-subscription/sn:output: 305 +--ro message-generator-id* string 307 9. YANG Module 309 file "ietf-distributed-notifications@2020-05-09.yang" 310 module ietf-distributed-notif { 311 yang-version 1.1; 312 namespace 313 "urn:ietf:params:xml:ns:yang:ietf-distributed-notifications"; 314 prefix mso; 315 import ietf-subscribed-notifications { 316 prefix sn; 317 } 319 organization "IETF NETCONF (Network Configuration) Working Group"; 320 contact 321 "WG Web: 322 WG List: 324 Editor: Tianran Zhou 325 327 Editor: Guangying Zheng 328 "; 330 description 331 "Defines augmentation for ietf-subscribed-notifications to 332 enable the distributed publication with single subscription. 334 Copyright (c) 2018 IETF Trust and the persons identified as 335 authors of the code. All rights reserved. 337 Redistribution and use in source and binary forms, with or 338 without modification, is permitted pursuant to, and subject to 339 the license terms contained in, the Simplified BSD License set 340 forth in Section 4.c of the IETF Trust's Legal Provisions 341 Relating to IETF Documents 342 (https://trustee.ietf.org/license-info). 344 This version of this YANG module is part of RFC XXXX; see the 345 RFC itself for full legal notices."; 347 revision 2020-05-09 { 348 description 349 "Initial version"; 350 reference 351 "RFC XXXX: Subscription to Distributed Notifications"; 352 } 354 grouping message-generator-ids { 355 description 356 "Provides a reusable list of message-generator-ids."; 358 leaf-list message-generator-id { 359 type string; 360 config false; 361 ordered-by user; 362 description 363 "Software process which created the message (e.g., 364 processor 1 on linecard 1). This field is 365 used to notify the collector the working originator."; 366 } 367 } 369 augment "/sn:subscriptions/sn:subscription" { 370 description 371 "This augmentation allows the message generators to be 372 exposed for a subscription."; 374 uses message-generator-ids; 375 } 377 augment "/sn:subscription-started" { 378 description 379 "This augmentation allows MSO specific parameters to be 380 exposed for a subscription."; 382 uses message-generator-ids; 383 } 385 augment "/sn:subscription-modified" { 386 description 387 "This augmentation allows MSO specific parameters to be 388 exposed for a subscription."; 390 uses message-generator-ids; 391 } 393 augment "/sn:establish-subscription/sn:output" { 394 description 395 "This augmentation allows MSO specific parameters to be 396 exposed for a subscription."; 398 uses message-generator-ids; 399 } 400 } 401 403 10. IANA Considerations 405 This document registers the following namespace URI in the IETF XML 406 Registry [RFC3688]: 408 URI: urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications 410 Registrant Contact: The IESG. 412 XML: N/A; the requested URI is an XML namespace. 414 This document registers the following YANG module in the YANG Module 415 Names registry [RFC3688]: 417 Name: ietf-subscribed-notifications 419 Namespace: urn:ietf:params:xml:ns:yang:ietf-subscribed- 420 notifications 422 Prefix: mso 424 Reference: RFC XXXX 426 11. Security Considerations 428 The YANG module specified in this document defines a schema for data 429 that is designed to be accessed via network management protocols such 430 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 431 is the secure transport layer, and the mandatory-to-implement secure 432 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 433 is HTTPS, and the mandatory-to-implement secure transport is TLS 434 [RFC5246]. 436 The NETCONF Access Control Model (NACM) [RFC6536] provides the means 437 to restrict access for particular NETCONF or RESTCONF users to a 438 preconfigured subset of all available NETCONF or RESTCONF protocol 439 operations and content. 441 The new data nodes introduced in this YANG module may be considered 442 sensitive or vulnerable in some network environments. It is thus 443 important to control read access (e.g., via get-config or 444 notification) to this data nodes. These are the subtrees and data 445 nodes and their sensitivity/vulnerability: 447 o /subscriptions/subscription/message-generator-ids 449 The entries in the two lists above will show where subscribed 450 resources might be located on the publishers. Access control MUST be 451 set so that only someone with proper access permissions has the 452 ability to access this resource. 454 Other Security Considerations is the same as those discussed in YANG- 455 Push [RFC8641]. 457 12. Contributors 459 Alexander Clemm 460 Futurewai 461 2330 Central Expressway 462 Santa Clara 463 California 464 United States of America 465 Email: ludwig@clemm.org 467 13. Acknowledgements 469 We thank Kent Watsen, Mahesh Jethanandani, Martin Bjorklund, Tim 470 Carey and Qin Wu for their constructive suggestions for improving 471 this document. 473 14. References 475 14.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 483 DOI 10.17487/RFC3688, January 2004, 484 . 486 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 487 (TLS) Protocol Version 1.2", RFC 5246, 488 DOI 10.17487/RFC5246, August 2008, 489 . 491 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 492 and A. Bierman, Ed., "Network Configuration Protocol 493 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 494 . 496 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 497 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 498 . 500 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 501 Protocol (NETCONF) Access Control Model", RFC 6536, 502 DOI 10.17487/RFC6536, March 2012, 503 . 505 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 506 for Subscription to YANG Datastores", RFC 7923, 507 DOI 10.17487/RFC7923, June 2016, 508 . 510 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 511 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 512 . 514 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 515 E., and A. Tripathy, "Subscription to YANG Notifications", 516 RFC 8639, DOI 10.17487/RFC8639, September 2019, 517 . 519 [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications 520 for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, 521 September 2019, . 523 14.2. Informative References 525 [I-D.ietf-netconf-https-notif] 526 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 527 for Configured Subscriptions", draft-ietf-netconf-https- 528 notif-02 (work in progress), March 2020. 530 [I-D.ietf-netconf-notification-messages] 531 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 532 Clemm, "Notification Message Headers and Bundles", draft- 533 ietf-netconf-notification-messages-08 (work in progress), 534 November 2019. 536 [I-D.unyte-netconf-udp-notif] 537 Zhou, T., Zheng, G., Lucente, P., Graf, T., and P. 538 Francois, "UDP-based Transport for Configured 539 Subscriptions", draft-unyte-netconf-udp-notif-00 (work in 540 progress), July 2020. 542 Appendix A. Examples 544 This appendix is non-normative. 546 A.1. Dynamic Subscription 548 Figure 3 shows a typical dynamic subscription to the device with 549 distributed data export capability. 551 +-------------+ +-------------+ +-------------+ 552 | Subscriber/ | | Publisher | | Publisher | 553 | Receiver | | (Master) | | (Agent) | 554 +-------------+ +------+------+ +------+------+ 555 | | | 556 | establish-subscription | | 557 +------------------------------>+ component | 558 | | subscription | 559 | RPC Reply: OK, id #22 +-------------->+ 560 | message generator ID [#1, #2] | | 561 +<------------------------------+ | 562 | | | 563 | notif-mesg, id #22 | | 564 | message generator ID #1 | | 565 +<------------------------------+ | 566 | | | 567 | notif-mesg, id#22 | | 568 | message generator ID #2 | | 569 +<----------------------------------------------+ 570 | | | 571 | modify-subscription (id#22) | | 572 +------------------------------>+ component | 573 | | subscription | 574 | RPC Reply: OK, id #22 +-------------->+ 575 +<------------------------------+ | 576 | | | 577 | subscription-modified, id#22 | | 578 | message generator ID [#1] | | 579 +<------------------------------+ | 580 | | | 581 | notif-mesg, id #22 | | 582 | message generator ID #1 | | 583 +<------------------------------+ | 584 | | | 585 | | | 586 + + + 588 Fig. 3 Call Flow for Dynamic Subscription 590 A "establish-subscription" RPC request as per [RFC8641] is sent to 591 the Master with a successful response. An example of using NETCONF: 593 595 598 600 ds:operational 601 602 604 /ex:foo 605 606 607 500 608 609 610 612 Fig. 4 "establish-subscription" Request 614 As the device is able to fully satisfy the request, the request is 615 given a subscription ID of 22. The response as in Figure 5 indicates 616 that the subscription is decomposed into two component subscriptions 617 which will be published by two message generators: #1 and #2. 619 621 623 22 624 625 631 2 632 633 635 Fig. 5 "establish-subscription" Positive RPC Response 637 Then, both Publishers send notifications with the corresponding piece 638 of data to the Receiver. 640 The subscriber may invoke the "modify-subscription" RPC for a 641 subscription it previously established. The RPC has no difference to 642 the single publisher case as in [RFC8641]. Figure 6 provides an 643 example where a subscriber attempts to modify the period and 644 datastore XPath filter of a subscription using NETCONF. 646 648 652 22 653 655 ds:operational 656 657 659 /ex:bar 660 661 662 250 663 664 665 667 Fig. 6 "modify-subscription" Request 669 If the modification is successfully accepted, the "subscription- 670 modified" subscription state notification is sent to the subscriber 671 by the Master. The notification, Figure 7 for example, indicates the 672 modified subscription is decomposed into one component subscription 673 which will be published by message generator #1. 675 676 2007-09-01T10:00:00Z 677 680 22 681 683 ds:operational 684 685 687 /ex:bar 688 689 690 250 691 692 736 2007-09-01T10:00:00Z 737 740 39 741 743 ds:operational 744 745 747 /ex:foo 748 749 750 250 751 752 758 2 759 760 761 763 Fig. 9 "subscription-started" Subscription State Notification 765 Then, both Publishers send notifications with the corresponding data 766 record to the Receiver. 768 Authors' Addresses 770 Tianran Zhou 771 Huawei 772 156 Beiqing Rd., Haidian District 773 Beijing 774 China 776 Email: zhoutianran@huawei.com 777 Guangying Zheng 778 Huawei 779 101 Yu-Hua-Tai Software Road 780 Nanjing, Jiangsu 781 China 783 Email: zhengguangying@huawei.com 785 Eric Voit 786 Cisco Systems 787 United States of America 789 Email: evoit@cisco.com 791 Thomas Graf 792 Swisscom 793 Binzring 17 794 Zuerich 8045 795 Switzerland 797 Email: thomas.graf@swisscom.com 799 Pierre Francois 800 INSA-Lyon 801 Lyon 802 France 804 Email: pierre.francois@insa-lyon.fr