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:

• configuration model definition;
• Remote procedure call (RPC) definition;
• 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.

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.

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

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

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:

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:

• Extend structure for configuration with technology specific parameters
• Extend structure for notification with technology specific parameters
• Extend structure for RPC with technology specific parameters
• 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 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:

• Maintenance domain (MD) at the root level;
• Maintenance Association (MA) at the second level;
• Maintenance Association Endpoint (MEP) and Maintenance Association Intermediate point(MIP) at the third level;
• Session at the fourth level;
• 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.

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:

   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 data. There are two places which we can choose as anchor point to insert additional data definitions:

• 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";
     }

• Output data node

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

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 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 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.

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:

• loss-stats-group: grouping object for loss measurement session statistics.
• measurement-timing-group: grouping object used for proactive and on-demand scheduling of PM measurement sessions.
• delay-measurement-configuration-group: grouping configuration object for the delay measurement function.
• delay-measurement-stats-group: grouping object for delay measurement session statistics.
• loss-measurement-configuration-group: grouping configuration object for the loss measurement function.
• 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:

• create-loss-measurement RPC: allows scheduling of one-way or two-way on-demand or proactive performance monitoring loss measurement sessions.
• abort-loss-measurement RPC: allows aborting of currently running or scheduled loss measurement session.
• create-delay-measurement RPC: allows scheduling of one-way or two-way on-demand or proactive performance monitoring delay measurement sessions.
• 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.

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.

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

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:

• loss-stats-group: grouping statistics object for TRILL Loss measurement sessions;
• measurement-timing-group: grouping object used for proactive and on-demand scheduling of PM measurement sessions;
• delay-measurement-configuration-group: grouping configuration object for TRILL delay measurement function;
• 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:

• create-loss-measurement RPC: allows scheduling of one-way or two-way on-demand or proactive performance monitoring loss measurement sessions.
• abort-loss-measurement RPC: allows aborting of currently running or scheduled loss measurement sessions.
• create-delay-measurement RPC: allows scheduling of one-way or two-way on-demand or proactive performance monitoring delay measurement sessions.
• 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.

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

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)
         +--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

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

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

   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;
            }
          }
        }

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

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;
         }
       }
     }

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


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

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

   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;
            }
          }
        }

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

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

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;
         }
       }
     }

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

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;
         }
       }
     }

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

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

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

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

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

   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
   UK

   Email: daniel@olddog.co.uk

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

   Email: wangzitao@huawei.com