Internet DRAFT - draft-zhuang-lime-yang-oam-model-applicability

draft-zhuang-lime-yang-oam-model-applicability







Network Working Group                                     T. Taylor, Ed.
Internet-Draft                                      PT Taylor Consulting
Intended status: Informational                            Y. Zhuang, Ed.
Expires: June 13, 2016                                            Huawei
                                                       December 11, 2015


   Applicability of Generic YANG Data Model for layer Independent OAM
                               Management
           draft-zhuang-lime-yang-oam-model-applicability-02

Abstract

   A generic YANG data model for Operations, Administration, and
   Maintenance (OAM) has been defined in [GENYANGOAM], with the
   intention that technology-specific extensions will be developed to be
   able reference/use the Generic YANG model.  In this document, we
   describe the applicability of the generic YANG OAM data model to
   specific OAM technologies.  To be concrete, we also demonstrate the
   usability and extensibility of the generic YANG OAM model with OAM
   protocols such as IP Ping, traceroute, BFD and MPLS LSP Ping.

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 June 13, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Taylor & Zhuang           Expires June 13, 2016                 [Page 1]

Internet-Draft      Applicability of LIME Base Model       December 2015


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used In This Document . . . . . . . . . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Basic Structure of Generic YANG Model for OAM . . . . . . . .   4
     3.1.  Performance Management Support  . . . . . . . . . . . . .   6
   4.  Guidelines For Extending the LIME Base Data Model . . . . . .   6
     4.1.  Extend configuration structure with technology specific
           parameters  . . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.1.  Maintenance domain (MD) at the root level . . . . . .   8
       4.1.2.  Maintenance Association (MA) at the second level  . .   9
       4.1.3.  Maintenance Association Endpoint (MEP) at the third
               level . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.4.  Session at the fourth level . . . . . . . . . . . . .  10
       4.1.5.  Interface at the fifth level  . . . . . . . . . . . .  10
     4.2.  Extend RPC structure with technology specific parameters   10
     4.3.  Extend Notification structure with technology specific
           parameters  . . . . . . . . . . . . . . . . . . . . . . .  12
     4.4.  Define New RPCs and Notifications . . . . . . . . . . . .  12
   5.  Applicability of LIME Model to Various Technologies . . . . .  12
     5.1.  Generic YANG Model extension for IP OAM . . . . . . . . .  13
       5.1.1.  MD Configuration Extension  . . . . . . . . . . . . .  13
       5.1.2.  MA Configuration Extension  . . . . . . . . . . . . .  13
       5.1.3.  MEP Configuration Extension . . . . . . . . . . . . .  14
       5.1.4.  RPC Extension . . . . . . . . . . . . . . . . . . . .  14
       5.1.5.  Performance Monitoring Extension  . . . . . . . . . .  15
     5.2.  Generic YANG Model extension for TRILL OAM  . . . . . . .  16
       5.2.1.  MD Configuration Extension  . . . . . . . . . . . . .  16
       5.2.2.  MA Configuration Extension  . . . . . . . . . . . . .  16
       5.2.3.  MEP Configuration Extension . . . . . . . . . . . . .  17
       5.2.4.  RPC Extension . . . . . . . . . . . . . . . . . . . .  18
       5.2.5.  Performance Management (PM) Extension . . . . . . . .  19
       5.2.6.  Usage example . . . . . . . . . . . . . . . . . . . .  19
     5.3.  Generic YANG Model extension for MPLS OAM . . . . . . . .  23
       5.3.1.  MD Configuration Extension  . . . . . . . . . . . . .  23
       5.3.2.  MA Configuration Extension  . . . . . . . . . . . . .  24
       5.3.3.  MEP Configuration Extension . . . . . . . . . . . . .  25
       5.3.4.  RPC Extension . . . . . . . . . . . . . . . . . . . .  26
       5.3.5.  Performance Management Extension  . . . . . . . . . .  26
       5.3.6.  Usage Example . . . . . . . . . . . . . . . . . . . .  27
     5.4.  Generic YANG Model extension for MPLS-TP OAM  . . . . . .  28



Taylor & Zhuang           Expires June 13, 2016                 [Page 2]

Internet-Draft      Applicability of LIME Base Model       December 2015


       5.4.1.  MD Configuration Extension  . . . . . . . . . . . . .  28
       5.4.2.  MA Configuration Extension  . . . . . . . . . . . . .  29
       5.4.3.  MEP Configuration Extension . . . . . . . . . . . . .  30
       5.4.4.  RPC Extension . . . . . . . . . . . . . . . . . . . .  30
       5.4.5.  Performance Monitoring Extension  . . . . . . . . . .  31
     5.5.  Generic YANG Model extension for NVO3 OAM . . . . . . . .  31
       5.5.1.  Technology Type Extension . . . . . . . . . . . . . .  31
       5.5.2.  Sub Technology Type Extension . . . . . . . . . . . .  32
       5.5.3.  MEP Configuration Extension . . . . . . . . . . . . .  32
       5.5.4.  Connectivity-Context Extension  . . . . . . . . . . .  33
       5.5.5.  RPC Extension . . . . . . . . . . . . . . . . . . . .  33
       5.5.6.  ECMP Extension  . . . . . . . . . . . . . . . . . . .  33
     5.6.  Generic YANG Model extension for BFD  . . . . . . . . . .  34
       5.6.1.  MD Level configuration extension  . . . . . . . . . .  34
       5.6.2.  MA configuration extension  . . . . . . . . . . . . .  35
       5.6.3.  MEP configuration extension . . . . . . . . . . . . .  36
   6.  Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .  37
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  38
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  38
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  38
     10.2.  Informative References . . . . . . . . . . . . . . . . .  38
   Appendix A.  Contributing Authors Infomation  . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41

1.  Introduction

   The Generic YANG [RFC6020] over NETCONF [RFC6241] data model for OAM
   defined in [GENYANGOAM], aims at providing consistent configuration,
   reporting and representation of OAM mechanisms at any layer for any
   technology.

   In this document, we discuss the applicability of the generic YANG
   OAM model to various OAM technologies and demonstrates that the YANG
   model(s) developed in the LIME WG are usable and extensible for those
   technologies.  The demonstration uses IP Ping, traceroute, BFD and
   LSP Ping as specific examples.

2.  Conventions Used In This Document

   This document contains no normative language.

2.1.  Terminology

   MP Maintenance Point [IEEE802.1Q].





Taylor & Zhuang           Expires June 13, 2016                 [Page 3]

Internet-Draft      Applicability of LIME Base Model       December 2015


   MEP  Maintenance association End Point [RFC7174] [IEEE802.1Q]
      [RFC6371].

   MIP  Maintenance domain Intermediate Point [RFC7174] [IEEE802.1Q]
      [RFC6371].

   MA Maintenance Association [IEEE802.1Q] [RFC7174].

   MD Maintenance Domain [IEEE802.1Q].

   OAM  Operations, Administration, and Maintenance [RFC6291].

   TRILL  Transparent Interconnection of Lots of Links [RFC6325].

   RPC  Remote Procedure Call[RFC6020].

3.  Basic Structure of Generic YANG Model for OAM

   As the basis of this document, the generic YANG model for OAM
   specified as the LIME base model is shown in Figure 1.































Taylor & Zhuang           Expires June 13, 2016                 [Page 4]

Internet-Draft      Applicability of LIME Base Model       December 2015


   module: ietf-gen-oam
         +--rw domains
            +--rw domain* [technology MD-name-string]
               +--rw technology        identityref
               +--rw MD-name-string    MD-name-string
               ...
               +--rw MAs
                  +--rw MA* [MA-name-string]
                     +--rw MA-name-string       MA-name-string
                     ...
                     +--rw MEP* [mep-name]
                     |  +--rw mep-name             MEP-name
                     |  ...
                     |  +--rw session* [session-cookie]
                     |  ...
                     +--rw MIP* [interface]
                     |  +--rw interface    if:interface-ref
                     +--rw related-oam-layer* [offset]
                        ...
      rpcs:
         +---x continuity-check
         |     ...
         +---x continuity-verification     {connectivity-verification}?
         |     ...
         +---x path-discovery
            ...
      notifications:
         +---n defect-condition-notification
            ...

            Figure 1: Structure of the Generic LIME Base Model

   The generic YANG OAM model comprises three definitions for
   configuration and operational state data:

   o  configuration model definition;

   o  Remote procedure call (RPC) definition;

   o  and notification definition.

   The configuration model definition provides hierarchical structure to
   describe fault domain (i.e., maintenance domain), test point (i.e.,
   maintenance point), technology type, layering, and session context
   for trouble-shooting.  This basic configuration model enables users
   to select corresponding layers and nodes serving as anchor points to
   define their specific technology OAM YANG models.




