<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wang-yang-bfd-oam-06" ipr="trust200902">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="YANG LIME BFD OAM">LIME base model extension for BFD
    Support</title>

    <author fullname="Zitao Wang" initials="Z." surname="Wang">
      <organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <street/>

          <city>Nanjing</city>

          <region/>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>wangzitao@huawei.com</email>
      </address>
    </author>

    <author fullname="Liang Xia" initials="L" surname="Xia">
      <organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <street/>

          <city>Nanjing</city>

          <region/>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>frank.xialiang@huawei.com</email>
      </address>
    </author>

    <author fullname="Deepak Kumar" initials="D." surname="Kumar">
      <organization abbrev="Cisco">Cisco Systems</organization>

      <address>
        <postal>
          <street>510 McCarthy Blvd Milpitas,</street>

          <street/>

          <city>CA</city>

          <region/>

          <code>95035</code>

          <country>USA</country>
        </postal>

        <email>dekumar@cisco.com</email>
      </address>
    </author>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <date year="2015"/>

    <area>Routing Area</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>BFD YANG OAM</keyword>

    <abstract>
      <t>This document discusses how LIME base model is applied to BFD and
      present an example of YANG Data model for BFD support. The YANG Model
      presented in this document extends the technology independent YANG model
      for OAM with BFD technology specifics.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>[draft-ietf-bfd-yang] defines a YANG data model that can be used to
      configure and manage Bidirectional Forwarding Detection (BFD). This
      document discusses how LIME base model is applied to BFD and present an
      example of YANG Data model for BFD support. The YANG Model example
      presented in this document extends the Generic YANG model for OAM
      defined in [I-D.ietf-lime-yang-oam- model]. The YANG model example uses
      the grouping defined in the BFD model [draft-ietf-bfd-yang]. The
      groupings contain the basic BFD session parameters for applications to
      use.</t>
    </section>

    <section title="Conventions and Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"/>.</t>

      <t>The following terms are defined in [RFC6241] and are not redefined
      here:</t>

      <t><list style="symbols">
          <t>client</t>

          <t>configuration data</t>

          <t>server</t>

          <t>state data</t>
        </list></t>

      <t>The following terms are defined in [RFC6020] and are not redefined
      here:</t>

      <t><list style="symbols">
          <t>augment</t>

          <t>data model</t>

          <t>data node</t>
        </list></t>

      <t>The terminology for describing YANG data models is found in
      [RFC6020].</t>

      <section title="Tree Diagrams">
        <t>A simplified graphical representation of the data model is used in
        this document. The meaning of the symbols in these diagrams is as
        follows:</t>

        <t>Each node is printed as:<figure>
            <artwork>
&lt;status&gt; &lt;flags&gt; &lt;name&gt; &lt;opts&gt; &lt;type&gt;

&lt;status&gt; is one of:
     +  for current
     x  for deprecated
     o  for obsolete


&lt;flags&gt; is one of:

    rw for configuration data 
    ro for non-configuration data
    -x for rpcs
    -n for notifications


&lt;name&gt; is the name of the node</artwork>
          </figure></t>

        <t>If the node is augmented into the tree from another module, its
        name is printed as &lt;prefix&gt;:&lt;name&gt;. <figure>
            <artwork>&lt;opts&gt; is one of:

     ?  for an optional leaf or choice
     !  for a presence container
     *  for a leaf-list or list
     [&lt;keys&gt;] for a list's keys

&lt;type&gt; is the name of the type for leafs and leaf-lists</artwork>
          </figure></t>
      </section>
    </section>

    <section title="Interaction between BFD OAM YANG model and LIME base model">
      <t>Both BFD model and LIME model can be developed as generic model. LIME
      model can be extended for BFD to provide consistent configuration,
      representaion and reporting. Therefore LIME model extension for BFD can
      be viewed as a BFD application. The consistent configuration and
      representation can be met by extending LIME configuration structure
      while the consistent reporting and representation can be met by
      extending LIME RPC structure or Notification Structure. Generic YANG
      model for OAM defined in [I-D.ietf-lime-yang-oam-model] can also be used
      as the basis for all the other OAM YANG models. This allows users to
      span across OAM tools of different technologies through a uniform API.
      The following Figure depicts the relationship of BFD OAM YANG model to
      the Layer Independent OAM YANG Model. <figure
          title="Relationship of BFD OAM YANG model to technology independent OAM YANG model">
          <artwork>      
                       +-+-+-+-+-+
                       |  Layer  |
                       |independent
                       |OAM YANG |
                       +-+-+-+-+-+
                            |
                            O
                            |
    +--------------------------------------------------+
    |               |                    |             |
