Internet DRAFT - draft-wbl-rtgwg-yang-ci-profile-bkgd

draft-wbl-rtgwg-yang-ci-profile-bkgd







Network Working Group                                           J. White
Internet-Draft                                                  D. Black
Intended status: Informational                                  Dell EMC
Expires: September 9, 2017                                      J. Leung
                                                       Intel Corporation
                                                           March 9, 2017


                  YANG Baseline Switch Profile Background
                  draft-wbl-rtgwg-yang-ci-profile-bkgd-01

Abstract

   A YANG device profile is primarily a group of YANG models that are
   appropriate for use with a particular class of device or in specific
   device roles.  This document provides background and describes the
   rationale for a baseline data center switch device profile, e.g., for
   top-of-rack switches in data center converged infrastructure.  This
   rationale is based on the reuse of YANG models by the DMTF Redfish
   standard for management of converged infrastructure, but the
   resulting YANG device profile is intended to be useable by any YANG-
   based network management approach or protocol, as opposed to being
   specific to Redfish.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 9, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



White, et al.          Expires September 9, 2017               [Page 1]

Internet-Draft                     I-D                        March 2017


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   *Disclaimer* - this is a -00 draft, whose primary goal is to capture
   the rationale for use of YANG for Redfish network management and the
   desirability of a baseline data center network switch profile,
   including providing technical background on the Redfish standard and
   its approach to network management.  The draft content is not
   polished, and the organization of the material is likely to change.

   A YANG device profile is primarily a group of YANG models that are
   appropriate for use with a particular class of device or in specific
   device roles.  This document provides background and describes the
   rationale for a baseline data center switch device profile, e.g., for
   top-of-rack switches in data center converged infrastructure.  The
   rationale is based on the reuse of YANG models by the DMTF Redfish
   standard for management of converged infrastructure, but the
   resulting YANG device profile is intended to be useable by any YANG-
   based network management approach or protocol; it is not intended to
   be Redfish-specific.

   In support of this rationale, this document provides background on
   how YANG is used in the Redfish management framework; the YANG
   modules are translated to Redfish schema definitions in order to
   enable reuse of the models are with Redfish-defined management
   protocols and related functionality.

2.  Motivation

   A common management framework with accompanying set of protocols and
   device models is desirable in systems management use cases.  A good
   example of this is in a converged infrastructure deployment within a
   data center.  Applications, servers, storage, appliances, and
   networking elements are assembled to create a combined coherent
   platform.  For the networking components in such an environment,
   there are platform management elements that are common with other
   types of systems such as thermal monitoring, physical enclosure,
   fans, and power supplies, as well as networking specific management
   elements to control the forwarding and filtering of network packets
   or the networking services.  The common elements should be accessed
   and managed in a single way across all systems within the deployment.



White, et al.          Expires September 9, 2017               [Page 2]

Internet-Draft                     I-D                        March 2017


   Management, orchestration, and control of such a system benefits from
   a single approach that enables unified tools sets and simplifies
   operations.

   The networking specific configuration within the converged
   infrastructure environment only needs a subset of all the possible
   networking protocols and services giving the converged controller
   only the minimum spanning control surface in terms of the models it
   can access.  A breakdown of the needs of such a switch result in
   about 5-10 YANG modules (see Appendix A).  These 5-10 modules should
   lead to common YANG-based data center network switch management
   across vendors and products.

   As a contrast, a full function edge router would need many more
   protocols and services along with full function virtualization
   resulting in the use of about 80 YANG modules.

2.1.  Redfish Background

   The DMTF (Distributed Management Task Force) Redfish standard is
   becoming the common standard for converged infrastructure (CI)
   management.  Converged Infrastructure consists of rack-scale (partial
   or full-rack) integrated compute, network and storage infrastructure
   that is procured and deployed as rack scale systems.

   Redfish data center storage management functionality has been
   extended in partnership with SNIA (Storage Networking Industry
   Association) resulting in the recently released Swordfish
   specification that extends Redfish for networked storage and storage
   network management.  The authors hope to work with the IETF to extend
   and align Redfish network management with IETF's YANG framework.

   Redfish is a management standard using a data model representation
   inside of a RESTful interface.  The model is expressed in terms of a
   standard, machine-readable schema, with the payload of the messages
   being expressed in JSON.

   Because it is a model-based API, Redfish is capable of representing a
   variety of implementations via a consistent interface.  It has
   mechanisms for managing data center resources, handling events, long
   lived tasks and discovery, as well.

   In Redfish, every URL represents a resource.  This could be a
   service, a collection, an entity or some other construct.  But in
   RESTful terms, these URIs point to resources and Redfish clients
   interact with these resources.  For example, the content of a
   resource, in JSON format, is returned when the Redfish client
   performs a HTTP GET.



