idnits 2.17.1 draft-rfernando-i2rs-yang-mods-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 : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 24 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC6020]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 594 has weird spacing: '...ntainer a-non...' -- The document date (February 15, 2013) is 4082 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 6020' is mentioned on line 14, but not defined == Missing Reference: 'RFC6020' is mentioned on line 100, but not defined == Missing Reference: 'RFC2119' is mentioned on line 155, but not defined == Missing Reference: 'RFC 6536' is mentioned on line 526, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Unused Reference: 'IRS-FRMWK' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'IRS-FRMWK-REQ' is defined on line 920, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ward-irs-framework (ref. 'IRS-FRMWK') ** Downref: Normative reference to an Informational draft: draft-rfernando-irs-framework-requirement (ref. 'IRS-FRMWK-REQ') Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Fernando 3 Intended Status: Proposed Standard P. Chinnakannan 4 Expires: August 19, 2013 M. Madhayyan 5 A. Clemm 6 February 15, 2013 8 YANG modifications for I2RS 9 draft-rfernando-i2rs-yang-mods-00 11 Abstract 13 Interface to Routing Systems (I2RS) provides the mechanisms for the 14 programmatic access of routing system components. YANG [RFC 6020] is 15 a modeling language that is used to specify an external visible data 16 model of sub-system - for defining both configuration and operational 17 data held in the networking device. NETCONF is the protocol that is 18 used to perform these configurations and accessing the operational 19 data. 21 This document proposes to use the YANG data modeling language for 22 I2RS data models. It also proposes a set of YANG language changes to 23 enable the I2RS data models for multi-client and programmatic access. 25 This document also proposes the scope for the I2RS programmed data 26 set on the Routing System and the necessary mechanisms for data 27 synchronization. 29 This document also recommends a binary encoding for "on-the-wire" 30 transfer of the YANG data model elements instead of XML. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as 40 Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2 I2RS Components . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.2 I2RS components . . . . . . . . . . . . . . . . . . . . . . 4 75 3 I2RS extensions to Yang . . . . . . . . . . . . . . . . . . . . 5 76 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2 Exclusive Owner I2RS . . . . . . . . . . . . . . . . . . . . 7 78 3.3 Canonical Client Name Identifier (cname) . . . . . . . . . . 11 79 3.4 Ephemeral data nodes . . . . . . . . . . . . . . . . . . . . 14 80 3.5 YANG module "ietf-i2rs-extensions.yang" . . . . . . . . . . 17 81 3.6 Client priority . . . . . . . . . . . . . . . . . . . . . . 19 82 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 21 83 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 84 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 6.1 Normative References . . . . . . . . . . . . . . . . . . . 21 86 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 88 1 Introduction 90 The Network Configuration Protocol (NETCONF) provides mechanisms to 91 programmatically install, manipulate, and delete the configuration of 92 network devices. It uses an Extensible Markup Language (XML)-based 93 data encoding for the configuration data as well as the protocol 94 messages. The NETCONF protocol uses a remote procedure call (RPC) 95 paradigm and protocol operations are performed on top of this simple 96 RPC layer. A client encodes an RPC in XML and sends it to a server 97 using a secure, connection-oriented session. The server responds 98 with a reply encoded in XML. 100 YANG is the NETCONF Data Modeling Language [RFC6020], which supports 101 hierarchical modeling of data elements that represent the 102 configuration and runtime state of a particular network element. 104 The elements defined by the YANG module can be used for NETCONF-based 105 communication, including passing configuration and state data, remote 106 procedure calls (RPCs), and notifications. Thus YANG allows one to 107 completely describe all the data sent between a NETCONF client and 108 server. 110 YANG models the hierarchical organization of data as a tree in which 111 each node has a name and a value or a set of child nodes. It provides 112 clear and concise descriptions of the nodes, as well the inter- 113 relationship between those nodes. 115 Interface to routing system (I2RS) framework is a draft proposal that 116 sets out to build a framework to provide a common, standard interface 117 to allow programmatic access to the information maintained in a 118 router, like the routing protocol states, statistics, Routing 119 Information Base (RIB) states, interface and their states etc. 121 Fundamental to the I2RS is a clear data model that defines the 122 semantics of the information that can be written and read. This 123 document proposes the use of Yang to define I2RS data models. It 124 further proposes a set of YANG language extensions in order satisfy 125 all the requirements of I2RS. 127 Specifically, this document makes the following proposal: 129 o That I2RS shall use YANG for defining the data models that are 130 applicable for I2RS. These models are termed 'I2RS data models' in 131 this document. 133 o A mechanism to express data ownership for a data set injected by 134 I2RS clients into a Routing System using the I2RS data models. 136 o A mechanism to express multi-client semantics and multi-client 137 operations in an I2RS data model. 139 o A mechanism to express the life time scope of programmatic data 140 injected by I2RS clients in a Routing System and to express them in 141 the I2RS data models. 143 The draft proposal for binary encoding for "on-the-wire" transfer of 144 the YANG data model elements instead of XML and the associated 145 NETCONF version2 is specified in a companion document (draft-tbd). 146 The extensions proposed in this document is independent of the other 147 changes proposed and will operate with or without the binary encoding 148 as well as NETCONF version 2. 150 1.1 Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2 I2RS Components 158 2.1 Overview 160 This section describes the roles performed by the different I2RS 161 components when YANG is used as the modeling language and NETCONF 162 used as the protocol. 164 2.2 I2RS components 166 An I2RS domain comprises of the following entities: 168 o A Routing System supporting the I2RS data models and interfaces. 170 o I2RS clients accessing and operating on the Routing systems using 171 the I2RS interface. 173 o I2RS servers present within a Routing system and providing the 174 interface into the I2RS services and associated data models. 176 o The NETCONF V2 Protocol that is used by the I2RS clients to access 177 the I2RS services provided by the I2RS servers using a binary 178 encoding format. 180 o The I2RS client admission and authorization control service, which 181 is co-located within the routing system. This function is provided by 182 an external service and this document recommends using NACM model 183 [RFC 6536]. 185 3 I2RS extensions to Yang 187 3.1 Overview 189 I2RS clients operate on the I2RS data models to obtain the services 190 provided by the Routing sub-systems. Client operations result in 191 creation, modification and deletion of data sets in the I2RS data 192 model tree, which is represented in YANG. 194 The data set injected by an I2RS client may be single valued, which 195 is modeled as a "leaf" object or multi-valued, which are modeled as 196 hierarchy of nodes using "containers", "lists", etc. The hierarchy of 197 nodes, termed as "data model sub tree" or simply "sub tree", is 198 conceptually owned by the I2RS client. 200 I2RS clients may access operational data and persistent configuration 201 data. In this, they are like applications that automate management 202 workflows. In addition, I2RS clients may inject ephemeral data. 203 Ephemeral data corresponds to data that installs state, but that 204 (unlike configuration data) is not persisted. 206 The ownership in this context requires identification of the I2RS 207 client that injected the data set and the exclusivity assurance that 208 the entire data set is injected and maintained by one client. 210 The exclusivity property guarantees that no other client shall modify 211 any data item in the data set injected by one I2RS client. This 212 concept of exclusivity assurance is proposed and described in section 213 3.2 Exclusive Owner, using the new YANG statement "exclusive-owner". 214 That said, while an I2RS client is not able to modify the data that 215 was injected by another client, it may able to view data injected by 216 other clients (assuming proper authorization). This is required so 217 that I2RS clients are able to understand the I2RS server's behavior. 219 In contrast, current NETCONF treats all data to be global, meaning 220 modification of data by one client is visible to all other clients 221 and can be modified by other clients as well. In short, NETCONF is 222 inherently designed for multi-owner datastores. Whether data items 223 can be modified or not depends on the intrinsic nature of the data 224 item (specified by 'config' statement). The proposed YANG extensions 225 allow establishing a concept of ownership to data that is based on 226 the extrinsic property of who created it, rather than solely based on 227 the intrinsic nature of the data item. The I2RS data models may be 228 operated upon by multiple I2RS clients or a NETCONF client or a 229 mixture of both types of clients. 231 I2RS also requires a uniform and consistent mechanism to identify the 232 client that had injected the data set for the entire data model or to 233 the subset of data model. This is required so that ownership of data 234 items can be tagged to the data item themselves. The YANG data model 235 language must provide a capability to express and capture the 236 identity of a data model client in uniform and consistent manner 237 across all data models. The data model client identifier must be a 238 canonical client name identifier whose value must reference an unique 239 client name record in a NETCONF access control model, NACM, [RFC 240 6536] database within the domain. Section, 3.4 Canonical Client Name 241 Identifier (cname) describes this capability through the canonical 242 client name, "cname" extension to YANG. 244 The I2RS clients operations on routing sub-systems results in 245 creation, modification and deletion of data elements that are 246 represented by the I2RS data models. The I2RS data models not only 247 provide the schema for the data set injected, but also indicate the 248 sections within the data model that are modifiable or editable by an 249 I2RS client. The term editable is used in this document to refer to 250 any IRS operation that leads to creation, modification or deletion of 251 data model elements. 253 The editable portions of a data model sub tree is indicated by the 254 YANG statement "config true", and any resulting data set through edit 255 operations are stored in a data store called the running 256 configuration data store. This data set is functionally permanent, in 257 the sense that this data set must be stored in a persistent data 258 store by the Routing System component and it is present across router 259 reboots. 261 However, in I2RS operations, one of the requirement is to allow the 262 i2rs clients to perform edit operations and the resulting data set is 263 not stored permanently. This data set is "ephemeral" and is lost once 264 a router reboots. This requirement is met using a new YANG extension 265 called "ephemeral true", which is described in section 3.5 Ephemeral 266 data nodes. 268 An I2RS client injects a set of data items under a sub tree within an 269 I2RS data model. The exclusivity assurance guarantees that no other 270 client will be able to modify any data item in the data set injected 271 by one I2RS client in a sub tree that is indicated through the YANG 272 statement "exclusive-owner". 274 It is possible for I2RS clients to attach data items marked as 275 "ephemeral" or "exclusive" as a subtree underneath another data node, 276 defined in an existing YANG data module. The fact that the I2RS 277 client injects data under an existing subtree MUST NOT affect the 278 behavior of this containing subtree. Specifically, the exclusivity 279 property MUST NOT prevent an item that was previously configurable, 280 from being locked for configuration purposes. If a container is 281 deleted, any I2RS client data attached below it is deleted along with 282 it. In practice, it is therefore RECOMMENDED that I2RS ephemeral data 283 is only attached below subtrees that are not subject to configuration 284 (e.g., data items representing an immutable property, such as the 285 system as a whole), or highly unlikely to change (e.g., data items 286 representing a physical interface). 288 Although 'exclusivity' and 'ephemeral' statements describe two 289 different characteristics, in practice they tend to apply to the same 290 set of data nodes. That said, the concept of exclusivity is 291 orthogonal to the concept of ephemeral data. This means that the 292 "exclusive" property can be applied to data nodes marked as "config 293 true" just as it can be applied to data nodes that are marked as 294 ephemeral. Applying an exclusivity concept to configuration data 295 implies the need to apply this concept across datastores (running, 296 startup, candidate etc). As noted before, NETCONF datastores are 297 essentially global and do not carry the notion of ownership to data. 299 3.2 Exclusive Owner I2RS 301 Currently NETCONF/YANG allows an instance of a sub tree, created by 302 one client, to be modified later by another client. A data model 303 primitive is required that disallows modifications to ephemeral data 304 elements under a sub tree created by one I2RS client by another I2RS 305 client. 307 This mechanism provides the guarantee that no other client shall 308 modify any data item in the data set injected by one I2RS client. 310 This draft specification proposes that a new YANG statement be 311 supported that defines a data node as "exclusive". The presence of 312 the statement indicates that the data node, and all its descendants, 313 is modifiable only by the client which created the instance. Other 314 clients can retrieve the data node, but cannot edit it or delete it. 315 They also cannot add any of their own data nodes below it. 317 There are several scenarios for applying exclusive ownership. The 318 following outlines some of them: 320 o Exclusive ownership shall apply for an entire list. This can be 321 visualized as multiple identical tables, with each table being owned 322 by one client. In this case, the YANG data model needs to be defined 323 such that the list is contained in a container. The exclusive 324 property is applied to that container. 326 o Exclusive ownership shall apply for a list element, but different 327 list elements can have different owners. This can be visualized as a 328 single table with multiple rows, with each row owned by a different 329 client. In this case, the exclusive property is applied at the level 330 of the definition of the list. 332 o Exclusive ownership shall apply only to a particular cell within a 333 list element. This can be visualized as a single table with one cell 334 of a row owned by a different clients. In this case, the exclusive 335 property is applied at the level of the definition of the data node 336 within the list. 338 The requirement for exclusive ownership is best illustrated with a 339 few examples. 341 In the first example, the exclusive property is applied to a 342 container within a list element. This means that within a list 343 element, the container and everything it contains can only be 344 modified by its owner. However, different list elements can have 345 different owners for the corresponding container. Also, data nodes 346 that are part of the same list element, but siblings of the 347 container, can be modified by other clients as well. 349 module i2rs-routing 350 { 352 imports ietf-i2rs-extensions { 353 prefix "ix"; 354 } 356 config true; 358 description "An i2rs-routing module that contains sub tree nodes 359 that are either single-owner or multi-owner. This example is for 360 illustration of the single owner data node that represents a 361 sub-section of cells in a row"; 363 list i2rs-route { 364 key "prefix"; 365 ..... 367 leaf prefix { 368 type inet:ip-prefix; 369 } 371 container i2rs-route-attributes { 372 ix:exclusive; 373 ix:ephemeral; 374 //This allows the name of the owning client 375 //to be returned as part of the instantiated 376 //information 377 uses ix:client; 379 description "The i2rs-route-attributes container contains 380 several properties of a route. Only the client that 381 originally created the container is allowed to modify or 382 delete the container and its contents."; 383 } 385 container i2rs-dont-care { 386 description "The i2rs-don't-care container contains 387 properties of a route that can be manipulated 388 by any client"; 389 } 390 } 391 } 393 In the second example, the exclusive property is applied to list 394 elements. Each list element has an exclusive owner. However, the 395 same list can contain many list elements, and different list elements 396 can have different exclusive owners. 398 module i2rs-routing 399 { 400 imports ietf-i2rs-extensions { 401 prefix "ix"; 402 } 404 config true; 406 description "An i2rs-routing module that contains sub tree 407 nodes that are either single-owner or multi-owner. This 408 example is for illustration of the single owner data node that 409 represents a single row within a table"; 411 list i2rs-route { 412 ix:exclusive; 413 ix:ephemeral; 414 key "prefix ix:cname"; 416 //This allows the name of the owning client 417 //to be returned as part of the instantiated 418 //information, and to be a part of the key 419 uses ix:client; 421 container i2rs-route-attributes { 422 description 423 "The i2rs-route-attributes container contains 424 several properties of a route. Each list element has 425 an exclusive owner. Only the client that created the 426 list element can edit or delete it. In case of 427 multiple list elements with the same prefix, the 428 element that is associated with the client of the 429 highest priority takes effect. "; 430 } 431 } 432 } 434 Note that in the above example, the client name ("ix:cname") is used 435 as a key. This allows two separate clients, distinguished by their 436 cname, to inject a list element of otherwise the same key. 438 Note furthermore that in this example, if there are multiple list 439 elements that have the same prefix as part of their index, only a 440 single list element (i.e. only a single route entry) for the same 441 prefix will be in effect. This is resolved by virtue of the owning 442 client's priority, as determined by the server. 444 This example addresses the following scenario: Consider two I2RS 445 clients, "sdn-app-A" and "sdn-app-b", operating on the above data 446 model and injecting routes. Both clients may inject the same prefix 447 "10.0.0.0/8" and will result into two separate data nodes in the 448 hosting routing system component. The data record introduced by the 449 I2RS client "sdn-app-A" is identified by the keys {10.0.0.0/8, "sdn- 450 app-A"}, which contains an instance of the container i2rs-route- 451 property and an instance of the container i2rs-don't-care. Likewise, 452 the data record introduced by the I2RS client "sdn-app-B" is 453 identified by the keys {10.0.0.0/8, "sdn-app-B"}. 455 It would have been possible to declare the same list without the 456 client name as a key. In that case, each list element still has its 457 own exclusive owner. However, two clients cannot own a list element 458 that otherwise has the same key. 460 In the third example, the exclusive property is applied to the entire 461 list. In this case, a container for the list is introduced and the 462 exclusive property applied at that level. 464 module i2rs-routing 465 { 466 imports ietf-i2rs-extensions { 467 prefix "ix"; 468 } 470 config true; 472 description "An i2rs-routing module that contains sub tree 473 nodes that are either single-owner or multi-owner. This 474 example is for illustration of the single owner data node that 475 represents a conceptual table"; 477 container i2rs-routes { 479 ix:exclusive; 480 ix:ephemeral; 481 uses ix:client; 483 description 484 "This container serves as the container of a list of 485 i2rs routes that has an exclusive owner. Only the 486 owner of this container can modify the list and any 487 list elements within it."; 489 list i2rs-route { 490 key "prefix"; 492 container i2rs-route-attributes { 493 description "The i2rs-route-attributes container 494 contains several properties of a route. "; 495 } 496 } 497 } 499 It should be noted that the concept of exclusive ownership pertains 500 only with regards to modification operations, not to retrieval 501 operations. Any client can retrieve data, even if it is exclusively 502 owned by another client. 504 3.3 Canonical Client Name Identifier (cname) 506 A routing system supports data models for different components within 507 the system which are known as I2RS data models in this specification. 508 The I2RS data models may be operated by multiple I2RS clients or a 509 single configuration NETCONF client or a mixture of both types of 510 clients. This programmatic access requires the concept of a client 511 and associated properties to be specified in the data model. A data 512 model requires a uniform and consistent methodology, and a mechanism 513 to identify the client that had injected the data set for the entire 514 data model or to the subset of the data model. The YANG data model 515 language must provide a capability to express and capture the 516 identity of a data model client in uniform and consistent manner 517 across all data models. 519 This specification proposes the following elements to meet with the 520 I2RS framework: 522 A new data type "cname" is introduced, used to identify the client 523 that owns a particular data node. 525 The data model client identifier value must reference a unique client 526 name record in a NETCONF access control model, [RFC 6536] database 527 within the domain. The NACM service within the domain shall be used 528 for specifying the client access privileges and other authentication, 529 authorization records. 531 A grouping, "client" is introduced which contains a client identifier 532 of cname type. The grouping may be used in conjunction with any data 533 nodes (e.g. containers or lists) whose data owner needs to be 534 identified. The client identifier is always provided by the server, 535 reflecting the client name as identified through NACM. 537 The client identifier may be used as key for identifying the client 538 in the data model sub tree sections that requires unambiguous 539 identity of the data owner. 541 This document specifies that I2RS data models use "cname" type to 542 specify the client identifier at required sections that are specified 543 using the "exclusive" keyword. 545 There are times when data provided by multiple clients need to be 546 maintained in a list with clear ownership of nodes maintained in the 547 list. For instance, next-hops for the same prefix could be provided 548 by multiple applications. 550 This type of data model construct can be achieved in two ways as 551 follows: 553 o Introducing an explicit YANG "list" node with a single key of the 554 type "cname" as a parent node for a data model sub tree that is a non 555 list type like containers, leaf-list, leaf etc. 557 o Introducing an additional key of the type "cname" for a data model 558 sub tree that is a YANG list. 560 module i2rs-routing { 562 imports ietf-i2rs-extensions { 563 prefix "ix"; 564 } 566 list i2rs-routing-client { 567 key "ix:cname"; 568 ix:exclusive; 570 description "The i2rs-routing-client is a list node 571 that provides the client identifier of the I2RS client 572 performing programmatic operation below this 573 sub tree in the data model"; 575 uses ix:client; 577 container i2rs-routing-table { 579 description "Routing table maintained per client"; 580 /* Contents not specified here*/ 581 } 582 } 583 } 585 The following code fragment demonstrates a I2RS programmatic sub tree 586 that is a list node. 588 module interfaces { 590 imports ietf-i2rs-extensions { 591 prefix "ix"; 592 } 594 container a-non-i2rs-container { 595 /* Contents not specified */ 596 } 598 list i2rs-routing-interface { 599 key "ix:cname if-name"; 600 ix:exclusive; 602 description "i2rs-routing-interface provides a list of i2rs 603 interfaces. The I2RS client identifier performing 604 programmatic access to the routing interfaces are identified 605 by the key client-id."; 607 uses ix:client; 609 leaf if-name { 610 type string; 612 description "The key field which is of the string type 613 that specifies the interface name"; 614 } 615 /* Other nodes not specified */ 616 } 617 } 619 3.4 Ephemeral data nodes 621 The I2RS clients operations on routing sub-systems results into 622 creation, modification and deletion of data elements that are 623 represented by the I2RS data models. The I2RS data models not only 624 provide the schema for the data set injected, but also indicate the 625 sections within the data model that are modifiable or editable by an 626 I2RS client. 628 The editable portions of a data model sub tree is indicated by the 629 YANG statement "config true", and any resulting data set through edit 630 operations are stored in a data store called the running 631 configuration data store. This data set is functionally permanent, in 632 the sense that this data set must be stored in a persistent data 633 store by the Routing System component and it is present across router 634 reboots. However, in Routing System operations a requirement is 635 present that must allow clients to perform edit operations and the 636 resulting data set is not stored permanently. This data set is 637 ephemeral and is present only for the duration in which the Router 638 System component is up and operational. This specification calls 639 this persistency nature of the I2RS client state data on the routing 640 system as ephemeral state and the data associated as ephemeral state 641 data. 643 NETCONF allow its clients to create, modify, and delete data model 644 elements expressed in YANG. This data created by NETCONF operations 645 is called as configuration data and is associated with a certain type 646 of data store called running configuration. The data present in the 647 running configuration data store is permanent and is present across 648 routing system reboots and is in contrast with the state data created 649 and maintained by I2RS clients. This requires a new YANG extension to 650 designate ephemeral state data. It must be noted that only sections 651 of the data model that use the YANG statement "config true" are 652 editable. Other sections of the data model that use the YANG 653 statement "config false" are not editable and these type of data are 654 called as operational data. Operational data is not associated with 655 any data store. I2RS clients need a third type of data which must be 656 editable, but not persistent across routing system component reboots 657 as well as not associated with any data store like the operational 658 data. 660 This specification proposes a new YANG statement called "ephemeral" 661 be supported which takes one argument that is a string with the value 662 that "true" or "false". A value of "true" indicates the inclusive 663 data node and all its sub tree is editable and remains persistent as 664 long as the routing system component is up and operational. Value of 665 'false' serves the same purpose of 'config false' i.e. to mark a 666 schema node as operational data. 668 The YANG statement "ephemeral true;" may be a specified at any node 669 of the data model tree and is inherited by all descendant nodes. 671 Ephemeral data cannot be part of a startup or candidate datastore. 672 It can only be part of a running datastore. 674 The following example shows a valid use of the "ephemeral" statement. 676 module i2rs-routing { 678 description "An i2rs-routing module with the root node of 679 designated as configurable for illustration purpose"; 681 container i2rs-routing-main-container { 683 config true; 685 container i2rs-section { 686 ix:ephemeral; 688 description "The node i2rs-section and its entire sub 689 tree is now made ephemeral. This indicates that this 690 node and all children of the container i2rs-section is 691 writable but not configurable any more. Any writes 692 made to this sub tree is not present in the running 693 configuration and is lost when the router reboots"; 694 } 696 container config-section { 697 config true; 698 description "The config-section node and its sub tree 699 is editable and is stored in the running config data 700 store. This sub tree is stored persistently across 701 reboots"; 702 } 704 container oper-section { 705 config false; 707 description "This is node and its sub tree is not 708 editable and is the operational data"; 709 } 711 container an-ephemeral-node { 712 ephemeral true; 714 container incorrect-config-node { 715 config true; 717 description "This node is marked incorrectly 718 as configurable and this is not permitted. A 719 descendant node of an ephemeral schema node cannot 720 be marked as 'config true'"; 721 } 722 } 723 } 724 } 726 The following example shows how a section of the ephemeral sub tree 727 can represent operational data. 729 module i2rs-routing { 730 description "An i2rs-routing module with the root node of 731 designated as configurable for illustration purpose"; 733 container i2rs-routing-main-container { 734 config true; 736 container another-ephemeral-node { 737 ix:ephemeral; 739 container an-intermediate-oper-node { 740 config false; 742 description "This node illustrates how an 743 ephemeral sub tree can have operational data."; 745 } 746 } 747 } 748 } 750 The following example shows in correct usage of the ephemeral 751 statement that would be flagged as error by the YANG compiler. 753 module i2rs-routing { 754 description "An i2rs-routing module with the root node of 755 designated as configurable for illustration purpose"; 757 container i2rs-routing-main-container { 758 config true; 760 container an-ephemeral-node { 761 ix:ephemeral; 763 container incorrect-config-node { 764 config true; 766 description "This node is marked incorrectly 767 as configurable and this is not permitted"; 768 } 769 } 771 container an-oper-node { 772 config false; 774 container an-errored-ephemeral-node { 775 ix:ephemeral; 777 description "This node is incorrect and will 778 not be accepted by the data model development 779 } 780 } 781 } 782 } 784 3.5 YANG module "ietf-i2rs-extensions.yang" 786 Yang module "ietf-i2rs-extensions" contains a set of definitions 787 needed by clients that intend to inject ephemeral state into a 788 device. Specifically, this module defines the following: 790 o A YANG extension that allows to declare the "ephemeral" clause 792 o A YANG extension that allows to declare the "exclusive" clause 793 o A grouping to be used in conjunction with data nodes that use the 794 ephemeral clause. This grouping contains node to identify the owning 795 control client and that client's priority. 797 o A set of management information containing a registry of control 798 clients, expiration timers, and operational status (TBD) 800 file "ietf-i2rs-extensions.yang" 802 module ietf-i2rs-extensions { 804 namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-extensions "; 806 prefix "i2rs-extn"; 808 imports nacm { 809 prefix nacm; 810 } 812 organization 813 "example.com"; 815 contact 816 "tbd"; 818 description 819 "This module contains YANG extensions that would be needed to 820 model i2rs specific data models."; 822 revision "2013-02-14"; 824 extension ephemeral { 825 description 826 "This extension can be used on schema nodes to indicate that 827 those data nodes and their descendant nodes do not survive 828 device reload." 830 argument access-specifier { 831 yin-element true; 832 }; 833 } 835 extension exclusive { 836 description 837 "This extension can be used on schema nodes to indicate that 838 those data nodes and their descendant nodes can be created by 839 and written to by only one i2rs client. Other clients may have 840 have read-only access to those data node.; 841 } 843 typedef cname { 844 type leafref { 845 path "/nacm:nacm/nacm:groups/nacm:group/nacm:name"; 846 } 847 description 848 "Control client ID by which the client is authenticated by the 849 server. An object of this type is always populated by the 850 server, not by the invoking application."; 851 } 853 grouping client { 854 leaf cname { 855 config false; 856 type cname; 857 } 858 } 859 } 861 3.6 Client priority 863 Multiple I2RS clients can inject ephemeral state in a device. With 864 the exclusivity statement in the data model, the state injected by 865 multiple clients can all be maintained concurrently on the device. 867 Applications in the device that are interested in ephemeral state 868 injected by multiple clients can subscribe to receive notifications 869 and read from the data store. In some cases, I2RS clients can inject 870 conflicting information. For instance, we could have multiple I2RS 871 clients programming different next- hop for the same destination 872 prefix. 874 In some cases, the backend applications would need to prioritize one 875 entry over the other. To do so, we may need some mechanism to assign 876 a relative priority to each of the i2rs client. 878 The proposal is to assign a priority to each client in the NACM 879 database. In I2RS datamodels that use the 'cname', backend 880 applications can receive the priority setting along with the client- 881 id. 883 To set the priority for a NACM user, the proposal is to enhance the 884 NACM user-group entries with a priority setting. Here is the 885 corresponding YANG snippet, to be incorporated into a corresponding 886 YANG module: 888 augment /nacm:nacm/nacm:groups/nacm:group { 890 leaf priority { 891 type uint32; 893 description 894 "Relative priority setting of a user-group (to which a i2rs 895 client gets assigned to". 897 default 0; 898 } 899 } 901 Both the user-group and priority setting is passed to the backend 902 application if the data model uses the 'exclusive true' keyword. It 903 is entirely up to the backend application to act on this data. 905 4 Security Considerations 907 This draft does not change the security characteristics of YANG. 909 5 IANA Considerations 911 This draft does not have any IANA considerations. 913 6 References 915 6.1 Normative References 917 [IRS-FRMWK] A. Atlas, T. Nadeau, D. Ward, "Interface to the Routing 918 System Framework", draft-ward-irs-framework-00 920 [IRS-FRMWK-REQ] R. Fernando et al, "IRS Framework Requirements", 921 draft-rfernando-irs-framework-requirement-00 923 7 Authors' Addresses 925 Rex Fernando 926 Cisco Systems 927 170 Tasman Dr 928 San Jose 929 EMail: rex@cisco.com 931 Palani Chinnakannan 932 Cisco Systems 933 170 Tasman Dr 934 San Jose 935 EMail: pals@cisco.com 937 Muthumayan Madhayyan 938 Cisco Systems 939 170 Tasman Dr 940 San Jose 941 EMail: muthu@cisco.com 943 Alexander Clemm 944 Cisco Systems 945 170 Tasman Dr 946 San Jose 947 EMail: alex@cisco.com