Taylor & Zhuang           Expires June 13, 2016                 [Page 5]

Internet-Draft      Applicability of LIME Base Model       December 2015


   The RPC definition provides uniform APIs for common OAM functions
   such as continuity check, connectivity verification, path discovery,
   performance measurement and their equivalents.  These APIs are used
   by the network management system (NMS) to control OAM tools and
   functionalities on network elements for measuring and monitoring the
   data plane (e.g., LSP Ping, IP performance measurement protocol) and
   troubleshooting (e.g., fault localization).  These OAM tools
   activation can be pro-active and on-demand.

   The notification definition also provides a uniform API to report
   defects, faults, and network failures at different layers.  This API
   is used by network elements to report to the network management
   system (NMS).  The content of each notification includes the fault
   domain and the test point(s) that detected the fault and may generate
   the error message.  This API must be activated proactively.

3.1.  Performance Management Support

   To support OAM Performance Management, the generic YANG Data Model
   for OAM needs to be extended by adding loss and delay measurements
   support with the following model structure:

   /* MEP Configuration extension */
    augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP:
       +--rw delay-measurements?
     augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP:
       +--rw loss-measurements?
   /* New rpcs */
   rpcs:
     +---x create-loss-measurement
     |     ...
     +---x abort-loss-measurement
     |     ...
     +---x create-delay-measurement
     |     ...
     +---x abort-delay-measurement
     |     ...

   Both pro-active and on-demand loss and delay measurement are
   supported by augument MEP configuration and RPCs with session type
   parameter.  The details of Performance management extension is
   specified in the [I-D.wang-lime-yang-pm]

4.  Guidelines For Extending the LIME Base Data Model

   YANG allows a module to reference external modules to reuse data
   already defined in those modules.  Therefore a technology-specific
   model can import data definitions from the LIME base model.



Taylor & Zhuang           Expires June 13, 2016                 [Page 6]

