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