draft-ietf-opsawg-sap.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC7950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml">
<!ENTITY RFC7149 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7149.xml">
<!ENTITY RFC7426 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7426.xml">
<!ENTITY RFC8299 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8299.xml">
<!ENTITY RFC8309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8309.xml">
<!ENTITY RFC8340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8340.xml">
<!ENTITY RFC8453 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8453.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8345 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8345.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-opsawg-sap-09" ipr="trust200902">
  <front>
    <title abbrev="A YANG Model for SAPs">A YANG Network Model for Service
    Attachment Points (SAPs)</title>

    <author fullname="Mohamed Boucadair" initials="M." role="editor"
            surname="Boucadair">
      <organization>Orange</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>France</country>
        </postal>

        <phone></phone>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Oscar Gonzalez de Dios" initials="O"
            surname="Gonzalez de Dios">
      <organization>Telefonica</organization>

      <address>
        <postal>
          <street></street>

          <city>Madrid</city>

          <region></region>

          <code></code>

          <country>Spain</country>
        </postal>

        <phone></phone>

        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>

    <author fullname="Samier Barguil" initials="S." surname="Barguil">
      <organization>Telefonica</organization>

      <address>
        <postal>
          <street></street>

          <city>Madrid</city>

          <region></region>

          <code></code>

          <country>Spain</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>samier.barguilgiraldo.ext@telefonica.com</email>

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

    <author fullname="Victor Lopez" initials="V." surname="Lopez">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country>Spain</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>victor.lopez@nokia.com</email>

        <uri></uri>
      </address>
    </author>

    <date year="2022" />

    <area>ops</area>

    <workgroup>OPSAWG</workgroup>

    <keyword>Service Infrastructure</keyword>

    <keyword>User Network Interface</keyword>

    <keyword>UNI</keyword>

    <keyword>NNI</keyword>

    <keyword>Network-to-Network Interface</keyword>

    <keyword>Inter-AS VPN</keyword>

    <keyword>CE</keyword>

    <keyword>PE</keyword>

    <keyword>Attachment Circuit</keyword>

    <keyword>Service Delivery Point</keyword>

    <keyword>Automation</keyword>

    <keyword>Service Delivery</keyword>

    <abstract>
      <t>This document defines a YANG data model for representing an abstract
      view of the provider network topology that contains the points from
      which its services can be attached (e.g., basic connectivity, VPN,
      network slices). Also, the model can be used to retrieve the points
      where the services are actually being delivered to customers (including
      peer networks).</t>

      <t>This document augments the 'ietf-network' data model by adding the
      concept of Service Attachment Points (SAPs). The SAPs are the network
      reference points to which network services, such as Layer 3 Virtual
      Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can
      be attached. Both User-Network Interface (UNI) and Network-to-Network
      Interface (NNI) are supported in the SAP data model.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>Service providers offer a variety of network services to their
      customers. Such services include, but are not limited to, Virtual
      Private Networks (VPNs), Software-Defined Wide Area Network (SDWAN)
      <xref target="I-D.ietf-bess-bgp-sdwan-usage"></xref>, and network slices
      <xref target="I-D.ietf-teas-ietf-network-slices"></xref>. In order to
      rationalize the overall service operations and allow for more automated
      service provisioning procedures, service providers need to maintain a
      view on where services can be delivered to customers. Such a view can be
      used, e.g., to feed an intelligence that is responsible for service
      order handling, service feasibility checks, tracking per-service
      coverage, etc. To that aim, this document introduces the concept of
      Service Attachment Points (SAPs).</t>

      <t>The SAPs represent the network reference points where network
      services can be delivered to customers. For example, this concept is
      used to decide where to attach and, thus, deliver the service in the
      Layer 3 VPN Service Model (L3SM) <xref target="RFC8299"></xref> and the
      Layer 2 VPN Service Model (L2SM) <xref target="RFC8466"></xref>. It can
      also be used to retrieve where such services are delivered to customers
      through the network configuration described in the Layer 3 VPN Network
      Model (L3NM) <xref target="RFC9182"></xref> and the Layer 2 VPN Network
      Model (L2NM) <xref target="I-D.ietf-opsawg-l2nm"></xref>.</t>

      <t>This document defines a YANG network model (<xref
      target="mod"></xref>) for representing, managing, and controlling the
      SAPs. The data model augments the 'ietf-network' module <xref
      target="RFC8345"></xref> by adding the concept of SAPs. <xref
      target="usage"></xref> provides a sample usage of the model. This
      document explains the scope and purpose of a SAP network model and its
      relation with other models (<xref target="rel"></xref>).</t>

      <t>A network may support multiple services, potentially of different
      types. Whether a SAP topology is dedicated to services of a specific
      service type, an individual service, or shared among many services of
      different types is deployment specific. This document supports all of
      these deployment schemes.</t>

      <t>This document does not make any assumption about the services
      provided by a network to its users. VPN services (e.g., Layer 3 Virtual
      Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN))
      <xref target="RFC4026"></xref> are used for illustration purposes
      (Appendices <xref format="counter" target="app1"></xref> and <xref
      format="counter" target="sample"></xref>).</t>

      <t>Given that User-Network Interface (UNI) and Network-to-Network
      Interface (NNI) are reference points that are widely used by operators
      to indicate the demarcation points when delivering services, both UNI
      and NNI SAPs are supported in the document. The reader may refer, e.g.,
      to <xref target="MEF6"></xref>, <xref target="MEF17"></xref>, <xref
      target="RFC6004"></xref>, or <xref target="RFC6215"></xref> for a
      discussion on the use of UNI and NNI reference points. An example of NNI
      usage in a VPN context is provided in <xref target="nniapp"></xref>.</t>

      <t>The YANG data model in <xref target="mod"></xref> conforms to the
      Network Management Datastore Architecture (NMDA) <xref
      target="RFC8342"></xref>.</t>
    </section>

    <section anchor="terminology" title="Terminology">
      <t>This document assumes that the reader is familiar with the contents
      of <xref target="RFC6241"></xref>, <xref target="RFC7950"></xref>, <xref
      target="RFC8345"></xref>, and <xref target="RFC8309"></xref>. The
      document uses terms from those documents.</t>

      <t>The meanings of the symbols in tree diagrams are defined in <xref
      target="RFC8340"></xref>.</t>

      <t>This document uses the term "network model" defined in Section 2.1 of
      <xref target="RFC8969"></xref>.</t>

      <t>This document uses the following terms:<list style="hanging">
          <t hangText="Service povider: ">The organization responsible for
          operating the network that offers a service (e.g., a VPN) to
          customers.</t>

          <t hangText="Attachment Circuit (AC):">A channel that connects a
          Customer Edge (CE) to a Provider Edge (PE). The AC may be a physical
          or logical link (Section 6.1 of <xref target="RFC4026"></xref>).</t>

          <t hangText="Customer Edge (CE): ">An equipment that is dedicated to
          a particular customer and is directly connected to one or more PEs
          via ACs. A CE is usually located at the customer premises. A CE may
          be dedicated to a single service (e.g., L3VPN), although it may
          support multiple VPNs if each one has separate attachment circuits.
          A CE can be a router, a bridge, a switch, etc.</t>

          <t hangText="Provider Edge (PE): ">An equipment owned and managed by
          the service provider that can support multiple services (e.g., VPNs)
          for different customers. A PE is directly connected to one or more
          CEs via ACs.</t>

          <t hangText="Service Attachment Points (SAPs):">An abstraction of
          the network reference points (e.g., PE side of an AC, CE side of an
          AC for a provider-managed CE) where network services can be
          delivered and/or are delivered to customers.</t>
        </list></t>
    </section>

    <section anchor="usage" title="Sample SAP Network Model Usage">
      <t>Management operations of a service provider network can be automated
      using a variety of means such as interfaces based on YANG modules <xref
      target="RFC8969"></xref>. From that standpoint, and considering the
      architecture depicted in <xref target="fi1"></xref>, a goal of this
      document is to provide a mechanism to show via a YANG-based interface an
      abstracted network view from the network controller to the service
      orchestration layer with a focus on where a service can be delivered to
      customers. The model is also used to retrieve the network reference
      points where a service is being delivered to customers. For services
      that require resources from peer networks, the module can also be used
      to expose NNIs.</t>

      <figure align="center" anchor="fi1" title="SAP Network Model Usage">
        <artwork align="left"><![CDATA[                            +-----------------+
                            |     Customer    |
                            +--------+--------+
            Customer Service Models  |
               (e.g., L3SM, L2SM)    |
                            +--------+--------+
                            |    Service      |
                            |  Orchestration  |
                            +------+---+------+
                Network Models     |   | SAP Network Model
              (e.g., L3NM, L2NM)   |   |
                            +------+---+------+
                            |     Network     |
                            |   Controller    |
                            +--------+--------+
                                     |
               +---------------------+---------------------+
               |                  Network                  |
               +-------------------------------------------+
]]></artwork>
      </figure>

      <t></t>

      <t>The service orchestration layer does not need to know about the
      internals of the underlying network (e.g., P nodes). <xref
      target="fi2a"></xref> shows the abstract network view as seen by a
      service orchestrator. However, this view is not enough to provide to the
      service orchestration layer the information to create services in the
      network. The service topology need is to be able to expose the set of
      nodes and the attachment points associated with the nodes from which
      network services can be grafted (delivered).</t>

      <t><figure align="center" anchor="fi2a"
          title="Abstract Network Topology">
          <artwork align="center"><![CDATA[.---------.          .---------.
|   PE1   |          |   PE2   |
'---------'          '---------'
           \        /
            \------/
            (      )
           (        )
            (      )
            /------\
          /         \                                       
.---------.          .---------.
|   PE3   |          |   PE4   |
'---------'          '---------']]></artwork>
        </figure></t>

      <t>Typically, and focusing on the UNIs, the service orchestration layer
      would see a set of PEs and a set of client-facing interfaces (physical
      or logical) to which CEs can be connected (or are actually connected).
      Such interfaces are also referred to as UNI-N (User-to-Network
      Interface, Network side) <xref target="RFC6215"></xref>. The service
      orchestration layer can use these interfaces to set up the requested
      services or to commit the delivery of a service. <xref
      target="fi3"></xref> depicts a sample SAP network topology that is
      maintained by the network controller and exposed to the service
      orchestration.</t>

      <figure align="center" anchor="fi3" title="SAP Network Topology">
        <artwork align="center"><![CDATA[           .-+-. .-+-. .-+-.              .-+-.       .-+-.   
         .-|sap|-|sap|-|sap|-.          .-|sap|-------|sap|-. 
         | '---' '---' '---' |          | '---'       '---' |
       .---.                 |          |                   |
       |sap|      PE1        |          |         PE2       |
       '---'                 |          |                   |
         |                   |          |                   |
         '-------------------'          '-------------------'
                                                   
                                                   
         .-------------------.          .-------------------.
         |                   |          |                   |
         |                   |          |                 .---.
         |         PE3       |          |        PE4      |sap|
         |                   |          |                 '---'
         | .---. .---. .---. |          | .---. .---. .---. |  
         '-|sap|-|sap|-|sap|-'          '-|sap|-|sap|-|sap|-'  
           '-+-' '-+-' '-+-'              '-+-' '-+-' '-+-'       
]]></artwork>
      </figure>

      <t>A single SAP network topology can be used for one or multiple service
      types (e.g., L3VPN, Ethernet VPN (EVPN)). The network controller can,
      then, expose the service types and associated interfaces via the
      SAPs.</t>

      <t>As shown in <xref target="fi3a"></xref>, the service orchestration
      layer will have also access to a set of customer service model (e.g.,
      the L3SM or the L2SM) in the customer-facing interface and a set of
      network models (e.g., the L3NM and network topology data models) in the
      resource-facing interface. In this use case, it is assumed that the
      network controller is unaware of what happens beyond the PEs towards the
      CEs; it is only responsible for the management and control of the SAPs
      and the network between PEs. In order to correlate between delivery
      points expressed in service requests and SAPs, the SAP model may include
      a peer customer point identifier. That identifier can be a CE
      identifier, a site identifier, etc.</t>

      <t><figure align="center" anchor="fi3a"
          title="Network Topology with CEs and ACs">
          <artwork align="center"><![CDATA[                                                      .---.
                                                      |CE2|
                                                      '-+-'
                                                        | 
           .-+-. .-+-. .-+-.              .-+-.       .-+-.   
         .-|sap|-|sap|-|sap|-.          .-|sap|-------|sap|-. 
         | '---' '---' '---' |          | '---'       '---' |
.---.  .---.                 |          |                   |
|CE1+--+sap|      PE1        |          |         PE2       |
'---'  '---'                 |          |                   |
         |                   |          |                   |
         '-------------------'          '-------------------'
                                                   
                                                   
         .-------------------.          .-------------------.
         |                   |          |                   |
         |                   |          |                 .---.  .---.
         |         PE3       |          |        PE4      |sap+--+CE5|
         |                   |          |                 '---'  '---'
         | .---. .---. .---. |          | .---. .---. .---. |  
         '-|sap|-|sap|-|sap|-'          '-|sap|-|sap|-|sap|-'   
           '-+-' '-+-' '-+-'              '-+-' '-+-' '-+-'   
                         |                  |     | 
                       .-+-.                |   .-+-.
                       |CE3+----------------'   |CE4|
                       '-+-'                    '-+-'   
]]></artwork>
        </figure></t>

      <t>Refer to <xref target="app1"></xref> for an example echoing the
      topology depicted in <xref target="fi3a"></xref>.</t>
    </section>

    <section anchor="rel" title="Relationship to Other YANG Data Models">
      <t>The SAP network model can be seen as inventory data associated with
      SAPs. The model maintains an inventory of nodes contained in a network
      relying upon <xref target="RFC8345"></xref>.</t>

      <figure align="center" anchor="fig5"
              title="Relation of SAP Network Model to Other Models">
        <artwork align="center"><![CDATA[                +-------------------------+
                |                         |
                |  Abstract Network Model |
                |                         |
                +------------+------------+
                             |
                   +---------+---------+
                   |                   |
            +------V------+     +------V------+
            |  Abstract   |     |  Inventory  |
            |  Network    |     |    Models   |
            |  Topology   |     |   e.g., SAP |
            |   Model     |     |   Network   |
            |             |     |    Model    |
            +-----+-------+     +-------------+
                  |
      +-----------+-----------+
      |           |           |
 +----V----+ +----V----+ +----V----+
 |TE Topo  | |L3 Topo  | |L2 Topo  |
 |  Model  | |  Model  | |  Model  | ...
 +---------+ +---------+ +---------+]]></artwork>
      </figure>

      <t><xref target="fig5"></xref> depicts the relationship of the SAP
      network model to other models. The SAP network model augments the
      Network model <xref target="RFC8345"></xref> and imports the Network
      Topology model, while other technology-specific topology models (e.g.,
      Traffic Engineering (TE) Topologies model <xref target="RFC8795"></xref>
      or Layer 3 Topologies model <xref target="RFC8346"></xref>) augment the
      Network Topology model.</t>

      <t>Also, the SAP is not a tunnel termination point (TTP) (Section 3.6 of
      <xref target="RFC8795"></xref>) nor a link.</t>

      <t>In the context of Software-Defined Networking (SDN) <xref
      target="RFC7149"></xref><xref target="RFC7426"></xref>, the SAP YANG
      data model can be used to exchange information between control elements,
      so as to support VPN service provision and resource management discussed
      in <xref target="RFC9182"></xref><xref
      target="I-D.ietf-opsawg-l2nm"></xref>. Through this data model, the
      service orchestration layer can learn the available endpoints (i.e.,
      SAPs) of interconnection resources of the underlying network. The
      service orchestration layer can determine which interconnection
      endpoints to add to an L2VPN or L3VPN service. With the help of other
      data models (e.g., L3SM <xref target="RFC8299"></xref> or L2SM <xref
      target="RFC8466"></xref>), hierarchical control elements can also assess
      the feasibility of an end-to-end IP connectivity or L2VPN connectivity
      and, therefore, derive the sequence of domains and the points of
      interconnection to use.</t>

      <t>Advanced interface-specific data nodes are not included in the SAP
      model. The interface identifiers listed in the SAP model can be used as
      filters to set or get such data using device models (e.g., <xref
      target="RFC7224"></xref>).</t>
    </section>

    <section anchor="tree" title="SAP Module Tree Structure">
      <t>The SAP network model 'ietf-sap-ntw' builds on the 'ietf-network'
      module <xref target="RFC8345" /> by augmenting the nodes with SAPs.</t>

      <t>The structure of the 'ietf-sap-ntw' module is shown in <xref
      target="fi4" />.</t>

      <figure align="center" anchor="fi4"
              title="SAP YANG Module Tree Structure">
        <artwork align="center"><![CDATA[module: ietf-sap-ntw
  augment /nw:networks/nw:network/nw:network-types:
    +--rw sap-network!
       +--rw service-type*   identityref
  augment /nw:networks/nw:network/nw:node:
    +--rw service* [service-type]
       +--rw service-type                   identityref
       +--rw sap* [sap-id]
          +--rw sap-id                      string
          +--rw description?                string
          +--rw parent-termination-point?   nt:tp-id
          +--rw attachment-interface?       string
          +--rw interface-type?             identityref
          +--rw encapsulation-type?         identityref
          +--rw role?                       identityref
          +--rw peer-sap-id?                string
          +--ro sap-status
          |  +--ro status?        identityref
          |  +--ro last-change?   yang:date-and-time
          +--ro service-status
             +--ro status?        identityref
             +--ro last-change?   yang:date-and-time

]]></artwork>
      </figure>

      <t />

      <t>A SAP network topology can be used for one or multiple service types
      ('service-type'). Examples of supported service types are as
      follows:<list style="symbols">
          <t>L3VPN <xref target="RFC4364" />,</t>

          <t>Virtual Private LAN Service (VPLS) <xref target="RFC4761" /><xref
          target="RFC4762" />,</t>

          <t><xref target="RFC8214">Virtual Private Wire Service
          (VPWS)</xref>,</t>

          <t><xref target="RFC7432">BGP MPLS-Based Ethernet VPN</xref>,</t>

          <t><xref target="RFC8214">VPWS in Ethernet VPN</xref>,</t>

          <t><xref target="RFC7623">Provider Backbone Bridging Combined with
          Ethernet VPN (PBB-EVPN)</xref>,</t>

          <t>VXLAN-based EVPN <xref target="RFC8365" />,</t>

          <t>Virtual Networks <xref target="RFC8453" />,</t>

          <t>Enhanced VPN (VPN+) <xref
          target="I-D.ietf-teas-enhanced-vpn" />,</t>

          <t>Network slice <xref
          target="I-D.ietf-teas-ietf-network-slices" />,</t>

          <t>SDWAN <xref target="I-D.ietf-bess-bgp-sdwan-usage" />, and</t>

          <t>Basic IP connectivity.</t>
        </list></t>

      <t>These service types build on the types that are already defined in
      <xref target="RFC9181" /> and additional types that are defined in this
      document. Other service types can be defined in future YANG modules, if
      needed.</t>

      <aside pn="section-5">
        <t indent="0" pn="section-5.1">Leveraging the service types defined in
        <xref target="RFC9181" /> is meant to ease the correlation between the
        SAP topology and the corresponding network modules that are used to
        provision a specific service over a provider's network.</t>
      </aside>

      <t>Filters based on the service type can be used to access per-service
      SAP topology. An example is depicted in <xref
      target="app-ex-res-body-filter" />.</t>

      <t>A node in the topology can support one or multiple service types
      ('service-type') among those listed under the 'sap-network' container. A
      list of SAPs are then bound to each service type that is supported by a
      given node. Each SAP is characterized as follows:<list style="hanging">
          <t hangText="'sap-id':">Includes an identifier that uniquely
          identifies a SAP within a node. <vspace blankLines="1" />The same
          SAP may appear under distinct service types. In such a case, the
          same identifier is used for these service types in
          association.<vspace blankLines="1" />SAPs that are associated with
          the interfaces that are directly hosting services, interfaces that
          are ready to host per-service sub-interfaces (but not yet
          activated), or service that are already instantiated on
          sub-interfaces are listed as SAPs.<vspace blankLines="1" />For
          example, 'sap-id' may be the VPN network access identifier in
          Section 7.6 of <xref target="RFC9182" />. An example to illustrate
          the use of this attribute during service creation is provided in
          <xref target="servicesap" />.</t>

          <t hangText="'description':">Includes a textual description of the
          SAP.</t>

          <t hangText="'parent-termination-point':">Includes a reference to
          the parent termination point to which the SAP is bound. As per
          Section 4.2 of <xref target="RFC8345" />, a termination point
          terminates a link in a node. A termination point can be a physical
          port, an interface, etc. <vspace blankLines="1" />This attribute is
          used, e.g., to associate an interface with its sub-interfaces as all
          these interfaces may be listed under the SAPs of a node. It is also
          used to link a SAP with the physical topology.<vspace
          blankLines="1" />For example, this data node can be used to map the
          IETF Network Slice endpoints (<xref
          target="I-D.ietf-teas-ietf-network-slices" />) to the
          service/tunnel/path endpoints in the underlay network.</t>

          <t hangText="'attachment-interface':">Indicates a reference to the
          interface to which the SAP is bound. The same interface may host
          multiple services. <vspace blankLines="1" />Whether the attachment
          identifier echoes the content of the attachment interface is
          deployment specific. <vspace blankLines="1" />For example, this
          reference may be any of the identifiers ('l2-termination-point',
          'local-bridge-reference', 'bearer-reference', or 'lag-interface-id')
          defined in Section 7.6.1 of <xref target="RFC9182" /> or
          'l3-termination-point' defined in Section 7.6.2 of <xref
          target="RFC9182" />. It is responsibility of the controller to
          ensure that consistent references are used in the SAP and underlying
          device modes or any other device inventory mechanism.</t>

          <t hangText="'interface-type':">Indicates whether a SAP is bound to
          a physical port, a loopback interface, a Link Aggregation Group
          (LAG) interface <xref target="IEEE802.1AX" />, an Integrated Routing
          Bridge (IRB) (e.g., <xref target="RFC9135" />), a local bridge
          reference, etc. <vspace blankLines="1" />The mapping to the detailed
          interface types as per <xref target="RFC7224" /> is maintained by
          the controller. That mapping is used, for example, when the
          controller translates this SAP network module into device
          modules.</t>

          <t hangText="'encapsulation-type':">Indicates the encapsulation type
          for the interface indicated in the 'attachment-interface' attribute.
          The types are taken from <xref target="RFC9181" />. <vspace
          blankLines="1" />This data node can be used, for example, to decide
          whether an existing SAP can be (re)used to host a service or if a
          new sub-interface has to be instantiated.</t>

          <t hangText="'role':">Specifies the role of a SAP (e.g., a UNI or
          NNI). <vspace blankLines="1" />A SAP inherits the role of its parent
          interface ('parent-termination-point').</t>

          <t hangText="'peer-sap-id':">Includes a reference to the remote
          endpoint of an attachment circuit. <vspace blankLines="1" />Examples
          of such a reference are: a site identifier (Section 6.3 of <xref
          target="RFC8299" />), a Service Demarcation Point (SDP) identifier
          (Section 2.1 of <xref
          target="I-D.ietf-teas-ietf-network-slices" />), the IP address of a
          peer Autonomous System Border Router (ASBR).</t>

          <t hangText="'sap-status':">Indicates the operational status of a
          SAP. Values are taken from the values defined in <xref
          target="RFC9181" />.<vspace blankLines="1" />When both a
          sub-interface and its parent interface are present, the status of
          the parent interface takes precedence over the status indicated for
          the sub-interface.</t>

          <t hangText="'service-status':">Reports the operational status of
          service for a given SAP. This information is particularly useful
          when many services are enabled for the same SAP, but only a subset
          of them are activated.</t>
        </list></t>

      <t />
    </section>

    <section anchor="mod" title="SAP YANG Module">
      <t>This module imports types from <xref target="RFC8343"></xref>, <xref
      target="RFC8345"></xref>, and <xref target="RFC9181"></xref>.</t>

      <t>The 'sap-information' is defined as a grouping for the reuse of these
      nodes in service-specific YANG modules.</t>

      <figure>
        <artwork><![CDATA[<CODE BEGINS>  file "ietf-sap-ntw@2022-04-11.yang"
module ietf-sap-ntw {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw";
  prefix sap;

  import ietf-network-topology {
    prefix nt;
    reference
      "RFC 8345: A YANG Data Model for Network
                 Topologies, Section 6.2";
  }
  import ietf-network {
    prefix nw;
    reference
      "RFC 8345: A YANG Data Model for Network
                 Topologies, Section 6.1";
  }
  import ietf-vpn-common {
    prefix vpn-common;
    reference
      "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3
                 VPNs";
  }

  organization
    "IETF OPSA (Operations and Management Area) Working Group ";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>

     Editor:   Mohamed Boucadair
               <mailto:mohamed.boucadair@orange.com>

     Author:   Oscar Gonzalez de Dios
               <mailto:oscar.gonzalezdedios@telefonica.com>

     Author:   Samier Barguil
               <mailto:samier.barguilgiraldo.ext@telefonica.com>

     Author:   Qin Wu
               <mailto:bill.wu@huawei.com>

     Author:   Victor Lopez
               <victor.lopez@nokia.com>";
  description
    "This YANG module defines a model for representing, managing,
     and controlling the Service Attachment Points (SAPs) in the
     network topology.

     Copyright (c) 2022 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.";

  revision 2022-04-11 {
    description
      "Initial version";
    reference
      "RFC XXXX: A YANG Network Model for Service Attachment 
                 Points (SAPs)";
  }

  identity virtual-network {
    base vpn-common:service-type;
    description
      "Virtual network. Refers to a logical network instance
       that is built over a physical network.";
    reference
      "RFC 8453: Framework for Abstraction and Control of TE
                 Networks (ACTN)";
  }

  identity enhanced-vpn {
    base vpn-common:service-type;
    description
      "Enhanced VPN (VPN+). VPN+ is an approach that is
       based on existing VPN and Traffic Engineering (TE) 
       technologies but adds characteristics that specific
       services require over and above traditional VPNs.";
    reference
      "draft-ietf-teas-enhanced-vpn: 
         A Framework for Enhanced Virtual Private Network
         (VPN+) Services";
  }

  identity network-slice {
    base vpn-common:service-type;
    description
      "IETF network slice.  An IETF network slice
       is a logical network topology connecting a number of
       endpoints using a set of shared or dedicated network
       resources that are used to satisfy specific service
       objectives.";
    reference
      "draft-ietf-teas-ietf-network-slices:
         Framework for IETF Network Slices";
  }

  identity sdwan {
    base vpn-common:service-type;
    description
      "PE-based Software-Defined Wide Area Network (SDWAN).";
    reference
      "draft-ietf-bess-bgp-sdwan-usage: BGP Usage for SDWAN 
         Overlay Network";
  }

  identity basic-connectivity {
    base vpn-common:service-type;
    description
      "Basic IP connectivity. This is, for example, a plain
       connectivity offered to Enterprises over a dedicated
       or shared MPLS infrastructure.";
  }

  identity interface-role {
    description
      "Base identity for the network role of an interface.";
  }

  identity uni {
    base interface-role;
    description
      "User-Network Interface (UNI).";
  }

  identity nni {
    base interface-role;
    description
      "Network-to-Network Interface (NNI).";
  }

  identity interface-type {
    description
      "Base identity for the interface type.";
  }

  identity phy {
    base interface-type;
    description
      "Physical port.";
  }

  identity loopback {
    base interface-type;
    description
      "Loopback interface.";
  }

  identity lag {
    base interface-type;
    description
      "Link Aggregation Group (LAG) interface.";
  }

  identity irb {
    base interface-type;
    description
      "Integrated Routing Bridge (IRB). An IRB typically
       connects an IP-VRF to a bridge domain.";
  }

  identity local-bridge {
    base interface-type;
    description
      "A local bridge reference to accommodate, e.g., 
       implementations that require internal bridging.
       When such a type is used, a reference to a local
       bridge domain is used to identify the interface.";
  }

  identity logical {
    base interface-type;
    description
      "Refers to a logical sub-interface that is typically 
       used to bind a service. This type is used only
       if none of the other logical types can be used.";
  }

  grouping sap-information {
    description
      "Service Attachment Point (SAP) information.";
    list sap {
      key "sap-id";
      description
        "The Service Attachment Points are abstraction of
         the points where network services such as L3VPNs,
         L2VPNs, or network slices can be attached to.";
      leaf sap-id {
        type string;
        description
          "Indicates an identifier that uniquely identifies
           SAP within a node.";
      }
      leaf description {
        type string;
        description
          "A textual description of the SAP.";
      }
      leaf parent-termination-point {
        type nt:tp-id;
        description
          "Indicates the parent termination point to 
           which the SAP is attached to. A termination
           point can be a physical port, an interface, etc.";
      }
      leaf attachment-interface {
        type string;
        description
          "Indicates the interface to which the SAP is bound.";
      }
      leaf interface-type {
        type identityref {
          base interface-type;
        }
        description
          "The type of the interface to which the SAP is bound.";
      }
      leaf encapsulation-type {
        type identityref {
          base vpn-common:encapsulation-type;
        }
        description
          "Encapsulation type of the interface to which the 
           SAP is bound.";
      }
      leaf role {
        type identityref {
          base interface-role;
        }
        description
          "Indicates the role of a SAP.";
      }
      leaf peer-sap-id {
        type string;
        description
          "Indicates an identifier of the peer's termination
           identifier (e.g., Customer Edge (CE)). This 
           information can be used for correlation purposes, 
           such as identifying the SAP that is attached to 
           an endpoint that is provided in a service request.";
      }      
      container sap-status {
        config "false";
        description
          "Indicates the SAP status.";
        uses vpn-common:oper-status-timestamp;
      }
      container service-status {
        config "false";
        description
          "Indicates the service status.";
        uses vpn-common:oper-status-timestamp;
      }
    }
  }

  augment "/nw:networks/nw:network/nw:network-types" {
    description
      "Introduces a new network type for SAP network.";
    container sap-network {
      presence "Indicates SAP network type.";
      description
        "The presence of the container node indicates the 
         SAP network type.";
      leaf-list service-type {
        type identityref {
          base vpn-common:service-type;
        }
        description
          "Indicates the set of supported service types.";
      }
    }
  }

  augment "/nw:networks/nw:network/nw:node" {
    when "../nw:network-types/sap:sap-network" {
      description
        "Augmentation parameters apply only for SAP 
         networks.";
    }
    description
      "SAP parameters for the node level.";
    list service {
      key "service-type";
      description
        "A list of supported service types for the node.";
      leaf service-type {
        type identityref {
          base vpn-common:service-type;
        }
        description
          "Indicates a service type.";
      }
      uses sap-information;
   }
  }
}
<CODE ENDS>]]></artwork>
      </figure>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document registers the following namespace URI in the "ns"
      subregistry within the "IETF XML Registry" <xref
      target="RFC3688"></xref>: <figure>
          <artwork><![CDATA[    URI: urn:ietf:params:xml:ns:yang:ietf-sap-ntw
    Registrant Contact: The IESG.
    XML: N/A, the requested URI is an XML namespace.
]]></artwork>
        </figure></t>

      <t>This document registers the following YANG module in the YANG Module
      Names registry <xref target="RFC6020"></xref> within the "YANG
      Parameters" registry: <figure>
          <artwork><![CDATA[    name: ietf-sap-ntw
    namespace: urn:ietf:params:xml:ns:yang:ietf-sap-ntw
    maintained by IANA? N
    prefix: sap
    reference: RFC XXXX
]]></artwork>
        </figure></t>
    </section>

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

      <t>The Network Configuration Access Control Model (NACM) <xref
      target="RFC8341"></xref> 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. These are the subtrees and data nodes and their
      sensitivity/vulnerability: <list style="symbols">
          <t>/nw:networks/nw:network/nw:node/sap:service-type/sap:sap<vspace
          blankLines="1" />This subtree specifies the configurations of the
          nodes in a SAP network model. Unexpected changes to this subtree
          (e.g., associating a SAP with another parent termination point)
          could lead to service disruption and/or network misbehavior.</t>
        </list></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. These are the subtrees and data nodes
      and their sensitivity/vulnerability:<list style="symbols">
          <t>/nw:networks/nw:network/nw:node/sap:service-type/sap:sap<vspace
          blankLines="1" />Unauthorized access to this subtree can disclose
          the operational state information of the nodes in a SAP network
          model (e.g., disclose the identity of a customer 'peer-sap-id').</t>
        </list></t>

      <t></t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Adrian Farrell, Daniel King, Dhruv Dhody, Benoit Claise, Bo
      Wu, Erez Segev, Raul Arco, Joe Clarke, Riyas Valiyapalathingal, Tom
      Petch, and Olga Havel for the comments.</t>

      <t>Thanks to Martin Bj&ouml;rklund for yang-doctors review, Menachem
      Dodge for the opsdir review, and Mach Chen for the rtgdir review.</t>

      <t>Special thanks to Adrian Farrel for the Shepherd review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.3688"?>

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.RFC.9181'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.7149"?>

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

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

      <?rfc include='reference.RFC.8466'?>

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

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

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

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

      <?rfc include='reference.RFC.9182'?>

      <?rfc include='reference.I-D.ietf-opsawg-l2nm'?>

      <?rfc include='reference.RFC.8969'?>

      <?rfc include='reference.I-D.ietf-teas-ietf-network-slices'?>

      <?rfc include='reference.I-D.ietf-teas-enhanced-vpn'?>

      <?rfc include='reference.I-D.ietf-bess-bgp-sdwan-usage'?>

      <?rfc include='reference.RFC.4364'?>

      <?rfc include='reference.RFC.4761'?>

      <?rfc include='reference.RFC.4762'?>

      <?rfc include='reference.RFC.8214'?>

      <?rfc include='reference.RFC.7623'?>

      <?rfc include='reference.RFC.7432'?>

      <?rfc include='reference.RFC.8365'?>

      <?rfc include='reference.RFC.8453'?>

      <?rfc include='reference.RFC.7224'?>

      <?rfc include='reference.RFC.4026'?>

      <?rfc include='reference.RFC.9135'?>

      <?rfc include='reference.RFC.6004'?>

      <?rfc include='reference.RFC.6215'?>

      <reference anchor="IEEE802.1AX">
        <front>
          <title>Link Aggregation</title>

          <author>
            <organization></organization>
          </author>

          <date month="" year="2020" />
        </front>

        <seriesInfo name="IEEE" value="Std 802.1AX-2020" />
      </reference>

      <reference anchor="MEF6"
                 target="https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.pdf">
        <front>
          <title>Technical Specification MEF 6, Ethernet Services Definitions
          - Phase I</title>

          <author fullname="">
            <organization>The Metro Ethernet Forum</organization>
          </author>

          <date month="June" year="2004" />
        </front>
      </reference>

      <reference anchor="MEF17"
                 target="https://www.mef.net/wp-content/uploads/2015/04/MEF-17.pdf">
        <front>
          <title>Technical Specification MEF 17, Service OAM Requirements
          &amp; Framework - Phase 1</title>

          <author fullname="">
            <organization>The Metro Ethernet Forum</organization>
          </author>

          <date month="April" year="2007" />
        </front>
      </reference>
    </references>

    <section anchor="app1" title="A Simplified SAP Network Example">
      <t>An example of a SAP topology that is reported by a network controller
      is depicted in <xref target="ex1"></xref>. This example echoes the
      topology shown in <xref target="fi3a"></xref>. Only a minimum set of
      information is provided for each SAP.</t>

      <t><figure anchor="ex1" title="A Simplified SAP Network Example">
          <artwork><![CDATA[{
  "ietf-network:networks": {
    "network": [
      {
        "network-types": {
          "ietf-sap-ntw:sap-network": {
            "service-type": [
              "ietf-vpn-common:l3vpn",
              "ietf-vpn-common:vpls"
            ]
          }
        },
        "network-id": "foo:an-id",
        "node": [
          {
            "node-id": "foo:pe1",
            "ietf-sap-ntw:service": [
              {
                "service-type": "ietf-vpn-common:l3vpn",
                "sap": [
                  {
                    "sap-id": "sap#11",
                    "peer-sap-id": "ce-1",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#12"
                  },
                  {
                    "sap-id": "sap#13"
                  },
                  {
                    "sap-id": "sap#14"
                  }
                ]
              }
            ]
          },
          {
            "node-id": "foo:pe2",
            "ietf-sap-ntw:service": [
              {
                "service-type": "ietf-vpn-common:l3vpn",
                "sap": [
                  {
                    "sap-id": "sap#21"
                  },
                  {
                    "sap-id": "sap#22",
                    "peer-sap-id": "ce-2",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  }
                ]
              }
            ]
          },
          {
            "node-id": "foo:pe3",
            "ietf-sap-ntw:service": [
              {
                "service-type": "ietf-vpn-common:l3vpn",
                "sap": [
                  {
                    "sap-id": "sap#31"
                  },
                  {
                    "sap-id": "sap#32"
                  },
                  {
                    "sap-id": "sap#33",
                    "peer-sap-id": "ce-3",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  }
                ]
              }
            ]
          },
          {
            "node-id": "foo:pe4",
            "ietf-sap-ntw:service": [
              {
                "service-type": "ietf-vpn-common:l3vpn",
                "sap": [
                  {
                    "sap-id": "sap#41",
                    "peer-sap-id": "ce-3",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#42",
                    "peer-sap-id": "ce-4",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#43"
                  },
                  {
                    "sap-id": "sap#44",
                    "peer-sap-id": "ce-5",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }
}]]></artwork>
        </figure></t>

      <t></t>
    </section>

    <section anchor="sample"
             title="A Simple Example of SAP Network Model: Node Filter">
      <t>In the example shown in <xref target="app-ex"></xref>, PE1 (with a
      "node-id" set to "foo:pe1") has two physical interfaces "GE0/6/1" and
      "GE0/6/4". Two sub-interfaces "GE0/6/4.1" and "GE0/6/4.2" are associated
      with the physical interface "GE0/6/4". Let us consider that four SAPs
      are exposed to the service orchestrator and mapped to these physical
      interfaces and sub-interfaces.</t>

      <t><figure align="center" anchor="app-ex"
          title="An Example of a PE and its Physical/Logical Interfaces">
          <artwork align="center"><![CDATA[   .-------------------------.
   |                 GE0/6/4 |
   | PE1                .----+----.
   |                    |sap#2    |GE0/6/4.1
   |                    |      .--+--.
   |                    |      |sap#3|
   |                    |      '--+--'
   |                    |         |GE0/6/4.2
   |                    |      .--+--.
   |                    |      |sap#4|
   |                    |      '--+--'
   |                    |         |
   |                    +----+----+
   |                         |
   |                  GE0/6/1|
   |                    .----+----.
   |                    |sap#1    |
   |                    '----+----'
   |                         |
   '-------------------------'
]]></artwork>
        </figure></t>

      <t>Let us assume that no service is enabled yet for the SAP associated
      with the physical interface "GE0/6/1". Also, let us assume that, for the
      SAPs that are associated with the physical interface "GE0/6/4", VPLS and
      L3VPN services are activated on the two sub-interfaces "GE0/6/4.1" and
      "GE0/6/4.2", respectively.</t>

      <t>A service orchestrator can query what services are provided on which
      SAPs of PE1 from the network controller by sending, e.g., a GET RESTCONF
      request. <xref target="app-ex-res-body"></xref> shows the body of the
      RESTCONF response that is received from the network controller.</t>

      <t><figure anchor="app-ex-res-body"
          title="An Example of a Response Body to a Request with a Node Filter">
          <artwork><![CDATA[{
  "ietf-sap-ntw:service": [
    {
      "service-type": "ietf-vpn-common:l3vpn",
      "sap": [
        {
          "sap-id": "sap#1",
          "description": "Ready to host SAPs",
          "attachment-interface": "GE0/6/1",
          "interface-type": "ietf-sap-ntw:phy",
          "role": "ietf-sap-ntw:uni",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          }
        },
        {
          "sap-id": "sap#2",
          "description": "Ready to host SAPs",
          "attachment-interface": "GE0/6/4",
          "interface-type": "ietf-sap-ntw:phy",
          "role": "ietf-sap-ntw:uni",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          }
        },
        {
          "sap-id": "sap#3",
          "description": "A first SAP description",
          "parent-termination-point": "GE0/6/4",
          "attachment-interface": "GE0/6/4.1",
          "interface-type": "ietf-sap-ntw:logical",
          "encapsulation-type": "ietf-vpn-common:vlan-type",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          },
          "service-status": {
            "status": "ietf-vpn-common:op-up"
          }
        }
      ]
    },
    {
      "service-type": "ietf-vpn-common:vpls",
      "sap": [
          "sap-id": "sap#1",
          "description": "Ready to host SAPs",
          "attachment-interface": "GE0/6/1",
          "interface-type": "ietf-sap-ntw:phy",
          "role": "ietf-sap-ntw:uni",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          }
        },
        {
          "sap-id": "sap#2",
          "description": "Ready to host SAPs",
          "attachment-interface": "GE0/6/4",
          "interface-type": "ietf-sap-ntw:phy",
          "role": "ietf-sap-ntw:uni",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          }
        },
        {
          "sap-id": "sap#4",
          "description": "Another description",
          "parent-termination-point": "GE0/6/4",
          "attachment-interface": "GE0/6/4.2",
          "interface-type": "ietf-sap-ntw:logical",
          "encapsulation-type": "ietf-vpn-common:vlan-type",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          },
          "service-status": {
            "status": "ietf-vpn-common:op-up"
          }
        }
      ]
    }
  ]
}
]]></artwork>
        </figure></t>

      <t><xref target="app-ex-res-body-filter"></xref> shows the message body
      of a response that is received from the network controller if the
      request includes a filter on the service type for a particular node:</t>

      <t><figure anchor="app-ex-res-body-filter"
          title="An Example of a Response Body to a Request with a Service Filter">
          <artwork><![CDATA[{
  "ietf-sap-ntw:service": [
    {
      "service-type": "ietf-vpn-common:l3vpn",
      "sap": [
        {
          "sap-id": "sap#1",
          "description": "Ready to host SAPs",
          "attachment-interface": "GE0/6/1",
          "interface-type": "ietf-sap-ntw:phy",
          "role": "ietf-sap-ntw:uni",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          }
        },
        {
          "sap-id": "sap#2",
          "description": "Ready to host SAPs",
          "attachment-interface": "GE0/6/4",
          "interface-type": "ietf-sap-ntw:phy",
          "role": "ietf-sap-ntw:uni",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          }
        },
        {
          "sap-id": "sap#3",
          "description": "A first SAP description",
          "parent-termination-point": "GE0/6/4",
          "attachment-interface": "GE0/6/4.1",
          "interface-type": "ietf-sap-ntw:logical",
          "encapsulation-type": "ietf-vpn-common:vlan-type",
          "sap-status": {
            "status": "ietf-vpn-common:op-up"
          },
          "service-status": {
            "status": "ietf-vpn-common:op-up"
          }
        }
      ]
    }
  ]
}
]]></artwork>
        </figure></t>

      <t></t>
    </section>

    <section anchor="nniapp"
             title="An Example of NNI SAP: Inter-AS VPN Option A">
      <t>Section 10 of <xref target="RFC4364"></xref> discuses several options
      to extend a VPN service beyond the scope of a single Autonomous System
      (AS). For illustration purposes, this section focuses on the so called
      "Option A" but similar examples can be considered for other options.</t>

      <t>In this option, an ASBR of an AS is directly connected to an ASBR of
      a neighboring AS. These two ASBRs are connected by multiple physical or
      logical interfaces. Also, at least one sub-interface is maintained by
      these ASBRs for each of the VPNs that require their routes to be passed
      from one AS to the other AS. Each ASBR behaves as a PE and treats the
      other as if it were a CE.</t>

      <t><xref target="optiona"></xref> shows a simplified (excerpt) topology
      of two ASes A and B with a focus on the interconnection links between
      these two ASes.</t>

      <t><figure align="center" anchor="optiona"
          title="An Example of Inter-AS VPN (Option A)">
          <artwork align="center"><![CDATA[.--------------------.                      .--------------------.
|                    |                      |                    |
|              A  .--+--.                .--+--.  A              |
|              S  |     +================+     |  S              |
|              B  | (VRF1)----(VPN1)----(VRF1) |  B              |
|              R  |     |                |     |  R              |
|                 | (VRF2)----(VPN2)----(VRF2) |                 |
|              a  |     +================+     |  b              |
|              1  '--+--'                '--+--'  1              |
|     AS A           |                      |         AS B       |
|              A  .--+--.                .--+--.  A              |
|              S  |     +================+     |  S              |
|              B  | (VRF1)----(VPN1)----(VRF1) |  B              |
|              R  |     |                |     |  R              |
|                 | (VRF2)----(VPN2)----(VRF2) |                 |
|              a  |     +================+     |  b              |
|              2  '--+--'                '--+--'  2              |
|                    |                      |                    |
'--------------------'                      '--------------------']]></artwork>
        </figure></t>

      <t><xref target="nniex1"></xref> shows an example of a message body that
      is received from the network controller of AS A (with a focus on the
      NNIs shown in <xref target="optiona"></xref>).</t>

      <t><figure anchor="nniex1" title="An Example of SAP Usage for NNI">
          <artwork><![CDATA[{
  "ietf-network:networks": {
    "network": [
      {
        "network-types": {
          "ietf-sap-ntw:sap-network": {
            "service-type": [
              "ietf-vpn-common:l3vpn"
            ]
          }
        },
        "network-id": "foo:an-id",
        "node": [
          {
            "node-id": "foo:asbr-a1",
            "ietf-sap-ntw:service": [
              {
                "service-type": "ietf-vpn-common:l3vpn",
                "sap": [
                  {
                    "sap-id": "sap#11",
                    "description": "parent inter-as link#1",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b1",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#12",
                    "description": "parent inter-as link#2",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b1",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#13",
                    "description": "vpn1",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b1",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#14",
                    "description": "vpn2",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b1",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  }
                ]
              }
            ]
          },
          {
            "node-id": "foo:asbr-a2",
            "ietf-sap-ntw:service": [
              {
                "service-type": "ietf-vpn-common:l3vpn",
                "sap": [
                  {
                    "sap-id": "sap#11",
                    "description": "parent inter-as link#1",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b2",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#12",
                    "description": "parent inter-as link#2",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b2",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#21",
                    "description": "vpn1",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b2",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  },
                  {
                    "sap-id": "sap#22",
                    "description": "vpn2",
                    "role": "ietf-sap-ntw:nni",
                    "peer-sap-id": "asbr-b2",
                    "service-status": {
                      "status": "ietf-vpn-common:op-up"
                    }
                  }
                ]
              }
            ]
          }
        ]
      }
    ]
  }
}]]></artwork>
        </figure></t>

      <t></t>
    </section>

    <section anchor="servicesap"
             title="An Example of Using the SAP Network Model in Service Creation">
      <t>This section describes an example to illustrate the use of the SAP
      model for service creation purposes.</t>

      <t>An example of a SAP topology is presented in <xref
      target="ex1"></xref>. This example includes four PEs with their SAPs, as
      well as the customer information.</t>

      <t>Let us assume that an operator wants to create an L3VPN service
      between two PEs (PE3 and PE4) that are servicing two CEs (CE6 and CE7).
      To that aim, the operator would query the SAP topology and would obtain
      a response similar to what is depicted in <xref target="ex1"></xref>.
      That response indicates that the SAPs having "sap#31" and "sap#43" as
      attachment identifiers do not have any installed services. Once the
      "free" SAPs are identified, the 'interface-type' and
      'encapsulation-type' are checked to see if the requested L3VPN service
      is compatible with the SAP characteristics. If they are compatible, as
      proposed in <xref target="tree"></xref>, the 'attachment-id' value can
      be used as the VPN network access identifier in an L3NM create
      query.</t>

      <t>Let us now assume that, instead of the L3VPN service, the operator
      wants to set up an L2VPN service. If the 'interface-type' is a physical
      port, a new logical SAP can be created using the SAP model to cope with
      the service needs (e.g., the 'encapsulation-type' attribute can be set
      to 'ietf-vpn-common:vlan-type'). Once the logical SAP is created, the
      'attachment-id' of the new SAP is used to create an L2NM instance
      (Section 7.6 of <xref target="I-D.ietf-opsawg-l2nm"></xref>).</t>
    </section>
  </back>
</rfc>