Internet-Draft      Applicability of LIME Base Model       December 2015


   The import statements are used to make definitions available inside
   other modules [RFC6020].  Users who want to develop a technology-
   specific OAM model should import the ietf-gen-oam YANG model with the
   following statements:

      module example-ietf-xxx-oam {
              namespace "urn:foo:params:xml:ns:yang:ietf-xxx-oam";
              prefix xxxoam;

              import ietf-gen-oam {
                prefix goam;
              }
              ......

   As described in Section 3, the LIME base model provides a
   hierarchical structure for configuration, notification and RPCs.
   Each of these three aspects should be extended with technology-
   specific features and parameters relating to each technology of
   interest.

   YANG allows a module to insert additional nodes into data models,
   including both the current module (and its submodules) or an external
   module.  This is useful to let specific technologies add specific
   parameters into the LIME base model.

   Here we summarize four ways to extend the LIME base model for
   specific technologies:

   o  Extend structure for configuration with technology specific
      parameters

   o  Extend structure for notification with technology specific
      parameters

   o  Extend structure for RPC with technology specific parameters

   o  Define new RPCs and notifications in the technology specific OAM
      data model.

4.1.  Extend configuration structure with technology specific parameters

   As described in [RFC6020], the "augment" statement defines the
   location in the data model hierarchy where new nodes are inserted.

   By using the "augment" statement, the hierarchy of configuration
   structure can be extended with new data nodes that express
   technology-specific parameters to meet the requirements of the
   respective technologies.  The technology-specific model developer



Taylor & Zhuang           Expires June 13, 2016                 [Page 7]

Internet-Draft      Applicability of LIME Base Model       December 2015


   must take care to select the right layers and nodes in the
   configuration structure as anchor points to insert these additional
   data.

   For example, assume a technology- specific OAM YANG model A.  An "a"
   node needs to be inserted within the MA (Maintenance Association):

      augment /goam:domains/goam:domain/goam:MAs/goam:MA:
                +--a?   foo

      Corresponding YANG encoding:

      augment "/goam:domains/goam:domain/goam:MAs/goam:MA"{
               leaf a{
                type foo
                 description
                 "foo";
       }
      }

   There are the following five levels in the hierarchy of configuration
   structure which we can choose as anchor point to insert additional
   data definitions:

   o  Maintenance domain (MD) at the root level;

   o  Maintenance Association (MA) at the second level;

   o  Maintenance Association Endpoint (MEP) and Maintenance Association
      Intermediate point(MIP) at the third level;

   o  Session at the fourth level;

   o  Interface at the fifth level;

4.1.1.  Maintenance domain (MD) at the root level

   At the Maintenance Domain level, domain data node at root level can
   be augmented with technology type.  [GENYANGOAM] defines a new
   globally unique, abstract, and untyped "technology-types" base
   identity by using the "identity" statement. "identity" and
   "identityref" are used to Identify New Technology Types.  Each
   technology-specific module then can extend technology type in the
   base model and specifies a corresponding concrete identity using this
   base: ipv4, ipv6, trill, mpls, etc.






Taylor & Zhuang           Expires June 13, 2016                 [Page 8]

Internet-Draft      Applicability of LIME Base Model       December 2015


4.1.2.  Maintenance Association (MA) at the second level

   At the Maintenance Association level, an MA data node can be
   augmented with connectivity context information.  For example:

   +--rw MAs
       +--rw MA* [MA-name-string]
          ...
          +--rw (connectivity-context)?
          |  +--:(context-null)
          |     +--rw context-null?        Empty

      Corresponding YANG encoding:

          choice connectivity-context {
            default "context-null";
            case context-null {
              description
                "this is a place holder when no context is needed";
              leaf context-null {
                type empty;
                description
                  "there is no context defined";
              }
            }
            description
              "connectivity context";
          }

   ietf-gen-oam YANG model users who want to define a specific OAM
   technology model can augment the corresponding choice node by
   defining a new case to carry technology specific extensions.

   For example, for a specific OAM technology YANG model A, an "a" node
   is needed to indicate the connectivity context for this specific OAM
   technology.  To achieve this, it is only necessary to augment the
   connectivity-context choice node in the ietf-gen-OAM YANG model by
   defining a "connectivity-context-A" case as:













Taylor & Zhuang           Expires June 13, 2016                 [Page 9]

Internet-Draft      Applicability of LIME Base Model       December 2015


      augment /goam:domains/goam:domain/goam:MAs/goam:MA
      /goam:connectivity-context:
            +--:(connectivity-context-A)
               +--a?   foo

      Corresponding YANG encoding:

      augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
      +"/goam:connectivity-context" {
         case connectivity-context-A {
          leaf a{
           type foo;}
          }
         }

   In some case when technology type in the Maintenance Domain level is
   not sufficient to identify OAM technology with different
   encapsulation method, MA data node can be further augmented with
   technology sub type (see an example in the section 5.5).

4.1.3.  Maintenance Association Endpoint (MEP) at the third level

   At the Maintenance Association Endpoint level, a MEP data node can be
   augmented with connectivity-context information, ECMP information and
   session information respectively.

4.1.4.  Session at the fourth level

   At the session level, Session data node can be augmented with
   technology specific information such as Session type, Session
   interval,etc.

4.1.5.  Interface at the fifth level

   At the interface level under MEP/MIP or under session, the interface
   data node can be augmented with technology specific information such
   as context information, interface type,disable/enable button,etc.

4.2.  Extend RPC structure with technology specific parameters

   [GENYANGOAM] defines rpc model which abstracts OAM specific commands
   in a technology independent manner.  In this RPC model, three generic
   RPC commands are specified.  By using the "augment" statement,the RPC
   structure for each OAM command can be extended with new data nodes
   that express technology-specific OAM command parameters to meet the
   requirements of the respective technologies.  The technology-specific
   model developer must take care to select the right layers and nodes
   in the RPC structure as anchor points to insert these additional



Taylor & Zhuang           Expires June 13, 2016                [Page 10]

Internet-Draft      Applicability of LIME Base Model       December 2015


   data.  There are two places which we can choose as anchor point to
   insert additional data definitions:

   o  Input data node

   Input data node can be augmented with technology type, sub-command
   type, session type and other technology specific parameters.  Here is
   an example of sub-command type:

   [GENYANGOAM] defines a "command-sub-type" abstract identity for
   different RPC commands, e.g., to distinguish the types of IP ping
   [RFC792], LSP ping [RFC4379].  Use of this identity is optional for
   most cases.

      The corresponding statements are shown as below.

        identity command-sub-type {
          description
            "defines different rpc command subtypes, e.g rfc792 IP
             ping, rfc4379 LSP ping, this is
             optional for most cases";
        }

        identity icmp-rfc792 {
          base command-sub-type;
          description
            "Defines the command subtypes for ICMPv4 ping";
          reference "RFC 792";
        }

        identity icmp-rfc4443 {
          base command-sub-type;
          description
            "Defines the command subtypes for ICMPv6 ping";
          reference "RFC 4443";
        }

        identity icmp-rfc4379 {
          base command-sub-type;
          description
            "Defines the command subtypes for LSP ping";
          reference "RFC 4379";
        }

   o  Output data node

   Similarly, output data nod can be augmented with technology specific
   test results information collected by executing OAM command.



Taylor & Zhuang           Expires June 13, 2016                [Page 11]

Internet-Draft      Applicability of LIME Base Model       December 2015


4.3.  Extend Notification structure with technology specific parameters

   [GENYANGOAM] defines one notification model which abstracts defects
   notification in a technology independent manner.  By using the
   "augment" statement,the notification structure can be extended with
   new data nodes that express technology-specific notification
   parameters to meet the requirements of the respective technologies.
   The technology-specific model developer must take care to select the
   right layers and nodes in the notification structure as anchor points
   to insert these additional data.

4.4.  Define New RPCs and Notifications

   The LIME base model presents three basic RPCs: continuity check,
   connectivity verification and path discovery.  Technology-specific
   OAM models can either extend the existing RPCs and notifications
   defined in the LIME base model or define new RPCs and notifications
   if generic RPCs and notifications cannot be reused to meet their
   requirements.

   For example, a Multicast Tree Verification (MTV) [TRILLOAMYANG] RPC
   command is defined in the TRILL OAM model to verify connectivity as
   well as data-plane and control-plane integrity of TRILL multicast
   forwarding as follows:

      RPCs:
         +---x mtv
            +--ro input
            |  +--ro technology             identityref
            |  +--ro MD-name-string         MD-name-string
            |  +--ro MA-name-string?        MA-name-string
            |  ...
            +--ro output
               +--ro response* [mep-address mep-id]
                  +--ro hop-count?                  uint8
                  +--ro mep-id                      tril-rb-nickname
                  +--ro mep-address                 tril-rb-nickname
                  ...

5.  Applicability of LIME Model to Various Technologies

   As mentioned above, the ietf-gen-oam model describes the abstract
   common core configuration, statistics, RPCs, and notifications for
   layer independent OAM management.

   Following guidelines stated in Section 4, ietf-gen-oam YANG model
   users can augment this base model by defining and adding new data
   nodes with technology specific functions and parameters into proper



Taylor & Zhuang           Expires June 13, 2016                [Page 12]

Internet-Draft      Applicability of LIME Base Model       December 2015


   anchor points of the ietf-gen-oam model, so as to develop a
   technology-specific OAM model.

   With these guidelines in hand, this section further demonstrates the
   usability of the ietf-gen-oam YANG model to various OAM technologies.
   Note that, in this section, we only present several snippets of
   technology-specific data model extensions for illustrative purposes.
   The complete model extensions should be worked on in respective
   protocol working groups.

5.1.  Generic YANG Model extension for IP OAM

5.1.1.  MD Configuration Extension

   MD level configuration parameters are management information which
   can be inherited in the TRILL OAM model and set by LIME base model as
   default values.  For example domain name can be set to area-ID in the
   IP OAM case.  In addition, at the Maintenance Domain level, domain
   data node at root level can be augmented with technology type.

   Note that MD level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.MD level configuration
   parameters MUST not be carried using IP Ping and traceroute protocol
   since IP Ping and traceroute doesn't support transport of these
   management information.

5.1.1.1.  Technology Type Extension

   The technology types ipv4 and ipv6 have already been defined in the
   LIME base model.  Therefore no technology type extension is required
   in the IP OAM model.

5.1.2.  MA Configuration Extension

   MA level configuration parameters are management information which
   can be inherited in the IP OAM model and set by LIME base model as
   default values.  In addition, at the Maintenance Association(MA)
   level, MA data node at the second level can be augmented with
   connectivity-context extension.

   Note that MA level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.MA level configuration
   parameters MUST not be carried using IP Ping and traceroute protocol




Taylor & Zhuang           Expires June 13, 2016                [Page 13]

Internet-Draft      Applicability of LIME Base Model       December 2015


   since IP Ping and traceroute doesn't support transport of these
   management information.

5.1.2.1.  Connectivity-Context Extension

   In IP OAM, one example of the connectivity-context is a 12 bit VLAN
   ID.  The LIME base model defines a placeholder for connectivity-
   context.  This allows other technologies to easily augment it to
   include technology specific extensions.  The snippet below depicts an
   example of augmenting context-id to include VLAN ID.

   augment /goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:MEP/goam:connectivity-context:
      +--:(context-id-vlan)
         +--rw context-id-vlan?   vlan
   augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP
   /goam:session/goam:connectivity-context:
      +--:(context-id-vlan)
         +--rw context-id-vlan?   vlan

5.1.3.  MEP Configuration Extension

   MEP configuration in the LIME base model already supports configuring
   the interface on which the MEP is located with an IP address.  There
   is no additional MEP configuration extension needed for IP OAM.

   However, IP Ping, traceroute do not use the MEPID in their message
   headers.  Therefore it is important to have method to derive the
   MEPID in an automatic manner with no user intervention.

5.1.3.1.  ECMP extension

   The flow-entropy parameter in the LIME OAM configuration model is an
   optional parameter.  Since standard IP OAM protocols, e.g., IP Ping
   and Traceroute, don't support ECMP path selection, the flow-entropy
   parameter does not need to be supported in the IP OAM model.

5.1.4.  RPC Extension

   Technology type in the RPC definition has already been defined in the
   LIME OAM base model.  Therefore no technology type extension is
   required in the RPC definition.  For IP OAM, IP Ping and IP
   Traceroute RPCs need to be supported.  For the IP OAM model, the
   continuity-check RPC with IPv4 or IPv6 as technology type can be
   mapped to the IP Ping RPC, while the path-discovery RPC with IPv4 or
   IPv6 as technology type can be mapped to IP Traceroute.





Taylor & Zhuang           Expires June 13, 2016                [Page 14]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.1.5.  Performance Monitoring Extension

   Editor Note: IP performance measurement (IPPM) and IP Ping and
   Traceroute are discussed separately based on the [RFC7276]
   classification of OAM technologies.  Although IPPM and IP OAM are
   both applied to the IP network, based on Table 4 of [RFC7276], IP OAM
   does not support performance measurement.  It is necessary to use
   OWAMP and TWAMP, defined in IPPM, for that purpose.

5.1.5.1.  MEP PM Configuration Extension

   To support IP performance measurement, MEP configuration in the LIME
   base model can be extended with:

   o  loss-stats-group: grouping object for loss measurement session
      statistics.

   o  measurement-timing-group: grouping object used for proactive and
      on-demand scheduling of PM measurement sessions.

   o  delay-measurement-configuration-group: grouping configuration
      object for the delay measurement function.

   o  delay-measurement-stats-group: grouping object for delay
      measurement session statistics.

   o  loss-measurement-configuration-group: grouping configuration
      object for the loss measurement function.

   o  loss-measurement-stats-group: grouping object for loss measurement
      session statistics.

5.1.5.2.  RPC PM Extension

   To support IP performance measurement, it is recommended that four
   RPCs are defined in the IPPM model:

   o  create-loss-measurement RPC: allows scheduling of one-way or two-
      way on-demand or proactive performance monitoring loss measurement
      sessions.

   o  abort-loss-measurement RPC: allows aborting of currently running
      or scheduled loss measurement session.

   o  create-delay-measurement RPC: allows scheduling of one-way or two-
      way on-demand or proactive performance monitoring delay
      measurement sessions.




Taylor & Zhuang           Expires June 13, 2016                [Page 15]

Internet-Draft      Applicability of LIME Base Model       December 2015


   o  abort-delay-measurement RPC: allows aborting of currently running
      or scheduled delay measurement sessions.

5.2.  Generic YANG Model extension for TRILL OAM

5.2.1.  MD Configuration Extension

   MD level configuration parameters are management information which
   can be inherited in the TRILL OAM model and set by LIME base model as
   default values.  For example domain name can be set to area-ID in the
   TRILL OAM case.  In addition, at the Maintenance Domain level, domain
   data node at root level can be augmented with technology type.

   Note that MD level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.

5.2.1.1.  Technology Type Extension

   No TRILL technology type has been defined in the LIME base model.
   Therefore a technology type extension is required in the TRILL OAM
   model.  The technology type "trill" is defined as an identity that
   augments the base "technology-types" defined in the LIME base model:

   identity trill{
    base goam:technology-types;
    description
     "trill type";
   }

5.2.2.  MA Configuration Extension

   MA level configuration parameters are management information which
   can be inherited in the TRILL OAM model and set by LIME base model as
   default values.  In addition, at the Maintenance Association(MA)
   level, MA data node at the second level can be augmented with
   connectivity-context extension.

   Note that MA level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.








Taylor & Zhuang           Expires June 13, 2016                [Page 16]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.2.2.1.  Connectivity-Context Extension

   In TRILL OAM, one example of connectivity-context is either a 12 bit
   VLAN ID or a 24 bit Fine Grain Label.  The LIME base model defines a
   placeholder for context-id.  This allows other technologies to easily
   augment that to include technology specific extensions.  The snippet
   below depicts an example of augmenting connectivity-context to
   include either VLAN ID or Fine Grain Label.

   augment /goam:domains/goam:domain/goam:MAs
   /goam:MA /goam:connectivity-context:
         +--:(connectivity-context-vlan)
         |  +--rw connectivity-context-vlan?   vlan
         +--:(connectivity-context-fgl)
            +--rw connectivity-context-fgl?    fgl

   augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP
   /goam:session/goam:connectivity-context:
         +--:(connectivity-context-vlan)
         |  +--rw connectivity-context-vlan?   vlan
         +--:(connectivity-context-fgl)
            +--rw connectivity-context-fgl?    fgl

5.2.3.  MEP Configuration Extension

   The MEP configuration definition in the LIME base model already
   supports configuring the interface of MEP with either MAC address or
   IP address.  In addition, the MEP address can be represented using a
   2 octet RBridge Nickname in TRILL OAM . Hence, the TRILL OAM model
   augments the MEP configuration in base model to add a nickname case
   into the MEP address choice node as follows:

   augment /goam:domains/goam:domain/goam:MAs
   /goam:MA/ goam:MEP/goam:mep-address:
         +--:( mep-address-trill)
         |  +--rw mep-address-trill?  tril-rb-nickname

   In addition, at the Maintenance Association Endpoint(MEP) level, MEP
   data node at the third level can be augmented with ECMP extension.

5.2.3.1.  ECMP Extension

   The flow-entropy parameter in the LIME base model is an optional
   parameter.  Since TRILL supports ECMP path selection, flow-entropy in
   TRILL is defined as a 96 octet field.  The snippet below illustrates
   its extension.





Taylor & Zhuang           Expires June 13, 2016                [Page 17]

Internet-Draft      Applicability of LIME Base Model       December 2015


   augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP
   /goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--rw flow-entropy-trill?   flow-entropy-trill
   augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP
   /goam:session/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--rw flow-entropy-trill?   flow-entropy-trill

5.2.4.  RPC Extension

   In the TRILL OAM YANG model, the continuity-check and path-discovery
   RPC commands are extended with TRILL specific requirements.  The
   snippet below illustrates the TRILL OAM RPC extension.

   augment /goam:continuity-check/goam:input:
         +--ro (out-of-band)?
         |  +--:(ipv4-address)
         |  |  +--ro ipv4-address?      inet:ipv4-address
         |  +--:(ipv6-address)
         |  |  +--ro ipv6-address?      inet:ipv6-address
         |  +--:(trill-nickname)
         |     +--ro trill-nickname?    tril-rb-nickname
         +--ro diagnostic-vlan?   boolean
   augment /goam:continuity-check/goam:input/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--ro flow-entropy-trill?   flow-entropy-trill
   augment /goam:continuity-check/goam:output:
         +--ro upstream-rbridge?   tril-rb-nickname
         +--ro next-hop-rbridge*   tril-rb-nickname
   augment /goam:path-discovery/goam:input:
         +--ro (out-of-band)?
         |  +--:(ipv4-address)
         |  |  +--ro ipv4-address?      inet:ipv4-address
         |  +--:(ipv6-address)
         |  |  +--ro ipv6-address?      inet:ipv6-address
         |  +--:(trill-nickname)
         |     +--ro trill-nickname?    tril-rb-nickname
         +--ro diagnostic-vlan?   boolean
   augment /goam:path-discovery/goam:input/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--ro flow-entropy-trill?   flow-entropy-trill
   augment /goam:path-discovery/goam:output/goam:response:
         +--ro upstream-rbridge?   tril-rb-nickname
         +--ro next-hop-rbridge*   tril-rb-nickname






Taylor & Zhuang           Expires June 13, 2016                [Page 18]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.2.5.  Performance Management (PM) Extension

5.2.5.1.  MEP PM Configuration Extension

   To support performance measurement for TRILL, MEP configuration in
   the LIME base model can be extended with:

   o  loss-stats-group: grouping statistics object for TRILL Loss
      measurement sessions;

   o  measurement-timing-group: grouping object used for proactive and
      on-demand scheduling of PM measurement sessions;

   o  delay-measurement-configuration-group: grouping configuration
      object for TRILL delay measurement function;

   o  delay-measurement-stats-group: grouping statistics object for
      TRILL delay measurement sessions.

5.2.5.2.  RPC PM Extension

   To support performance measurement for TRILL, it is recommended that
   four new RPCs are defined in the TRILL OAM PM model:

   o  create-loss-measurement RPC: allows scheduling of one-way or two-
      way on-demand or proactive performance monitoring loss measurement
      sessions.

   o  abort-loss-measurement RPC: allows aborting of currently running
      or scheduled loss measurement sessions.

   o  create-delay-measurement RPC: allows scheduling of one-way or two-
      way on-demand or proactive performance monitoring delay
      measurement sessions.

   o  abort-delay-measurement RPC: allows aborting of currently running
      or scheduled delay measurement sessions.

5.2.6.  Usage example

   This part gives a simple example of implementing the TRILL OAM model
   onto network devices.

   The scenario is shown in Figure 2, in which there are two companies:
   A and B.  Both have departments in City 1 and City 2.  Meanwhile,
   different departments within the same company should be able to
   communicate with each other.  However, the communication services of
   these two companies should be separated from each other.



Taylor & Zhuang           Expires June 13, 2016                [Page 19]

Internet-Draft      Applicability of LIME Base Model       December 2015


   To meet the requirements above, two Ethernet Lease line, E-Line-1 and
   E-Line-2, are set between NE1 and NE3: to isolate the communication
   traffic between two companies.  VLAN 100 associates port 3-EFF8-1 of
   NE1 facing with company A while VLAN 200 associates port 3-EF8-2 of
   NE1 facing with company B.  For network maintenance, NE1, NE2 and NE3
   are within a same maintenance domain: MD1.  Two maintenance
   associations MA1 and MA2 are configured and stand for E-Line-1 and
   E-Line-2 under MD1.  The MAC addresses of NE1, NE2, NE3 are MAC-FOO1,
   MAC-FOO2, MAC-FOO3 respectively.

                   +------+       +-----+       +------+
                   |      |       |     |       |      |
                   |  NE1 +-------| NE2 |-------+  NE3 |
                   |      |       |     |       |      |
           +-------+--+---+       +-----+       +---+--+---------+
   3-EFF8-1|          |3-EFF8-2                     |            |
           |          |                             |            |
         +-+-+     +--++                          +-+-+        +-+-+
         |   |     |   |                          |   |        |   |
         +---+     +---+                          +---+        +---+
          A          B                              A            B
              CITY1                                      CITY2

                       Figure 2: TRILL OAM scenario

5.2.6.1.  TRILL OAM Extension

   To fulfill the TRILL OAM configuration, the LME base model should be
   extended by augmenting the connectivity-context and inserting a port
   node in the MEP list.  The snippet below illustrates an example of
   TRILL OAM model extension.

   augment /goam:domains/goam:domain/goam:MAs
   /goam:MA/goam:MEP /goam:mep-address:
         +--:( mep-address-trill)
         |  +--rw mep-address-trill?  tril-rb-nickname
   augment /goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:connectivity-context:
         +--:(connectivity-context-vlan)
         |  +--rw connectivity-context-vlan?   vlan
         +--:(connectivity-context-fgl)
            +--rw connectivity-context-fgl?    fgl

   augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP
   /goam:session/goam:connectivity-context:
         +--:(connectivity-context-vlan)
         |  +--rw connectivity-context-vlan?   vlan
         +--:(connectivity-context-fgl)



Taylor & Zhuang           Expires June 13, 2016                [Page 20]

Internet-Draft      Applicability of LIME Base Model       December 2015


            +--rw connectivity-context-fgl?    fgl
   augment /goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:MEP/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--rw flow-entropy-trill?   flow-entropy-trill
   augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP
   /goam:session/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--rw flow-entropy-trill?   flow-entropy-trill
   augment /goam:continuity-check/goam:input:
         +--ro (out-of-band)?
         |  +--:(ipv4-address)
         |  |  +--ro ipv4-address?      inet:ipv4-address
         |  +--:(ipv6-address)
         |  |  +--ro ipv6-address?      inet:ipv6-address
         |  +--:(trill-nickname)
         |     +--ro trill-nickname?    tril-rb-nickname
         +--ro diagnostic-vlan?   boolean
   augment /goam:continuity-check/goam:input/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--ro flow-entropy-trill?   flow-entropy-trill
   augment /goam:continuity-check/goam:output:
         +--ro upstream-rbridge?   tril-rb-nickname
         +--ro next-hop-rbridge*   tril-rb-nickname
   augment /goam:path-discovery/goam:input:
         +--ro (out-of-band)?
         |  +--:(ipv4-address)
         |  |  +--ro ipv4-address?      inet:ipv4-address
         |  +--:(ipv6-address)
         |  |  +--ro ipv6-address?      inet:ipv6-address
         |  +--:(trill-nickname)
         |     +--ro trill-nickname?    tril-rb-nickname
         +--ro diagnostic-vlan?   boolean
   augment /goam:path-discovery/goam:input/goam:flow-entropy:
         +--:(flow-entropy-trill)
            +--ro flow-entropy-trill?   flow-entropy-trill
   augment /goam:path-discovery/goam:output/goam:response:
         +--ro upstream-rbridge?   tril-rb-nickname
         +--ro next-hop-rbridge*   tril-rb-nickname

5.2.6.2.  Corresponding XML Instance Example

   This section gives an example of the corresponding XML instance for
   devices to implement the example TRILL OAM data models in
   Section 5.2.6.1.

      <domains>
       <domains>



Taylor & Zhuang           Expires June 13, 2016                [Page 21]

Internet-Draft      Applicability of LIME Base Model       December 2015


        <technology> ethernet </techonlogy>
        <MD-name-string> MD1 </MD-name-string>
        <MAs>
         <MA>
          <MA-name-string>MA1</MA-name-string>
          <connectivity-context>
           <connectivity-context-vlan>
            100
           </connectivity-context-vlan>
          </connectivity-context>
          <MEP>
           <mep-name>NE1</mep-name>
           <mp-address>
            <mac-address>
             00-1E-4C-84-22-F1
            </mac-address>
           </mp-address>
          </MEP>
          <MEP>

           <mep-name>NE3</mep-name>
           <port>3-EFF8-1</port>
           <mp-address>
            <mac-address>
             00-1E-4C-84-22-F3
            </mac-address>
           </mp-address>
          </MEP>
          <MIP>NE2</MIP>
         </MA>
         <MA>
          <MA-name-string>MA2</MA-name-string>
          <connectivity-context>
           <connectivity-context-vlan>
            200
           </connectivity-context-vlan>
          </connectivity-context>
          <MEP>
           <mep-name>NE1</mep-name>
           <mp-address>
            <mac-address>
             00-1E-4C-84-22-F1
            </mac-address>
           </mp-address>
          </MEP>
          <MEP>
           <mep-name>NE3</mep-name>
           <mp-address>



Taylor & Zhuang           Expires June 13, 2016                [Page 22]

Internet-Draft      Applicability of LIME Base Model       December 2015


            <mac-address>
             00-1E-4C-84-22-F3
            </mac-address>
           </mp-address>
          </MEP>
          <MIP>NE2</MIP>
         </MA>
        </MAs>
       </domains>
      </domains>

5.3.  Generic YANG Model extension for MPLS OAM

5.3.1.  MD Configuration Extension

   MD level configuration parameters are management information which
   can be inherited in the MPLS OAM model and set by LIME base model as
   default values.  For example domain name can be set to area-ID in the
   MPLS OAM case.  In addition, at the Maintenance Domain level, domain
   data node at root level can be augmented with technology type and
   sub-technology type.

   Note that MD level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.  MD level configuration
   parameters MUST not be carried using MPLS OAM protocol(e.g., LSP
   Ping) since MPLS OAM protocol doesn't support transport of these
   management information.

5.3.1.1.  Technology Type Extension

   No MPLS technology type has been defined in the LIME base model,
   hence it is required in the MPLS OAM model.  The technology type
   "mpls" is defined as an identity that augments the base "technology-
   types" defined in the LIME base model:

      identity mpls{
       base goam:technology-types;
       description
        "mpls type";
      }

5.3.1.2.  Sub Technology Type Extension

   In MPLS, since different encapsulation types such as IP/UDP
   Encapsulation, PW-ACH encapsulation can be employed, the "technology-
   sub-type" data node is defined and added into the MPLS OAM model to



Taylor & Zhuang           Expires June 13, 2016                [Page 23]

Internet-Draft      Applicability of LIME Base Model       December 2015


   further identify the encapsulation types within the MPLS OAM model.
   Based on it, we also define a technology sub-type for IP/UDP
   encapsulation and PW-ACH encapsulation.  Other Encapsulation types
   can be defined in the same way.

      identity technology-sub-type {
                description
                  "certain implementations can have different
                   encapsulation types such as ip/udp, pw-ach and so on.
                   Instead of defining separate models for each
                   encapsulation, we define a technology sub-type to
                   further identify different encapsulations. Technology
                   sub-type is associated at the MA level";
              }

           identity technology-sub-type-udp {
             base technology-sub-type;
             description
               "technology sub-type is IP/UDP encapsulation";
           }

           identity technology-sub-type-ach {
             base technology-sub-type;
             description
               "technology sub-type is PW-ACH encapsulation";
           }
           }

      augment "/goam:domains/goam:domain/goam:MAs/goam:MA" {
             leaf technology-sub-type {
               type identityref {
                 base technology-sub-type;
               }
             }
           }

