idnits 2.17.1 draft-wbl-rtgwg-yang-ci-profile-bkgd-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2017) is 2576 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 622 -- Looks like a reference, but probably isn't: '2' on line 624 -- Looks like a reference, but probably isn't: '3' on line 626 -- Looks like a reference, but probably isn't: '4' on line 629 -- Looks like a reference, but probably isn't: '5' on line 631 -- Looks like a reference, but probably isn't: '6' on line 633 == Unused Reference: 'RFC2119' is defined on line 617, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. White 3 Internet-Draft D. Black 4 Intended status: Informational Dell EMC 5 Expires: September 9, 2017 J. Leung 6 Intel Corporation 7 March 9, 2017 9 YANG Baseline Switch Profile Background 10 draft-wbl-rtgwg-yang-ci-profile-bkgd-01 12 Abstract 14 A YANG device profile is primarily a group of YANG models that are 15 appropriate for use with a particular class of device or in specific 16 device roles. This document provides background and describes the 17 rationale for a baseline data center switch device profile, e.g., for 18 top-of-rack switches in data center converged infrastructure. This 19 rationale is based on the reuse of YANG models by the DMTF Redfish 20 standard for management of converged infrastructure, but the 21 resulting YANG device profile is intended to be useable by any YANG- 22 based network management approach or protocol, as opposed to being 23 specific to Redfish. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 1. Introduction 59 *Disclaimer* - this is a -00 draft, whose primary goal is to capture 60 the rationale for use of YANG for Redfish network management and the 61 desirability of a baseline data center network switch profile, 62 including providing technical background on the Redfish standard and 63 its approach to network management. The draft content is not 64 polished, and the organization of the material is likely to change. 66 A YANG device profile is primarily a group of YANG models that are 67 appropriate for use with a particular class of device or in specific 68 device roles. This document provides background and describes the 69 rationale for a baseline data center switch device profile, e.g., for 70 top-of-rack switches in data center converged infrastructure. The 71 rationale is based on the reuse of YANG models by the DMTF Redfish 72 standard for management of converged infrastructure, but the 73 resulting YANG device profile is intended to be useable by any YANG- 74 based network management approach or protocol; it is not intended to 75 be Redfish-specific. 77 In support of this rationale, this document provides background on 78 how YANG is used in the Redfish management framework; the YANG 79 modules are translated to Redfish schema definitions in order to 80 enable reuse of the models are with Redfish-defined management 81 protocols and related functionality. 83 2. Motivation 85 A common management framework with accompanying set of protocols and 86 device models is desirable in systems management use cases. A good 87 example of this is in a converged infrastructure deployment within a 88 data center. Applications, servers, storage, appliances, and 89 networking elements are assembled to create a combined coherent 90 platform. For the networking components in such an environment, 91 there are platform management elements that are common with other 92 types of systems such as thermal monitoring, physical enclosure, 93 fans, and power supplies, as well as networking specific management 94 elements to control the forwarding and filtering of network packets 95 or the networking services. The common elements should be accessed 96 and managed in a single way across all systems within the deployment. 98 Management, orchestration, and control of such a system benefits from 99 a single approach that enables unified tools sets and simplifies 100 operations. 102 The networking specific configuration within the converged 103 infrastructure environment only needs a subset of all the possible 104 networking protocols and services giving the converged controller 105 only the minimum spanning control surface in terms of the models it 106 can access. A breakdown of the needs of such a switch result in 107 about 5-10 YANG modules (see Appendix A). These 5-10 modules should 108 lead to common YANG-based data center network switch management 109 across vendors and products. 111 As a contrast, a full function edge router would need many more 112 protocols and services along with full function virtualization 113 resulting in the use of about 80 YANG modules. 115 2.1. Redfish Background 117 The DMTF (Distributed Management Task Force) Redfish standard is 118 becoming the common standard for converged infrastructure (CI) 119 management. Converged Infrastructure consists of rack-scale (partial 120 or full-rack) integrated compute, network and storage infrastructure 121 that is procured and deployed as rack scale systems. 123 Redfish data center storage management functionality has been 124 extended in partnership with SNIA (Storage Networking Industry 125 Association) resulting in the recently released Swordfish 126 specification that extends Redfish for networked storage and storage 127 network management. The authors hope to work with the IETF to extend 128 and align Redfish network management with IETF's YANG framework. 130 Redfish is a management standard using a data model representation 131 inside of a RESTful interface. The model is expressed in terms of a 132 standard, machine-readable schema, with the payload of the messages 133 being expressed in JSON. 135 Because it is a model-based API, Redfish is capable of representing a 136 variety of implementations via a consistent interface. It has 137 mechanisms for managing data center resources, handling events, long 138 lived tasks and discovery, as well. 140 In Redfish, every URL represents a resource. This could be a 141 service, a collection, an entity or some other construct. But in 142 RESTful terms, these URIs point to resources and Redfish clients 143 interact with these resources. For example, the content of a 144 resource, in JSON format, is returned when the Redfish client 145 performs a HTTP GET. 147 OData is an OASIS standard for expressing the schema of a JSON 148 document. OData allows a fuller description of the JSON document, 149 than json-schema. The format of OData schema is specified in CSDL 150 (Common Schema Definition Language). 152 OData also describes directives that can appear on the URI to control 153 the contents of the HTTP response. In Redfish, these directives 154 (i.e. $top and $skip) are stated as 'should'. Networking extension 155 may change the requirement to 'shall'. 157 Redfish releases include both OData and json-schema schema. With 158 json-schema, users can take advantage of its larger tool chain. 160 Additional information about OData can be found at the OData site 161 [1]. 163 Additional information about Redfish can be found at DMTF's Redfish 164 site [2]. Specifically, the Redfish White Paper [3] provides a good 165 overview. 167 2.2. YANG and Redfish 169 Within the networking world, YANG has become the preferred management 170 framework. YANG expresses each section of the overall model as a 171 module containing a tree of nodes where each node is either a 172 container node that builds the hierarchy or a leaf node containing 173 data elements for the model. Redfish network management leverages 174 YANG as the core model definition language to maintain consistency 175 with other YANG based network management approaches. Using a common 176 model structure results in equivalent data elements yielding the same 177 data or content when accessed via different interfaces or protocols. 179 Redfish's network management supports this consistency by reusing 180 YANG modules as Redfish models for network functionality and 181 services, mechanically translating those modules to the Redfish 182 interface, based on HTTP, JSON, and OData. 184 The Redfish approach to network management enables definitions of a 185 specific system views or profiles that are aligned with the 186 configuration functionality required in a specific scenario or for a 187 specific class of network devices. A particularly relevant example 188 is a baseline switch model description with a minimum set of model 189 elements; this is useful when configuring a switch within a larger 190 converged infrastructure system. The model elements of the baseline 191 switch should be the smallest set of models necessary to configure a 192 data center switch in a converged infrastructure environment; the 193 corresponding set of YANG modules would be a simple data center 194 network device profile. A more complex network router might need 195 tunnel models, overlay models, extensive QoS models, and other 196 elements. 198 The top level resource structure of Redfish is show below. 200 ./redfish/v1/Systems 201 ./redfish/v1/Chassis 202 ./redfish/v1/NetworkDevices 203 (other redfish resources) 205 Within this structure a network switch is viewed as a data center 206 element for its common subsystems such as chassis, power, thermal, 207 cooling, management access setup, etc while the network modeling is 208 specified within the instances of the NetworkDevices[] collection. 209 Each member of the NetworkDevices[] collection has implements its own 210 set translated YANG modules. For consistency, the set of modules 211 grouped under a NetworkDevice instance can follow one of multiple 212 standard groupings expressed as a profile to manage different classes 213 of equipment and satisfy different use cases. Two profile examples 214 are the basic switch and virtualized edge router. 216 2.3. YANG mapping to Redfish 218 The notion of schema is different in Redfish and YANG. 220 In YANG, a schema is device specific. The user determines the YANG 221 modules utilized by a system, and may consult a module library as 222 part of doing so (e.g., RFC7895 [4]). The YANG schema is realized as 223 a set of YANG modules, each with a prescribed node tree structure. 225 In Redfish, there is one schema that encompasses the entire 226 namespace. In other words, Redfish has a global namespace for its 227 schema, of which the device implements a subset. The Redfish schema 228 is realized as resources accessed via a URI, so the namespace 229 contains the information about which YANG modules are utilized. The 230 OData directives $expand and $filter allows the client to discovery 231 this directly from the parent namespace node above the modules. 233 That functionality obviates any Redfish need to use YANG module 234 combination techniques such as YANG Schema-mount [5]. 236 Despite these differences, the proposed profiles should be usable by 237 both YANG based protocols (e.g., NETCONF, RESTCONF) and Redfish, as 238 the core content of each profile is a set of YANG modules. 240 To allow Redfish to manage network devices, the YANG modules needs to 241 be translated into OData CSDL (Common Schema Definition Language). 242 The translation is specified in the YANG-to-Redfish Mapping 243 Specification [6]. The translation has the following 244 characteristics: 246 o Includes, imports, and augments, are compiled out to create a 247 single consistent schema block constituting a particular instance 248 of a NetworkDevice. 250 o The YANG node tree layout is reflected in the URI layout 252 o The individual YANG container nodes and list nodes are rendered as 253 resources with the YANG tree hierarchy reflected as navigation 254 properties. 256 Access to the YANG data model elements uses a Redfish JSON accessed 257 via a provider on the URI target. 259 Leaf nodes representing common back end system "features or elements" 260 return consistent data independent of node name and network device 261 hierarchy. 263 The NetworkDevices[] collection allows 265 o Multiple co-existing and consistent views onto a system. 267 * Horizontally extensible 269 * Vertical hierarchy allowing for control interface delegation 271 o This is similar to a "view class" or facade approach in software. 273 2.4. Example Mapping 275 The following shows the resource which results from mapping RFC7223 276 (ietf_interface module) to the Redfish schema. Below is a fragment 277 of the data model from the RFC. 279 +--rw interfaces 280 | +--rw interface* [name] 281 | +--rw name string 282 | +--rw description? string 283 | +--rw type identityref 284 | +--rw enabled? boolean 285 | +--rw link-up-down-trap-enable? enumeration 286 +--ro interfaces-state 287 +--ro interface* [name] 288 +--ro name string 289 +--ro type identityref 290 +--ro admin-status enumeration 291 The translation to Redfish CSDL is performed using the RFC's YANG 292 code. The translation will generate the CSDL files for the 293 ietf_interfaces resource and each YANG container. The path to these 294 resources mirror the above data model. 296 ./redfish/v1/NetworkDevices/Switch1 297 ./redfish/v1/NetworkDevices/Switch1/ietf_interfaces 298 ./redfish/v1/NetworkDevices/Switch1/ietf_interfaces/interfaces 299 ./redfish/v1/NetworkDevices/Switch1/ietf_interfaces/interfaces/ethernet1 300 ./redfish/v1/NetworkDevices/Switch1/ietf_interfaces/interfaces_state 301 ... 303 A HTTP GET of the "ethernet1" singleton resource will return the 304 following JSON document. Note that each property from the above data 305 model is present in the resource. 307 { 308 "Id": "ethernet1", 309 "Name": "ethernet1", 310 "Description": "Ethernet interface on slot 1", 311 "type": "iana_if_type:ethernetCsmacd", 312 "enabled": "true", 313 "link_up_down_trap_enable": "true" 315 "@odata.context": 316 "/redfish/v1/$metadata#ietf_interfaces.interfaces.interface. 317 interface", 318 "@odata.type": "#interface.v1_0_0.interfaces", 319 "@odata.id": 320 "/redfish/v1/NetworkDevices/Switch1/ietf_interfaces 321 /interfaces/ethernet1" 322 } 324 The three properties at the end of the JSON document are OData 325 annotations. 327 3. Security Considerations 329 Redfish also improves security control since there is a single point 330 of management contact for a device to control all of its functions. 332 (Additional security discussion will be provided later.) 334 4. Appendix A 336 YANG models needed to managed a network switch: 338 o RFC7223 (Interfaces) 339 o RFC7224 (IANA) 341 o RFC7277 (IPv4, IPv6) 343 o RFC7317 (System Identification, Time-Date, NTP) 345 o VLANs 347 o ACLs 349 o Syslog 351 5. Appendix B 353 The following describes how the Redfish NetworkDevices[] collection 354 resource allows multiple co-existing and consistent views onto a 355 system. 357 As an example, a router could have the following: 359 //redfish.example.net/redfish/v1/NetworkDevices/masterRouter 360 //redfish.example.net/redfish/v1/NetworkDevices/vrf1 361 //redfish.example.net/redfish/v1/NetworkDevices/vrf2 363 In this example, masterRouter represents the complete system with all 364 interfaces, all tables, all system level configuration, and a model 365 structure for assigning resources to virtual instances. The 366 resources, vrf1 and vrf2, represent a particular partitioning of the 367 system to create virtual router instances each assigned a subset of 368 the total resource pool. 370 The above structure has similarities with that expressed by the 371 device model from the following references: 373 o https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-01 375 o https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-01 377 o https://tools.ietf.org/html/draft-ietf-rtgwg-lne-model-01 379 o https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03 381 In these references a Network Device contains Logical Network 382 Elements which, in turn, contain Network Instances. From the device 383 model reference, the Network Device represents the system as a whole. 384 The Logical Network Element represents a partition of a physical 385 system. The Logical Network Element represents a VRF or VSI (virtual 386 switching instance). 388 The Redfish NetworkDevices collection resource would map this 389 modeling approach by using an element of the collection for the 390 Network Device and one for each of the Logical Network Elements and 391 Network Instances. These collection elements would add references at 392 the NetworkDevices element level to map the containment of of the 393 device model. The overall ./redfish/v1/ root maps to the Routing 394 Area Network Device. 396 6. Appendix C 398 The following is the ietf_interfaces.interfaces.interface_v1.xml CSDL 399 metadata file, which is referenced in @odata.context annotation in 400 the example mapping. The entity type referenced in the @odata.type 401 annotation is in the second Namespace. 403 When mapping YANG code to CDSL, values are mapped to existing OData 404 core properties, when possible. Otherwise, new annotations are 405 defined in RedfishYangExtensions.xml. This file is referenced at the 406 beginning of the document. 408 409 411 414 415 416 419 421 422 425 427 429 431 433 435 437 439 440 442 444 446 448 450 452 454 455 456 457 458 460 462 464 466 467 468 470 472 474 476 478 479 480 481 483 485 487 489 491 492 494 496 498 500 502 503 505 507 509 511 513 515 517 518 520 521 522 524 525 526 527 528 530 532 534 7. Appendix D 536 The following is the IETF YANG source XML from RFC7223 used for the 537 example mapping. 539 file "ietf-interfaces@2014-05-08.yang" 540 module ietf-interfaces { 541 namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces"; 542 prefix if; 543 import ietf-yang-types { 544 prefix yang; 545 } 546 organization 547 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 548 . . . 550 After the typedef, identity, and feature statements, the data model 551 is defined. Below is the fragment that becomes 552 ietf_interfaces.interfaces.interface_v1.xml. 554 /* 555 * Configuration data nodes 556 */ 557 container interfaces { 558 description 559 "Interface configuration parameters."; 560 list interface { 561 key "name"; 562 description 563 "The list of configured interfaces..."; 564 leaf name { 565 type string; 566 description 567 "The name of the interface..."; 568 } 569 leaf description { 570 type string; 571 description 572 "A textual description of the interface..."; 573 reference 574 "RFC 2863: The Interfaces Group MIB - ifAlias"; 575 } 576 leaf type { 577 type identityref { 578 base interface-type; 579 } 580 mandatory true; 581 description 582 "The type of the interface..."; 583 reference 584 "RFC 2863: The Interfaces Group MIB - ifType"; 585 } 586 leaf enabled { 587 type boolean; 588 default "true"; 589 description 590 "This leaf contains the configured,..."; 591 reference 592 "RFC 2863: The Interfaces Group MIB - ifAdminStatus"; 594 leaf link-up-down-trap-enable { 595 if-feature if-mib; 596 type enumeration { 597 enum enabled { 598 value 1; 599 } 600 enum disabled { 601 value 2; 602 } 603 } 604 description 605 "Controls whether linkUp/linkDown SNMP..."; 606 reference 607 "RFC 2863: The Interfaces Group MIB - 608 ifLinkUpDownTrapEnable"; 609 } 610 } 611 . . . 613 8. References 615 8.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 8.2. URIs 622 [1] http://odata.org 624 [2] http://dmtf.org/redfish 626 [3] http://www.dmtf.org/sites/default/files/standards/documents/ 627 DSP2044_1.0.0.pdf 629 [4] http://www.rfc-editor.org/info/rfc7895 631 [5] https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03 633 [6] http://www.dmtf.org/sites/default/files/standards/documents/ 634 DSP0271_0.5.6.pdf 636 Authors' Addresses 638 Joseph White 639 Dell EMC 641 Email: joseph.l.white@dell.com 643 David Black 644 Dell EMC 646 Email: david.black@dell.com 648 John Leung 649 Intel Corporation 651 Email: john.leung@intel.com