+-+-+-+-+-+    +-+-+-+-+-+          +-+-+-+-+-+   +-+-+-+-+-+
| TRILL   |    | NVO3    |          | BFD     |. .|  foo    |
|OAM YANG |    |OAM YANG |          |OAM YANG |   |OAM YANG |
+-+-+-+-+-+    +-+-+-+-+-+          +-+-+-+-+-+   +-+-+-+-+-+
      |              |                    |            |
      |              |                    |            |
      |              |                    |            |
    +----------------------------------------------------+
    |             Uniform API                            |
    +----------------------------------------------------+
</artwork>
        </figure></t>
    </section>

    <section title="Generic YANG Model extension for BFD">
      <section title="MD Level configuration extension">
        <t>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.</t>

        <section title="Technology Type Extension">
          <t>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:</t>
        </section>

        <section title="Sub Technology Type Extension">
          <t>In BFD, since different encapsulation types such as IP/UDP
          Encapsulation, PW-ACH encapsulation can be employed.</t>

          <t>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:<list style="symbols">
              <t>technology-sub-type-sh-udp: technology sub-type is single hop
              with IP/UDP encapsulation;</t>

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

              <t>technology-sub-type-sh-ach: technology sub-type is single hop
              with PW-ACH encapsulation;</t>

              <t>technology-sub-type-mh-ach: technology sub-type is multiple
              hop with PW-ACH encapsulation;</t>
            </list></t>

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

          <figure>
            <artwork>   augment "/goam:domains/goam:domain/" {
          leaf sub-technology{
            type identityref {
              base technology-sub-type;
            }
          }
        }</artwork>
          </figure>
        </section>
      </section>

      <section title="MA configuration extension">
        <t>MA level configuration parameters (e.g., MA Name)are management
        information which can be inherited in the BFD model and set by LIME
        base model as default values. One example of MA Name is Tunnel Name or
        LAG Name. In addition, at the Maintenance Association(MA) level, MA
        data node at the second level can be augmented with
        connectivity-context extension.</t>

        <section title="Connectivity-Context Extension">
          <t>In BFD 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.</t>

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

      <section title="MEP configuration extension">
        <t>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.</t>

        <section title="Session Configuration Extension">
          <t>At the Session level, Session data node at the fouth level can be
          augmented with 3 interval parameters and 2 TTL parameters. The
          Session Configuration extension should reuse grouping defined in
          [draft-ietf-bfd-yang] for session related parameters. In
          [draft-ietf-bfd-yang], source and destination address in the
          bfd-session-cfg can be corresponding to Session configuration
          extension as source MEP and destination MEP.</t>

          <figure>
            <artwork>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
</artwork>
          </figure>
        </section>

        <section title="Interface configuration extension">
          <t>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-ietf-bfd-yang]. Interface configuration
          extension should reuse grouping defined in [draft-ietf-bfd-yang] for
          interface related parameters. </t>

          <figure>
            <artwork>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