5.3.2.  MA Configuration Extension

   MA level configuration parameters are management information which
   can be inherited in the MPLS- OAM model and set by LIME base model as
   default values.  In addition, at the Maintenance Association(MA)
   level, MA data node at the second level can be augmented with
   connectivity-context extension.

   Note that MA level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.  MA level configuration



Taylor & Zhuang           Expires June 13, 2016                [Page 24]

Internet-Draft      Applicability of LIME Base Model       December 2015


   parameters MUST not be carried using MPLS OAM protocol(e.g., LSP
   Ping) since MPLS OAM protocol doesn't support transport of these
   management information.

5.3.2.1.  Connectivity-Context Extension

   In MPLS, one example of context-id is a 20 bit MPLS label.  The LIME
   base model defines a placeholder for context-id.  This allows other
   technologies to easily augment that to include technology specific
   extensions.  The snippet below depicts an example of augmenting
   context-id to include per VRF MPLS labels in IP VPN or per CE MPLS
   labels in IP VPN.

   augment "/goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:connectivity-context"
            {
              case connectivity-context-mpls {
                 leaf vrf-label {
                   type vrf-label;
                 }
               }
            }

5.3.3.  MEP Configuration Extension

   In MPLS, the MEP address is either an IPv4 or IPV6 address in case
   IP/UDP encapsulation.  MEP-ID is either a 2 octet unsigned integer
   value in case IP/UDP encapsulation or a variable length label value
   in case of G-ACH encapsulation.  In the LIME base model, MEP-ID is
   defined as a variable length label value and the same definition can
   be used for MPLS with no further modification.  In addition, at the
   Maintenance Association Endpoint(MEP) level, MEP data node at the
   third level can be augmented with Session extension and interface
   extension.

