idnits 2.17.1 draft-hares-netconf-i2rs-netconf-01.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 171 has weird spacing: '...tastore are c...' == Line 354 has weird spacing: '... source name...' == Line 357 has weird spacing: '... filter this...' -- The document date (March 12, 2017) is 2603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7921' is mentioned on line 1085, but not defined == Missing Reference: 'RFC6241' is mentioned on line 1043, but not defined == Missing Reference: 'RFC7950' is mentioned on line 1100, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1015, but not defined == Missing Reference: 'RFC7920' is mentioned on line 1080, but not defined == Missing Reference: 'RFC7922' is mentioned on line 1090, but not defined == Missing Reference: 'RFC7923' is mentioned on line 1095, but not defined == Missing Reference: 'RFC7803' is mentioned on line 1071, but not defined == Missing Reference: 'RFC6536' is mentioned on line 1056, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC7589' is mentioned on line 1065, but not defined == Missing Reference: 'RFC7895' is mentioned on line 1076, but not defined ** Obsolete undefined reference: RFC 7895 (Obsoleted by RFC 8525) == Missing Reference: 'RFC4107' is mentioned on line 1020, but not defined == Missing Reference: 'RFC4960' is mentioned on line 1024, but not defined ** Obsolete undefined reference: RFC 4960 (Obsoleted by RFC 9260) == Missing Reference: 'RFC5339' is mentioned on line 1028, but not defined == Missing Reference: 'RFC5424' is mentioned on line 1034, but not defined == Missing Reference: 'RFC6020' is mentioned on line 1038, but not defined == Missing Reference: 'RFC6242' is mentioned on line 1048, but not defined == Missing Reference: 'RFC6244' is mentioned on line 1052, but not defined == Missing Reference: 'RFC7158' is mentioned on line 1061, but not defined ** Obsolete undefined reference: RFC 7158 (Obsoleted by RFC 7159) == Missing Reference: 'RFC7952' is mentioned on line 1104, but not defined == Missing Reference: 'RFC7958' is mentioned on line 1108, but not defined == Unused Reference: 'I-D.ietf-i2rs-rib-data-model' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 1137, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l3-topology' is defined on line 1147, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-schema-mount' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-syslog-model' is defined on line 1217, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-07 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-10 == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-03 == Outdated reference: A later version (-16) exists of draft-ietf-i2rs-yang-l3-topology-08 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-00 == Outdated reference: A later version (-22) exists of draft-ietf-netconf-netconf-event-notifications-01 == Outdated reference: A later version (-09) exists of draft-ietf-netconf-rfc6536bis-00 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-01 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-05 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-12 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-00 == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-04 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-12 Summary: 4 errors (**), 0 flaws (~~), 43 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational A. Dass 5 Expires: September 13, 2017 Ericsson 6 March 12, 2017 8 NETCONF Changes to Support I2RS Protocol 9 draft-hares-netconf-i2rs-netconf-01.txt 11 Abstract 13 This document describes a NETCONF capabiilty to support the Interface 14 to Routing system (I2RS) protocol requirements for I2RS protocol 15 version 1. The I2RS protocol is a re-use higher layer protocol which 16 defines extensions to other protocols (NETCONF and RESTCONf) and 17 extensions to the Yang Data Modeling language. 19 The I2RS protocol supports ephemeral state datastores as control 20 plane datastores. Initial versions of this document contain 21 descriptions of the ephemeral datastore. Future versions may move 22 this description to NETMOD datastore description documents. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions Related to Ephemeral Configuration . . . . . . . 3 60 2.1. Requirements language . . . . . . . . . . . . . . . . . . 4 61 2.2. I2RS Definitions . . . . . . . . . . . . . . . . . . . . 4 62 3. Requirements control-plane datstore and ephemeral 63 capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. I2RS protocol requirements . . . . . . . . . . . . . . . 5 65 3.2. Overview of NETCONF support for I2RS protocol 66 requirements . . . . . . . . . . . . . . . . . . . . . . 5 67 4. NETCONF capability for control-plane datastore . . . . . . . 5 68 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Capability identifier . . . . . . . . . . . . . . . . . . 8 71 4.4. New Operations . . . . . . . . . . . . . . . . . . . . . 8 72 4.4.1. . . . . . . . . . . . . . . . . . . . . . 8 73 4.4.2. and ), but use a priority scheme 267 to handle multiple clients attempting to write the same data. The 268 default validation within a control plane datastore's config objects 269 (e.g. config=TRUE) is the configuration datastore validation, but if 270 Yang data modules specify different validation for the datastore or 271 specific nodes then the control plane datastores will use this 272 validation. 274 Some data modules may be used for both a control plane datastore and 275 the configuration datastore. If additional validation is used for 276 these modules, it is recommend that these modules use the "rpc" 277 function for the additional validation rather than the 278 functions. 280 4.2. Dependencies 282 The following are the dependencies for the :control-plane capability 284 o Yang features: 286 * [I-D.ietf-netmod-revised-datastores] functionality including 287 the ietf-yang-architecture" data module. 289 * [I-D.hares-netmod-i2rs-yang] Yang additions related to 290 datastores definitions related to control plane datastores 291 (datastoredef, datastore, dstype, precedence, protosup, 292 validation), and ephemeral state. 294 o The following NETCONF features: 296 * NETCONF [RFC6241] with its updates [RFC7803], 298 * Network Access Control Model [RFC6536] with update by 299 [I-D.ietf-netconf-rfc6536bis] 301 * Running NETCONF over TLS with mutually X.509 authentication 302 [RFC7589] 304 * Keystore Model [I-D.ietf-netconf-keystore], 306 * Subscribing to Yang Datastore updates 307 [I-D.ietf-netconf-yang-push], 309 * NETCONF support for Event Notifications 310 [I-D.ietf-netconf-netconf-event-notifications], 312 * Subscribing to NETCONF Events (updated) 313 [I-D.ietf-netconf-rfc5277bis] 315 * Yang Patch Media type [I-D.ietf-netconf-yang-patch], 317 * NETCONF/RESTCONF Zero Touch provisioning 318 [I-D.ietf-netconf-zerotouch], 320 * TLS Client and Server Models 321 [I-D.ietf-netconf-tls-client-server] 323 * Call Home [I-D.ietf-netconf-call-home], 325 * Module library [RFC7895], 326 * NETCONF/RESTCONF Zero Touch provisioning 327 [I-D.ietf-netconf-zerotouch], 329 4.3. Capability identifier 331 The controlplane-datastore capability is identified by the following 332 capability string: (:control-plane (uri-tbd)) where the uri-tbd is to 333 be assigned by IANA. 335 4.4. New Operations 337 The following are additional protocol operations NETCONF [RFC6241] to 338 support the following queries based on a datastore source/target 339 datastore being specified: 341 o "get-data" 343 o "write-data" 345 o "validate-data" 347 The must be registered with IANA. 349 4.4.1. 351 The get-data command has obtains configuration and operational data. 352 The parameters the following: 354 source name of the datastore being queried. The valid names are 355 "applied", "opstate", or a datstore name registered with IANA. 357 filter this identifies the portions of the device configuration 358 datastore is to receive. If this parameter is not present, the 359 entire datastore is returned. The filter MAY support subtypes 360 "subtree", "uri", and "xpath" capabilities described in [RFC6241]. 361 Filters may also include the elements for state (E.g. config true, 362 config false, ephemeral true; ephemeral false;). 364 Positive Response If the device was able to satify the request, an 365 is sent. The section contains the appropriate 366 subset. 368 Negative Response If the device was unable to satify the request, 369 an is included in the 371 Example - retrieve route1 in route list. 372 wfrom control plane datastore (cp-alpha) 373 and gets both configuration and ephemeral data. 375 377 379 380 381 382 384 385 1 386 388 389 391 393 395 396 397 398 400 401 1 402 192.2/8 /16 403 129.1.5.1 404 Eth0 405 true 406 408 409 411 Figure 1 413 Example 2 - retrieve users subtree from the ephemeral database 414 which has example control plane datastore (cp-alpha) 415 and gets only config=true data; 417 419 421 422 423 424 426 427 1 428 431 432 434 436 438 439 440 441 443 444 1 445 192.2/8 /16 446 129.1.5.1 447 Eth0 448 450 451 453 Figure 2 - get config data 455 4.4.2. or parameters if the 488 :url capability is set. An XPATH is accepted within the or 489 parameters if the :xpath capability is set. 491 4.4.2.2. defaults 493 The following are the defaults: 495 o The target datastore does not exists, it will be created if local 496 support exists. Otherwise, the reply will indicate "non-supported 497 datastore". 499 o If no sub-operations is specified the sub-operation, the default 500 is merge. 502 o If no priority parameter is specified, the priority will be set to 503 1 (lowest external priority). 505 o If error-option is not set, then the default is "stop-on-error". 506 (Note: for I2RS WG input. Is "stop-on-error" the same as "none"? 507 ) 509 o If no test-option parameter is set, the write data operates as a 510 'set" without validation first. 512 o if no secondary-identifier is given, the secondary identifier 513 stored is "" indicating a null string. 515 The NETCONF priority for the "write data" function is simply the 516 Netconf priority range. If implementations have an internal 517 priority, the precedence between the local configuration and the 518 NETCONF supplied configuration is set by a operator applied knob. 519 For example, an implementation could indicate that the local 520 configuration priority can range from 0-10 and the NETCONF priority 521 is 10 plus the value of the priority parameter. 523 4.4.2.3. target 525 The target is a datastore whose name is registered with IANA. 527 Example Write data 529 dsname = i2rs-agent 531 533 534 535 merge 536 50< 537 all-or-nothing 538 539 541 542 1 543 192.2/8 /16 544 129.1.5.1 545 Eth0 546 548 549 551 4.4.2.4. write data operations attributes 553 The description of each operation is below: 555 (config, opstate) : the creation of the data node in the 556 datatstore if and only if the data does not already exist in the 557 target datastore. If the data already exists, then an 558 is return wtih an error tag of "data-exists". Failure information 559 or Success informatnoi is also pass to the notification functions 560 (events and traceability). 562 (config, opstate) : the creation of the 563 datastore based on datastructures in the config and opstate 564 parameters. The datastore ownership is set to client creating the 565 datastore plus the priority. 567 (config) : the deletion of the data node if the data node 568 exists in the configuration and either the same client deletes the 569 node or a client with a high priority deletes the node. If 570 configuration data does not exist in the datastore, then the element is returned with a with value of "data- 572 missing". The error information is passed to the notification 573 functions to be sent as event or (optionally) placed in a tracing 574 file. 576 Delete all configuration and operational data 577 configured into the datastore, and the delete the datastore. The 578 client requesting a delete-store must either be the owner of the 579 datastore or have a higher priority than the client that owns the 580 datastore. If a higher priority client takes ownership, the lower 581 priority client is notified. If the devices is able to satisfy 582 request, the positive response is that includes 583 element. If the device is unable to complete request, the that includes element. The operations results 585 are forwarded to event and traceabilty functions. 587 If the datastore does not exist, it creates the 588 datastore and copies the configuration values and opstate values 589 into the datastore. The ownership information (client identity 590 and priority) is saved as part of the datastore. If the datastore 591 does exist and the client with ownership of the datastore changes 592 it, then the client can replace all the datastore nodes. If a 593 different client with lower priority than the client having 594 ownership wants to change the datastore, the request is rejected. 595 If a client with higher priority than the client having ownership, 596 then the the owership changed to the new client, all the data in 597 the datastore is deleted, all new data uploaded (config and 598 opstate nodes). If a server is able to satisfy request, the 599 positive response is that includes element. If 600 the server is unable to complete request, the that 601 includes element. The operational results are 602 forwarded to event and traceabilty functions. If a copy-datastore 603 action is in progress, and a client with a higher priority asks to 604 copy-datastore, the original 606 (config) : parameter specifies merge. If the (config, opstate) : the remove of the data node if the data 616 nodes specified in the or the node exist. If 617 data nodes do not exist, the "remove" operation is silently 618 ignored and error results are forwarded to traceabilty functions. 620 (config) : replaces data in target if the same client 621 replaces the top-level node, priority is ignored. If a different 622 client replaces the note, the priority must be higher than the top 623 level node's priority. If any data is replaced, this event is 624 passed to the notification function (events and traceability), and 625 a notification is sent to the previous client setting this data 626 that the data has been reset. If the request to replace is reject 627 due to the current top-level node having a higher priority, then 628 an returns with an error tag of "insufficient- 629 priority". If the node is replace by a different client, the 630 original client is notified of the change. 632 (opstate) : resets opstate nodes with counters to initial 633 settings. 635 4.4.2.5. 637 The priority parameter sets a integer value for the priority as shown 638 in figure x. 640 4.4.2.6. 642 The parameter performs basic function it does in the 643 basic function. Just in [RFC6241], the 644 parameter MAY be specified only if the device advertises the 645 ":validate:1.1" capability. The only difference is that the 646 validation specified by the data model may augment the validation 647 test and the valdiation will also include the ability of the client 648 to set this element. If a validation error occurs, the test-then-set 649 will not perform the write-data function. 651 4.4.2.7. parameter 653 has the following attributes 655 stop-on-error : Abort the write-data on the first error. This is 656 the default. 658 msg-rollback-on-error : if an error condition occurs such that error 659 serverity is generated, the server will stop 660 processing the write-data operation and restore the specific 661 configuratoin to its complete state at the start of the "write- 662 data" operation. This option only processes roll-back on single 663 messages which includes 665 * if multiple operations occur in single message, error in one 666 operation (E.g. read data) must not impact other operations 667 (write-data); 669 * multiple operations in multiple message should be supported, 670 but roll-back should only include a single message. 672 This option requires the server to support the :rollback-on-error 673 capability. 675 4.4.2.8. secondary-id 677 This operation associates a secondary identifier with a set of write- 678 data operations. The secondary identifier is an opaque string. 680 4.5. Modification to protocol operations 682 4.5.1. Unsupported protocol operations 684 The following protocol operations are not supported in the control 685 plane datastore: 687 o , 689 o , 691 o , 693 o , 694 o , 696 o 698 4.5.2. Modified protocol operations 700 4.5.2.1. and 702 The is modified to take a target of a control plane 703 datastore name (registered with IANA). Since no locks are set, none 704 should be released. 706 The is modified to take a target of a control plane 707 datastore name (registered with IANA). Since no locks are set, none 708 should be released. 710 4.6. Interactions with Capabilities 712 4.6.1. Unsupported Capabiltiies 714 The following capabilities are not supported: 716 writeable-running capability, 718 candidate configuration capability, 720 confirmed commit capability, 722 distinct startup capbility, 724 4.6.2. Modified Capabilities 726 4.6.2.1. rollback-on-error 728 The rollback-on-error allows the error handling to be roll-back-on- 729 error (all-or-nothing in I2RS terms) for the control plane datastore. 730 The control plane datastore name is a valid target if the rollback- 731 on-error capability is combined with the control plane datastore 732 capability. 734 4.6.2.2. validate 736 The validation capability engated with the control plane capability 737 operates to validate the config portion of the control plane 738 datastore. Therefore, the is allowed to have a datstore 739 name which is registered with IANA. 741 The validation of the configuration portion may contain the 742 "validation" yang command which provides alternative validation 743 mechanisms for specific data objects. 745 4.6.2.3. URL capability and XPATH capability 747 The URL capabilities specify a in the and 748 operate as normal, but are allowed to specify a module within a 749 control plane datastore. 751 5. NETCONF Ephemeral capability 753 capability-name: control-plane 755 5.1. Overview 757 The ephemeral capability is the ability to support control plane 758 datastores which are entirely ephemeral or have ephemeral state 759 modules, or ephemeral statements within objects in a modules. These 760 objects can be configuration state (config=TRUE) or operational state 761 (config=FALSE). 763 Ephemeral state in datastores, ephemeral modules or ephemeral objects 764 within a module have one key characteristics: the data does not 765 persist across reboots. The ephemeral configuration state must be 766 restored by a client, and the operational state will need to be 767 regenerated. 769 The entire requirements for ephemeral state for the I2RS control 770 plane protocol are listed in [I-D.ietf-i2rs-ephemeral-state]. Many 771 of these require fulfilled by the NETCONF control-plane 772 capabilty(Ephemeral-REQ-07, Ephemeral-REQ-11, Ephemeral-REQ-12, 773 Ephemeral-REQ-13, Ephemeral-REQ-14, Ephemeral-REQ-16). 775 The key features include: 777 o references between (to/from) ephemeral state and non-ephemeral 778 state for constraints purposes (see Ephemeral-REQ-02, Ephemeral- 779 REQ-03, and Ephemeral-REQ-04 in [I-D.ietf-i2rs-ephemeral-state]). 781 o operations to set and modify the constraints on the amount of 782 resources the I2RS Agent (aka NETCONF server) can consume 783 (Ephemeral-REQ-05) 785 o Yang modules must identify Yang objects (modules, submodules or 786 objects within yang modules which are ephemeral and augment other 787 nodes) and allow an "ephemeral=TRUE" feature. 789 5.2. Dependencies 791 Ephemeral state is not supported in the configuration datstore. The 792 ephemeral state capability depends on having the control-plane 793 datastore capability enabled (with appropriate NETCONF capabilities 794 described above), and an IANA registered datastore name. 796 Yang must support the ability to to denote that a datastore, module, 797 submodule or object within a module can be denoted as ephemeral. 798 This capbility depends on the yang additions described in 799 [I-D.hares-netmod-i2rs-yang] for control plane datastores, ephemeral 800 key word, and validation key word. 802 Ephemeral state operation depends on notification of events and 803 traceability of errors. I2RS ephemeral state requires that 805 5.3. New Operations 807 Note: One operation that is suggested for ephemeral state is to set 808 resource limits. It does not seem to be an ephemeral state issue, 809 but a control plane issue. This feature is placed here until future 810 discussion for I2RS WG. 812 5.3.1. resource-limits 814 resource-limits 816 definition - TBD 818 The [I-D.ietf-i2rs-ephemeral-state] suggests setting these limits, 819 but it does not seem to be an ephemeral function. 821 5.4. Modifications to Protocol Operations 823 5.4.1. Unsupported Operations 825 The ephemeral state only works as an augment to the control-plane 826 datastore. Therefore, the following protocol operations, which are 827 not supported in the control-plane datastore capability, are also not 828 supported in the ephemeral capability: 830 o , 832 o , 834 o , 836 o , 837 o , 839 o 841 5.4.2. Modified Operations 843 The ephemeral state only works as an augment to the control-plane 844 datastore with specific ephemeral validations. Therefore, the 845 and are modified as described in the 846 sections below. 848 5.4.2.1. Modifications 850 The is modified to take a target of a control plane 851 datastore name (registered with IANA). Since no locks are set, none 852 should be released. 854 5.4.2.2. Modifications 856 The is modified to take a target of a control plane 857 datastore name (registered with IANA). Since no locks are set, none 858 should be released. 860 5.4.2.3. Modifications 862 The ephemeral state may require validation to determine if the 863 constraints obey ephemeral-state rules. If the :validate capability 864 is used, the following parameter requires ephemeral-state contraints 865 (Ephemeral-REQ-02, Ephemeral-REQ-03, and Ephemeral-REQ-04). If the 866 ephemeral-constraint parameter is engaged for a module or object that 867 is not ephemeral, the parameter is silently ignored. Error 868 information is forwarded to the event notification processes and the 869 traceability functions. 871 Additional Parameter 873 ephemeral-constraint 875 6. Yang model Simple Ephemeral Data model 877 datastoredef cp-alpha { 878 dstype control-plane; 879 description { 880 "example control plane datastore "; 881 } 882 module-list tiny-rt-instance; 883 precedence applied { 884 precedenceval 5; 886 } 887 precedence opstate { 888 precedenceval 5; 889 } 890 } 892 datastoredef cp-beta { 893 dstype control-plane i2rs-v0; 894 description { 895 "example control plane datastore "; 896 } 897 module-list tiny-rib; 898 ephemeral true; 899 precedence applied { 900 precedenceval 50; 901 } 902 precedence opstate { 903 precedenceval 50; 904 } 905 } 906 module cp-example-1 { 907 namespace "http://exaple.com/schema/cp-examples/1.1/tiny-rib"; 908 prefix trib; 909 import ietf-inet-types { 910 prefix inet; 911 } 912 import ietf-yang-types { 913 prefix yang; 914 } 916 grouping trib-rt { 917 description "tiny rib route"; 918 leaf route-index { 919 type uint64; 920 mandatory true; 921 description "route index"; 922 } 923 leaf v4-prefix-match { 924 type inet:ipv4-prefix; 925 mandatory true; 926 } 927 leaf v4-nexthop { 928 type inet:ipv4 929 mandatory true; 930 } 931 leaf if-outgoing { 932 type if:interface-ref; 933 mandatory true; 934 description { 935 "Name of outgoing interface"; 936 } 937 leaf installed { 938 type boolean; 939 config false; 940 description "rt install status "; 941 } 942 } 943 container tiny-rt-instance { 944 description 945 "Tiny routing instance for 946 example purposes"; 947 leaf name { 948 type string; 949 description 950 "The name of routing instance 951 which must be unique. "; 952 } 953 list route-list { 954 key "route-index"; 955 description 956 "a list of routes of rib" 957 uses trib-rt; 958 } 959 } 961 rpc trib-add { 962 description "add route to tiny rib"; 963 input { 964 leaf datastore { 965 type string; //iana registered 966 mandatory true; 967 description 968 "iana datastore name"; 969 } 970 container trib-routes { 971 description 972 "Tiny rib routes to be added 973 to tiny rib"; 974 list route-list { 975 key "route-index"; 976 users trib-rt; 977 } 978 } 979 } 980 output { 981 container trib-add-status { 982 leaf success { 983 type boolean; 984 description "add succeded"; 985 } 986 leaf failure-reason { 987 type string; 988 description "reason for failure "; 989 } 990 } 991 } 992 } 994 7. IANA Considerations 996 TBD 998 8. Security Considerations 1000 The security requirements for the I2RS protocol are covered in 1001 [I-D.ietf-i2rs-protocol-security-requirements]. The security 1002 environment the I2RS protocol is covered in 1003 [I-D.ietf-i2rs-security-environment-reqs]. Any person implementing 1004 or deploying the I2RS protocol should consider both security 1005 requirements. 1007 9. Acknowledgements 1009 TBD 1011 10. References 1013 10.1. Normative References: 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, 1017 DOI 10.17487/RFC2119, March 1997, 1018 . 1020 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1021 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 1022 June 2005, . 1024 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 1025 RFC 4960, DOI 10.17487/RFC4960, September 2007, 1026 . 1028 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 1029 of Existing GMPLS Protocols against Multi-Layer and Multi- 1030 Region Networks (MLN/MRN)", RFC 5339, 1031 DOI 10.17487/RFC5339, September 2008, 1032 . 1034 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 1035 DOI 10.17487/RFC5424, March 2009, 1036 . 1038 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1039 the Network Configuration Protocol (NETCONF)", RFC 6020, 1040 DOI 10.17487/RFC6020, October 2010, 1041 . 1043 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1044 and A. Bierman, Ed., "Network Configuration Protocol 1045 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1046 . 1048 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1049 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1050 . 1052 [RFC6244] Shafer, P., "An Architecture for Network Management Using 1053 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 1054 2011, . 1056 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 1057 Protocol (NETCONF) Access Control Model", RFC 6536, 1058 DOI 10.17487/RFC6536, March 2012, 1059 . 1061 [RFC7158] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1062 Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March 1063 2014, . 1065 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1066 NETCONF Protocol over Transport Layer Security (TLS) with 1067 Mutual X.509 Authentication", RFC 7589, 1068 DOI 10.17487/RFC7589, June 2015, 1069 . 1071 [RFC7803] Leiba, B., "Changing the Registration Policy for the 1072 NETCONF Capability URNs Registry", BCP 203, RFC 7803, 1073 DOI 10.17487/RFC7803, February 2016, 1074 . 1076 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1077 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1078 . 1080 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 1081 Statement for the Interface to the Routing System", 1082 RFC 7920, DOI 10.17487/RFC7920, June 2016, 1083 . 1085 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1086 Nadeau, "An Architecture for the Interface to the Routing 1087 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1088 . 1090 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 1091 the Routing System (I2RS) Traceability: Framework and 1092 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 1093 2016, . 1095 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 1096 for Subscription to YANG Datastores", RFC 7923, 1097 DOI 10.17487/RFC7923, June 2016, 1098 . 1100 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1101 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1102 . 1104 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 1105 RFC 7952, DOI 10.17487/RFC7952, August 2016, 1106 . 1108 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 1109 "DNSSEC Trust Anchor Publication for the Root Zone", 1110 RFC 7958, DOI 10.17487/RFC7958, August 2016, 1111 . 1113 10.2. Informative References 1115 [I-D.hares-netmod-i2rs-yang] 1116 Hares, S. and a. amit.dass@ericsson.com, "Yang for I2RS 1117 Protocol", draft-hares-netmod-i2rs-yang-04 (work in 1118 progress), March 2017. 1120 [I-D.ietf-i2rs-ephemeral-state] 1121 Haas, J. and S. Hares, "I2RS Ephemeral State 1122 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 1123 progress), November 2016. 1125 [I-D.ietf-i2rs-protocol-security-requirements] 1126 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1127 Related Requirements", draft-ietf-i2rs-protocol-security- 1128 requirements-17 (work in progress), September 2016. 1130 [I-D.ietf-i2rs-rib-data-model] 1131 Wang, L., Ananthakrishnan, H., Chen, M., 1132 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 1133 YANG Data Model for Routing Information Base (RIB)", 1134 draft-ietf-i2rs-rib-data-model-07 (work in progress), 1135 January 2017. 1137 [I-D.ietf-i2rs-rib-info-model] 1138 Bahadur, N., Kini, S., and J. Medved, "Routing Information 1139 Base Info Model", draft-ietf-i2rs-rib-info-model-10 (work 1140 in progress), December 2016. 1142 [I-D.ietf-i2rs-security-environment-reqs] 1143 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 1144 Security Requirements", draft-ietf-i2rs-security- 1145 environment-reqs-03 (work in progress), March 2017. 1147 [I-D.ietf-i2rs-yang-l3-topology] 1148 Clemm, A., Medved, J., Varga, R., Liu, X., 1149 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 1150 for Layer 3 Topologies", draft-ietf-i2rs-yang- 1151 l3-topology-08 (work in progress), January 2017. 1153 [I-D.ietf-netconf-call-home] 1154 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 1155 draft-ietf-netconf-call-home-17 (work in progress), 1156 December 2015. 1158 [I-D.ietf-netconf-keystore] 1159 Watsen, K. and G. Wu, "Keystore Model", draft-ietf- 1160 netconf-keystore-00 (work in progress), October 2016. 1162 [I-D.ietf-netconf-netconf-event-notifications] 1163 Prieto, A., Clemm, A., Voit, E., Nilsen-Nygaard, E., 1164 Tripathy, A., Chisholm, S., and H. Trevino, "NETCONF 1165 Support for Event Notifications", draft-ietf-netconf- 1166 netconf-event-notifications-01 (work in progress), October 1167 2016. 1169 [I-D.ietf-netconf-restconf] 1170 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1171 Protocol", draft-ietf-netconf-restconf-18 (work in 1172 progress), October 2016. 1174 [I-D.ietf-netconf-rfc5277bis] 1175 Clemm, A., Prieto, A., Voit, E., Nilsen-Nygaard, E., 1176 Tripathy, A., Chisholm, S., and H. Trevino, "Subscribing 1177 to Event Notifications", draft-ietf-netconf-rfc5277bis-01 1178 (work in progress), October 2016. 1180 [I-D.ietf-netconf-rfc6536bis] 1181 Bierman, A. and M. Bjorklund, "Network Configuration 1182 Protocol (NETCONF) Access Control Model", draft-ietf- 1183 netconf-rfc6536bis-00 (work in progress), January 2017. 1185 [I-D.ietf-netconf-tls-client-server] 1186 Watsen, K., "TLS Client and Server Models", draft-ietf- 1187 netconf-tls-client-server-01 (work in progress), November 1188 2016. 1190 [I-D.ietf-netconf-yang-patch] 1191 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 1192 Media Type", draft-ietf-netconf-yang-patch-14 (work in 1193 progress), November 2016. 1195 [I-D.ietf-netconf-yang-push] 1196 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 1197 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 1198 YANG datastore push updates", draft-ietf-netconf-yang- 1199 push-05 (work in progress), March 2017. 1201 [I-D.ietf-netconf-zerotouch] 1202 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 1203 for NETCONF or RESTCONF based Management", draft-ietf- 1204 netconf-zerotouch-12 (work in progress), January 2017. 1206 [I-D.ietf-netmod-revised-datastores] 1207 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1208 and R. Wilton, "A Revised Conceptual Model for YANG 1209 Datastores", draft-ietf-netmod-revised-datastores-00 (work 1210 in progress), December 2016. 1212 [I-D.ietf-netmod-schema-mount] 1213 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 1214 ietf-netmod-schema-mount-04 (work in progress), March 1215 2017. 1217 [I-D.ietf-netmod-syslog-model] 1218 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 1219 Configuration", draft-ietf-netmod-syslog-model-12 (work in 1220 progress), February 2017. 1222 Authors' Addresses 1224 Susan Hares 1225 Huawei 1226 Saline 1227 US 1229 Email: shares@ndzh.com 1231 Amit Daas 1232 Ericsson 1234 Email: amit.dass@ericsson.com