White, et al.          Expires September 9, 2017               [Page 3]

Internet-Draft                     I-D                        March 2017


   OData is an OASIS standard for expressing the schema of a JSON
   document.  OData allows a fuller description of the JSON document,
   than json-schema.  The format of OData schema is specified in CSDL
   (Common Schema Definition Language).

   OData also describes directives that can appear on the URI to control
   the contents of the HTTP response.  In Redfish, these directives
   (i.e. $top and $skip) are stated as 'should'.  Networking extension
   may change the requirement to 'shall'.

   Redfish releases include both OData and json-schema schema.  With
   json-schema, users can take advantage of its larger tool chain.

   Additional information about OData can be found at the OData site
   [1].

   Additional information about Redfish can be found at DMTF's Redfish
   site [2].  Specifically, the Redfish White Paper [3] provides a good
   overview.

2.2.  YANG and Redfish

   Within the networking world, YANG has become the preferred management
   framework.  YANG expresses each section of the overall model as a
   module containing a tree of nodes where each node is either a
   container node that builds the hierarchy or a leaf node containing
   data elements for the model.  Redfish network management leverages
   YANG as the core model definition language to maintain consistency
   with other YANG based network management approaches.  Using a common
   model structure results in equivalent data elements yielding the same
   data or content when accessed via different interfaces or protocols.

   Redfish's network management supports this consistency by reusing
   YANG modules as Redfish models for network functionality and
   services, mechanically translating those modules to the Redfish
   interface, based on HTTP, JSON, and OData.

   The Redfish approach to network management enables definitions of a
   specific system views or profiles that are aligned with the
   configuration functionality required in a specific scenario or for a
   specific class of network devices.  A particularly relevant example
   is a baseline switch model description with a minimum set of model
   elements; this is useful when configuring a switch within a larger
   converged infrastructure system.  The model elements of the baseline
   switch should be the smallest set of models necessary to configure a
   data center switch in a converged infrastructure environment; the
   corresponding set of YANG modules would be a simple data center
   network device profile.  A more complex network router might need



White, et al.          Expires September 9, 2017               [Page 4]

Internet-Draft                     I-D                        March 2017


   tunnel models, overlay models, extensive QoS models, and other
   elements.

   The top level resource structure of Redfish is show below.

   ./redfish/v1/Systems
   ./redfish/v1/Chassis
   ./redfish/v1/NetworkDevices
   (other redfish resources)

   Within this structure a network switch is viewed as a data center
   element for its common subsystems such as chassis, power, thermal,
   cooling, management access setup, etc while the network modeling is
   specified within the instances of the NetworkDevices[] collection.
   Each member of the NetworkDevices[] collection has implements its own
   set translated YANG modules.  For consistency, the set of modules
   grouped under a NetworkDevice instance can follow one of multiple
   standard groupings expressed as a profile to manage different classes
   of equipment and satisfy different use cases.  Two profile examples
   are the basic switch and virtualized edge router.

2.3.  YANG mapping to Redfish

   The notion of schema is different in Redfish and YANG.

   In YANG, a schema is device specific.  The user determines the YANG
   modules utilized by a system, and may consult a module library as
   part of doing so (e.g., RFC7895 [4]).  The YANG schema is realized as
   a set of YANG modules, each with a prescribed node tree structure.

   In Redfish, there is one schema that encompasses the entire
   namespace.  In other words, Redfish has a global namespace for its
   schema, of which the device implements a subset.  The Redfish schema
   is realized as resources accessed via a URI, so the namespace
   contains the information about which YANG modules are utilized.  The
   OData directives $expand and $filter allows the client to discovery
   this directly from the parent namespace node above the modules.

   That functionality obviates any Redfish need to use YANG module
   combination techniques such as YANG Schema-mount [5].

   Despite these differences, the proposed profiles should be usable by
   both YANG based protocols (e.g., NETCONF, RESTCONF) and Redfish, as
   the core content of each profile is a set of YANG modules.

   To allow Redfish to manage network devices, the YANG modules needs to
   be translated into OData CSDL (Common Schema Definition Language).
   The translation is specified in the YANG-to-Redfish Mapping



White, et al.          Expires September 9, 2017               [Page 5]