5.3.3.1.  ECMP Extension

   Since MPLS supports ECMP path selection, the flow-entropy should be
   defined in MPLS OAM model.  Technology type is used to extend the
   YANG model to specific usage.











Taylor & Zhuang           Expires June 13, 2016                [Page 25]

Internet-Draft      Applicability of LIME Base Model       December 2015


   augment "/goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:flow-entropy" {
          case flow-entropy-mpls {
            leaf flags-mpls {
              type flags-mpls;
            }
            leaf flow-entropy-mpls{
              type flow-entropy-mpls;
            }
          }
        }

5.3.3.2.  Per interface Configuration Extension

   TBC.

5.3.4.  RPC Extension

5.3.4.1.  CV extension for LSP Ping

5.3.4.2.  Path Discovery Extension for LSP Ping

5.3.4.3.  New RPC Alarm Indication Signal (AIS)

   See [RFC6427].

5.3.4.4.  New RPC for Lock Report (LKR)

   See [RFC6427].

5.3.5.  Performance Management Extension

5.3.5.1.  MEP Configuration Extension

   To support performance monitoring for MPLS, MEP configuration in the
   LIME base model can be extended with:

   o  TBC.

5.3.5.2.  RPC Extension

   To support performance monitoring for MPLS, it is recommended that
   five new RPCs are defined in the MPLS OAM PM model:

   o  MPLS Direct Loss Measurement (DLM) RPC [RFC6374];

   o  MPLS Inferred Loss Measurement (ILM) RPC [RFC6374];




