idnits 2.17.1 draft-scharf-alto-yang-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 215 has weird spacing: '...ilities capa...' -- The document date (July 4, 2014) is 3577 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) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-01 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-yang-json-00 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-10 == Outdated reference: A later version (-10) exists of draft-randriamasy-alto-multi-cost-07 == Outdated reference: A later version (-03) exists of draft-roome-alto-pid-properties-02 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG M. Scharf 3 Internet-Draft Alcatel-Lucent Bell Labs 4 Intended status: Standards Track July 4, 2014 5 Expires: January 5, 2015 7 ALTO Extension for YANG Modules 8 draft-scharf-alto-yang-00 10 Abstract 12 The Application-Layer Traffic Optimization (ALTO) protocol is 13 designed to expose network topology information to applications. The 14 ALTO protocol includes a well-defined set of base services. This 15 document specifies an optional ALTO extension that enables ALTO 16 clients to discover and query additional data being defined by YANG 17 modules. This document describes the corresponding extensions of the 18 ALTO Information Resource Directory and other required mechanisms. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 5, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. ALTO Network Topology Exposure vs. Network Configuration . . 3 57 4. Benefits of Using YANG Data Models . . . . . . . . . . . . . 4 58 5. Extending ALTO to Support YANG Modules . . . . . . . . . . . 5 59 5.1. ALTO Information Resource Directory . . . . . . . . . . . 5 60 5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 6 61 5.3. YANG Data Model Assumptions . . . . . . . . . . . . . . . 6 62 5.4. Media Type . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.5. Accessing the URI . . . . . . . . . . . . . . . . . . . . 7 64 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The Application-Layer Traffic Optimization (ALTO) protocol 76 [I-D.ietf-alto-protocol] is designed to expose network topology 77 information to applications. The ALTO Information Resource Directory 78 (IRD) of an ALTO server describes the services supported by an ALTO 79 server and corresponding attributes. As defined in 80 [I-D.ietf-alto-protocol], each information resource has several 81 associated attributes, including an assigned identifier, a response 82 format, capabilities, accepted input parameters, and other resources 83 that it may depend on. Prior to obtaining ALTO guidance, ALTO client 84 may retrieve the Information Resource Directory from the ALTO server 85 to determine the attributes of individual information resources that 86 this ALTO Server provides. 88 The ALTO protocol is designed to be extensible, and several protocols 89 extensions have been suggested, including for instance 90 [I-D.roome-alto-pid-properties] or [I-D.randriamasy-alto-multi-cost]. 91 In addition to such extensions of the ALTO protocol, an ALTO server 92 may be willing to offer additional network information and guidance 93 beyond the base functionality of the ALTO protocol. In this case, 94 one option is to specify the offered guidance using YANG [RFC6020] as 95 data modeling language. 97 This document specifies an optional ALTO extension that enables ALTO 98 clients to discover and query additional data offered by an ALTO 99 server, being defined by YANG modules. This document describes the 100 corresponding extensions of the ALTO Information Resource Directory 101 and other required mechanisms. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. ALTO Network Topology Exposure vs. Network Configuration 111 ALTO is designed as a protocol between clients integrated in 112 applications and servers that provide network information and 113 guidance (e.g., basic network location structure and preferences of 114 network paths). The objective is to modify network resource 115 consumption patterns at application level while maintaining or 116 improving application performance. The basic information of ALTO is 117 based on an abstract representation of the network as it matters to 118 applications at endpoints. 120 Given the focus on topology exposure to guidance, there are several 121 differences between ALTO and other protocols used for network 122 management, such as SNMP [RFC3411] or NETCONF [RFC6241]: 124 o Specialization: ALTO is an optimized protocol focused on exposing 125 network topology data. This is different to general-purpose 126 protocols. 128 o Read-only: ALTO is a query/response protocol to retrieve data. 129 Neither ALTO network/cost map queries nor queries to the ALTO 130 endpoint property or cost services are designed to affect state in 131 the ALTO server or in the ALTO client. Network management 132 protocols are typically designed to manipulate the configuration 133 of network devices. 135 o Trust model: The ALTO protocol has been designed for use cases 136 where the ALTO server and client can be located in different 137 organizations or trust domains. Network configuration will 138 require a much stronger security model. 140 o Non-NMS applications: ALTO is designed for applications that 141 perform resource selections among endpoints, e.g., in an 142 application overlay. Such applications are typically not part of 143 an Element Management System (EMS) or Network Management System 144 (NMS). 146 o A priori knowledge: ALTO does not assume that an ALTO client has 147 any a priori knowledge about the ALTO server and its supported 148 features. An ALTO server can be discovered automatically. In 149 network management, there is often a need for explicit 150 configuration, e.g., of security credentials. 152 o Terminology: In ALTO, the application is running a client, while 153 the network offers a service by means of a server. SNMP would use 154 the terms manager and agent for these entities, and NETCONF may 155 use the terms server and client in the opposite way. This 156 reflects the different usage patterns. 158 These aspects are also detailed in [I-D.ietf-alto-deployments]. 160 The same differences also apply to control plane protocols designed 161 to configure state on network elements, such as components of a Path 162 Computation Element (PCE) architecture or an Interface to the Routing 163 System (I2RS). 165 4. Benefits of Using YANG Data Models 167 Despite different use cases, ALTO clients could use a limited set of 168 functions originally designed for network management, including 169 protocol functions for read-only retrieval of data. For instance, an 170 ALTO server may use network monitoring data or Operations, 171 Administration, and Maintenance (OAM) measurement results as data 172 sources [I-D.ietf-alto-deployments], and that data could originate 173 from Network Management Systems (NMS). If permitted by privacy 174 policies, an ALTO server could be willing to optionally expose such 175 input data used by the ALTO service to ALTO clients. 177 In that case, a straightforward solution is to transform that input 178 data into a format supported by ALTO, e.g., network and cost maps 179 with additional cost metrics. Yet, if the ALTO server already 180 queries data specified in YANG [RFC6020], it could optionally also 181 expose that data to ALTO clients, provided that the aforementioned 182 restrictions are taken into account. 184 Support of YANG modules would be a simple way for an ALTO server to 185 offer optional, additional services, e.g., to access monitoring data. 186 A data model described in YANG could enable an ALTO client to easily 187 determine the type of additional data exposed by ALTO, since a YANG 188 module specifies the corresponding syntax. 190 As a specific example, an ALTO server may have access to interface 191 statistics for endpoints in the network, using the YANG module "ietf- 192 interfaces" [RFC7223], and it may use these statistics to e.g. to 193 calculate network and cost maps. If an ALTO client would 194 specifically be interested in counter metrics such as "out-errors", 195 the ALTO server could obviously expose this by ALTO, e.g., as several 196 cost maps or as an endpoint/PID property 197 [I-D.roome-alto-pid-properties]. An alternative approach would be 198 that the ALTO server natively exposes that data in a YANG-based 199 format. This requires a solution to support YANG modules in ALTO. 201 5. Extending ALTO to Support YANG Modules 203 This section specifies how an ALTO server can announce the support of 204 additional, optional services defined by YANG modules. 206 5.1. ALTO Information Resource Directory 208 According [I-D.ietf-alto-protocol], objects in the ALTO Information 209 Resource Directory (IRD) have the following format: 211 object { 212 JSONString uri; 213 JSONString media-type; 214 [JSONString accepts;] 215 [Capabilities capabilities;] 216 [ResourceID uses<0..*>;] 217 } IRDResourceEntry; 219 The extension in this document use this format and defines the 220 following setting of these objects: 222 o uri: A URI at which the data is provided. This can both be an URI 223 at the ALTO server, or it can delegate to another server 224 (Section 9.2.4 of [I-D.ietf-alto-protocol]). This extension uses 225 the URI to refer to data described in YANG modules. 227 o media-type: The media type that is to be used by GET (or POST) 228 requests to the corresponding URI. This is further detailed 229 below. 231 o accepts: This optional parameter can also be set if required, as 232 described in [I-D.ietf-alto-protocol]. 234 o capabilities: Capabilities are optional. A server MAY announce 235 the use of YANG as data modeling language for certain resources as 236 a capability ("yang" : true), if this is not already implied by 237 the media-type. Further capabilities might be used to describe 238 the YANG modules, but this is TBD. 240 o uses: The setting of this parameter is for further study. 241 According to [I-D.ietf-alto-protocol], this setting can be used to 242 define other resources on which this resource directly depends. 243 As a result, it could for instance be used to refer to ALTO cost 244 maps that are related to the data described in this resource 245 refering to YANG modules. 247 An example of a corresponding ALTO Information Resource Directory 248 entry would be: 250 ... 251 "my-own-map-data" : { 252 "uri" : 253 "http://alto.example.com/restconf/data/my-own-map-data", 254 "media-type" : "application/yang.data+json", 255 "capabilities" : { 256 "yang" : true 257 } 258 }, 259 ... 261 5.2. JSON Encoding 263 The ALTO protocol uses a REST-ful design and encodes its requests and 264 responses using JSON [RFC4627]. Therefore, all data returned using 265 this specification MUST be encoded in JSON. 267 [I-D.ietf-netmod-yang-json] defines rules for representing data 268 defined using YANG as JSON text. 270 5.3. YANG Data Model Assumptions 272 YANG can model configuration data as well as state data. The latter 273 is marked by the "config false" statement [RFC6020]. State data on a 274 system is no configuration data and cannot be changed, such as read- 275 only status information and collected statistics. When a node in a 276 YANG module is tagged with "config false", its sub-hierarchy is 277 flagged as state data as well. 279 Since ALTO only offers read-only access to information, this document 280 implicitly assumes that the URI announced by an ALTO server only 281 exposes read-only data. This document only describes how an ALTO 282 client can discover the URI for additional data and learn now to 283 retrieve data by a REST protocol from there; the actual communication 284 and interpretation of data is outside the scope of this document. 286 Read-only access can trivially be enforced if an ALTO server using 287 the mechanism in this document only use YANG modules that contain 288 state data only, i.e., all containers, lists, and leafs etc. are be 289 covered by "config false" statements. Alternatively, there could be 290 ways to ensure read-only access, e.g., by appropriate selection of 291 the URI. 293 Any write access by a client using the information in the ALTO IRD is 294 outside the scope of this memo. 296 This document does not cover notifications. The handling of 297 "notifications" in a YANG module is therefore outside the scope of 298 the document. 300 The handling of "rpc" statements in a YANG module is for further 301 study. 303 5.4. Media Type 305 This document does not register additional media types. An ALTO 306 client SHOULD use the media type(s) defined in the ALTO IRD to access 307 the URI, as detailed in the next section. 309 An example media type could be "application/yang.data+json" as 310 defined in [I-D.ietf-netconf-restconf]. 312 5.5. Accessing the URI 314 The way to retrieve data from the URI returned by the ALTO IRD 315 depends on the media type. An ALTO client can determine from the 316 media type whether it supports the method and whether optional data 317 from an ALTO server can be retrieved. This document describes an 318 optional ALTO extension and does not mandate that an ALTO client 319 supports any specific protocol. 321 One approach to retrieve additional data described by a YANG model 322 would be RESTCONF [I-D.ietf-netconf-restconf]. In this case, the 323 ALTO IRD is basically used as a discovery mechanism for corresponding 324 RESTCONF URIs. For RESTCONF, the syntax of the URI, as well as the 325 protocol for data retrieval is defined in 326 [I-D.ietf-netconf-restconf]. For instance, a valid URI would be 327 "http://alto.example.com/restconf/data/my-own-map-data", and a 328 corresponding media type could be "application/yang.api". If the URI 329 points to the RESTCONF root, the client could also use other APIs as 330 defined in [I-D.ietf-netconf-restconf], e.g., to retrieve the YANG 331 module definition file. The latter would enable an ALTO client to 332 dynamically learn the YANG module definitions. 334 In a simpler variant, an ALTO server would just return the complete 335 tree of state data encoded in JSON [I-D.ietf-netmod-yang-json]. This 336 could be sufficient for extensions equivalent to the current ALTO 337 network and cost map services without filtering, which always return 338 all available data without fine-grained query access. Details of 339 this mode are for further study. 341 6. Example 343 In the following, we illustrate the mechanism described in this 344 document with a simple example. 346 The initial query of an ALTO client to an ALTO server's IRD could be: 348 GET /directory HTTP/1.1 349 Host: alto.example.com 350 Accept: application/alto-directory+json, 351 application/alto-error+json 353 The server would then return the supported ALTO services, including 354 the one specified in this document: 356 HTTP/1.1 200 OK 357 Content-Length: TBD 358 Content-Type: application/alto-directory+json 360 { 361 "meta" : { 362 ... 363 }, 364 "resources" : { 365 ... 366 "my-own-map-data" : { 367 "uri" : 368 "http://alto.example.com/restconf/data/my-own-map-data", 369 "media-type" : "application/yang.data+json", 370 "capabilities" : { 371 "yang" : true 372 } 373 }, 374 ... 375 } 376 } 378 Since the media type refers to [I-D.ietf-netconf-restconf], a follow- 379 up query of the ALTO client supporting this protocol could be: 381 GET /restconf/data/my-own-map-data HTTP/1.1 382 Host: alto.example.com 383 Accept: application/yang.data+json 385 The response of the server is outside the scope of this document and 386 depends on the YANG data model accessed by that URI. For instance, 387 assume the following trivial model of an extension just giving a 388 convenient list of the PIDs currently used by the ALTO server: 390 module my-own-map-data { 391 ... 392 container my-own-map-data { 393 config false; 394 list pid-list { 395 key pid; 396 leaf pid { 397 type string; 398 } 399 } 400 } 401 ... 402 } 404 Then, the server response could be: 406 HTTP/1.1 200 OK 407 Content-Length: TBD 408 Content-Type: application/yang.data+json 410 { 411 "my-own-map-data" : { 412 "pid-list" : [ 413 { 414 "pid" : "PID1", 415 }, 416 { 417 "pid" : "PID2", 418 }, 419 ... 420 { 421 "pid" : "PID9", 422 } 423 ] 424 } 425 } 427 This is a trivial example, but the same principle is applicable to 428 any YANG module. Obviously, an ALTO client has to support processing 429 of the corresponding YANG module (or modules) to make use of this 430 extension. 432 7. IANA Considerations 434 TBD 436 8. Security Considerations 438 This document descibes read-only access to data optionally announced 439 by an ALTO server. The security considerations of the ALTO protocol 440 as detailed in [I-D.ietf-alto-protocol] and 441 [I-D.ietf-alto-deployments] apply to the ALTO extension in this 442 document. Specifically, the operator of an ALTO server has to ensure 443 that there is no unauthorized access to sensitive data. This 444 extension should not be used if there are privacy concerns. 446 9. Conclusion 448 TBD 450 10. References 452 10.1. Normative References 454 [I-D.ietf-alto-protocol] 455 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 456 ietf-alto-protocol-27 (work in progress), March 2014. 458 [I-D.ietf-netconf-restconf] 459 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 460 "RESTCONF Protocol", draft-ietf-netconf-restconf-01 (work 461 in progress), July 2014. 463 [I-D.ietf-netmod-yang-json] 464 Lhotka, L., "JSON Encoding of Data Modeled with YANG", 465 draft-ietf-netmod-yang-json-00 (work in progress), April 466 2014. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC4627] Crockford, D., "The application/json Media Type for 472 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 474 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 475 Network Configuration Protocol (NETCONF)", RFC 6020, 476 October 2010. 478 10.2. Informative References 480 [I-D.ietf-alto-deployments] 481 Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, 482 "ALTO Deployment Considerations", draft-ietf-alto- 483 deployments-10 (work in progress), July 2014. 485 [I-D.randriamasy-alto-multi-cost] 486 Randriamasy, S., Roome, B., and N. Schwan, "Multi-Cost 487 ALTO", draft-randriamasy-alto-multi-cost-07 (work in 488 progress), October 2012. 490 [I-D.roome-alto-pid-properties] 491 Roome, W. and Y. Yang, "PID Property Extension for ALTO 492 Protocol", draft-roome-alto-pid-properties-02 (work in 493 progress), July 2014. 495 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 496 Architecture for Describing Simple Network Management 497 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 498 December 2002. 500 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 501 Bierman, "Network Configuration Protocol (NETCONF)", RFC 502 6241, June 2011. 504 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 505 Management", RFC 7223, May 2014. 507 Author's Address 509 Michael Scharf 510 Alcatel-Lucent Bell Labs 511 Lorenzstrasse 10 512 Stuttgart 70435 513 Germany 515 Email: michael.scharf@alcatel-lucent.com