<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-jags-spring-sr-service-programming-yang-01 2021-1-26 jrajaman $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>

<rfc category="std" docName="draft-jags-spring-sr-service-programming-yang-03"
     ipr="trust200902" updates="">
  <?rfc toc="yes" ?>
  <?rfc compact="yes"?>
  <?rfc subcompact="no"?>
  <?rfc symrefs="yes"?>
  <?rfc sortrefs="yes" ?>

   
  <front>
   
    <title abbrev="YANG Data Model for SR Service Programming">YANG Data Model for SR Service Programming</title>

    <author fullname="Jaganbabu Rajamanickam" initials="J." surname="Rajamanickam">
      <organization>Cisco Systems</organization>
      <address>
        <email>jrajaman@cisco.com</email>
      </address>
    </author>

    <author fullname="Kamran Raza" initials="K." surname="Raza">
      <organization>Cisco Systems</organization>
      <address>
        <email> skraza@cisco.com</email>
      </address>
    </author>
      
    <author fullname="Daniel Bernier" initials="D." surname="Bernier">
      <organization>Bell Canada</organization>
      <address>
        <email>daniel.bernier@bell.ca</email>
      </address>
    </author>

    <author fullname="Gaurav Dawra" initials="G." surname="Dawra">
      <organization>LinkedIn</organization>
      <address>
        <email>gdawra.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Cheng Li" initials="C." surname="Li">
      <organization> Huawei</organization>
      <address>
        <email>c.l@huawei.com</email>
      </address>
    </author>
    
   <date day="25" month="January" year="2022"/>

   <area>Routing</area>
   <workgroup>SPRING Working Group</workgroup>
   <keyword>IPv6</keyword>
   <keyword>SRv6</keyword>
   <keyword>YANG</keyword>

   <abstract>
     <t>This document describes a YANG data model for Segment Routing (SR) Service Programming.
     The model serves as a base framework for configuring and managing an SR based
     service programming. Additionally, this document specifies the model for
     a Service Proxy for SR-unaware services. 
     </t>

 <t> The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA).
 </t>
 
   </abstract>
      
  </front>
  
  <middle>
    
    <section title="Introduction">
            
      <t>
	The Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> is one of the
	network management protocols that defines mechanisms to manage network devices. YANG
	<xref target="RFC6020"/> is a modular language that represents data structures in an
	XML tree format, and is used as a data modeling language for the NETCONF.
        </t>
      
      <t>
        Segment Routing is an architecture based on the source routing
        paradigm that seeks the right balance between distributed
        intelligence and centralized programmability.  SR can be used with an
        MPLS or an IPv6 data plane to steer packets through an ordered list
        of instructions, called segments.  These segments may encode simple
        routing instructions for forwarding packets along a specific network
        path, but also steer them through Virtual Network Function (VNF) or
        physical service appliances available in the network.
      </t>
        
      <t>
        In an SR network, each of these services, running either on a
        physical appliance or in a virtual environment, are associated with a
        segment identifier (SID).  These service SIDs are then leveraged as
        part of a SID-list to steer packets through the desired
        services in the service chain.  Service SIDs may be combined together in a SID-list
        to achieve the service programming, but also with other types of segments as
        defined in <xref target="RFC8402"/>. SR thus provides a fully integrated solution
        for overlay, underlay and service programming.  Furthermore, the IPv6
        instantiation of SR (SRv6) supports metadata transportation in the
        Segment Routing header <xref target="RFC8754"/>, either natively in the tag field or
        with extensions such as TLVs.
      </t>

      <t>
        This document describes how a service can be associated with a SID,
        including legacy services with no SR capabilities, and how these
        service SIDs are integrated within an SR policy.  The definition of
        an SR Policy and the traffic steering mechanisms are covered in
        <xref target="I-D.ietf-spring-segment-routing-policy"/> and hence outside the scope
        of this document.
      </t>
      
      <t>
        This document introduces a YANG data model for the SR based service 
        programming configuration and management.
	Furthermore, this document also covers the basic SR unaware behaviours as defined in
	<xref target="I-D.ietf-spring-sr-service-programming"/>.
      </t>

      <t>
          This document does not cover the following:
	<list style="symbols">
            <t> SR-aware service specific management parameters </t>
	</list>
      </t>


      <t>
	The model currently defines the following constructs that are used for managing 
        SR based service programming:
	<list style="symbols">
          <t> Configuration </t>
	  <t> Operational State </t>
	  <t> Notifications </t>
	</list>
      </t>
      
    </section>
        
    <section title="Specification of Requirements">

     <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 BCP 14 <xref target="RFC2119"/>
       <xref target="RFC8174"/>  when, and only when, they appear in all capitals, as shown here.
     </t>
           
    </section>

    <section title="YANG Model">
      
      <section title="Overview">
	
	<t>
	  This document defines the following four new YANG modules:
	  <list style="symbols">
            <t> ietf-service-function-types: Defines common service function types </t>
	    <t> ietf-sr-service-programming-types: Defines common type definitions used for
            SR based service programming YANG model </t>
	    <t> ietf-sr-service-programming: Defines management model for SR based service
            programming framework. This is a base and common framework for both
            SR-aware and SR-unaware services. </t>
	    <t> ietf-sr-service-programming-proxy: Defines management model for SR service proxy
            for SR unaware services</t>
	  </list>
	</t>
	
	
	<t>
	  The modelling in this document complies with the Network Management Datastore
	  Architecture (NMDA) defined in <xref target="RFC8342"/>.
	  The operational state data is combined with the associated configuration data in
	  the same hierarchy <xref target="RFC8407"/>.
	  When protocol states are retrieved from the NMDA operational state datastore, the
	  returned states cover all "config true" (rw) and "config false" (ro) nodes defined
	  in the schema.
	</t>

	<t>
	  In this document, when a simplified graphical representation of 
	  YANG model is presented in a tree diagram, the meaning of the symbols
	  in these tree diagrams is defined in <xref target="RFC8340"/>.
	</t>

	<t>
	  In this document, the SR service programming YANG model is split based
          on dynamic SID allocation and static SID allocation. In the case of
          dynamic SID allocation, new SR service programming tree would be used.
          In the case of static MPLS SID allocation for the SR service 
          programming, the existing SR MPLS YANG model <xref target="RFC9020"/> 
          would be augmented with the SR MPLS service programming specific
          parameters. Similarly the static SRv6 base YANG model (TBD) would be 
          augmented with the SRv6 service programming specific parameters.  
	</t>
		
      </section>
      
      <section title="Service Function Types">
	
	<t>
         A service is identified by (type, variant, instance). The type 
         represents the type of service functions (such as Firewall,
         DPI IPS etc.), The variant value is a unique identifier which
         could identify the vendor and its product informations, The 
         instance is used to refer to a specific instance of the same 
         (service, variant).
	</t>

	<t>
         We define a new YANG module ietf-service-function-types to
         specify common definitions and types for service and service
         function. The types and definitions are generic and hence
         can be used in any (SR based or non-SR) YANG models.
	</t>

	<t>
         The main definitions and types defined in ietf-service-function-types module include:
	  <list style="symbols">
	    <t> service-function-type: A new identity type to specify service
                function types, such as firewall, dpi etc. Other identities can be
                define by other modules in future.
            </t>
	  </list>
	</t>
	
      </section>
      
      <section title="SR Service Programming Types">
	
	<t>
	  The types required to model SR based service programming are defined in a
          new module ietf-sr-service-programming-types.
        </t>

        <t>
	  The main types defined in this module includes:
	  <list style="symbols">
	    <t> service-program-behaviour-type: Defines SR service program
                behaviours like sr-aware, static-proxy etc...
            </t>
	    <t> service-program-oper-status-type: Defines SR service programming operational 
                status. This includes the reason for down status as well
            </t>
	    <t> service-proxy-inner-pkt-type: Defines SR service proxy
                inner packet types
            </t>
	    
	  </list>
	</t>
	
      </section>
      
      <section title="SR Service Programming Base">
	
	<t>
         The base model and framework for SR based service
         programming using dynamic SID allocation is defined in a new module
         ietf-sr-service-programming.
	</t>
	<t>
         In the case of static MPLS SID allocation
         for the SR service programming, the existing SR MPLS
         YANG model <xref target="RFC9020"/> would be augmented with the 
         SR MPLS service programming specific parameters.
	</t>
	<t>
         In the case of static SRv6 based YANG
         model (TBD) would be augmented with the 
         SRv6 service programming specific parameters. 
	</t>
	<t>
         This module provides a common base 
         for both the SR-aware and SR-unaware
         service programming in terms of configuration,
         operation state and notifications. 
	</t>
	<t>
         The ietf-sr-service-programming module hangs off
         main SR parent by augmenting "/rt:routing/sr:segment-routing".
	</t>

        <section title="Configuration" anchor="section_cfg">
          <t> 
            This module defines some fundamental items required to configure
            SR based service programming. In particular, it defines 
            service program provisioning as follows:

            <list style="symbols">
              <t> service program behaviour: Defining a service program behaviour </t>
              <t> service offered: Defining a specific service
                 (type, variant, instance) offered this service programming </t>
              <t> Assigning a SR service SID: Defining SID data plane, method to
                  allocate the SID etc.. </t>
              <t> service program enablement: Administratively Enable/Disable 
                  a service program </t>
              <t> SR services: Defining a base container which could be augmented to
                  define SR-aware or SR-unaware (via service-proxy) service
                  specific parameters </t>
            </list>
          </t>

	  <t> 
            Following is a simplified graphical tree representation of the data model for 
            SR service programming (Dynamic SID allocation) base configuration only
          </t>

          <figure title="SR Service Programming Config Tree - Dynamic SID allocation" anchor="CfgTree-Dynamic">

            <artwork>

