<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3775 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3775.xml">
<!ENTITY RFC4225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4225.xml">
<!ENTITY RFC4866 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4866.xml">
<!ENTITY RFC5213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5213.xml">
<!-- added by sjjeong: -->
<!ENTITY I-D.clemm-i2rs-yang-network-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clemm-i2rs-yang-network-topo.xml">
<!ENTITY I-D.clemm-i2rs-yang-l3-topo SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.clemm-i2rs-yang-l3-topo.xml">
<!ENTITY I-D.ietf-idr-ls-distribution SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-ls-distribution.xml">
]>
<rfc category="std" docName="draft-wang-i2rs-yang-service-topo-dm-01"
     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="service topology">A YANG Data Model for Service
    Topology</title>

    <author fullname="Zitao(Michael) 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="Qin Wu" initials="Q." surname="Wu">
      <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>

        <phone>+86 25 56623633</phone>

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

    <author fullname="Susan Hares " initials="S." surname="Hares">
      <organization abbrev="Huawei">Huawei Technologies,Co.,Ltd</organization>

      <address>
        <postal>
          <street>7453 Hickory Hill</street>

          <street/>

          <city>Saline</city>

          <region>MI</region>

          <code>48176</code>

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

        <phone/>

        <email>Email: shares@ndzh.com</email>
      </address>
    </author>

    <date year="2015"/>

    <area>RTG Area</area>

    <workgroup>I2RS</workgroup>

    <abstract>
      <t>This document defines a YANG data model for Service Function Forward
      Topology. This I2RS yang data model is part of the I2RS protocol
      independent topology set of data models.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>An overlay network consists of tunnels established among designated
      nodes to traverse segments of networks.</t>

      <t>This draft describes a protocol independent topology of service
      function forwarder nodes which augments the <xref
      target="I-D.clemm-i2rs-yang-network-topo"/> model as a specific service
      topology (SFF). Figure 1 shows how the SFF is an extension of the
      service forwarded nodes.</t>

      <t><figure>
          <artwork> 
    
          +---------------------------------------+
         /            _[X1]_          "Service"  /
        /           _/  :   \_        (SFF)     /
       /          _/     :    \_               /
      /         _/        :     \_            /
     /         /           :      \          /
    /       [X2]__________________[X3]      /
   +---------:--------------:------:-------+
              :              :     :
          +----:--------------:----:--------------+
         /      :              :   :        "L3" /
        /        :              :  :            /
       /         :               : :           /
      /         [Y1]_____________[Y2] tunnels /
     /           *               * *         /
    /            *              *  *        /
   +--------------*-------------*--*-------+
                   *           *   *
          +--------*----------*----*--------------+
         /     [Z1]_______________[Z1] "Optical" /
        /         \_         *   _/             /
       /            \_      *  _/              /
      /               \_   * _/               /
     /                  \ * /                /
    /                    [Z]                /
   +---------------------------------------+
     
     Figure 1 