Taylor & Zhuang           Expires June 13, 2016                [Page 26]

Internet-Draft      Applicability of LIME Base Model       December 2015


   o  MPLS Delay Measurement (DM) RPC [RFC6374];

   o  MPLS Direct Loss and Delay Measurement RPC [RFC6374];

   o  MPLS Inferred Loss and Delay Measurement RPC [RFC6374].

5.3.6.  Usage Example

   In the MPLS tunnel scenario (see Figure 3): tunnel_1 is a static LSP
   tunnel passing through NE1-NE2-NE4.  It is used to perform LSP PING.
   tunnel_3 is another static LSP tunnel passing through NE4-NE2-NE1,
   used to bring back the LSP PING result.  tunnel_2 is a third static
   LSP tunnel passing through NE1-NE3-NE4, used to perform LSP
   Traceroute. tunnel_4 is a fourth static LSP tunnel passing through
   NE4-NE3-NE1, used to bring back the LSP Traceroute result.

                                 +-------+
                                 |       |
                +--------------->+  NE2  +----------------+
                | ...............|       |<.............. |
                | .              +-------+              . |
                | .                                     . |
                | v                                     . v
            +---+---+                                 +---+---+
            |       |                                 |       |
            |  NE1  |                                 |  NE4  |
            |       |                                 |       |
            +---+---+                                 +---+--^+
             .  ^                                         |  .
             .  |                                         |  .
             .  |                +-------+                |  .
             .  |                |       |                |  .
             .  +----------------+  NE3  +<---------------+  .
             ....................|       |....................
                                 +-------+


        ----- forward direction LSP tunnel
        ......backward direction LSP tunnel

                        Figure 3: MPLS OAM scenario

5.3.6.1.  MPLS OAM Model Extension

   TBD.






Taylor & Zhuang           Expires June 13, 2016                [Page 27]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.3.6.2.  Corresponding XML Instance Example

   TBD.

5.4.  Generic YANG Model extension for MPLS-TP OAM

5.4.1.  MD Configuration Extension

   MD level configuration parameters are management information which
   can be inherited in the MPLS-TP OAM model and set by LIME base model
   as default values.  For example domain name can be set to area-ID or
   the provider's Autonomous System Number (ASN) [RFC6370] in the MPLS-
   TP OAM case.  In addition, at the Maintenance Domain level, domain
   data node at root level can be augmented with technology type and
   sub-technology type.

   Note that MD level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures

5.4.1.1.  Technology Type Extension

   No MPLS-TP technology type has been defined in the LIME base model,
   hence it is required in the MPLS OAM model.  The technology type
   "mpls-tp" is defined as an identity that augments the base
   "technology- types" defined in the LIME base model:

    identity mpls-tp{
          base goam:technology-types;
          description
           "mpls-tp type";
         }

5.4.1.2.  Sub Technology Type Extension

   In MPLS-TP, since different encapsulation types such as IP/UDP
   Encapsulation, PW-ACH encapsulation can be employed, the "technology-
   sub-type" data node is defined and added into the MPLS OAM model to
   further identify the encapsulation types within the MPLS-TP OAM
   model.  Based on it, we also define a technology sub-type for IP/UDP
   encapsulation and PW-ACH encapsulation.  Other Encapsulation types
   can be defined in the same way.








Taylor & Zhuang           Expires June 13, 2016                [Page 28]

Internet-Draft      Applicability of LIME Base Model       December 2015


      identity technology-sub-type {
                description
                  "certain implementations can have different
                   encapsulation types such as ip/udp, pw-ach and so on.
                   Instead of defining separate models for each
                   encapsulation, we define a technology sub-type to
                   further identify different encapsulations. Technology
                   sub-type is associated at the MA level";
              }

           identity technology-sub-type-udp {
             base technology-sub-type;
             description
               "technology sub-type is IP/UDP encapsulation";
           }

           identity technology-sub-type-ach {
             base technology-sub-type;
             description
               "technology sub-type is PW-ACH encapsulation";
           }
           }

      augment "/goam:domains/goam:domain/goam:MAs/goam:MA" {
             leaf technology-sub-type {
               type identityref {
                 base technology-sub-type;
               }
             }
           }

5.4.2.  MA Configuration Extension

   MA level configuration parameters are management information which
   can be inherited in the MPLS-TP OAM model and set by LIME base model
   as default values.  One example of MA Name is MEG LSP ID or MEG
   Section ID or MEG PW ID[RFC6370].  In addition, at the Maintenance
   Association(MA) level, MA data node at the second level can be
   augmented with connectivity-context extension.

   Note that MA level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.







Taylor & Zhuang           Expires June 13, 2016                [Page 29]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.4.2.1.  Connectivity-Context Extension

   In MPLS-TP, one example of context-id is a 20 bit MPLS label.  The
   LIME base model defines a placeholder for context-id.  This allows
   other technologies to easily augment that to include technology
   specific extensions.  The snippet below depicts an example of
   augmenting context-id to include per VRF MPLS labels in IP VPN
   [RFC4364] or per CE MPLS labels in IP VPN [RFC4364].

      augment "/goam:domains/goam:domain/goam:MAs/goam:MA
      /goam:connectivity-context"
               {
                 case connectivity-context-mpls {
                    leaf vrf-label {
                      type vrf-label;
                    }
                  }
               }

5.4.3.  MEP Configuration Extension

   In MPLS-TP, MEP-ID is either a variable length label value in case of
   G-ACH encapsulation or a 2 octet unsigned integer value in case of
   IP/UDP encapsulation.  One example of MEP-ID is MPLS-TP LSP_MEP_ID
   [RFC6370].  In case of using IP/UDP encapsulation, the MEP address
   can be either an IPv4 or IPV6 address.  In the LIME base model, MEP-
   ID is defined as a variable length label value and the same
   definition can be used for MPLS-TP with no further modification.  In
   addition, at the Maintenance Association Endpoint(MEP) level, MEP
   data node at the third level can be augmented with Session extension
   and interface extension.