Internet-Draft                     I-D                        March 2017


   Specification [6].  The translation has the following
   characteristics:

   o  Includes, imports, and augments, are compiled out to create a
      single consistent schema block constituting a particular instance
      of a NetworkDevice.

   o  The YANG node tree layout is reflected in the URI layout

   o  The individual YANG container nodes and list nodes are rendered as
      resources with the YANG tree hierarchy reflected as navigation
      properties.

   Access to the YANG data model elements uses a Redfish JSON accessed
   via a provider on the URI target.

   Leaf nodes representing common back end system "features or elements"
   return consistent data independent of node name and network device
   hierarchy.

   The NetworkDevices[] collection allows

   o  Multiple co-existing and consistent views onto a system.

      *  Horizontally extensible

      *  Vertical hierarchy allowing for control interface delegation

   o  This is similar to a "view class" or facade approach in software.

2.4.  Example Mapping

   The following shows the resource which results from mapping RFC7223
   (ietf_interface module) to the Redfish schema.  Below is a fragment
   of the data model from the RFC.

   +--rw interfaces
   | +--rw interface* [name]
   | +--rw name string
   | +--rw description? string
   | +--rw type identityref
   | +--rw enabled? boolean
   | +--rw link-up-down-trap-enable? enumeration
   +--ro interfaces-state
   +--ro interface* [name]
   +--ro name string
   +--ro type identityref
   +--ro admin-status enumeration



White, et al.          Expires September 9, 2017               [Page 6]

Internet-Draft                     I-D                        March 2017


   The translation to Redfish CSDL is performed using the RFC's YANG
   code.  The translation will generate the CSDL files for the
   ietf_interfaces resource and each YANG container.  The path to these
   resources mirror the above data model.

./redfish/v1/NetworkDevices/Switch1
./redfish/v1/NetworkDevices/Switch1/ietf_interfaces
./redfish/v1/NetworkDevices/Switch1/ietf_interfaces/interfaces
./redfish/v1/NetworkDevices/Switch1/ietf_interfaces/interfaces/ethernet1
./redfish/v1/NetworkDevices/Switch1/ietf_interfaces/interfaces_state
...

   A HTTP GET of the "ethernet1" singleton resource will return the
   following JSON document.  Note that each property from the above data
   model is present in the resource.

   {
       "Id": "ethernet1",
       "Name": "ethernet1",
       "Description": "Ethernet interface on slot 1",
       "type": "iana_if_type:ethernetCsmacd",
       "enabled": "true",
       "link_up_down_trap_enable": "true"

       "@odata.context":
           "/redfish/v1/$metadata#ietf_interfaces.interfaces.interface.
               interface",
       "@odata.type": "#interface.v1_0_0.interfaces",
       "@odata.id":
           "/redfish/v1/NetworkDevices/Switch1/ietf_interfaces
               /interfaces/ethernet1"
   }

   The three properties at the end of the JSON document are OData
   annotations.

3.  Security Considerations

   Redfish also improves security control since there is a single point
   of management contact for a device to control all of its functions.

   (Additional security discussion will be provided later.)

4.  Appendix A

   YANG models needed to managed a network switch:

   o  RFC7223 (Interfaces)



White, et al.          Expires September 9, 2017               [Page 7]

Internet-Draft                     I-D                        March 2017


   o  RFC7224 (IANA)

   o  RFC7277 (IPv4, IPv6)

   o  RFC7317 (System Identification, Time-Date, NTP)

   o  VLANs

   o  ACLs

   o  Syslog

5.  Appendix B

   The following describes how the Redfish NetworkDevices[] collection
   resource allows multiple co-existing and consistent views onto a
   system.

   As an example, a router could have the following:

   //redfish.example.net/redfish/v1/NetworkDevices/masterRouter
   //redfish.example.net/redfish/v1/NetworkDevices/vrf1
   //redfish.example.net/redfish/v1/NetworkDevices/vrf2

   In this example, masterRouter represents the complete system with all
   interfaces, all tables, all system level configuration, and a model
   structure for assigning resources to virtual instances.  The
   resources, vrf1 and vrf2, represent a particular partitioning of the
   system to create virtual router instances each assigned a subset of
   the total resource pool.

   The above structure has similarities with that expressed by the
   device model from the following references:

   o  https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-01

   o  https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-01

   o  https://tools.ietf.org/html/draft-ietf-rtgwg-lne-model-01

   o  https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03

   In these references a Network Device contains Logical Network
   Elements which, in turn, contain Network Instances.  From the device
   model reference, the Network Device represents the system as a whole.
   The Logical Network Element represents a partition of a physical
   system.  The Logical Network Element represents a VRF or VSI (virtual
   switching instance).



White, et al.          Expires September 9, 2017               [Page 8]