</artwork>
        </figure></t>

      <t>There can be many types of protocol independent service topologies
      such as: L2VPN, L3VPN, MPLS, EVPN, and others. The Service Function
      Chaining services consists of a topology of Service Function Forwarder
      nodes connected by links which are tunnels that connect the service
      nodes. Each Service Forwarder node has service functions attached to the
      Service Function Forwarder node.</t>

      <t>The SFF topology is built on top of one or several underlying
      networks (see figure 1). In case multi-tenancy is needed, multiple SFF
      topologies can be built on top of the same underlying network. Each
      tenant can only see its own service topology. But all the tenant's
      service topology can be mapped into the same L3 network topology.</t>

      <t>The I2RS protocol independent topologies are abstractions created by
      the I2RS Client directly or by instructions to I2RS agent to import
      network topologies or aggregations of the network topology. The I2RS
      protocol independent L3 topology is created by the client or the clients
      instruction to import specific information from the I2RS Agent from
      static configuration or IGPs (E.g. OSPF or ISIS) or information passed
      in EGPs (e.g. <xref target="I-D.ietf-idr-ls-distribution"/>. Similarly,
      the protocol independent SFF topology is abstraction of network topology
      information. Since SFF has no another control plane protocol running on
      top of the underlying networks, this information will need to be
      gathered from other sources.</t>

      <t>This document defines a Yang data model for the SFF protocol
      independent topology.</t>
    </section>

    <section title="Definitions and Acronyms">
      <t>Datastore: A conceptual store of instantiated management information,
      with individual data items represented by data nodes which are arranged
      in hierarchical manner.</t>

      <t>Data subtree: An instantiated data node and the data nodes that are
      hierarchically contained within it.</t>

      <t>NETCONF: Network Configuration Protocol.</t>

      <t>URI: Uniform Resource Identifier.</t>

      <t>YANG: A data definition language for NETCONF.</t>

      <t>Classification: Locally instantiated policy and customer/network/
      service profile matching of traffic flows for identification of
      appropriate outbound forwarding actions.</t>

      <t>Classifier: An element that performs Classification.</t>

      <t>Service Function Chain (SFC): A service function chain defines a set
      of abstract service functions and ordering constraints that must be
      applied to packets and/or frames selected as a result of
      classification.</t>

      <t>Service Function (SF): A function that is responsible for specific
      treatment of received packets.</t>

      <t>Service Function Forwarder (SFF): A service function forwarder is
      responsible for delivering traffic received from the network to one or
      more connected service functions according to information carried in the
      SFC encapsulation, as well as handling traffic coming back from the
      SF.</t>

      <t>Metadata: provides the ability to exchange context information
      between classifiers and SFs and among SFs.</t>

      <t>Service Function Path (SFP): The SFP provides a level of indirection
      between the fully abstract notion of service chain as a sequence of
      abstract service functions to be delivered, and the fully specified
      notion of exactly which SFF/SFs the packet will visit when it actually
      traverses the network.</t>

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

    <section title="SFF Topology Data Model">
      <t>This section describe the architecture and the tree diagram of the
      service topology yang data model.</t>

      <section title="Model Overview">
        <t>The abstract Topology yang Model contain a set of abstract nodes
        and a list of abstract links. Service Function Chain Topo yang model
        and other service topo model can be augumented from the abstract
        topology model with SFC base topology specifics.</t>

        <t>The following Figure depicts the relationship of service topology
        yang model to the abstract topology yang model.</t>

        <t><figure
            title="The relationship of service topology yang model to the abstract topology yang model">
            <artwork> 
                +-----------------+
                |    Abstract     |
                | Topology Model  |
                |                 |
                +--------|--------+
                         |
               +-----------------------+
               |          .....         |
               |      
        +------V----------+
        |     Service     |
        | Topology models |
        |                 |
        +--------|---------
                 | 
        +----|------------------------|---+
             |                        |
    +--------V--------+      +--------V-----------+      
    |Service Function |      | Another protocol   |          
    |   Forwarder     |      | Independent Service|
    | Topology Models |      | Topology Models    |
    +-----------------+      +--------------------+
  
      Figure 2 
</artwork>
          </figure></t>

        <t><figure>
            <artwork> 

   The following is the generic topology module 
   
     module: network
      +--rw network* [network-id]
         +--rw network-id            network-id
         +--ro server-provided?      boolean
         +--rw network-types
         +--rw supporting-network* [network-ref]
         |  +--rw network-ref    leafref
         +--rw node* [node-id]
            +--rw node-id            node-id
            +--rw supporting-node* [network-ref node-ref]
               +--rw network-ref    leafref
               +--rw node-ref       leafref
  
     The service modules augments the network types and this data structures. 
     To provide context for this model, this sample augment for the 
     types is provided (but not normative for this draft).
 
        module: Service Topologies   
        augment /nt:network-topology/nt:topology/nt:topology-types
          +--rw Service-Topologies 
             +--rw SFF-topology 
             +--rw L3VPN-Service-topology
             +--rw EVPN-Service-topology


       Figure 3: The structure of the abstract (base) network model
</artwork>
          </figure></t>
      </section>

      <section title="SFF Topology Yang">
        <t>The following figure provide the structure of service topology yang
        model. Each node is printed as:</t>

        <t><figure title="">
            <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 notification

     &lt;name&gt; is the name of the node
      If the node is augmented into the tree from another module, its
   name is printed as &lt;prefix&gt;:&lt;name&gt;.

   &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
   
           Figure 4 
</artwork>
          </figure></t>
      </section>

      <section title="SFF topology Model Description">
        <t><figure>
            <artwork>SFF Topology Module 
   
   module: SFF topology  
   augment /nt:network-topology/nt:topology/nt:topology-types
     +--rw Service-Topologies 
        +--SFF Topology!
augment /nt:network-topology/nt:topology
     +--rw service-topo-id     network-id
     +--rw service-topology-attributes 
        +--rw node-count          uint32      
        +--rw topology-extension!
augment /nt:network-topology/nt:topology/nt:node 
     +--rw node-type!
     |  +--rw classifier-node?  string
     |  +--rw sf-node?        string
     |  +--rw sff-node?       string
     +--rw next-hop*[hop-id]
     |  +--hop-id           node-id
     +--rw node-extension!
        +--rw classifier-extension!
        |  +--rw classifier-id  node-id
        |  +--rw sfc-policy    uint32
        |  +--rw sfp!
        |     +--rw sfp-id    uint32
        |     +--rw sf-list*[sf-id]
        |     +--rw sf-id  node-id
        |     +--rw sff-list*[sff-id]
        |     +--rw sff-id  node-id 
        +--rw sf-node-extension!
        |  +--rw sf-id  node-id
        |  +--rw sf-node-locator  uint32
        |  +--rw sf-type!
        |  |  +--rw firewall?    uint32
        |  |  +--rw loadbalancer? uint32
        |  |  +--rw NAT44?     uint32
        |  |  +--rw NAT64?     uint32
        |  |  +--rw DPI?     uint32
        |  +--rw sf-inventory-data!
        +--rw sff-node-extension!
           +--rw sff-id   node-id
           +--rw (sffn-address)?
           |  +--:(ipv4-address)
           |  |  +--rw ipv4-address?        inet:ipv4-address
           |  +--:(ipv6-address)
           |     +--rw ipv6-address?     inet:ipv6-address
           +--rw sffn-virtual-context!
           |  +--rw context-id          uint32
           +--rw Attached-service-address!
           |  +--rw service-node*[service-node-id]
           |  |  +--rw service-node-id  node-id
           |  +--rw host-system*[host-system-id]
           |     +--rw host-system-id   uint32
           +--rw customer-support*[customer-id]
           |  +--rw customer-id  uint32
           +--rw customer-service-resource*[customer-resource-id]
           |  +--rw customer-resource-id  node-id
           +--rw sffn-vntopo!
             
            Figure 5 
</artwork>
          </figure></t>

        <t>The service topo yang model contains a service-topology structure.
        Based on the base model, this can be a list.</t>

        <t>topology model</t>

        <t>The generic model contains a topology leaf. The SFF augments the
        topology types leaf within this topology life with the SFF-topology
        type. The SFF module also augments the topology with topology-id leaf,
        and a topology attributes leaf that contains node count leaf and
        topology-extension container. The node-count leaf can be used to
        indicate the number of nodes which contained in the service-topology
        list. The topology-extension container can be used to augment the
        service topology model by topology specifics.</t>

        <t>node structure</t>

        <t>The generic topology structure also contains a node (nt:node), and
        this structure has been augmented by containers for node type, a
        next-hop container, and a node-extensions. The node-type container can
        used to indicate the type node, such classifier, a sf or a sff. The
        node-extension container can be used to augment the node list by node
        specifics, for example: classifier extension, sf extension, sff
        extension.</t>

        <t>link structure</t>

        <t>The generic link topology structure contains a link (nt:link)
        structure, and this generic link structure has been augmented to
        include a sff-link-type leaf, sff-direction container, and an
        segment-extension leaf. The segment-extension container can be used to
        augment the segment list by segment specifics. Such as netconf segment
        extension, i2rs segment extension.</t>

        <t>classifier extension</t>

        <t>In SFC, the classifier is used to locally instantiated policy and
        customer/network/service profile matching of traffic flows for
        identification of appropriate outbound forwarding actions.</t>

        <t>sf-node-extension</t>

        <t>The sf is a function that is responsible for specific treatment of
        received packets. As a logical component.</t>

        <t>sff-node-extension</t>

        <t>The service function forwarder is responsible for delivering
        traffic received from the network to one or more connected service
        functions according to information carried in the SFC encapsulation,
        as well as handling traffic coming back from the SF.</t>
      </section>
    </section>

    <section title="SFF Topology YANG Module">
      <t><figure>
          <artwork>&lt;CODE BEGINS&gt; file "sff-topology.yang"
module sff-topology{
    yang-version 1;
    namespace "urn:TBD:params:xml:ns:yang:sff-topology";
    prefix "sff-topo";

    organization "TBD";

    contact
    "wangzitao@huawei.com";

    description
    "This module defines sff topology yang data model";


    import network-topology {
        prefix "nt";
    }

    import ietf-inet-types {
        prefix "inet";
    }

    import network { prefix nd; }

//import service-topologies{ prefix st;}

organization "IETF I2RS Working Group";
     contact
      "wangzitao@huawei.com";
     description
       "This module defines sfc topology yang data model";
   
     typedef node-id {
       type inet:uri;
     }
 
 augment "/nt:network-topology/nt:topology/nt:topology-types"{
  container Service-Topologies{
   container SFF-Topology{
    description
    "SFF topology.";
   }
  }
 }
 
 augment "/nt:network-topology/nt:topology"{
   leaf service-topo-id{
    type network-id;
  }
  container service-topology-attributes{
   leaf node-count{
    type uint32;
   }
   container topology-extension{
    description
    "can be augment/extension.";
   }
  }
 }
 
 augment "/nt:network-topology/nt:topology/nt:node"{
  container node-type{
   leaf classifier-node{
    type string;
    }
   leaf sf-node{
    type string;
   } 
   leaf sff-node{
    type string;
   }
  }

  list next-hop{
   key "hop-id";
   leaf hop-id{
    type node-id;
   }
  }

  container node-extension{
   container classifier-extension{
       leaf classifier-id{
        type node-id;
        description
        "The identifier of the classifier.";}
      leaf sfc-policy{
       type uint32;
       description
       "Indicate the policy of sfc.";}
      container sfp{
       description
       "contains several sfps.";
       leaf sfp-id{
        type uint32;
        description
        "The identifier of the sfp.";}
       list sf-list{
        key "sf-id";
         leaf sf-id{
          type node-id;
          description 
          "The identifier of the sf which include in the sfp.";}
       } 
       list sff-list{
        key "sff-id";
         leaf sff-id{
          type node-id;
          description 
          "The identifier of the sff which include in the sfp.";}
       } 
      }//end the sfp container 
     }
 
     container sf-node-extension{
      leaf sf-id{
       type node-id;
       description 
       "The identifier of the service function(sf).";}
      leaf sf-node-locator{
       type uint32;
       description 
       "To indicate the service function (sf) locator";}
      container sf-type{
       leaf firewall{
        type uint32;
        description
        "To indicate the service function (sf) is firewall.";}
       leaf loadbalancer{
        type uint32;
        description
        "To indicate the service function (sf) is loadbalancer.";}
       leaf NAT44{
        type uint32;
        description
        "To indicate the service function (sf) is NAT44.";}
       leaf NAT64{
        type uint32;
        description
        "To indicate the service function (sf) is NAT64.";}
       leaf DPI{
        type uint32;
        description
        "To indicate the service function (sf) is DPI.";}
      }//end the sf-type container
      container sf-inventory-data{
       description
       "The container of the inventory data of service function (sf).";
      }
     }
 
     container sff-node-extension{
      leaf sff-id{
       type node-id;
       description
       "The identifier of the service function forward (sff).";} 
      choice sffn-address{
       description
       "The address of the service function forward (sff) node";
       case ipv4-address{
        leaf ipv4-address{
         type inet:ipv4-address;}
       }
       case ipv6-address{
        leaf ipv6-address{
         type inet:ipv6-address;}
       }
      }//end the choice sffn-address 
      container sffn-virtual-context{
       leaf context-id{
        type uint32;
        description
        "the identifier of the sffn virtual context.";}
      } 
      container Attached-service-address{
       list service-node{
        key "service-node-id";
        leaf service-node-id{
         type node-id;
         description
         "The identifier of the service node.";}
        }//end the service-node list
        list host-system{
         key "host-system-id";
         leaf host-system-id{
          type uint32;
          description
          "The identifier of the host system.";}
        }//end the service-node list
      } //end the attached-service-address container
      list customer-support{
       key "customer-id";
       leaf customer-id{
        type uint32;
        description
        "The identifier of the customer.";}
      }//end the customer-support list 
      list customer-service-resource{
       key "customer-resource-id";
       leaf customer-resource-id{
        type node-id;
        description
        "The identifier of the customer resource.";}
      }//end the customer-service-resource list 
      container sffn-vntopo{
       description
       "This container can be use to contain the virtual network topology of 
        Sffn. And it can be augment by specific virtual network topology.";
      }
     }
    }
   }
}
&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">
      &rfc2119;

      <reference anchor="RFC6020">
        <front>
          <title>YANG - A Data Modeling Language for the Network Configuration
          Protocol (NETCONF)</title>

          <author fullname="M.Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>

          <date month="October" year="2010"/>
        </front>

        <seriesInfo name="RFC" value="6020"/>
      </reference>

      <reference anchor="RFC6241">
        <front>
          <title>Network Configuration Protocol (NETCONF)</title>

          <author fullname="R.Enns" initials="R." surname="Enns">
            <organization/>
          </author>

          <author fullname="M.Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>

          <author fullname="J.Schoenwaelder" initials="J."
                  surname="Schoenwaelder">
            <organization/>
          </author>

          <author fullname="A.Bierman " initials="A." surname="Bierman">
            <organization/>
          </author>

          <date month="June" year="2011"/>
        </front>

        <seriesInfo name="RFC" value="6241'"/>
      </reference>

      <reference anchor="draft-ietf-sfc-architecture-02">
        <front>
          <title>Service Function Chaining (SFC) Architecture</title>

          <author fullname="Joel Halpern" initials="J" surname="Halpern">
            <organization/>
          </author>

          <date month="May" year="2014"/>
        </front>

        <seriesInfo name="ID" value="draft-ietf-sfc-architecture-02"/>
      </reference>

      <?rfc include="reference.RFC.6536"?>

      <?rfc include='reference.I-D.clemm-i2rs-yang-network-topo'?>

      <?rfc include='reference.I-D.ietf-idr-ls-distribution'?>
    </references>
  </back>
</rfc>