5.4.3.1.  ECMP Extension

   The flow-entropy parameter in the LIME OAM configuration model is an
   optional parameter.  Standard MPLS-TP OAM protocol does not support
   ECMP path selection, so the flow-entropy parameter does not need to
   be supported in the MPLS-TP OAM model.

5.4.3.2.  Per interface Configuration Extension

   TBC.

5.4.4.  RPC Extension







Taylor & Zhuang           Expires June 13, 2016                [Page 30]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.4.4.1.  CC extension for MPLS-TP BFD CC Message

5.4.4.2.  CV extension for MPLS-TP BFD CV Message

5.4.4.3.  CV extension for On-Demand LSP CV with Non-IP Encapsulation

5.4.4.4.  CV extension for On-Demand LSP CV with IP Encapsulation

5.4.4.5.  New RPC for Remote Defect Indication

   See [RFC6435].

5.4.4.6.  New RPC for Lock Instruct

   See [RFC6435].

5.4.5.  Performance Monitoring Extension

5.4.5.1.  MEP Configuration Extension

   To support performance monitoring for MPLS-TP, MEP configuration in
   the LIME base model can be extended with:

   o  TBC.

5.4.5.2.  RPC Extension

   To support performance monitoring for MPLS-TP, it is recommended that
   five new RPCs are defined in the MPLS OAM PM model:

   o  MPLS-TP Loss Measurement (LM) Message RPC [RFC6375];

   o  MPLS-TP Test Message RPC [RFC6375];

   o  MPLS-TP Delay Measurement(DM) Message RPC [RFC6375];

5.5.  Generic YANG Model extension for NVO3 OAM

5.5.1.  Technology Type Extension

   No NVO3 technology type has been defined in the LIME base model.
   Therefore technology type extension is required in the NVO3 OAM
   model.  The technology type "nvo3" is defined as an identity that
   augments the base "technology-types" defined in the LIME base model:







Taylor & Zhuang           Expires June 13, 2016                [Page 31]

Internet-Draft      Applicability of LIME Base Model       December 2015


      identity nvo3{
       base goam:technology-types;
       description
        "nvo3 type";
      }

5.5.2.  Sub Technology Type Extension

   In NVO3, since different overlay encapsulation types such as VxLAN,
   NVGRE can be employed, the "technology-sub-type" data node is defined
   and added into the NVO3 OAM model to further identify the overlay
   types within the NVO3 model.  Based on it, we also define a
   technology sub-type for VxLAN encapsulation.  NVGRE and GENEVE, sub-
   types can be defined in the same way.

   identity technology-sub-type {
             description
               "certain implementations such as nvo3 can have different
                encapsulation types such as vxlan, nvgre and so on.
                Instead of defining separate models for each
                encapsulation, we define a technology sub-type to
                further identify different encapsulations. Technology
                sub-type is associated at the MA level";
           }

        identity technology-sub-type-vxlan {
          base technology-sub-type;
          description
            "technology sub-type is vxlan";
        }
   augment "/goam:domains/goam:domain/goam:MAs/goam:MA" {
          leaf technology-sub-type {
            type identityref {
              base technology-sub-type;
            }
          }
        }

5.5.3.  MEP Configuration Extension

   In NVO3, the MEP address is either an IPv4 or IPV6 address.  In the
   LIME base model, MEP address is defined as an IP address and the same
   definition can be used for NVO3 with no further modification.








Taylor & Zhuang           Expires June 13, 2016                [Page 32]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.5.4.  Connectivity-Context Extension

   In NVO3, one example of context-id is a 24 bit virtual network
   identifier (VNI).  The LIME base model defines a placeholder for
   context-id.  This allows other technologies to easily augment that to
   include technology specific extensions.  The snippet below depicts an
   example of augmenting context-id to include VNI.

   augment "/goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:connectivity-context"
            {
               case connctivity-context-nvo3 {
                 leaf vni {
                   type vni;
                 }
               }
            }

5.5.5.  RPC Extension

   In the NVO3 OAM YANG model, the End-Station-Locator RPC command is
   defined.  This command locates an end-station within the NVO3
   deployment.  [PTT -- what other tools are applicable??? Presumably
   one can use ICMP Ping, LSP Ping for CV, and the PM extensions, per
   RFC 7276 Table 4.]

5.5.6.  ECMP Extension

   In NVO3, flow-entropy depends on the technology sub-type, e.g.,
   VxLAN.  Technology sub-type is used to extend the base model to
   specific usage.  The snippet below illustrates the extension for
   VxLAN.

   augment "/goam:domains/goam:domain/goam:MAs/goam:MA
   /goam:flow-entropy" {
          case flow-entropy-vxlan {
            leaf flags-vxlan {
              type flags-vxlan;
            }
            leaf flow-entropy-vxlan {
              type flow-entropy-vxlan;
            }
          }
        }







Taylor & Zhuang           Expires June 13, 2016                [Page 33]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.6.  Generic YANG Model extension for BFD

5.6.1.  MD Level configuration extension

   MD level configuration parameters are management information which
   can be inherited in the BFD model and set by LIME base model as
   default values.  For example domain name can be set to area-ID in the
   BFD case.  In addition, at the Maintenance Domain level, domain data
   node at root level can be augmented with technology type and sub-
   technology type.

   Note that MD level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.  MD level configuration
   parameters MUST not be carried using BFD protocol since BFD doesn't
   support transport of these management information.

5.6.1.1.  Technology Type Extension

   No BFD technology type has been defined in the LIME base model.
   Therefore a technology type extension is required in the BFD OAM
   model.  The technology type "bfd" is defined as an identity that
   augments the base "technology-types" defined in the LIME base model:

5.6.1.2.  Sub Technology Type Extension

   In BFD, since different encapsulation types such as IP/UDP
   Encapsulation, PW-ACH encapsulation can be employed.

   In lime-bfd-extension yang data model, we define an identity:
   "technology-sub-type" to further identify the encapsulation types
   within the BFD.  And based on it, we also define four identity
   encapsulation types:

   o  technology-sub-type-sh-udp: technology sub-type is single hop with
      IP/UDP encapsulation;

   o  technology-sub-type-mh-udp: technology sub-type is multiple hop
      with IP/UDP encasulation;

   o  technology-sub-type-sh-ach: technology sub-type is single hop with
      PW-ACH encapsulation;

   o  technology-sub-type-mh-ach: technology sub-type is multiple hop
      with PW-ACH encapsulation;





Taylor & Zhuang           Expires June 13, 2016                [Page 34]

Internet-Draft      Applicability of LIME Base Model       December 2015


   In MD level, we define a sub-technology leaf with an identityref type
   which base on the technology-sub-type:

      augment "/goam:domains/goam:domain/" {
             leaf sub-technology{
               type identityref {
                 base technology-sub-type;
               }
             }
           }

5.6.2.  MA configuration extension

   MA level configuration parameters are management information which
   can be inherited in the BFD model and set by LIME base model as
   default values.  In addition, at the Maintenance Association(MA)
   level, MA data node at the second level can be augmented with
   connectivity-context extension.

   Note that MA level configuration parameters provides context
   information for management system to correlate faults, defects,
   network failures with location information, which helps quickly
   identify root causes of network failures.  MA level configuration
   parameters MUST not be carried using BFD protocol since BFD doesn't
   support transport of these management information.

5.6.2.1.  Connectivity-Context Extension

   In BFD, one example of context-id is a 32bit local discriminator.
   The LIME base model defines a placeholder for context-id.  This
   allows other technologies to easily augment that to include
   technology specific extensions.  The snippet below depicts an example
   of augmenting context-id to include local discriminator.

   augment "/goam:domains/goam:domain/goam:MAs/goam:MA
     /goam:connectivity-context"
                  {
                    case connectivity-context-bfd {
                       leaf local-discriminator {
                         type local-discriminator;
                       }
                     }
                  }








Taylor & Zhuang           Expires June 13, 2016                [Page 35]

Internet-Draft      Applicability of LIME Base Model       December 2015