Internet-Draft                     I-D                        March 2017


   The Redfish NetworkDevices collection resource would map this
   modeling approach by using an element of the collection for the
   Network Device and one for each of the Logical Network Elements and
   Network Instances.  These collection elements would add references at
   the NetworkDevices element level to map the containment of of the
   device model.  The overall ./redfish/v1/ root maps to the Routing
   Area Network Device.

6.  Appendix C

   The following is the ietf_interfaces.interfaces.interface_v1.xml CSDL
   metadata file, which is referenced in @odata.context annotation in
   the example mapping.  The entity type referenced in the @odata.type
   annotation is in the second Namespace.

   When mapping YANG code to CDSL, values are mapped to existing OData
   core properties, when possible.  Otherwise, new annotations are
   defined in RedfishYangExtensions.xml.  This file is referenced at the
   beginning of the document.

     <?xml version="1.0" encoding="UTF-8"?>
     <edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx"
             Version="4.0">
         <Edmx:Reference
             Uri="http://docs.oasis-open.org/odata/odata/v4.0/cs01/
                 vocabularies/Org.OData.Core.V1.xml">
             <Edmx:Include Alias="Odata" Namespace="Org.OData.Core.V1"/>
         </Edmx:Reference>
         <Edmx:Reference
             Uri="http://docs.oasis-open.org/odata/odata/v4.0/cs01/
                 vocabularies/Org.OData.Capabilities.V1.xml">
             <Edmx:Include Alias="Odata"
                 Namespace="Org.OData.Capabilities.V1"/>
         </Edmx:Reference>
         <Edmx:Reference
             Uri="http://redfish.dmtf.org/schemas/v1/
                 RedfishYangExtensions.xml">
             <Edmx:Include Alias="Redfish.Yang"
                 Namespace="Redfish.Yang"/>
         </Edmx:Reference>

         <Edmx:DataServices>

         <Schema Namespace="interface"
                 xmlns="http://docs.oasis-open.org/odata/ns/edm" >
             <EntityType Name="interface"
                     BaseType="Resource.v1_0_0.Resource">
                 <Annotation Term="OData.Description"



White, et al.          Expires September 9, 2017               [Page 9]

Internet-Draft                     I-D                        March 2017


                     String="<manual input>." />
                 <Annotation Term="OData.AdditionalProperties"
                     Bool="False"/>
             </EntityType>
         </Schema>

         <Schema Namespace="interface.v1_0_0"
                 xmlns="http://docs.oasis-open.org/odata/ns/edm" >
             <EntityType Name="interface" BaseType=
                     "ietf_interfaces.interfaces.interface.interface" >
                 <Annotation Term="OData.Description"
                     String="<manual input>." />
                 <Annotation Term="OData.AdditionalProperties"
                     Bool="False"/>
                 <Annotation Term="Redfish.Yang.NodeType"
                     EnumMember="Redfish.Yang.NodeTypes/list" />
                 <Annotation Term="Redfish.Yang.key"
                     String=" the yang key string"/>
                 <Key>
                     <PropertyRef Name="name"/>
                 </Key>
                 <Property Name="name" Type="Edm:String">
                     <Annotation Term="OData.Description"
                         String="..." />
                     <Annotation Term="OData.Permissions"
                         EnumMember="OData.Permissions/Read"/>
                     <Annotation Term="Redfish.Yang.NodeType"
                         EnumMember="Redfish.Yang.NodeTypes/leaf"/>
                     <Annotation Term="Redfish.Yang.YangType"
                         String="string" />
                 </Property>
                 <Property Name="description" Type="Edm:String">
                     <Annotation Term="OData.Description"
                         String="..." />
                     <Annotation Term="OData.Permissions"
                         EnumMember="OData.Permissions/Read"/>
                     <Annotation Term="Redfish.Yang.NodeType"
                         EnumMember="Redfish.Yang.NodeTypes/leaf" />
                     <Annotation Term="Redfish.Yang.YangType"
                         String="string" />
                     <Annotation Term="Redfish.Yang.reference"
                         String="RFC 2863: The Interfaces Group..." />
                 </Property>
                 <Property Name="type" Type="Edm:String">
                     <Annotation Term="OData.Description" String="..."/>
                     <Annotation Term="Redfish.Yang.NodeType"
                         EnumMember="Redfish.Yang.NodeTypes/leaf" />
                     <Annotation Term="Redfish.Yang.YangType"



White, et al.          Expires September 9, 2017              [Page 10]

