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. Taylor & Zhuang Expires June 13, 2016 [Page 21] Internet-Draft Applicability of LIME Base Model December 2015 ethernet MD1 MA1 100 NE1 00-1E-4C-84-22-F1 NE3 3-EFF8-1 00-1E-4C-84-22-F3 NE2 MA2 200 NE1 00-1E-4C-84-22-F1 NE3 Taylor & Zhuang Expires June 13, 2016 [Page 22] Internet-Draft Applicability of LIME Base Model December 2015 00-1E-4C-84-22-F3 NE2 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, . [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, . [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, . [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, . [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, . [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, . [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, . [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]