module: ietf-sr-service-programming
  augment /rt:routing/sr:segment-routing:
    +--rw service-programming
       +--rw service-program* [name]
          +--rw name                        -> /rt:routing/
                                               sr:segment-routing/
                                               sr-svc-pgm:service-programming/
                                               service-program/
                                               service-programming-info/
                                               service-name
          +--rw sid-binding
          |  +--ro alloc-mode?   sr-svc-pgm-types:sid-alloc-mode-type
          |  +--rw mpls
          |  |  +--ro sid?   rt-types:mpls-label
          |  +--rw srv6
          |     +--ro sid?       srv6-types:srv6-sid
          |     +--rw locator?   -> /rt:routing/sr:segment-routing/
          |                         srv6:srv6/locators/locator/name
          +--rw service-programming-info
             +--rw behaviour           identityref
             +--rw dataplane           sr-svc-pgm-types:dataplane-type
             +--rw service-name        string
             +--rw service-type        identityref
             +--rw service-variant     string
             +--rw service-instance    uint32
             +--rw admin-status?       sr-svc-pgm-types:admin-status-type
             +--rw sr-services


            </artwork>

          </figure>


	  <t> 
            Following is a simplified graphical tree representation of the data model for 
            SR service programming (Static SR MPLS SID allocation) base configuration only.
            In this case SR MPLS base YANG model has been augmented to support SR service 
            programming using static SR MPLS SID allocation. This has been done for the 
            user convince to program all the SR service programming parameters from the 
            based SR MPLS YANG itself
          </t>

          <figure title="SR Service Programming Config Tree - Static SR MPLS SID allocation" anchor="CfgTree-MPLS-static">

            <artwork>

module: ietf-sr-service-programming
  augment /rt:routing/sr:segment-routing/sr-mpls:sr-mpls/sr-mpls:bindings:
    +--rw mpls-static-service-programming
       +--rw service-program* [name]
          +--rw name                        -> /rt:routing/
                                               sr:segment-routing/
                                               sr-svc-pgm:service-programming/
                                               service-program/
                                               service-programming-info/
                                               service-name
          +--rw sid                         rt-types:mpls-label
          +--rw service-programming-info
             +--rw behaviour           identityref
             +--ro dataplane?          sr-svc-pgm-types:dataplane-type
             +--rw service-name        string
             +--rw service-type        identityref
             +--rw service-variant     string
             +--rw service-instance    uint32
             +--rw admin-status?       sr-svc-pgm-types:admin-status-type
             +--rw sr-services



            </artwork>

          </figure>

	  <t> 
            Following is a simplified graphical tree representation of the data model for 
            SR service programming (Static SRv6 SID allocation) base configuration only.
            TBD (Once the based SRv6 static model is available, this section will be filled)
          </t>

        </section>

        <section title="Operational State" anchor="section_oper">

          <t>
            As per NMDA model, the state related to configuration items specified in above
            section <xref target="section_cfg"/> can be retrieved from the same tree. This
            section defines other operational state items related to SR based
            service programming.
          </t>

          <t>
            The operational state corresponding to an SR based service program includes:
            <list style="symbols">
              <t> Operational status: Provides detail information on the operational state of
                  the SR service program. </t>
              <t> statistics: Provides the statistics details such as number of
                  packets/bytes received, processed and dropped corresponding to
                  a SR service program.</t>
            </list>
          </t>

          <t>
            Following is a simplified graphical tree representation of the data model for the 
            SR service programming base operational state (for read-only items):
          </t>

          <figure title="SR Service Programming Operational State Tree" anchor="OperTree">

            <artwork>

Dynamic SID allocation case:

module: ietf-sr-service-programming
  augment /rt:routing/sr:segment-routing:
    +--rw service-programming
       +--rw service-program* [name]
          +--rw service-programming-info
             +--ro oper-status?        identityref
             +--ro statistics
               +--ro in-packet-count?         yang:counter64
               +--ro in-bytes-count?          yang:counter64
               +--ro out-packet-count?        yang:counter64
               +--ro out-bytes-count?         yang:counter64
               +--ro in-drop-packet-count?    yang:counter64
               +--ro out-drop-packet-count?   yang:counter64
    

Static SR MPLS SID allocation case:

module: ietf-sr-service-programming
  augment /rt:routing/sr:segment-routing/sr-mpls:sr-mpls/sr-mpls:bindings:
    +--rw mpls-static-service-programming
       +--rw service-program* [name]
          +--rw service-programming-info
             +--ro oper-status?        identityref
             +--ro statistics
               +--ro in-packet-count?         yang:counter64
               +--ro in-bytes-count?          yang:counter64
               +--ro out-packet-count?        yang:counter64
               +--ro out-bytes-count?         yang:counter64
               +--ro in-drop-packet-count?    yang:counter64
               +--ro out-drop-packet-count?   yang:counter64


Static SRv6 SID allocation case:

TBD

            </artwork>

          </figure>

        </section>

        <section title="Notification" anchor="notif">
          <t>
            This model defines a list of notifications to inform an operator of important 
            events detected during the SR service programming operation. These events are:
          <list style="symbols">
            <t> SR service program operational state changes: This would also give the
                reason for the state change when it is down </t>
          </list>
          </t>
          <t>
            Following is a simplified graphical tree representation of the data model for the 
            SR service programming notification:
          </t>

          <figure title="SR Service Programming Notification Tree" anchor="NotifTree">

            <artwork>

module: ietf-sr-service-programming
  notifications:
    +---n service-program-oper-status
       +--ro name           -> /rt:routing/sr:segment-routing/
                               sr-svc-pgm:service-programming/
                               service-program/name
       +--ro oper-status    -> /rt:routing/sr:segment-routing/
                               sr-svc-pgm:service-programming/
                               service-program/oper-status

            </artwork>

          </figure>

        </section>

      </section>


      <section title="SR Service Proxy">

	<t>
          This document also defines a separate and new YANG
          data model for Service Proxy for SR unaware services.
          The model defines the configuration and operational
          state related to different proxy behaviours defined
          earlier in ietf-sr-service-programming-types.
          The model is defined in a new module
          ietf-sr-service-programming proxy.
	</t>
	<t>
          To support SR service programming proxy for dynamic SID 
          allocation,this module augments the SR service program tree
          (/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming/
          sr-svc-pgm:service-program/sr-svc-pgm:sr-services)
          as defined earlier in ietf-sr-service-programming module.
	</t>
	<t>
          To support SR service programming proxy for static 
          SR MPLS SID allocation, this module augments the base SR MPLS 
          YANG mode defined in the RFC <xref target="RFC9020"/> 
          (/rt:routing/sr:segment-routing/sr-mpls:sr-mpls/sr-mpls:bindings/
          sr-svc-pgm:mpls-static-service-programming/
          sr-svc-pgm:service-program/sr-svc-pgm:service-programming-info/
          sr-svc-pgm:sr-services:)
	</t>
	<t>
          To support SR service programming proxy for static 
          SRv6 SID allocation, this module augments the base static 
          SRv6 model - TBD
	</t>

	<t>
          The following sections describe different types of proxy behaviours and associated YANG modelling constructs.
	</t>

	<section title="Static Proxy" anchor="section_static_proxy">
          <t>
            The static proxy is an SR endpoint behaviour for processing SR-MPLS or SRv6 
            encapsulated traffic on behalf of an SR-unaware services.
          </t>
          <t>
            The following parameters are required to provision the SR static proxy:
            <list style="symbols">
              <t> inner-packet-type: Inner packet type </t>
              <t> next-hop: Next hop Ethernet address (only for the inner type is IPv4 or IPv6)
                  </t>
              <t> out-interface-name: Local interface for sending traffic towards the service
                  Endpoint </t>
              <t> in-interface-name: Local interface receiving traffic coming back from the
                  service Endpoint </t>
              <t> packet-cache-info: SR information to be attached on the traffic coming back
                  from the service. This could be list of MPLS Label stack or SRv6 SIDs </t>
            </list>
          </t>
          <t>
            Following is a simplified graphical tree representation of the data model for the 
            SR static proxy:
          </t>

          <figure title="SR Static Proxy Tree" anchor="Static">

            <artwork>

Dynamic SID allocation case:

module: ietf-sr-service-programming-proxy
  augment /rt:routing/sr:segment-routing/
          sr-svc-pgm:service-programming/
          sr-svc-pgm:service-program/
          sr-svc-pgm:service-programming-info/
          sr-svc-pgm:sr-services:
    +--rw service-proxy
       +--rw (proxy-type)
          +--:(static)
            +--rw static-proxy
               +--rw inner-packet-type     identityref
               +--rw next-hop?             yang:mac-address
               +--rw out-interface-name    string
               +--rw in-interface-name     string
               +--rw packet-cache-info
                  +--rw (cache-type)
                     +--:(mpls)
                     |  +--rw mpls-sids* [index]
                     |     +--rw index         uint8
                     |     +--rw mpls-label    rt-types:mpls-label
                     +--:(srv6)
                        +--rw ipv6-source-address?   inet:ipv6-address
                        +--rw srv6-sids* [index]
                           +--rw index       uint8
                           +--rw srv6-sid    srv6-types:srv6-sid



Static SR MPLS SID allocation case:

module: ietf-sr-service-programming-proxy
  augment /rt:routing/sr:segment-routing/
          sr-mpls:sr-mpls/sr-mpls:bindings/
          sr-svc-pgm:mpls-static-service-programming/
          sr-svc-pgm:service-program/
          sr-svc-pgm:service-programming-info/
          sr-svc-pgm:sr-services:
    +--rw static-mpls-service-proxy
       +--rw (proxy-type)
          +--:(static)
            +--rw static-proxy
               +--rw inner-packet-type     identityref
               +--rw next-hop?             yang:mac-address
               +--rw out-interface-name    string
               +--rw in-interface-name     string
               +--rw packet-cache-info
                  +--rw (cache-type)
                     +--:(mpls)
                     |  +--rw mpls-sids* [index]
                     |     +--rw index         uint8
                     |     +--rw mpls-label    rt-types:mpls-label
                     +--:(srv6)
                        +--rw ipv6-source-address?   inet:ipv6-address
                        +--rw srv6-sids* [index]
                           +--rw index       uint8
                           +--rw srv6-sid    srv6-types:srv6-sid