Internet-Draft                     I-D                        March 2017


                         String="identityref"/>
                     <Annotation Term="Redfish.Yang.base"
                         String="interface-type"/>
                     <Annotation Term="Redfish.Yang.mandatory"
                         EnumMember="Redfish.Yang.Mandatory/true"/>
                     <Annotation Term="Redfish.Yang.reference"
                         String="RFC 2863: The Interfaces Group..." />
                 </Property>
                 <Property DefaultValue="true" Name="enabled"
                         Type="Edm:Boolean">
                     <Annotation Term="OData.Description"
                         String="This leaf contains..." />
                     <Annotation Term="Redfish.Yang.NodeType"
                         EnumMember="Redfish.Yang.NodeTypes/leaf" />
                     <Annotation Term="Redfish.Yang.YangType"
                         String="boolean"/>
                     <Annotation Term="Redfish.Yang.reference"
                         String="RFC 2863: The Interfaces..."/>
                 </Property>
                 <Property Name="link_up_down_trap_enable"
                         Type="Edm:Enumeration">
                     <Annotation Term="OData.Description"
                         String="Controls whether..."/>
                     <Annotation Term="Redfish.Yang.NodeType"
                         EnumMember="Redfish.Yang.NodeTypes/leaf"/>
                     <Annotation Term="Redfish.Yang.YangType"
                         String="enumeration"/>
                     <Annotation Term="Redfish.Yang.if_feature"
                         String="if-mib"/>
                     <Annotation Term="Redfish.Yang.reference"
                         String="RFC 2863: The Interfaces..." />
                     <EnumType
                             Name="link_up_down_trap_enableEnumeration">
                         <Member Name="enabled" Value="1">
                             <Annotation Term="Redfish.Yang.enum"
                                 String="enabled"/>
                         </Member>
                         <Member Name="disabled" Value="2">
                             <Annotation Term="Redfish.Yang.enum"
                                 String="disabled"/>
                         </Member>
                     </EnumType>
                 </Property>
             </EntityType>
         </Schema>

         </Edmx:DataServices>




White, et al.          Expires September 9, 2017              [Page 11]

Internet-Draft                     I-D                        March 2017


     </edmx:Edmx>

7.  Appendix D

   The following is the IETF YANG source XML from RFC7223 used for the
   example mapping.

   <CODE BEGINS> file "ietf-interfaces@2014-05-08.yang"
   module ietf-interfaces {
       namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
       prefix if;
       import ietf-yang-types {
           prefix yang;
       }
       organization
           "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
       . . .

   After the typedef, identity, and feature statements, the data model
   is defined.  Below is the fragment that becomes
   ietf_interfaces.interfaces.interface_v1.xml.

       /*
        * Configuration data nodes
        */
       container interfaces {
           description
               "Interface configuration parameters.";
           list interface {
               key "name";
               description
                   "The list of configured interfaces...";
           leaf name {
               type string;
               description
                   "The name of the interface...";
           }
           leaf description {
               type string;
               description
                   "A textual description of the interface...";
               reference
                   "RFC 2863: The Interfaces Group MIB - ifAlias";
           }
           leaf type {
               type identityref {
                   base interface-type;
               }



White, et al.          Expires September 9, 2017              [Page 12]

Internet-Draft                     I-D                        March 2017


               mandatory true;
               description
                   "The type of the interface...";
               reference
                   "RFC 2863: The Interfaces Group MIB - ifType";
           }
           leaf enabled {
               type boolean;
               default "true";
               description
                   "This leaf contains the configured,...";
               reference
                   "RFC 2863: The Interfaces Group MIB - ifAdminStatus";

           leaf link-up-down-trap-enable {
               if-feature if-mib;
               type enumeration {
                   enum enabled {
                       value 1;
                   }
                   enum disabled {
                       value 2;
                   }
               }
               description
                   "Controls whether linkUp/linkDown SNMP...";
               reference
                   "RFC 2863: The Interfaces Group MIB -
                       ifLinkUpDownTrapEnable";
           }
       }
       . . .

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  URIs

   [1] http://odata.org

   [2] http://dmtf.org/redfish

   [3] http://www.dmtf.org/sites/default/files/standards/documents/
       DSP2044_1.0.0.pdf



White, et al.          Expires September 9, 2017              [Page 13]

Internet-Draft                     I-D                        March 2017


   [4] http://www.rfc-editor.org/info/rfc7895

   [5] https://tools.ietf.org/html/draft-ietf-netmod-schema-mount-03

   [6] http://www.dmtf.org/sites/default/files/standards/documents/
       DSP0271_0.5.6.pdf

Authors' Addresses

   Joseph White
   Dell EMC

   Email: joseph.l.white@dell.com


   David Black
   Dell EMC

   Email: david.black@dell.com


   John Leung
   Intel Corporation

   Email: john.leung@intel.com


























White, et al.          Expires September 9, 2017              [Page 14]