5.6.3.  MEP configuration extension

   In BFD, the MEP address is either an IPv4 or IPV6 address.  MEP-ID is
   either a 2 octet unsigned integer value or a variable length label
   value.  In the LIME base model, MEP-ID is defined as a variable
   length label value and the same definition can be used for BFD with
   no further modification.  In addition, at the Maintenance Association
   Endpoint(MEP) level, MEP data node at the third level can be
   augmented with Session extension and interface extension.

5.6.3.1.  Session Configuration Extension

   At the Session level, Session data node at the fouth level can be
   augmented with 3 interval parameters and 2 TTL parameters.  In
   [draft-zheng-bfd-yang], source and destination address in the bfd-
   session-cfg can be corresponding to Session configuration extension
   as source MEP and destination MEP.

augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session:
+--rw (interval-config-type)?
|  +--:(tx-rx-intervals)
|  |  +--rw desired-min-tx-interval     uint32
|  |  +--rw required-min-rx-interval    uint32
|  +--:(single-interval)
|     +--rw min-interval                uint32

augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session:
+--rw tx-ttl?                     ttl
+--rw rx-ttl                      ttl

5.6.3.2.  Interface configuration extension

   At the Interface level, interface data node at the fifth level can be
   augmented with the same parameters defined in per-interface
   configuration of [draft-zheng-bfd-yang].
















Taylor & Zhuang           Expires June 13, 2016                [Page 36]

Internet-Draft      Applicability of LIME Base Model       December 2015


augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam: outgoing-interface:
+--rw local-multiplier?                multiplier
+--rw (interval-config-type)?
|  +--:(tx-rx-intervals)
|  |  +--rw desired-min-tx-interval          uint32
|  |  +--rw required-min-rx-interval         uint32
|  +--:(single-interval)
|     +--rw min-interval                     uint32
+--rw demand-enabled?                  boolean
+--rw enable-authentication?           boolean
+--rw authentication-parms {bfd-authentication}?
|  +--rw key-chain-name?   string
|  +--rw algorithm?        bfd-auth-algorithm
+--rw desired-min-echo-tx-interval?    uint32
+--rw required-min-echo-rx-interval?   uint32

5.6.3.3.  New Notification definition

   [GENYANGOAM] defines a notification model which abstracts defects
   notification in a technology independent manner.However what BFD is
   required is state change notification, therefore a new notification
   definition can be specified to meet BFD requirement.

   notifications:
      +---n state-change-notification
         +--ro local-discriminator?      uint32
         +--ro remote-discriminator?     uint32
         +--ro new-state?                enumeration
         +--ro state-change-reason?      string
         +--ro time-in-previous-state?   string
         +--ro dest-addr?                inet:ip-address
         +--ro source-addr?              inet:ip-address
         +--ro session-cookie?           leafref
         +--ro technology-sub-type?      identityref
         +--ro interface?                leafref
         +--ro echo-enabled?             boolean

   In this state-change-notification, technology-sub-type is used to
   identify whether the notification is for single hop or multi-hop or
   other types.

6.  Open Issues

      Do we need to specify usage examples for each technology-specific
      OAM model?

      Applicability of LIME base model structure on BFD in details




Taylor & Zhuang           Expires June 13, 2016                [Page 37]

Internet-Draft      Applicability of LIME Base Model       December 2015


      Applicability of LIME base model structure on MPLS OAM and MPLS-TP
      OAM.

7.  Security Considerations

   TBD.

8.  IANA Considerations

   This document registers the following namespace URI in the IETF XML
   registry.

   URI:TBD

9.  Acknowledgements

   The authors would like to thank Gregory Mirsky for his valuable
   comments and suggestions on this document.

10.  References

10.1.  Normative References

   [GENYANGOAM]
              Senevirathne , T., Finn, N., Kumar, D., Salam, S., Wu, Q.,
              and Z. Wang, "Generic YANG Data Model for Operations,
              Administration, and Maintenance (OAM)", ID
              https://datatracker.ietf.org/doc/draft-tissa-lime-yang-
              oam-model/, June 2015.

   [IEEE802.1Q]
              "Media Access Control (MAC) Bridges and Virtual Bridged
              Local Area Networks", IEEE Std 802.1Q-2011, August 2011.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <http://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", June
              2011.

10.2.  Informative References







Taylor & Zhuang           Expires June 13, 2016                [Page 38]

Internet-Draft      Applicability of LIME Base Model       December 2015


   [I-D.wang-lime-yang-pm]
              Wang, Z., Wu, Q., Kumar, D., and T. Taylor, "Generic YANG
              Data Model for Operations, Administration, and Maintenance
              (OAM) Performance Management", draft-wang-lime-yang-pm-01
              (work in progress), November 2015.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <http://www.rfc-editor.org/info/rfc4379>.

   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
              Acronym in the IETF", BCP 161, RFC 6291,
              DOI 10.17487/RFC6291, June 2011,
              <http://www.rfc-editor.org/info/rfc6291>.

   [RFC6325]  Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
              Ghanwani, "Routing Bridges (RBridges): Base Protocol
              Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011,
              <http://www.rfc-editor.org/info/rfc6325>.

   [RFC6371]  Busi, I., Ed. and D. Allan, Ed., "Operations,
              Administration, and Maintenance Framework for MPLS-Based
              Transport Networks", RFC 6371, DOI 10.17487/RFC6371,
              September 2011, <http://www.rfc-editor.org/info/rfc6371>.

   [RFC7174]  Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake
              3rd, "Transparent Interconnection of Lots of Links (TRILL)
              Operations, Administration, and Maintenance (OAM)
              Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014,
              <http://www.rfc-editor.org/info/rfc7174>.

   [RFC7276]  Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
              Weingarten, "An Overview of Operations, Administration,
              and Maintenance (OAM) Tools", RFC 7276,
              DOI 10.17487/RFC7276, June 2014,
              <http://www.rfc-editor.org/info/rfc7276>.

   [RFC792]   Postel, J., "Internet Control Message Protocol", RFC 792,
              September 1981.

   [TRILLOAMYANG]
              Kumar, D., Senevirathne, T., Finn, N., Salam, S., Xia, L.,
              and W. Hao, "YANG Data Model for TRILL Operations,
              Administration, and Maintenance (OAM) (Work in progress)",
              May 2015.




Taylor & Zhuang           Expires June 13, 2016                [Page 39]

Internet-Draft      Applicability of LIME Base Model       December 2015


Appendix A.  Contributing Authors Infomation

      Huub van Helvoort
      Hai Gaoming BV
      Netherlands

      Email: huubatwork@gmail.com

      Roland Schott
      Deutsche Telekom
      Deutsche-Telekom-Allee 7
      Darmstadt  64295
      Germany

      EMail: Roland.Schott@telekom.de

      Qin Wu
      Huawei
      101 Software Avenue, Yuhua District
      Nanjing, Jiangsu  210012
      China

      Email: bill.wu@huawei.com

      Deepak Kumar
      CISCO Systems
      510 McCarthy Blvd
      Milpitas, CA  95035
      USA

      Email: dekumar@cisco.com

      Yuji Tochio
      Fujitsu
      Japan

      Email: tochio@jp.fujitsu.com

      Guangying Zheng
      Huawei
      101 Software Avenue, Yuhua District
      Nanjing, Jiangsu  210012
      China

      Email: zhengguangying@huawei.com

      Daniel King
      Lancaster University



Taylor & Zhuang           Expires June 13, 2016                [Page 40]

Internet-Draft      Applicability of LIME Base Model       December 2015


      UK

      Email: daniel@olddog.co.uk

      Zitao Wang
      Huawei Technologies,Co.,Ltd
      101 Software Avenue, Yuhua District
      Nanjing  210012
      China

      Email: wangzitao@huawei.com

Authors' Addresses

   Tom Taylor  (editor)
   PT Taylor Consulting
   Ottawa
   Canada

   Email: tom.taylor.stds@gmail.com


   Yan Zhuang (editor)
   Huawei Technologies,Co.,Ltd
   101 Software Avenue, Yuhua District
   Nanjing  210012
   China

   Email: zhuangyan.zhuang@huawei.com






















Taylor & Zhuang           Expires June 13, 2016                [Page 41]