Static SRv6 SID allocation case:
 TDB

            </artwork>

          </figure>

	</section>

	<section title="Dynamic Proxy" anchor="section_dynamic_proxy">
          <t>
            The dynamic proxy is an improvement over the static proxy that dynamically learns 
            the SR information before removing it from the incoming traffic. The same
            information can be re-attached to the traffic returning from the service Endpoints.
            The dynamic proxy relies on the local caching.
          </t>
          <t>
            The following parameters are required to provision the SR dynamic proxy:
            <list style="symbols">
              <t> out-interface-name: Local interface for sending traffic towards the service
                  Endpoint </t>
              <t> in-interface-name: Local interface receiving traffic coming back from the
                  service Endpoint </t>
            </list>
          </t>
          <t>
            Following is a simplified graphical tree representation of the data model for the 
            SR static proxy:
          </t>

          <figure title="SR Dynamic Proxy Tree" anchor="Dynamic">

            <artwork>
Dynamic SID allocation case:

module: ietf-sr-service-programming-proxy
  augment /rt:routing/sr:segment-routing/
          sr-svc-pgm:service-programming/
          sr-svc-pgm:service-program/
          sr-svc-pgm:service-programming-info/
          sr-svc-pgm:sr-services:
    +--rw service-proxy
       +--rw (proxy-type)
          +--:(dynamic)
            +--rw dynamic-proxy
               +--rw out-interface-name    string
               +--rw in-interface-name     string



Static SR MPLS SID allocation case:

module: ietf-sr-service-programming-proxy
  augment /rt:routing/sr:segment-routing/
          sr-mpls:sr-mpls/sr-mpls:bindings/
          sr-svc-pgm:mpls-static-service-programming/
          sr-svc-pgm:service-program/
          sr-svc-pgm:service-programming-info/
          sr-svc-pgm:sr-services:
    +--rw static-mpls-service-proxy
       +--rw (proxy-type)
          +--:(dynamic)
             +--rw dynamic-proxy
                +--rw out-interface-name    string
                +--rw in-interface-name     string



Static SRv6 SID allocation case:
  TBD


            </artwork>

          </figure>

        </section>

	<section title="Masquerading Proxy" anchor="section_masq_proxy">
          <t>
            The masquerading proxy is an SR endpoint behaviour for processing SRv6 traffic on
            behalf of an SR-unaware service. This masquerading behaviour is independent from 
            the inner payload type.
          </t>
          <t>
            The following parameters are required to provision the SR masquerading proxy
            <list style="symbols">
              <t> next-hop: Next hop Ethernet address </t>
              <t> out-interface-name: Local interface for sending traffic towards the service
                  Endpoint </t>
              <t> in-interface-name: Local interface receiving traffic coming back from the
                  service Endpoint </t>
            </list>
          </t>
          <t>
            Following is a simplified graphical tree representation of the data model for the 
            SR masquerading proxy:
          </t>

          <figure title="SR masquerading Proxy Tree" anchor="Masq">

            <artwork>

Dynamic SID allocation case:

module: ietf-sr-service-programming-proxy
  augment /rt:routing/sr:segment-routing/
          sr-svc-pgm:service-programming/
          sr-svc-pgm:service-program/
          sr-svc-pgm:service-programming-info/
          sr-svc-pgm:sr-services:
    +--rw service-proxy
       +--rw (proxy-type)
          +--:(masquerading)
             +--rw masquerading-proxy
                +--rw next-hop?             yang:mac-address
                +--rw out-interface-name    string
                +--rw in-interface-name     string


Static SRv6 SID allocation case:

TBD

            </artwork>

          </figure>

        </section>

      </section>

    </section>


    <section title="YANG Specification" anchor="YANG">
      <t>
        Following are actual YANG definition for SR service
        programming modules defined earlier in the document.
      </t>

      <section title="Service Types" anchor="YANG-Types">
        <t>
          Following are the Service Types definitions.
        </t>
        <figure title="ietf-service-function-types.yang" anchor="YANG-service-type">
          <artwork>
            <![CDATA[
            <CODE BEGINS> file "ietf-service-function-types.yang" -->

module ietf-service-function-types {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-service-function-types";
  prefix "service-types";

  organization "IETF SPRING Working Group";

  contact
      "WG Web:   <http://tools.ietf.org/wg/spring/>
       WG List:  <mailto:spring@ietf.org>

       Editor:   Jaganbabu Rajamanickam
                 <mailto:jrajaman@cisco.com>

       Editor:   Kamran Raza
                 <mailto:skraza@cisco.com>

       Editor:   Daniel Bernier
                 <mailto:daniel.bernier@bell.ca>

       Editor:   Gaurav Dawra
                 <mailto:gdawra.ietf@gmail.com>

       Editor:   Cheng Li
                 <mailto:c.l@huawei.com>";

  /*
   * Below are the definition for the service types
   * Any new service type could added by extending
   * this identity
   */
  identity service-function-type {
      description
        "Base identity from which specific service function
         types are derived.";
  }

  identity firewall {
      base service-function-type;
      description
        "Firewall Service type";
  }

  identity dpi {
      base service-function-type;
      description
        "Deep Packet Inspection Service type";
  }

  identity napt44 {
      base service-function-type;
      description
        "Network Address and Port Translation 44
         Service type";
  }

  identity classifier {
      base service-function-type;
      description
        "classifier Service type";
  }

  identity load-balancer {
      base service-function-type;
      description
        "load-balancer Service type";
  }

  identity ips {
      base service-function-type;
      description
        "Intrusion Prevention System Service type (Ex: Snort)";
  }

}

            <CODE ENDS>
             ]]>
          </artwork>
        </figure>
      </section>


      <section title="SR Service Programming Types" anchor="YANG-SR-SVC-Types">
        <t>
          Following are the SR service programming specific types definitions.
        </t>
        <figure title="ietf-sr-service-programming-types.yang" anchor="YANG-sr-svc-type">
          <artwork>
            <![CDATA[
            <CODE BEGINS> file "ietf-sr-service-programming-types.yang" -->

module ietf-sr-service-programming-types {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-types";
  prefix "sr-service-types";

  organization "IETF SPRING Working Group";

  contact
      "WG Web:   <http://tools.ietf.org/wg/spring/>
       WG List:  <mailto:spring@ietf.org>

       Editor:   Jaganbabu Rajamanickam
                 <mailto:jrajaman@cisco.com>

       Editor:   Kamran Raza
                 <mailto:skraza@cisco.com>

       Editor:   Daniel Bernier
                 <mailto:daniel.bernier@bell.ca>

       Editor:   Gaurav Dawra
                 <mailto:gdawra.ietf@gmail.com>

       Editor:   Cheng Li
                 <mailto:c.l@huawei.com>";

  /*
   * SR Service programming behaviour
   */
  identity service-program-behaviour-type {
      description
        "Base identity for SR service programming behaviour";
  }

  identity sr-aware {
      base service-program-behaviour-type;
      description
        "SR aware native applications.";
  }

  identity static-proxy {
      base service-program-behaviour-type;
      description
        "Static Proxy";
  }

  identity dynamic-proxy {
      base service-program-behaviour-type;
      description
        "Dynamic Proxy";
  }

  identity Masquerading-proxy {
      base service-program-behaviour-type;
      description
        "Masquerading Proxy";
  }

  identity Masquerading-NAT-proxy {
      base service-program-behaviour-type;
      description
        "Masquerading Proxy with NAT flavor";
  }

  identity Masquerading-caching-proxy {
      base service-program-behaviour-type;
      description
        "Masquerading Proxy with caching flavor";
  }

  identity Masquerading-NAT-caching-proxy {
      base service-program-behaviour-type;
      description
        "Masquerading Proxy with caching flavor";
  }


  /*
   * Below are the definition for the service proxy inner packet types
   * Any new service proxy inner packet type could added by extending
   * this identity
   */
  identity service-proxy-inner-pkt-type {
      description
        "Base identity from which SR service proxy types are derived.";
  }

  identity Ethernet {
      base service-proxy-inner-pkt-type;
      description
        "Expected inner packet type as Ethernet - derived from
         service-proxy-inner-pkt-type";
  }

  identity IPv4 {
      base service-proxy-inner-pkt-type;
      description
        "Expected inner packet type as IPv4 - derived from
         service-proxy-inner-pkt-type";
  }

  identity IPv6 {
      base service-proxy-inner-pkt-type;
      description
        "Expected inner packet type as IPv6 - derived from
         service-proxy-inner-pkt-type";
  }


  /*
   * SR Service SID operational status
   */
  identity service-program-oper-status-type {
      description
        "Base identity from which SR service program operational
         status types are derived.";
  }

  identity up {
      base service-program-oper-status-type;
      description
        "Service program status is operational";
  }

  identity down-unknown {
      base service-program-oper-status-type;
      description
        "Service program status is down because of unknown reason";
  }

  identity sid-allocation-pending {
      base service-program-oper-status-type;
      description
        "Service program status is down because of SID allocation is pending";
  }

  identity sid-allocation-conflict {
      base service-program-oper-status-type;
      description
        "Service program status is down because of SID conflict";
  }

  identity sid-out-of-bound {
      base service-program-oper-status-type;
      description
        "Service program status is down because of SID is out of bound";
  }

  identity interface-down {
      base service-program-oper-status-type;
      description
        "Service program status is down because of out/in interface is down";
  }

  identity admin-forced-down {
      base service-program-oper-status-type;
      description
        "Service program status is administratively forced down";
  }

  /*
   * Typedefs
   */
  typedef admin-status-type {
    type enumeration {
      enum up {
        description "Admin Up";
      }
      enum down {
        description "Admin Down";
      }
    }
  }

  typedef dataplane-type {
    type enumeration {
      enum mpls {
        description "MPLS dataplane";
      }
      enum srv6 {
        description "SRv6 dataplane";
      }
    }
  }

  typedef sid-alloc-mode-type {
    type enumeration {
      enum static {
        description "Static SID allocation";
      }
      enum dynamic {
        description "Dynamic SID allocation";
      }
    }
  }
}

            <CODE ENDS>
             ]]>
          </artwork>
        </figure>
      </section>


      <section title="SR Service Programming Base" anchor="YANG-SR-SVC-Base">
        <t>
          Following are the SR service programming base model definition.
        </t>
        <figure title="ietf-sr-service-programming.yang" anchor="YANG-sr-svc-base">
          <artwork>
            <![CDATA[
            <CODE BEGINS> file "ietf-sr-service-programming.yang" -->

module ietf-sr-service-programming {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-sr-service-programming";
  prefix "sr-svc-pgm";

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

  import ietf-srv6-base {
    prefix "srv6";
  }

  import ietf-routing {
    prefix rt;
    reference "RFC 8349: A YANG Data Model for Routing
               Management (NMDA Version)";
  }

  import ietf-service-function-types {
    prefix "service-types";
  }

  import ietf-segment-routing {
    prefix sr;
  }

  import ietf-segment-routing-mpls {
    prefix srmpls;
  }

  import ietf-sr-service-programming-types {
    prefix "sr-svc-pgm-types";
  }

  import ietf-routing-types {
    prefix "rt-types";
  }

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

  organization "IETF SPRING Working Group";

  contact
      "WG Web:   <http://tools.ietf.org/wg/spring/>
       WG List:  <mailto:spring@ietf.org>

       Editor:   Jaganbabu Rajamanickam
                 <mailto:jrajaman@cisco.com>

       Editor:   Kamran Raza
                 <mailto:skraza@cisco.com>

       Editor:   Daniel Bernier
                 <mailto:daniel.bernier@bell.ca>

       Editor:   Gaurav Dawra
                 <mailto:gdawra.ietf@gmail.com>

       Editor:   Cheng Li
                 <mailto:c.l@huawei.com>";

  grouping service-statistics {

    container statistics {

      config false;
      description "Service statistics";

      leaf in-packet-count {
        type yang:counter64;
        description
          "Total number of packets processed by this service";
      }

      leaf in-bytes-count {
        type yang:counter64;
        description
          "Total number of bytes processed by this service";
      }

      leaf out-packet-count {
        type yang:counter64;
        description
          "Total number of packets end out after processing by this service";
      }

      leaf out-bytes-count {
        type yang:counter64;
        description
          "Total number of bytes end out after processing by this service";
      }

      leaf in-drop-packet-count {
        type yang:counter64;
        description
          "Total number of packets dropped while processing by this service";
      }

      leaf out-drop-packet-count {
        type yang:counter64;
        description
          "Total number of packets dropped while this service try to
           forward to its destination";
      }
    }
  }

  grouping service-mpls-sid-binding {
    container mpls {
      description
        "MPLS Service SID binding Container";

      when "../../service-programming-info/dataplane = 'mpls'";

      leaf sid {
        config false;
        type rt-types:mpls-label;
        description
          "MPLS SID value.";
      }
    }
  }

  grouping service-srv6-sid-binding {
    container srv6 {
      description
        "SRv6 Service SID binding Container";

      when "../../service-programming-info/dataplane = 'srv6'";

      leaf sid {
        config false;
        type srv6-types:srv6-sid;
        description
          "SRv6 SID value.";
      }

      leaf locator {
        type leafref {
          path "/rt:routing/sr:segment-routing"
              + "/srv6:srv6/srv6:locators/srv6:locator/srv6:name";
        }
        description
          "Reference to a SRv6 locator. This is valid only when
           the SID allocation mode is dynamic";
      }
    }
  }

  grouping service-sid-binding {
    container sid-binding {
      description
        "Service SID binding Container";

      leaf alloc-mode {
        config false;
        default dynamic;
        type sr-svc-pgm-types:sid-alloc-mode-type;
        description
          "Service SID allocation mode";
      }

      uses service-mpls-sid-binding;
      uses service-srv6-sid-binding;
    }
  }

  grouping service-programming-infos {
    container service-programming-info {

        leaf behaviour {
          mandatory true;
          type identityref {
            base sr-svc-pgm-types:service-program-behaviour-type;
          }
          description
            "SR program behaviour";
        }

        leaf dataplane {
          mandatory true;
          type sr-svc-pgm-types:dataplane-type;
          description
            "Service SID dataplane.";
        }

        leaf service-name {
          mandatory true;
          type string;
          description
            "Service program name to identify a specific program.";
        }

        leaf service-type {
          mandatory true;
          type identityref {
            base service-types:service-function-type;
          }
          description
            "Service-Type defined by IANA Service Type Table (STT). Like
             Firewall, DPI etc..."; 
        }

        leaf service-variant {
          mandatory true;
          type string;
          description
            "This identifies the variant of the service. This value should 
             be unique in the given network. Example Format: 
             <vendor>-<vendor-sub-variant>-<product-version>.";
        }

        leaf service-instance {
          mandatory true;
          type uint32;
          description
            "Service instance which differentiates the same service -- e.g.
             same vendors Firewall service could have several instances 
             available. This could be used to differentiate the VPN
             customers or for load sharing purposes.";
        }

        leaf admin-status {
          type sr-svc-pgm-types:admin-status-type;
          default down;
          description
            "Admin Status";
        }

        leaf oper-status {
          config false;
          type identityref {
            base sr-svc-pgm-types:service-program-oper-status-type;
          }
          description
            "Service SID operational mode.";
        }

        uses service-statistics;


        container sr-services {

          description
              "Any SR-aware or AR-unaware services could augment this container";
          reference "Segment Routing Service Programming Architecture.";
        }
    }
  }

  grouping service-programmings {
    container service-programming {
      description
        "service programming container.
         Any new services programming added could augment
         this container to support that specific services.
         Currently in this model, only service proxy
         is defined. (i.e) For example if
         a Firewall services needs to be added then
         they could augment this container and
         extend this model";

      list service-program {
        key "name";
        description
          "Service program is keyed by the service program name";

        leaf name {
          mandatory true;
          type leafref {
            path "/rt:routing/sr:segment-routing/"
                + "sr-svc-pgm:service-programming/"
                + "sr-svc-pgm:service-program/"
                + "sr-svc-pgm:service-programming-info/"
                + "sr-svc-pgm:service-name";
          }
        }

        uses service-sid-binding;
        uses service-programming-infos;
      }
    }
  }

  /*
   * MPLS/SRv6 SR service programming using dynamic SID allocation
   */
  augment "/rt:routing/sr:segment-routing" {
    description
      "Augmenting the segment-routing to add SR service programming";

    uses service-programmings;
  }

  /*
   * MPLS SR service programming using static MPLS binding SID
   */
  augment "/rt:routing/sr:segment-routing/srmpls:sr-mpls/srmpls:bindings" {
    description
      "Augmenting the segment-routing MPLS static binding to add static 
       MPLS SR service programming";

    container mpls-static-service-programming {
      description
        "Augmenting the MPLS segment-routing bindings with the SR service 
         programming";
      list service-program {
        key "name";
        description
          "Service program is keyed by the service program name";

        leaf name {
          mandatory true;
          type leafref {
            path "/rt:routing/sr:segment-routing/"
                + "sr-svc-pgm:service-programming/"
                + "sr-svc-pgm:service-program/"
                + "sr-svc-pgm:service-programming-info/"
                + "sr-svc-pgm:service-name";
          }
        }

        leaf sid {
          mandatory true;
          type rt-types:mpls-label;
          description
            "MPLS SID value.";
        }

        uses service-programming-infos {
          /*
           * In the case of MPLs static binding configuration
           * the dataplane is set to mpls and not allowed to
           * configure
           */
          refine service-programming-info/dataplane {
            mandatory false;
            default mpls;
            config false;
          }
        }
      }
    }

  }

  /*
   * SRv6 SR service programming using static SRv6 binding SID
   */
  augment "/rt:routing/sr:segment-routing/srv6:srv6/srv6:locators/srv6:locator" {
    description
      "Augmenting the segment-routing SRv6 static to add static binding to
       SRv6 SR service programming";
       
    container end-AS {
      description
        "End.AS - Static Proxy SID behaviour";
      list service-program {
        key "name";
        description
          "Service program is keyed by the service program name";

        leaf name {
          mandatory true;
          type leafref {
            path "/rt:routing/sr:segment-routing/"
                + "sr-svc-pgm:service-programming/"
                + "sr-svc-pgm:service-program/"
                + "sr-svc-pgm:service-programming-info/"
                + "sr-svc-pgm:service-name";
          }
        }

        uses service-programming-infos {
          /*
           * In the case of SRv6 static binding configuration
           * the dataplane is set to mpls and not allowed to
           * configure
           */
          refine service-programming-info/dataplane {
            config false;
            mandatory false;
            default srv6;
          }
          refine service-programming-info/behaviour {
            config false;
            //when "service-programming-info/dataplane = 'srv6'";
            mandatory false;
            default sr-svc-pgm-types:static-proxy;
          }

        }
      }
    }

    container end-AD {
      description
        "End.AD - Dynamic Proxy SID behaviour";
      list service-program {
        key "name";
        description
          "Service program is keyed by the service program name";

        leaf name {
          mandatory true;
          type leafref {
            path "/rt:routing/sr:segment-routing/"
                + "sr-svc-pgm:service-programming/"
                + "sr-svc-pgm:service-program/"
                + "sr-svc-pgm:service-programming-info/"
                + "sr-svc-pgm:service-name";
          }
        }

        uses service-programming-infos {

          refine service-programming-info/dataplane {
            config false;
            mandatory false;
            default srv6;
          }
          refine service-programming-info/behaviour {
            //when "service-programming-info/dataplane = 'srv6'";
            config false;
            mandatory false;
            default sr-svc-pgm-types:dynamic-proxy;
          }

        }
      }
    }

    container end-AM {
      description
        "End.AD - Masquerading Proxy SID behaviour";
      list service-program {
        key "name";
        description
          "Service program is keyed by the service program name";

        leaf name {
          mandatory true;
          type leafref {
            path "/rt:routing/sr:segment-routing/"
                + "sr-svc-pgm:service-programming/"
                + "sr-svc-pgm:service-program/"
                + "sr-svc-pgm:service-programming-info/"
                + "sr-svc-pgm:service-name";
          }
        }

        uses service-programming-infos {

          refine service-programming-info/dataplane {
            config false;
            mandatory false;
            default srv6;
          }
          refine service-programming-info/behaviour {
            //when "service-programming-info/dataplane = 'srv6'";
            mandatory false;
            default sr-svc-pgm-types:Masquerading-proxy;
          }

        }
      }
    }

  }

  notification service-program-oper-status {
    description
      "This notification is sent when there is a change in the service
       program oper status.";
    leaf name {
      mandatory true;
      type leafref {
        path "/rt:routing/sr:segment-routing/"
            + "sr-svc-pgm:service-programming/"
            + "sr-svc-pgm:service-program/"
            + "sr-svc-pgm:name";
      }
      description
        "Service program name to identify a specific programming.";
    }

    leaf oper-status {
      mandatory true;
      type leafref {
        path "/rt:routing/sr:segment-routing/"
            + "sr-svc-pgm:service-programming/"
            + "sr-svc-pgm:service-program/"
            + "sr-svc-pgm:service-programming-info/"
            + "sr-svc-pgm:oper-status";
      }
      description
        "Service program operational status.";
    }

  }
}

            <CODE ENDS>
             ]]>
          </artwork>
        </figure>
      </section>


      <section title="SR Service Proxy" anchor="YANG-SR-SVC-proxy">
        <t>
          Following are the SR service programming service proxy model definition.
        </t>
        <figure title="ietf-sr-service-programming-proxy.yang" anchor="YANG-sr-svc-proxy">
          <artwork>
            <![CDATA[
            <CODE BEGINS> file "ietf-sr-service-programming-proxy.yang" -->
module ietf-sr-service-programming-proxy {
  yang-version 1.1;

  namespace "urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-proxy";
  prefix "sr-svc-proxy";

  import ietf-yang-types {
    prefix yang;
  }

  import ietf-routing {
    prefix rt;
    reference "RFC 8349: A YANG Data Model for Routing
               Management (NMDA Version)";
  }

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

  import ietf-segment-routing {
    prefix sr;
  }

  import ietf-sr-service-programming {
    prefix "sr-svc-pgm";
  }

  import ietf-sr-service-programming-types {
    prefix "sr-svc-pgm-types";
  }

  import ietf-routing-types {
    prefix "rt-types";
  }

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

  import ietf-segment-routing-mpls {
    prefix sr-mpls;
  }

  organization "IETF SPRING Working Group";

  contact
      "WG Web:   <http://tools.ietf.org/wg/spring/>
       WG List:  <mailto:spring@ietf.org>

       Editor:   Jaganbabu Rajamanickam
                 <mailto:jrajaman@cisco.com>

       Editor:   Kamran Raza
                 <mailto:skraza@cisco.com>

       Editor:   Daniel Bernier
                 <mailto:daniel.bernier@bell.ca>

       Editor:   Gaurav Dawra
                 <mailto:gdawra.ietf@gmail.com>

       Editor:   Cheng Li
                 <mailto:c.l@huawei.com>";

  grouping service-proxy-parameters {

    leaf out-interface-name {
      mandatory true;
      type string;
      description
        "Interface name on which the packet sent to the service endpoint";
    }

    leaf in-interface-name {
      mandatory true;
      type string;
      description
        "Interface name on which the packet received from the service endpoint";
    }
  }

  grouping mpls-packet-cache-info {
    description
      "MPLS Label stack";

    list mpls-sids {
      key "index";

      leaf index {
        type uint8 {
          range "1..16";
        }
        description
          "cache index - MPLS Label stack index";
      }

      leaf mpls-label {
        mandatory true;
        type rt-types:mpls-label;
        description
          "MPLS Label value.";
      }
    }
  }

  grouping srv6-packet-cache-info {
    description
      "SRv6 SID stack";

    leaf ipv6-source-address {
      type inet:ipv6-address;
      description
        "IPv6 source address that needs in the case if SRv6.";
    }
    list srv6-sids {
      key "index";

      leaf index {
        type uint8 {
          range "1..16";
        }
        description
          "cache index - SRv6 SID index";
      }

      leaf srv6-sid {
        mandatory true;
        type srv6-types:srv6-sid;
        description
          "SRv6 SID.";
      }
    }
  }

  grouping service-proxy-packet-cache-info {
    description
      "SRv6 Proxy header cache";

    container packet-cache-info {

      choice cache-type {
        mandatory true;
        case mpls {

          when "/rt:routing/sr:segment-routing
                /sr-svc-pgm:service-programming
                /sr-svc-pgm:service-program
                /sr-svc-pgm:service-programming-info
                /sr-svc-pgm:dataplane = 'mpls'";

          uses mpls-packet-cache-info;
        }
        case srv6 {

          when "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming
            /sr-svc-pgm:service-program
            /sr-svc-pgm:service-programming-info
            /sr-svc-pgm:dataplane = 'srv6'";

          uses srv6-packet-cache-info;
        }
      }
    }
  }

  grouping static-service-proxy {
    container static-proxy {
      when "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming
            /sr-svc-pgm:service-program
            /sr-svc-pgm:service-programming-info
            /sr-svc-pgm:behaviour = 'static-proxy'";
      description
        "Parameters related to static service proxy";

      leaf inner-packet-type {
        mandatory true;
        type identityref {
          base sr-svc-pgm-types:service-proxy-inner-pkt-type;
        }
        description
          "Defines the expected inner packet type";
      }

      leaf next-hop {
        when "(../inner-packet-type = 'IPv4' or ../inner-packet-type = 'IPv6')";
        type yang:mac-address;
        description
          "Nexthop Ethernet address for inner packet type IPv4/IPv6";
      }
      uses service-proxy-parameters;
      uses service-proxy-packet-cache-info;
    }
  }

  grouping dynamic-service-proxy {
    container dynamic-proxy {
      when "/rt:routing/sr:segment-routing/sr-svc-pgm:service-programming
            /sr-svc-pgm:service-program
            /sr-svc-pgm:service-programming-info
            /sr-svc-pgm:behaviour = 'dynamic-proxy'";
      description
        "Parameters related to dynamic service proxy";
      uses service-proxy-parameters;
    }
  }

  grouping masquerading-service-parameters {

    leaf next-hop {
      type yang:mac-address;
      description
        "Nexthop Ethernet address";
    }
    uses service-proxy-parameters;
  }

  grouping masquerading-service-proxy {
    container masquerading-proxy {
      description
        "Parameters related to masquerading service proxy";

      when "/rt:routing/sr:segment-routing
            /sr-svc-pgm:service-programming
            /sr-svc-pgm:service-program
            /sr-svc-pgm:service-programming-info
            /sr-svc-pgm:dataplane = 'srv6' and /rt:routing
            /sr:segment-routing/sr-svc-pgm:service-programming
            /sr-svc-pgm:service-program
            /sr-svc-pgm:service-programming-info
            /sr-svc-pgm:behaviour = 'Masquerading-proxy'";

      uses masquerading-service-parameters;
    }
  }

  grouping service-proxy-programming {
    container service-proxy {

      choice proxy-type {
        mandatory true;
        case static {
          uses static-service-proxy;
        }
        case dynamic {
          uses dynamic-service-proxy;
        }
        case masquerading {
          uses masquerading-service-proxy;
        }
      }
    }

  }

  augment "/rt:routing/sr:segment-routing/
           sr-svc-pgm:service-programming/
           sr-svc-pgm:service-program/
           sr-svc-pgm:service-programming-info/
           sr-svc-pgm:sr-services" {
    description
      "Augmenting the segment-routing bindings to add SR-unaware
       service programming";

    uses service-proxy-programming;
  }

  grouping static-mpls-service-proxy-programming {
    container static-mpls-service-proxy {

      choice proxy-type {
        mandatory true;
        case static {
          uses static-service-proxy;
        }
        case dynamic {
          uses dynamic-service-proxy;
        }
      }
    }

  }

  augment "/rt:routing/sr:segment-routing/
           sr-mpls:sr-mpls/sr-mpls:bindings/
           sr-svc-pgm:mpls-static-service-programming/
           sr-svc-pgm:service-program/
           sr-svc-pgm:service-programming-info/
           sr-svc-pgm:sr-services" {
    uses static-mpls-service-proxy-programming;
  }

}


            <CODE ENDS>
             ]]>
          </artwork>
        </figure>
      </section>


    </section>


    <section title="Security Considerations">

	<t>
	  The YANG module specified in this document defines a schema for data that
	  is designed to be accessed via network management protocols such as
	  NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
	  The lowest NETCONF layer is the secure transport 
	  layer, and the mandatory-to-implement secure transport is Secure Shell (SSH)
	  <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
	  mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.
	</t>

	<t>
	  The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/>
	provides the means to restrict access for particular NETCONF or RESTCONF users to a
	preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.
	</t>

	<t>
	  There are a number of data nodes defined in this YANG module that are writable/creatable/
	  deletable (i.e., config true, which is the default). These data nodes may be considered
	  sensitive or vulnerable in some network environments. Write operations (e.g., edit-config)
	  to these data nodes without proper protection can have a negative effect on network
	  operations.
	</t>

	<t>
	  Some of the readable data nodes in this YANG module may be considered sensitive or
	  vulnerable in some network environments. It is thus important to control read access
	  (e.g., via get, get-config, or notification) to these data nodes. 
	</t>


	<t> It goes without saying that this specification also inherits the security
	considerations captured in the SRv6 specification document
	<xref target="I-D.ietf-spring-sr-service-programming"/>.
	</t>
	      
    </section>
    
      	
    <section title="IANA Considerations">

      <t> This document requests the registration of the following URIs in the IETF
      "XML registry" <xref target="RFC3688"/>: </t>
      <texttable>
	<ttcol>URI</ttcol>
	<ttcol>Registrant</ttcol>
	<ttcol>XML</ttcol>
	
	<c> urn:ietf:params:xml:ns:yang:ietf-service-function-types </c>
	<c> The IESG </c>
	<c> N/A </c>

	<c> urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-types</c>
	<c> The IESG </c>
	<c> N/A </c>

	<c> </c> <c> </c> <c> </c>
	
	<c> urn:ietf:params:xml:ns:yang:ietf-sr-service-programming</c>
	<c> The IESG </c>
	<c> N/A </c>

	<c> urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-proxy</c>
	<c> The IESG </c>
	<c> N/A </c>
	
      </texttable>
      
      
      <t> This document requests the registration of the following YANG modules in the
      "YANG Module Names" registry <xref target="RFC6020"/>: </t>

      <texttable>
	<ttcol> Name </ttcol>
	<ttcol> Namespace </ttcol>
	<ttcol> Prefix </ttcol>
	<ttcol> Reference </ttcol>

	<c> ietf-service-function-types </c>
	<c> urn:ietf:params:xml:ns:yang:ietf-service-function-types </c>
	<c> service-function-types </c>
	<c> This document </c>

	<c> </c> <c> </c> <c> </c> <c> </c>

	<c> ietf-sr-service-programming-types </c>
	<c> urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-types </c>
	<c> ietf-sr-service-programming-types </c>
	<c> This document </c>

	<c> </c> <c> </c> <c> </c> <c> </c>

	<c> ietf-sr-service-programming </c>
	<c> urn:ietf:params:xml:ns:yang:ietf-sr-service-programming </c>
	<c> ietf-sr-service-programming </c>
	<c> This document </c>

	<c> </c> <c> </c> <c> </c> <c> </c>
	
	<c> ietf-sr-service-programming-proxy </c>
	<c> urn:ietf:params:xml:ns:yang:ietf-sr-service-programming-proxy </c>
	<c> ietf-sr-service-programming-proxy </c>
	<c> This document </c>
      </texttable>
      
      <t> -- RFC Editor: Replace "This document" with the document RFC number at time of publication,
      and remove this note.
      </t>
      
    </section>
         
    <section title="Acknowledgments">
      <t> The authors would like to acknowledge Francois Clad, Ketan Talaulikar, and 
          Darren Dukes for their review of some of the contents in this document. </t>
   

    </section>
    
  </middle>
  
  <back>
      
    <references title="Normative References">
      &rfc2119;
      <?rfc include="reference.RFC.3688"?>
      <?rfc include="reference.RFC.6020"?>
      <?rfc include="reference.RFC.6241"?>
      <?rfc include="reference.RFC.6242"?>
      <?rfc include="reference.RFC.8040"?>     
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8340"?>
      <?rfc include="reference.RFC.8341"?>
      <?rfc include="reference.RFC.8342"?>
      <?rfc include="reference.RFC.8446"?>
      <?rfc include="reference.RFC.8402"?>
      <?rfc include="reference.RFC.9020"?>
      <?rfc include="reference.I-D.ietf-spring-sr-service-programming"?>
      <?rfc include="reference.I-D.ietf-spring-segment-routing-policy"?>
      <?rfc include="reference.RFC.8754"?>  
      <?rfc include="reference.RFC.8407"?>  
    </references>

  </back>
 
</rfc>