</artwork>
          </figure>
        </section>

        <section title="New Notification definition">
          <t>[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. The new
          notification defintion should reuse groupings defined in
          [draft-ietf-bfd-yang] for state change related parameters.</t>

          <figure>
            <artwork>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</artwork>
          </figure>

          <t>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.</t>
        </section>
      </section>
    </section>

    <section title="Model structure of LIME model extension for BFD">
      <t>The complete data hierarchy related to the OAM YANG model is
      presented below. <figure title="Data hierarchy of BFD OAM">
          <artwork>module: lime-bfd-extension
augment /goam:domains/goam:domain/goam:MAs/goam:MA:
   +--rw technology-sub-type?   identityref
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session:
   +--rw on-demand-enable?        boolean
   +--rw local-multiplier?        uint8
   +--rw bfd-tx-rx-interval
   |  +--rw desired-min-tx-interval?    uint32
   |  +--rw required-min-rx-interval?   uint32
   +--rw enable-authentication?   boolean
   +--rw bfd-authentication {bfd-authentication}?
      +--rw key-chain-name?   string
      +--rw algorithm?        enumeration
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session:
   +--rw tx-ttl?   uint8
   +--rw rx-ttl?   uint8
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:connectivity-context:
   +--:(connectivity-context-bfd)
      +--rw local-discriminator?    uint32
      +--rw remote-discriminator?   uint32
augment /goam:domains/goam:domain/goam:MAs/goam:MA/goam:MEP/goam:session/goam:outgoing-interface:
   +--rw on-demand-enable?                boolean
   +--rw local-multiplier?                uint8
   +--rw bfd-tx-rx-interval
   |  +--rw desired-min-tx-interval?    uint32
   |  +--rw required-min-rx-interval?   uint32
   +--rw enable-authentication?           boolean
   +--rw bfd-authentication {bfd-authentication}?
   |  +--rw key-chain-name?   string
   |  +--rw algorithm?        enumeration
   +--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</artwork>
        </figure></t>
    </section>

    <section title="OAM YANG Module">
      <t><figure>
          <artwork>&lt;CODE BEGINS&gt; file "ietf-lime-bfd-extension.yang"
module ietf-lime-bfd-extension{
 namespace 
 "urn:ietf:params:xml:ns:yang:ietf-lime-bfd-extension";
     prefix limebfd;

     import ietf-gen-oam  {
       prefix goam;
     }

     import ietf-bfd {
      prefix bfd;
     }

	 import ietf-interfaces {
	  prefix if;
	 }
	 
	organization
	"IETF BFD Working Group";   
	contact
    "WG List:   &lt;mailto:bfd@ietf.org&gt;
     Editor:";

    description
    "This YANG Model extends the technology independent
    YANG model for OAM with BFD technology specifics.";	
	
     revision 2014-08-30 {
       description
       "Initial revision.";
	   reference "";
     }
		  
      identity bfd{
       base goam:technology-types;
       description
        "bfd type";
      }

   identity technology-sub-type {
     description
     "certain implementations such as bfd 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-sh-udp {
   base technology-sub-type;
     description
    "technology sub-type is single 
	hop with IP/UDP encapsulation";
     }

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

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

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

grouping tx-rx-ttl{
 description
 "bfd tx ttl";

  leaf tx-ttl{
   type uint8;
   description
   "tx ttl.";
  }
  leaf rx-ttl{
   type uint8;
   description
   "rx ttl.";
  }
}


feature bfd-authentication {
      description "BFD authentication supported";
    }


augment "/goam:domains/goam:domain/goam:MAs/goam:MA"{
    when "goam:technology = 'bfd'"
	 {description
	 "when goam:technology = bfd.";}
          leaf technology-sub-type {
            type identityref {
              base technology-sub-type;
            }
			description
			"technology sub-type such as 
			single hop udp, multiple hop udp,
			single hop ach, multiple hop ach.";
          }
    description
	"augment the MA with bfd parameters.";
        }

augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session"{
    when "goam:technology = 'bfd'"
	 {description
	 "when goam:technology = bfd.";}
 leaf admin-down {
      type boolean;
      default false;
      description
  "Is the BFD session administratively down";
               }

uses bfd:bfd-grouping-common-cfg-parms;

description
"augment the session with bfd parameters.";
}

augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session"{
 when "technology-sub-type = 'technology-sub-type-mh-udp'
   or 'technology-sub-type-mh-ach'"{
   description
   "when technology sub type = techonlogy sub type mh udp
   or technology sub type = technology-sub-type-mh-ach.";
   }
   
   uses tx-rx-ttl;
   description
   "augment the session with bfd parameters.";
}


augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session/goam:connectivity-context"{
 when "goam:technology = 'bfd'"{
  description
  "when goam:techolgoy =bfd.";}
       case connectivity-context-bfd {
        leaf local-discriminator {
         type uint32;
 description
 "local discriminator";
        }
leaf remote-discriminator{
 type uint32;

 description
 "remote-discriminator";
}
       }
	   description
	   "augment the connectivity-context with
	   bfd parameters.";
      }

augment "/goam:domains/goam:domain/goam:MAs/goam:MA"
+"/goam:MEP/goam:session/goam:outgoing-interface"{
  when "technology-sub-type = 'technology-sub-type-sh-udp'
   or 'technology-sub-type-sh-ach'"{
  description
  "when technology-sub-type = 'technology-sub-type-sh-udp'
   or 'technology-sub-type-sh-ach.";
   }
uses bfd:bfd-grouping-common-cfg-parms;
uses bfd:bfd-grouping-echo-cfg-parms;
 description
 "augment the outgoing interface with bfd parameters.";                                                                                                                                                            
}
notification state-change-notification
{
  uses bfd:bfd-notification-parms;
   leaf interface {
   type if:interface-ref;
   description "Interface to which this BFD session belongs to";
   }
   leaf echo-enabled {
    type boolean;
    description "Was echo enabled for BFD";
   } 
 description
 "state change notification.";
}
}

&lt;CODE ENDS&gt;
</artwork>
        </figure></t>
    </section>

    <section title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section title="IANA Considerations">
      <t>TBD.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997"/>

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
                "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
                "OPTIONAL" in this document are to be interpreted as described
                in RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <?rfc include="reference.RFC.6241.xml" ?>

      <?rfc include="reference.RFC.5880.xml" ?>

      <?rfc include="reference.RFC.6020.xml"?>

      <?rfc include="reference.RFC.7331.xml"?>

      <?rfc include="reference.I-D.tissa-lime-yang-oam-model"?>
    </references>
  </back>
</rfc>
