rfc9408xml2.original.xml   rfc9408.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> <!DOCTYPE rfc [
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbsp "&#160;">
<!-- One method to get references from the online citation libraries. <!ENTITY zwsp "&#8203;">
There has to be one entity for each item to be referenced. <!ENTITY nbhy "&#8209;">
An alternate method (rfc include) is described in the references. --> <!ENTITY wj "&#8288;">
<!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 --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<!-- For a complete list and description of processing instructions (PIs), std" consensus="true" docName="draft-ietf-opsawg-sap-15" number="9408" ipr="trus
please see http://xml.resource.org/authoring/README.html. --> t200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" sy
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds mRefs="true" sortRefs="true" version="3">
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) --> <!-- xml2rfc v2v3 conversion 3.16.0 -->
<?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-15" ipr="trust200902">
<front> <front>
<title abbrev="A YANG Model for SAPs">A YANG Network Model for Service <title abbrev="A YANG Network Data Model for SAPs">A YANG Network Data Model for Service
Attachment Points (SAPs)</title> Attachment Points (SAPs)</title>
<seriesInfo name="RFC" value="9408"/>
<author fullname="Mohamed Boucadair" initials="M." role="editor" <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
surname="Boucadair"> ucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<country>France</country> <country>France</country>
</postal> </postal>
<phone></phone>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Oscar Gonzalez de Dios" initials="O" surname="Gonzalez de
<author fullname="Oscar Gonzalez de Dios" initials="O" Dios">
surname="Gonzalez de Dios">
<organization>Telefonica</organization> <organization>Telefonica</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Madrid</city> <city>Madrid</city>
<region/>
<region></region> <code/>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<email>oscar.gonzalezdedios@telefonica.com</email> <email>oscar.gonzalezdedios@telefonica.com</email>
</address> </address>
</author> </author>
<author fullname="Samier Barguil" initials="S." surname="Barguil"> <author fullname="Samier Barguil" initials="S." surname="Barguil">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Madrid</city> <city>Madrid</city>
<region/>
<region></region> <code/>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<facsimile></facsimile>
<email>samier.barguil_giraldo@nokia.com</email> <email>samier.barguil_giraldo@nokia.com</email>
<uri></uri>
</address> </address>
</author> </author>
<author fullname="Qin Wu" initials="Q." surname="Wu"> <author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization> <organization>Huawei</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue, Yuhua District</street> <extaddr>Yuhua District</extaddr>
<street>101 Software Avenue</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>bill.wu@huawei.com</email> <email>bill.wu@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Victor Lopez" initials="V." surname="Lopez"> <author fullname="Victor Lopez" initials="V." surname="Lopez">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone>
<facsimile></facsimile>
<email>victor.lopez@nokia.com</email> <email>victor.lopez@nokia.com</email>
<uri></uri>
</address> </address>
</author> </author>
<date year="2023" month="June" />
<date year="" />
<area>ops</area> <area>ops</area>
<workgroup>opsawg</workgroup>
<workgroup>OPSAWG</workgroup>
<keyword>Service Infrastructure</keyword> <keyword>Service Infrastructure</keyword>
<keyword>User Network Interface</keyword> <keyword>User Network Interface</keyword>
<keyword>UNI</keyword> <keyword>UNI</keyword>
<keyword>NNI</keyword> <keyword>NNI</keyword>
<keyword>Network-to-Network Interface</keyword> <keyword>Network-to-Network Interface</keyword>
<keyword>Inter-AS VPN</keyword> <keyword>Inter-AS VPN</keyword>
<keyword>CE</keyword> <keyword>CE</keyword>
<keyword>PE</keyword> <keyword>PE</keyword>
<keyword>Attachment Circuit</keyword> <keyword>Attachment Circuit</keyword>
<keyword>Service Delivery Point</keyword> <keyword>Service Delivery Point</keyword>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Service Delivery</keyword> <keyword>Service Delivery</keyword>
<abstract> <abstract>
<t>This document defines a YANG data model for representing an abstract <t>This document defines a YANG data model for representing an abstract
view of the provider network topology that contains the points from view of the provider network topology that contains the points from
which its services can be attached (e.g., basic connectivity, VPN, which its services can be attached (e.g., basic connectivity, VPN,
network slices). Also, the model can be used to retrieve the points network slices). Also, the model can be used to retrieve the points
where the services are actually being delivered to customers (including where the services are actually being delivered to customers (including
peer networks).</t> peer networks).</t>
<t>This document augments the 'ietf-network' data model defined in RFC 834
<t>This document augments the 'ietf-network' data model by adding the 5
concept of Service Attachment Points (SAPs). The SAPs are the network by adding the concept of Service Attachment Points (SAPs). The SAPs are th
reference points to which network services, such as Layer 3 Virtual e
network reference points to which network services, such as Layer 3 Virtua
l
Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can
be attached. One or multiple services can be bound to the same SAP. Both be attached. One or multiple services can be bound to the same SAP. Both
User-Network Interface (UNI) and Network-to-Network Interface (NNI) are User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are
supported in the SAP data model.</t> supported in the SAP data model.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>Service providers offer a variety of network services to their <t>Service providers offer a variety of network services to their
customers. Such services include, but are not limited to, Virtual customers. Such services include, but are not limited to, Virtual
Private Networks (VPNs), Software-Defined Wide Area Network (SDWAN) Private Networks (VPNs), Software-Defined Wide-Area Network (SD-WAN) overl
<xref target="I-D.ietf-bess-bgp-sdwan-usage"></xref>, and network slices ay networks
<xref target="I-D.ietf-teas-ietf-network-slices"></xref>. In order to <xref target="BGP-SDWAN-USAGE" format="default"/>, and network slices
<xref target="IETF-NETWORK-SLICES" format="default"/>. In order to
rationalize the overall service operations and allow for more automated rationalize the overall service operations and allow for more automated
service provisioning procedures, service providers need to maintain a service provisioning procedures, service providers need to maintain a
view on where services can be delivered to customers. Such a view can be view on where services can be delivered to customers. For example, such a
used, e.g., to feed an intelligence that is responsible for service view can be
used to feed an intelligence entity that is responsible for service
order handling, service feasibility checks, tracking per-service order handling, service feasibility checks, tracking per-service
coverage, etc. (e.g., Section 3.2 of <xref target="RFC8969"></xref>). To coverage, etc. (e.g., <xref target="RFC8969" sectionFormat="of" section="3 .2"/>). To
that aim, this document introduces the concept of Service Attachment that aim, this document introduces the concept of Service Attachment
Points (SAPs).</t> Points (SAPs).</t>
<t>The SAPs represent the network reference points where network <t>The SAPs represent the network reference points where network
services can be delivered to customers. For example, this concept is services can be delivered to customers. For example, this concept is
used to decide where to attach and, thus, deliver the service in the 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 3 VPN Service Model (L3SM) <xref target="RFC8299" format="default"/>
Layer 2 VPN Service Model (L2SM) <xref target="RFC8466"></xref>. It can and the
Layer 2 VPN Service Model (L2SM) <xref target="RFC8466" format="default"/>
. It can
also be used to retrieve where such services are delivered to customers also be used to retrieve where such services are delivered to customers
through the network configuration described in the Layer 3 VPN Network through the network configuration described in the Layer 3 VPN Network
Model (L3NM) <xref target="RFC9182"></xref> and the Layer 2 VPN Network Model (L3NM) <xref target="RFC9182" format="default"/> and the Layer 2 VPN
Model (L2NM) <xref target="RFC9291"></xref>.</t> Network
Model (L2NM) <xref target="RFC9291" format="default"/>.</t>
<t>This document defines a YANG network model (<xref <t>This document defines a YANG network model (<xref target="mod" format="
target="mod"></xref>) for representing, managing, and controlling the default"/>) for representing, managing, and controlling the
SAPs. The data model augments the 'ietf-network' module <xref SAPs. The data model augments the 'ietf-network' module <xref target="RFC8
target="RFC8345"></xref> by adding the concept of SAPs. <xref 345" format="default"/> by adding the concept of SAPs. <xref target="usage" form
target="usage"></xref> provides a sample usage of the model. This at="default"/> provides a sample usage of the model. This
document explains the scope and purpose of a SAP network model and its document explains the scope and purpose of a SAP network model and its
relation with other models (<xref target="rel"></xref>).</t> relationship to other models (<xref target="rel" format="default"/>).</t>
<t>A network may support multiple services, potentially of different <t>A network may support multiple services, potentially of different
types. Whether a SAP topology is dedicated to services of a specific types. Whether a SAP topology is dedicated to services of a specific
service type, an individual service, or shared among many services of service type or an individual service, or is shared among many services of
different types is deployment specific. This document supports all of different types, is deployment specific. This document supports all of
these deployment schemes.</t> these deployment schemes.</t>
<t>This document does not make any assumptions about the services
<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 provided by a network to its users. VPN services (e.g., Layer 3 Virtual
Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN)) Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN))
<xref target="RFC4026"></xref> are used for illustration purposes <xref target="RFC4026" format="default"/> are used for illustration purpos
(Appendices <xref format="counter" target="app1"></xref> and <xref es
format="counter" target="sample"></xref>).</t> (Appendices&nbsp;<xref format="counter" target="app1"/> and <xref format="
counter" target="sample"/>).</t>
<t>Given that User-Network Interface (UNI) and Network-to-Network <t>Given that User-to-Network Interface (UNI) and Network-to-Network
Interface (NNI) are reference points that are widely used by operators Interface (NNI) are reference points that are widely used by operators
to indicate the demarcation points when delivering services, both UNI to indicate the demarcation points when delivering services, both UNI
and NNI SAPs are supported in the document. The reader may refer, e.g., and NNI SAPs are supported in this document. The reader may refer
to <xref target="MEF6"></xref>, <xref target="MEF17"></xref>, <xref to <xref target="MEF6" format="default"/>, <xref target="MEF17" format="de
target="RFC6004"></xref>, or <xref target="RFC6215"></xref> for a fault"/>, <xref target="RFC6004" format="default"/>, or <xref target="RFC6215" f
discussion on the use of UNI and NNI reference points. An example of NNI ormat="default"/> for examples of
usage in a VPN context is provided in <xref target="nniapp"></xref>.</t> discussions regarding the use of UNI and NNI reference points. An example
of NNI
<t>The YANG data model in <xref target="mod"></xref> conforms to the usage in a VPN context is provided in <xref target="nniapp" format="defaul
Network Management Datastore Architecture (NMDA) <xref t"/>.</t>
target="RFC8342"></xref>.</t> <t>The YANG data model in <xref target="mod" format="default"/> conforms t
o the
Network Management Datastore Architecture (NMDA) <xref target="RFC8342" fo
rmat="default"/>.</t>
</section> </section>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>This document assumes that the reader is familiar with the contents <t>This document assumes that the reader is familiar with the contents
of <xref target="RFC6241"></xref>, <xref target="RFC7950"></xref>, <xref of <xref target="RFC6241" format="default"/>, <xref target="RFC7950" forma
target="RFC8345"></xref>, and <xref target="RFC8309"></xref>. The t="default"/>, <xref target="RFC8345" format="default"/>, and <xref target="RFC8
document uses terms from those documents.</t> 309" format="default"/>, as it uses terms from those RFCs.</t>
<t>The meanings of the symbols in tree diagrams are defined in <xref targe
<t>The meanings of the symbols in tree diagrams are defined in <xref t="RFC8340" format="default"/>.</t>
target="RFC8340"></xref>.</t> <t>This document uses the term "network model" as defined in
<xref target="RFC8969" sectionFormat="of" section="2.1"/>.</t>
<t>This document uses the term "network model" defined in Section 2.1 of <t>This document uses the following terms:</t>
<xref target="RFC8969"></xref>.</t> <dl newline="false" spacing="normal">
<dt>Service provider: </dt>
<t>This document uses the following terms:<list style="hanging"> <dd>The organization responsible for
<t hangText="Service provider: ">The organization responsible for
operating the network that offers a service (e.g., a VPN) to operating the network that offers a service (e.g., a VPN) to
customers.</t> customers.</dd>
<dt>Attachment Circuit (AC):</dt>
<t hangText="Attachment Circuit (AC):">A channel that connects a <dd>A channel that connects a
Customer Edge (CE) to a Provider Edge (PE). The AC may be a physical Customer Edge (CE) to a Provider Edge (PE).</dd>
or logical link (Section 6.1 of <xref target="RFC4026"></xref>).</t> <dt>Customer Edge (CE): </dt>
<dd>Equipment that is dedicated to a
<t hangText="Customer Edge (CE): ">Equipment that is dedicated to a
particular customer and is directly connected to one or more PEs via 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 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 dedicated to a single service (e.g., an L3VPN), although it may suppor
multiple VPNs if each one has separate attachment circuits. A CE can t
be a router, a bridge, a switch, etc.</t> multiple VPNs if each one has separate ACs. A CE can
be a router, a bridge, a switch, etc.</dd>
<t hangText="Provider Edge (PE): ">Equipment owned and managed by <dt>Provider Edge (PE): </dt>
<dd>Equipment owned and managed by
the service provider that can support multiple services (e.g., VPNs) the service provider that can support multiple services (e.g., VPNs)
for different customers. A PE is directly connected to one or more for different customers. A PE is directly connected to one or more
CEs via ACs.</t> CEs via ACs.</dd>
<dt>Service Attachment Points (SAPs):</dt>
<t hangText="Service Attachment Points (SAPs):">An abstraction of <dd>An abstraction of
the network reference points (e.g., PE side of an AC, CE side of an the network reference points (e.g., the PE side of an AC, or the CE si
de of an
AC for a provider-managed CE) where network services can be AC for a provider-managed CE) where network services can be
delivered and/or are delivered to customers. A SAP can be bound to delivered and/or are delivered to customers. A SAP can be bound to
one or multiple ACs.</t> one or multiple ACs.</dd>
</list></t> </dl>
</section> </section>
<section anchor="usage" numbered="true" toc="default">
<section anchor="usage" title="Sample SAP Network Model Usage"> <name>Sample SAP Network Model Usage</name>
<t>Management operations of a service provider network can be automated <t>A service provider network's management operations can be automated
using a variety of means such as interfaces based on YANG modules <xref using a variety of means such as interfaces based on YANG modules <xref ta
target="RFC8969"></xref><xref target="RFC6241"></xref><xref rget="RFC8969" format="default"/> <xref target="RFC6241" format="default"/> <xre
target="RFC8040"></xref>. From that standpoint, and considering the f target="RFC8040" format="default"/>. From that standpoint, and considering the
architecture depicted in <xref target="fi1"></xref>, a goal of this architecture depicted in <xref target="fi1" format="default"/>, a goal of
document is to provide a mechanism to show via a YANG-based interface an 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 abstracted network view from the network controller to the service
orchestration layer with a focus on where a service can be delivered to orchestration layer with a focus on where a service can be delivered to
customers. The model is also used to retrieve the network reference customers. The model is also used to retrieve the network reference
points where a service is being delivered to customers. For services points where a service is being delivered to customers. For services
that require resources from peer networks, the module can also be used that require resources from peer networks, the model can also be used
to expose NNIs.</t> to expose NNIs.</t>
<figure anchor="fi1">
<figure align="center" anchor="fi1" title="SAP Network Model Usage"> <name>SAP Network Model Usage</name>
<artwork align="left"><![CDATA[ +------------ <artwork align="left" name="" type="" alt=""><![CDATA[
-----+ +-----------------+
| Customer | | Customer |
+--------+--------+ +--------+--------+
Customer Service Models | Customer Service Models |
(e.g., L3SM, L2SM) | (e.g., L3SM, L2SM) |
+--------+--------+ +--------+--------+
| Service | | Service |
| Orchestration | | Orchestration |
+------+---+------+ +------+---+------+
Network Models | | SAP Network Model Network Models | | SAP Network Model
(e.g., L3NM, L2NM) | | (e.g., L3NM, L2NM) | |
+------+---+------+ +------+---+------+
| Network | | Network |
| Controller | | Controller |
+--------+--------+ +--------+--------+
| |
+---------------------+---------------------+ +---------------------+---------------------+
| Network | | Network |
+-------------------------------------------+ +-------------------------------------------+
]]></artwork> ]]></artwork></figure>
</figure> <t>The reader may refer to <xref target="RFC4026" sectionFormat="of" secti
on="5"/> for an overview of the building blocks that are usually invoked when
<t>The reader may refer to Section 5 of <xref target="RFC4026"></xref>
for an overview of the building blocks that are usually invoked when
characterizing a service provider network.</t> characterizing a service provider network.</t>
<t>The service orchestration layer does not need to know about all the <t>The service orchestration layer does not need to know about all the
internals of the underlying network (e.g., P nodes). <xref internals of the underlying network (e.g., P nodes (<xref target="RFC4026"
target="fi2a"></xref> shows the abstract network view as seen by a sectionFormat="of" section="5.3.1"/>)). <xref target="fi2a" format="default"/>
shows the abstract network view as seen by a
service orchestrator. However, this view is not enough to provide to the service orchestrator. However, this view is not enough to provide to the
service orchestration layer the information to create services in 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 network. The service topology needs to be able to expose the set of
nodes and the attachment points associated with the nodes from which nodes and the attachment points associated with the nodes from which
network services can be grafted (delivered).</t> network services can be grafted (delivered).</t>
<figure anchor="fi2a">
<t><figure align="center" anchor="fi2a" <name>Abstract Network Topology</name>
title="Abstract Network Topology"> <artwork align="center" name="" type="" alt=""><![CDATA[.---------.
<artwork align="center"><![CDATA[.---------. .---------. .---------.
| PE1 | | PE2 | | PE1 | | PE2 |
'---------' '---------' '---------' '---------'
\ / \ /
\------/ \------/
( ) ( )
( ) ( )
( ) ( )
/------\ /------\
/ \ / \
.---------. .---------. .---------. .---------.
| PE3 | | PE4 | | PE3 | | PE4 |
'---------' '---------']]></artwork> '---------' '---------'
</figure></t> ]]></artwork></figure>
<t>Typically, and focusing on the UNIs, the service orchestration layer <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 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). or logical) to which CEs can be connected (or are actually connected).
Such interfaces are also referred to as UNI-N (User-to-Network Such interfaces are also referred to as UNI-N (User-to-Network
Interface, Network side) <xref target="RFC6215"></xref>. The service Interface, Network side) <xref target="RFC6215" format="default"/>. The se rvice
orchestration layer can use these interfaces to set up the requested orchestration layer can use these interfaces to set up the requested
services or to commit the delivery of a service. <xref services or to commit the delivery of a service. <xref target="fi3" format
target="fi3"></xref> depicts a sample SAP network topology that is ="default"/> depicts a sample SAP network topology that is
maintained by the network controller and exposed to the service maintained by the network controller and exposed to the service
orchestration.</t> orchestration.</t>
<figure anchor="fi3">
<figure align="center" anchor="fi3" title="A SAP Network Topology"> <name>A SAP Network Topology</name>
<artwork align="center"><![CDATA[ .-+-. .-+-. .-+-. <artwork align="center" name="" type="" alt=""><![CDATA[ .-+-.
.-+-. .-+-. .-+-. .-+-. .-+-. .-+-.
.-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-. .-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-.
| '---' '---' '---' | | '---' '---' | | '---' '---' '---' | | '---' '---' |
.---. | | | .---. | | |
|sap| PE1 | | PE2 | |sap| PE1 | | PE2 |
'---' | | | '---' | | |
| | | | | | | |
'-------------------' '-------------------' '-------------------' '-------------------'
.-------------------. .-------------------. .-------------------. .-------------------.
| | | | | | | |
| | | .---. | | | .---.
| PE3 | | PE4 |sap| | PE3 | | PE4 |sap|
| | | '---' | | | '---'
| .---. .---. .---. | | .---. .---. .---. | | .---. .---. .---. | | .---. .---. .---. |
'-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-'
'-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' '-+-'
]]></artwork> ]]></artwork></figure>
</figure>
<t>A single SAP network topology can be used for one or multiple service <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, types (e.g., L3VPN, Ethernet VPN (EVPN)). The network controller can
then, expose the service types and associated interfaces via the then expose the service types and associated interfaces via the
SAPs.</t> SAPs.</t>
<t>As shown in <xref target="fi3a" format="default"/>, the service orchest
<t>As shown in <xref target="fi3a"></xref>, the service orchestration ration
layer will have also access to a set of customer service model (e.g., layer will also have access to a set of customer service models (e.g.,
the L3SM or the L2SM) in the customer-facing interface and a set of 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 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 resource-facing interface. In this use case, it is assumed that the
network controller is unaware of what happens beyond the PEs towards 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 CEs; it is only responsible for the management and control of the SAPs
and the network between PEs. In order to correlate between delivery and the network between PEs. In order to correlate between delivery
points expressed in service requests and SAPs, the SAP model may include points expressed in service requests and SAPs, the SAP model may include
a peer customer point identifier. That identifier can be a CE a peer customer point identifier. That identifier can be a CE
identifier, a site identifier, etc.</t> identifier, a site identifier, etc.</t>
<figure anchor="fi3a">
<name>Network Topology with CEs and ACs</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
.---.
|CE2|
'-+-'
|
.-+-. .-+-. .-+-. .-+-. .-+-.
.-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-.
| '---' '---' '---' | | '---' '---' |
.---. .---. | | |
|CE1+--+sap| PE1 | | PE2 |
'---' '---' | | |
| | | |
'-------------------' '-------------------'
<t><figure align="center" anchor="fi3a" .-------------------. .-------------------.
title="Network Topology with CEs and ACs"> | | | |
<artwork align="center"><![CDATA[ | | | .---. .---.
.---. | PE3 | | PE4 |sap+--+CE5|
|CE2| | | | '---' '---'
'-+-' | .---. .---. .---. | | .---. .---. .---. |
| '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-'
.-+-. .-+-. .-+-. .-+-. .-+-. '-+-' '-+-' '-+-' '-+-' '-+-' '-+-'
.-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-. | | |
| '---' '---' '---' | | '---' '---' | .-+-. | .-+-.
.---. .---. | | | |CE3+---------------' |CE4|
|CE1+--+sap| PE1 | | PE2 | '---' '---'
'---' '---' | | | ]]></artwork></figure>
| | | | <t>Refer to <xref target="app1" format="default"/> for an example echoing
'-------------------' '-------------------' the
topology depicted in <xref target="fi3a" format="default"/>.</t>
.-------------------. .-------------------.
| | | |
| | | .---. .---.
| 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>
<section anchor="rel" numbered="true" toc="default">
<section anchor="rel" title="Relationship to Other YANG Data Models"> <name>Relationship to Other YANG Data Models</name>
<t>The SAP network model can be seen as inventory data associated with <t>The SAP network model can be seen as inventory data associated with
SAPs. The model maintains an inventory of customer-facing nodes SAPs. The model maintains an inventory of customer-facing nodes
contained in a network relying upon <xref target="RFC8345"></xref>.</t> contained in a network relying upon <xref target="RFC8345" format="default
"/>.</t>
<figure align="center" anchor="fig5" <t><xref target="fig5" format="default"/> depicts the relationship of the
title="Relation of SAP Network Model to Other Models"> SAP
<artwork align="center"><![CDATA[ +---------------------- network model to other models. The SAP network model augments the
---+ network model defined in <xref target="RFC8345" format="default"/> and imp
orts the network
topology model defined in <xref target="RFC8345" format="default"/>, while
other technology-specific topology models (e.g., the
model for Traffic Engineering (TE) topologies <xref target="RFC8795" forma
t="default"/>
or the model for Layer 3 topologies <xref target="RFC8346" format="default
"/>) augment the
network topology model defined in <xref target="RFC8345" format="default"/
>.
</t>
<figure anchor="fig5">
<name>Relationship of SAP Network Model to Other Models</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
+-------------------------+
| | | |
| Abstract Network Model | | Abstract Network Model |
| | | |
+------------+------------+ +------------+------------+
| |
+---------+---------+ +---------+---------+
| | | |
+------V------+ +------V------+ +------V------+ +------V------+
| Abstract | | Inventory | | Abstract | | Inventory |
| Network | | Models | | Network | | Models |
| Topology | | e.g., SAP | | Topology | | (e.g., SAP |
| Model | | Network | | Model | | Network |
| | | Model | | | | Model) |
+-----+-------+ +-------------+ +-----+-------+ +-------------+
| |
+-----------+-----------+ +-----------+-----------+
| | | | | |
+----V----+ +----V----+ +----V----+ +----V----+ +----V----+ +----V----+
|TE Topo | |L3 Topo | |L2 Topo | |TE Topo | |L3 Topo | |L2 Topo |
| Model | | Model | | Model | ... | Model | | Model | | Model | ...
+---------+ +---------+ +---------+]]></artwork> +---------+ +---------+ +---------+
</figure> ]]></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>SAPs can be seen as customer-facing termination points (TPs) with <t>SAPs can be seen as customer-facing termination points (TPs) with
specific service provisions. However, a difference between SAPs and TPs specific service provisions. However, one difference between SAPs and TPs
is that links are terminated by a single TP (Section 4.4.6 of <xref is that links are terminated by a single TP (<xref target="RFC8345" sectio
target="RFC8345"></xref>) while an AC can be terminated by multiple nFormat="of" section="4.4.6"/>) while an AC can be terminated by multiple
SAPs. Also, a SAP is not a tunnel termination point (TTP) (Section 3.6 SAPs. Also, a SAP is neither a tunnel termination point (TTP) (<xref targe
of <xref target="RFC8795"></xref>) nor a link.</t> t="RFC8795" sectionFormat="of" section="3.6"/>) nor a link.</t>
<t>In the context of Software-Defined Networking (SDN) <xref target="RFC71
<t>In the context of Software-Defined Networking (SDN) <xref 49" format="default"/> <xref target="RFC7426" format="default"/>, the SAP YANG
target="RFC7149"></xref><xref target="RFC7426"></xref>, the SAP YANG
data model can be used to exchange information between control elements, data model can be used to exchange information between control elements,
so as to support VPN service provision and resource management discussed so as to support VPN service provision and resource management as discusse
in <xref target="RFC9182"></xref><xref target="RFC9291"></xref>. Through d
in <xref target="RFC9182" format="default"/> and <xref target="RFC9291" fo
rmat="default"/>. Through
this data model, the service orchestration layer can learn the available this data model, the service orchestration layer can learn the available
endpoints (i.e., SAPs) of interconnection resources of the underlying endpoints (i.e., SAPs) of interconnection resources of the underlying
network. The service orchestration layer can determine which network. The service orchestration layer can determine which
interconnection endpoints to add to an L2VPN or L3VPN service. With the 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 help of other data models (e.g., the L3SM <xref target="RFC8299" format="d
L2SM <xref target="RFC8466"></xref>), hierarchical control elements can efault"/> or the
also assess the feasibility of an end-to-end IP connectivity or L2VPN L2SM <xref target="RFC8466" format="default"/>), hierarchical control elem
connectivity and, therefore, derive the sequence of domains and the ents can
also assess the feasibility of end-to-end IP connectivity or L2VPN
connectivity and therefore can derive the sequence of domains and the
points of interconnection to use.</t> points of interconnection to use.</t>
<t>Advanced interface-specific data nodes are not included in the SAP <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 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 filters to set or get such data using device models (e.g., <xref target="R
target="RFC7224"></xref>).</t> FC7224" format="default"/>).</t>
</section> </section>
<section anchor="tree" numbered="true" toc="default">
<section anchor="tree" title="SAP Module Tree Structure"> <name>SAP Module Tree Structure</name>
<t>The SAP network model 'ietf-sap-ntw' builds on the 'ietf-network' <t>The SAP network model 'ietf-sap-ntw' builds on the 'ietf-network'
module <xref target="RFC8345" /> by augmenting the nodes with SAPs.</t> module <xref target="RFC8345" format="default"/> by augmenting the nodes w
ith SAPs.</t>
<t>The structure of the 'ietf-sap-ntw' module is shown in <xref <t>The structure of the 'ietf-sap-ntw' module is shown in <xref target="fi
target="fi4" />.</t> 4" format="default"/>.</t>
<figure anchor="fi4">
<figure align="center" anchor="fi4" <name>SAP YANG Module Tree Structure</name>
title="SAP YANG Module Tree Structure"> <sourcecode name="" type="yangtree"><![CDATA[module: ietf-sap-ntw
<artwork align="center"><![CDATA[module: ietf-sap-ntw
augment /nw:networks/nw:network/nw:network-types: augment /nw:networks/nw:network/nw:network-types:
+--rw sap-network! +--rw sap-network!
+--rw service-type* identityref +--rw service-type* identityref
augment /nw:networks/nw:network/nw:node: augment /nw:networks/nw:network/nw:node:
+--rw service* [service-type] +--rw service* [service-type]
+--rw service-type identityref +--rw service-type identityref
+--rw sap* [sap-id] +--rw sap* [sap-id]
+--rw sap-id string +--rw sap-id string
+--rw description? string +--rw description? string
+--rw parent-termination-point? nt:tp-id +--rw parent-termination-point? nt:tp-id
skipping to change at line 577 skipping to change at line 435
+--ro sap-status +--ro sap-status
| +--ro status? identityref | +--ro status? identityref
| +--ro last-change? yang:date-and-time | +--ro last-change? yang:date-and-time
+--rw service-status +--rw service-status
+--rw admin-status +--rw admin-status
| +--rw status? identityref | +--rw status? identityref
| +--rw last-change? yang:date-and-time | +--rw last-change? yang:date-and-time
+--ro oper-status +--ro oper-status
+--ro status? identityref +--ro status? identityref
+--ro last-change? yang:date-and-time +--ro last-change? yang:date-and-time
]]></sourcecode></figure>
]]></artwork>
</figure>
<t />
<t>A SAP network topology can be used for one or multiple service types <t>A SAP network topology can be used for one or multiple service types
('service-type'). Examples of supported service types are as ('service-type'). Examples of supported service types are as
follows:<list style="symbols"> follows:</t>
<t>L3VPN <xref target="RFC4364" />,</t> <ul spacing="normal">
<li>L3VPN <xref target="RFC4364" format="default"/></li>
<t>Virtual Private LAN Service (VPLS) <xref target="RFC4761" /><xref <li>Virtual Private LAN Service (VPLS) <xref target="RFC4761" format="de
target="RFC4762" />,</t> fault"/> <xref target="RFC4762" format="default"/></li>
<li>
<t><xref target="RFC8214">Virtual Private Wire Service <xref target="RFC8214" format="default">Virtual Private Wire Service
(VPWS)</xref>,</t> (VPWS)</xref></li>
<li>
<t><xref target="RFC7432">BGP MPLS-Based Ethernet VPN</xref>,</t> <xref target="RFC7432" format="default">BGP MPLS-based Ethernet VPN</x
ref></li>
<t><xref target="RFC8214">VPWS in Ethernet VPN</xref>,</t> <li>
<xref target="RFC8214" format="default">VPWS in Ethernet VPN</xref></l
<t><xref target="RFC7623">Provider Backbone Bridging Combined with i>
Ethernet VPN (PBB-EVPN)</xref>,</t> <li>
<xref target="RFC7623" format="default">Provider Backbone Bridging com
<t>VXLAN-based EVPN <xref target="RFC8365" />,</t> bined with
Ethernet VPN (PBB-EVPN)</xref></li>
<t>Virtual Networks <xref target="RFC8453" />,</t> <li>VXLAN-based EVPN <xref target="RFC8365" format="default"/> ("VXLAN"
stands for "Virtual eXtensible Local Area Network")</li>
<t>Enhanced VPN (VPN+) <xref <li>Virtual Network <xref target="RFC8453" format="default"/></li>
target="I-D.ietf-teas-enhanced-vpn" />,</t> <li>Enhanced VPN (VPN+) <xref target="I-D.ietf-teas-enhanced-vpn" format
="default"/></li>
<t>Network slice <xref <li>Network slice service <xref target="IETF-NETWORK-SLICES" format="def
target="I-D.ietf-teas-ietf-network-slices" />,</t> ault"/></li>
<li>SD-WAN <xref target="BGP-SDWAN-USAGE" format="default"/></li>
<t>SDWAN <xref target="I-D.ietf-bess-bgp-sdwan-usage" />, and</t> <li>Basic IP connectivity</li>
</ul>
<t>Basic IP connectivity.</t>
</list></t>
<t>These service types build on the types that are already defined in <t>These service types build on the types that are already defined in
<xref target="RFC9181" /> and additional types that are defined in this <xref target="RFC9181" format="default"/> and additional types that are de fined in this
document. Other service types can be defined in future YANG modules document. Other service types can be defined in future YANG modules
(including future revisions of the YANG module defined in this (including future revisions of the YANG module defined in this
document), if needed.</t> document), if needed.</t>
<aside>
<aside pn="section-5"> <t>Leveraging the service types defined in
<t indent="0" pn="section-5.1">Leveraging the service types defined in <xref target="RFC9181" format="default"/> is meant to ease the correlati
<xref target="RFC9181" /> is meant to ease the correlation between the on between the
SAP topology and the corresponding network modules that are used to SAP topology and the corresponding network models that are used to
provision a specific service over a provider's network.</t> provision a specific service over a provider's network.</t>
</aside> </aside>
<t>Filters based on the service type can be used to access per-service <t>Filters based on the service type can be used to access per-service
SAP topology. An example is depicted in <xref SAP topology. An example is depicted in <xref target="app-ex-res-body-filt
target="app-ex-res-body-filter" />.</t> er" format="default"/> in <xref target="sample"/>.</t>
<t>A node in the topology can support one or multiple service types <t>A node in the topology can support one or multiple service types
('service-type') among those listed under the 'sap-network' container. A ('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 list of SAPs is then bound to each service type that is supported by a
given node. Each SAP is characterized as follows:<list style="hanging"> given node. Each SAP is characterized as follows:</t>
<t hangText="'sap-id':">Includes an identifier that uniquely <dl newline="false" spacing="normal">
identifies a SAP within a node. <vspace blankLines="1" />The same <dt>'sap-id':</dt>
<dd>
<t>Includes an identifier that uniquely
identifies a SAP within a node. </t>
<t>The same
SAP may appear under distinct service types. In such a case, the SAP may appear under distinct service types. In such a case, the
same identifier is used for these service types in same identifier is used for a shared SAP for each of these service typ
association.<vspace blankLines="1" />SAPs that are associated with es.</t>
<t>SAPs that are associated with
the interfaces that are directly hosting services, interfaces that the interfaces that are directly hosting services, interfaces that
are ready to host per-service sub-interfaces (but not yet are ready to host per-service sub-interfaces (but are not yet
activated), or services that are already instantiated on activated), or services that are already instantiated on
sub-interfaces are listed as SAPs. For illustration purposes, <xref sub-interfaces are listed as SAPs. For illustration purposes, <xref ta
target="app-ex-res-body" /> depicts how to indicate interfaces that rget="app-ex-res-body" format="default"/> in <xref target="sample"/> depicts how
are capable for hosting per-service sub-interfaces.<vspace to indicate interfaces that
blankLines="1" />For example, 'sap-id' may be the VPN network access are capable of hosting per-service sub-interfaces.</t>
identifier in Section 7.6 of <xref target="RFC9182" />. An example <t>For example, 'sap-id' may be the VPN network access
to illustrate the use of this attribute during service creation is identifier defined in <xref target="RFC9182" sectionFormat="of" sectio
provided in <xref target="servicesap" />.</t> n="7.6"/>. An example
that illustrates the use of this attribute during service creation is
<t hangText="'description':">Includes a textual description of the provided in <xref target="servicesap" format="default"/>.</t>
SAP.</t> </dd>
<dt>'description':</dt>
<t hangText="'parent-termination-point':">Includes a reference to <dd>Includes a textual description of the
SAP.</dd>
<dt>'parent-termination-point':</dt>
<dd>
<t>Includes a reference to
the parent termination point to which the SAP is bound. As per the parent termination point to which the SAP is bound. As per
Section 4.2 of <xref target="RFC8345" />, a termination point <xref target="RFC8345" sectionFormat="of" section="4.2"/>, a terminati on point
terminates a link in a node. A termination point can be a physical terminates a link in a node. A termination point can be a physical
port, an interface, etc. <vspace blankLines="1" />The referenced port, an interface, etc. </t>
<t>The referenced
parent termination point is expected to be a customer-facing parent termination point is expected to be a customer-facing
termination point, not a core-facing termination point.<vspace termination point, not a core-facing termination point.</t>
blankLines="1" />This attribute is used, e.g., to associate an <t>For example, this attribute is used to associate an
interface with its sub-interfaces as all these interfaces may be 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 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 the physical topology. </t>
data node can be used to map the IETF Network Slice endpoints (<xref <t>For example, this
target="I-D.ietf-teas-ietf-network-slices" />) to the data node can be used to map the IETF Network Slice endpoints <xref ta
rget="IETF-NETWORK-SLICES" format="default"/> to the
service/tunnel/path endpoints in the underlay network.</t> service/tunnel/path endpoints in the underlay network.</t>
</dd>
<t hangText="'attachment-interface':">Indicates a reference to the <dt>'attachment-interface':</dt>
<dd>
<t>Indicates a reference to the
interface to which the SAP is bound. The same interface may host interface to which the SAP is bound. The same interface may host
multiple services. <vspace blankLines="1" />Whether the attachment multiple services. </t>
<t>Whether the attachment
identifier echoes the content of the attachment interface is identifier echoes the content of the attachment interface is
deployment specific. <vspace blankLines="1" />For example, this deployment specific. </t>
<t>For example, this
reference may be any of the identifiers ('l2-termination-point', reference may be any of the identifiers ('l2-termination-point',
'local-bridge-reference', 'bearer-reference', or 'lag-interface-id') 'local-bridge-reference', 'bearer-reference', or 'lag-interface-id')
defined in Section 7.6.1 of <xref target="RFC9182" /> or defined in <xref target="RFC9182" sectionFormat="of" section="7.6.1"/>
'l3-termination-point' defined in Section 7.6.2 of <xref or
target="RFC9182" />. It is the responsibility of the controller to 'l3-termination-point' as defined in <xref target="RFC9182" sectionFor
ensure that consistent references are used in the SAP and underlying mat="of" section="7.6.2"/>. The controller is responsible for
device modes or any other device inventory mechanism.</t> ensuring that consistent references are used in the SAP and underlying
device models or any other device inventory mechanism.</t>
<t hangText="'interface-type':">Indicates whether a SAP is bound to </dd>
<dt>'interface-type':</dt>
<dd>
<t>Indicates whether a SAP is bound to
a physical port, a loopback interface, a Link Aggregation Group a physical port, a loopback interface, a Link Aggregation Group
(LAG) interface <xref target="IEEE802.1AX" />, an Integrated Routing (LAG) interface <xref target="IEEE802.1AX" format="default"/>, an Inte
Bridge (IRB) (e.g., <xref target="RFC9135" />), a local bridge grated Routing and Bridging (IRB) interface (e.g., <xref target="RFC9135" format
reference, etc. <vspace blankLines="1" />The mapping to the detailed ="default"/>), a local bridge
interface types as per <xref target="RFC7224" /> is maintained by reference, etc.</t>
<t>The mapping to the detailed
interface types as per <xref target="RFC7224" format="default"/> is ma
intained by
the controller. That mapping is used, for example, when the the controller. That mapping is used, for example, when the
controller translates this SAP network module into device modules controller translates this SAP network model into device models
(Section 4.4 of <xref target="RFC8969" />).</t> (<xref target="RFC8969" sectionFormat="of" section="4.4"/>).</t>
</dd>
<t hangText="'encapsulation-type':">Indicates the encapsulation type <dt>'encapsulation-type':</dt>
<dd>
<t>Indicates the encapsulation type
for the interface indicated in the 'attachment-interface' attribute. for the interface indicated in the 'attachment-interface' attribute.
The types are taken from <xref target="RFC9181" />. <vspace The types are taken from <xref target="RFC9181" format="default"/>. </
blankLines="1" />This data node can be used, for example, to decide t>
<t>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 whether an existing SAP can be (re)used to host a service or if a
new sub-interface has to be instantiated.</t> new sub-interface has to be instantiated.</t>
</dd>
<t hangText="'role':">Specifies the role of a SAP (e.g., a UNI or <dt>'role':</dt>
NNI). <vspace blankLines="1" />A SAP inherits the role of its parent <dd>
<t>Specifies the role of a SAP (e.g., a UNI or
NNI). </t>
<t>A SAP inherits the role of its parent
interface ('parent-termination-point').</t> interface ('parent-termination-point').</t>
</dd>
<t hangText="'allows-child-saps':">When set to 'true', this data <dt>'allows-child-saps':</dt>
node indicates that the attachment interface for this SAP is capable <dd>
of hosting per-service sub-interfaces. <vspace <t>When set to 'true', indicates that the attachment interface for
blankLines="1" />Whether a service can be directly attached to the this SAP is capable of hosting per-service sub-interfaces. </t>
<t>Whether a service can be directly attached to the
parent SAP in addition to child SAPs depends on the service.</t> parent SAP in addition to child SAPs depends on the service.</t>
</dd>
<t hangText="'peer-sap-id':">Includes references to the remote <dt>'peer-sap-id':</dt>
endpoints of an attachment circuit. This identifier may or may not <dd>
<t>Includes references to the remote
endpoints of an AC. This identifier may or may not
be the same as the SAP identifier used in the peer's configuration. be the same as the SAP identifier used in the peer's configuration.
Note that the use of identical identifiers eases correlating between Note that the use of identical identifiers eases the correlation betwe
a peer's service request with a local SAP. <vspace en
blankLines="1" />Examples of such a reference are: a site identifier a peer's service request and a local SAP. </t>
(Section 6.3 of <xref target="RFC8299" />), a Service Demarcation <t>Examples of such a reference are a site identifier
Point (SDP) identifier (Section 2.1 of <xref (<xref target="RFC8299" sectionFormat="of" section="6.3"/>), a Service
target="I-D.ietf-teas-ietf-network-slices" />), and the IP address Demarcation
Point (SDP) identifier (Section&nbsp;<xref target="IETF-NETWORK-SLICES
" section="3.2" sectionFormat="bare">"Core Terminology"</xref> of <xref target="
IETF-NETWORK-SLICES"/>), and the IP address
of a peer Autonomous System Border Router (ASBR).</t> of a peer Autonomous System Border Router (ASBR).</t>
</dd>
<t hangText="'sap-status':">Indicates the operational status of a <dt>'sap-status':</dt>
SAP. Values are taken from the values defined in <xref <dd>
target="RFC9181" />.<vspace blankLines="1" />When both a <t>Indicates the operational status of a
sub-interface and its parent interface are present, but the parent SAP. Values are taken from the values defined in <xref target="RFC9181
" format="default"/>.</t>
<t>When both a
sub-interface and its parent interface are present but the parent
interface is disabled, the status of the parent interface takes interface is disabled, the status of the parent interface takes
precedence over the status indicated for the sub-interface.</t> precedence over the status indicated for the sub-interface.</t>
</dd>
<t hangText="'service-status':">Indicates the administrative and <dt>'service-status':</dt>
<dd>
<t>Indicates the administrative and
operational status of the service for a given SAP. This information operational status of the service for a given SAP. This information
is particularly useful when many services are provisioned for the is particularly useful when many services are provisioned for the
same SAP, but only a subset of these services are activated. As same SAP but only a subset of these services is activated. As
such, the administrative 'service-status' MUST NOT be influenced by such, the administrative 'service-status' <bcp14>MUST NOT</bcp14> be i
the value of the operational 'sap-status'. <vspace nfluenced by
blankLines="1" />The service 'oper-status' reflects the operational the value of the operational 'sap-status'. </t>
<t>The service 'oper-status' reflects the operational
status of the service only as observed at a specific SAP, not the status of the service only as observed at a specific SAP, not the
overall network level status of the service connecting many SAPs. overall network-level status of the service connecting many SAPs.
The network level service status can be retrieved using specific The network-level service status can be retrieved using specific
network models, e.g., Section 7.3 of <xref target="RFC9182" /> or network models, e.g., those listed in <xref target="RFC9182" sectionFo
Section 7.3 of <xref target="RFC9291" />. <vspace rmat="of" section="7.3"/> or
blankLines="1" />In order to assess the service delivery status for <xref target="RFC9291" sectionFormat="of" section="7.3"/>. </t>
<t>In order to assess the service delivery status for
a given SAP, it is recommended to check both the administrative and a given SAP, it is recommended to check both the administrative and
operational service status ('service-status') in addition to the operational service status ('service-status') in addition to the
'sap-status'. In doing so, a network controller (or operator) can 'sap-status'. In doing so, a network controller (or operator) can
detect anomalies. For example, if a service is administratively detect anomalies. For example, if a service is administratively
enabled for a SAP and the 'sap-status' of that SAP is reported as enabled for a SAP and the 'sap-status' of that SAP is reported as
being down, the service 'oper-status' is also expected to be down. being down, the service 'oper-status' is also expected to be down.
Retrieving a distinct service operational status under these Retrieving a distinct service operational status under these
conditions can be used as a trigger to detect an anomaly. Likewise, conditions can be used as a trigger to detect an anomaly. Likewise,
administrative status and operational status can be compared to administrative status and operational status can be compared to
detect service-specific SAP activation anomalies. For example, a detect service-specific SAP activation anomalies. For example, a
service that is administratively declared as inactive for a SAP but service that is administratively declared as inactive for a SAP but
reported as operationally active for that SAP is an indication that reported as operationally active for that SAP is an indication that
some service provision actions are needed to align the observed some service provision actions are needed to align the observed
service status with the expected service status.</t> service status with the expected service status.</t>
</list></t> </dd>
</dl>
<t />
</section> </section>
<section anchor="mod" numbered="true" toc="default">
<section anchor="mod" title="SAP YANG Module"> <name>SAP YANG Module</name>
<t>This module imports types from <xref target="RFC6991"></xref>, <xref <t>This module imports types from <xref target="RFC6991" format="default"/
target="RFC8343"></xref>, <xref target="RFC8345"></xref>, and <xref >, <xref target="RFC8345" format="default"/>, and <xref target="RFC9181" format=
target="RFC9181"></xref>.</t> "default"/>.</t>
<t>The 'sap-entry' and 'sap-list' are defined as groupings for the reuse <t>The 'sap-entry' and 'sap-list' are defined as groupings for the reuse
of these nodes in service-specific YANG modules.</t> of these nodes in service-specific YANG modules.</t>
<sourcecode name="ietf-sap-ntw@2023-05-22.yang" type="yang" markers="true"
<figure> ><![CDATA[
<artwork><![CDATA[<CODE BEGINS> file "ietf-sap-ntw@2023-01-09.yang"
module ietf-sap-ntw { module ietf-sap-ntw {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw"; namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw";
prefix sap; prefix sap;
import ietf-network-topology { import ietf-network-topology {
prefix nt; prefix nt;
reference reference
"RFC 8345: A YANG Data Model for Network "RFC 8345: A YANG Data Model for Network
Topologies, Section 6.2"; Topologies, Section 6.2";
skipping to change at line 819 skipping to change at line 674
Author: Oscar Gonzalez de Dios Author: Oscar Gonzalez de Dios
<mailto:oscar.gonzalezdedios@telefonica.com> <mailto:oscar.gonzalezdedios@telefonica.com>
Author: Samier Barguil Author: Samier Barguil
<mailto:samier.barguil_giraldo@nokia.com> <mailto:samier.barguil_giraldo@nokia.com>
Author: Qin Wu Author: Qin Wu
<mailto:bill.wu@huawei.com> <mailto:bill.wu@huawei.com>
Author: Victor Lopez Author: Victor Lopez
<victor.lopez@nokia.com>"; <mailto:victor.lopez@nokia.com>";
description description
"This YANG module defines a model for representing, managing, "This YANG module defines a model for representing, managing,
and controlling the Service Attachment Points (SAPs) in the and controlling the Service Attachment Points (SAPs) in the
network topology. network topology.
Copyright (c) 2023 IETF Trust and the persons identified as Copyright (c) 2023 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Revised BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC 9408; see the
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself RFC itself for full legal notices.";
for full legal notices.";
revision 2023-01-09 { revision 2023-05-22 {
description description
"Initial version"; "Initial version.";
reference reference
"RFC XXXX: A YANG Network Model for Service Attachment "RFC 9408: A YANG Network Data Model for Service Attachment
Points (SAPs)"; Points (SAPs)";
} }
identity virtual-network { identity virtual-network {
base vpn-common:service-type; base vpn-common:service-type;
description description
"Virtual network. Refers to a logical network instance "Virtual network. Refers to a logical network instance
that is built over a physical network."; that is built over a physical network.";
reference reference
"RFC 8453: Framework for Abstraction and Control of TE "RFC 8453: Framework for Abstraction and Control of TE
Networks (ACTN)"; Networks (ACTN)";
} }
identity enhanced-vpn { identity enhanced-vpn {
base vpn-common:service-type; base vpn-common:service-type;
description description
"Enhanced VPN (VPN+). VPN+ is an approach that is "Enhanced VPN (VPN+). VPN+ is an approach that is
based on existing VPN and Traffic Engineering (TE) based on existing VPN and Traffic Engineering (TE)
technologies but adds characteristics that specific technologies but adds characteristics that specific
services require over and above conventional VPNs."; services require over and above conventional VPNs.";
reference reference
"draft-ietf-teas-enhanced-vpn: "draft-ietf-teas-enhanced-vpn:
A Framework for Enhanced Virtual Private Network A Framework for Enhanced Virtual Private Network
(VPN+) Services"; (VPN+)";
} }
identity network-slice { identity network-slice {
base vpn-common:service-type; base vpn-common:service-type;
description description
"IETF network slice. An IETF network slice "IETF Network Slice. An IETF Network Slice
is a logical network topology connecting a number of is a logical network topology connecting a number of
endpoints using a set of shared or dedicated network endpoints using a set of shared or dedicated network
resources that are used to satisfy specific service resources that are used to satisfy specific service
objectives."; objectives.";
reference reference
"draft-ietf-teas-ietf-network-slices: "draft-ietf-teas-ietf-network-slices:
A Framework for IETF Network Slices"; A Framework for IETF Network Slices";
} }
identity sdwan { identity sdwan {
base vpn-common:service-type; base vpn-common:service-type;
description description
"PE-based Software-Defined Wide Area Network (SDWAN)."; "PE-based Software-Defined Wide-Area Network (SD-WAN).";
reference reference
"draft-ietf-bess-bgp-sdwan-usage: BGP Usage for SDWAN "draft-ietf-bess-bgp-sdwan-usage:
Overlay Network"; BGP Usage for SD-WAN Overlay Networks";
} }
identity basic-connectivity { identity basic-connectivity {
base vpn-common:service-type; base vpn-common:service-type;
description description
"Basic IP connectivity. This is, for example, a plain "Basic IP connectivity. This is, for example, a plain
connectivity offered to Enterprises over a dedicated form of connectivity offered to enterprises over a
or shared MPLS infrastructure."; dedicated or shared MPLS infrastructure.";
} }
identity interface-role { identity interface-role {
description description
"Base identity for the network role of an interface."; "Base identity for the network role of an interface.";
} }
identity uni { identity uni {
base interface-role; base interface-role;
description description
"User-Network Interface (UNI)."; "User-to-Network Interface (UNI).";
} }
identity nni { identity nni {
base interface-role; base interface-role;
description description
"Network-to-Network Interface (NNI)."; "Network-to-Network Interface (NNI).";
} }
identity interface-type { identity interface-type {
description description
skipping to change at line 943 skipping to change at line 797
identity lag { identity lag {
base interface-type; base interface-type;
description description
"Link Aggregation Group (LAG) interface."; "Link Aggregation Group (LAG) interface.";
} }
identity irb { identity irb {
base interface-type; base interface-type;
description description
"Integrated Routing Bridge (IRB). An IRB typically "Integrated Routing and Bridging (IRB) interface. An IRB
connects an IP-VRF to a bridge domain."; interface typically connects an IP Virtual Routing and
Forwarding (IP-VRF) entity to a bridge domain.";
} }
identity local-bridge { identity local-bridge {
base interface-type; base interface-type;
description description
"A local bridge reference to accommodate, e.g., "A local bridge reference to accommodate (for example)
implementations that require internal bridging. implementations that require internal bridging.
When such a type is used, a reference to a local When such a type is used, a reference to a local
bridge domain is used to identify the interface."; bridge domain is used to identify the interface.";
} }
identity logical { identity logical {
base interface-type; base interface-type;
description description
"Refers to a logical sub-interface that is typically "Refers to a logical sub-interface that is typically
used to bind a service. This type is used only used to bind a service. This type is used only
if none of the other more specific types (i.e., if none of the other more specific types (i.e.,
loopback, lag, irb, or local-bridge) can be used."; 'loopback', 'lag', 'irb', or 'local-bridge') can be used.";
} }
grouping sap-entry { grouping sap-entry {
description description
"Service Attachment Point (SAP) entry information."; "Service Attachment Point (SAP) entry information.";
leaf sap-id { leaf sap-id {
type string; type string;
description description
"Indicates an identifier that uniquely identifies "Indicates an identifier that uniquely identifies
a SAP."; a SAP.";
} }
leaf description { leaf description {
type string; type string;
description description
"A textual description of the SAP."; "A textual description of the SAP.";
} }
leaf parent-termination-point { leaf parent-termination-point {
type nt:tp-id; type nt:tp-id;
description description
"Indicates the parent termination point to "Indicates the parent termination point to
which the SAP is attached to. A termination which the SAP is attached. A termination
point can be a physical port, an interface, etc."; point can be a physical port, an interface, etc.";
} }
leaf attachment-interface { leaf attachment-interface {
type string; type string;
description description
"Indicates the interface to which the SAP is bound."; "Indicates the interface to which the SAP is bound.";
} }
leaf interface-type { leaf interface-type {
type identityref { type identityref {
base interface-type; base interface-type;
skipping to change at line 1023 skipping to change at line 878
leaf allows-child-saps { leaf allows-child-saps {
type boolean; type boolean;
description description
"Indicates whether the attachment interface of this "Indicates whether the attachment interface of this
SAP is capable of hosting per-service sub-interfaces."; SAP is capable of hosting per-service sub-interfaces.";
} }
leaf-list peer-sap-id { leaf-list peer-sap-id {
type string; type string;
description description
"Indicates an identifier of the peer's termination "Indicates an identifier of the peer's termination
identifier (e.g., Customer Edge (CE)). This identifier (e.g., a Customer Edge (CE)). This
information can be used for correlation purposes, information can be used for correlation purposes,
such as identifying the SAP that is attached to such as identifying the SAP that is attached to
an endpoint that is provided in a service request."; an endpoint that is provided in a service request.";
} }
} }
grouping sap-list { grouping sap-list {
description description
"Service Attachment Point (SAP) information."; "SAP information.";
list sap { list sap {
key "sap-id"; key "sap-id";
description description
"The Service Attachment Points are abstraction of "The SAPs are an abstraction of the points to which
the points where network services such as L3VPNs, network services such as L3VPNs, L2VPNs, or network
L2VPNs, or network slices can be attached to."; slices can be attached.";
uses sap-entry; uses sap-entry;
container sap-status { container sap-status {
config false; config false;
description description
"Indicates the operational status of the SAP, "Indicates the operational status of the SAP,
independent of any service provisioned over it."; independent of any service provisioned over it.";
uses vpn-common:oper-status-timestamp; uses vpn-common:oper-status-timestamp;
} }
container service-status { container service-status {
skipping to change at line 1082 skipping to change at line 937
"Operational status of the service provisioned "Operational status of the service provisioned
at the SAP."; at the SAP.";
uses vpn-common:oper-status-timestamp; uses vpn-common:oper-status-timestamp;
} }
} }
} }
} }
augment "/nw:networks/nw:network/nw:network-types" { augment "/nw:networks/nw:network/nw:network-types" {
description description
"Introduces a new network type for SAP network."; "Introduces a new network type for a SAP network.";
container sap-network { container sap-network {
presence "Indicates SAP network type."; presence "Indicates the SAP network type.";
description description
"The presence of the container node indicates the "The presence of the container node indicates the
SAP network type."; SAP network type.";
leaf-list service-type { leaf-list service-type {
type identityref { type identityref {
base vpn-common:service-type; base vpn-common:service-type;
} }
description description
"Indicates the set of supported service types."; "Indicates the set of supported service types.";
} }
skipping to change at line 1121 skipping to change at line 976
type identityref { type identityref {
base vpn-common:service-type; base vpn-common:service-type;
} }
description description
"Indicates a service type."; "Indicates a service type.";
} }
uses sap-list; uses sap-list;
} }
} }
} }
<CODE ENDS>]]></artwork> ]]></sourcecode>
</figure>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document registers the following namespace URI in the "ns" <t>This document registers the following namespace URI in the "ns"
subregistry within the "IETF XML Registry" <xref subregistry within the "IETF XML Registry" <xref target="RFC3688" format="
target="RFC3688"></xref>: <figure> default"/>: </t>
<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"> <dl newline="false" spacing="compact">
<t>The YANG module specified in this document defines schema for data <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-sap-ntw</dd>
that is designed to be accessed via network management protocols such as <dt>Registrant Contact:</dt><dd>The IESG.</dd>
NETCONF <xref target="RFC6241"></xref> or RESTCONF <xref <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
target="RFC8040"></xref>. The lowest NETCONF layer is the secure </dl>
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 <t>This document registers the following YANG module in the "YANG Module
target="RFC8341"></xref> provides the means to restrict access for Names" subregistry <xref target="RFC6020" format="default"/> within the "Y
ANG
Parameters" registry: </t>
<dl newline="false" spacing="compact">
<dt>Name:</dt><dd>ietf-sap-ntw</dd>
<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-sap-ntw</dd>
<dt>Maintained by IANA?</dt><dd>N</dd>
<dt>Prefix:</dt><dd>sap</dd>
<dt>Reference:</dt><dd>RFC 9408</dd>
</dl>
</section>
<section anchor="scecurity" numbered="true" toc="default">
<name>Security Considerations</name>
<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 particular NETCONF or RESTCONF users to a preconfigured subset of all
available NETCONF or RESTCONF protocol operations and content.</t> available NETCONF or RESTCONF protocol operations and content.</t>
<t>There are a number of data nodes defined in this YANG module that are <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). writable/creatable/deletable (i.e., config true, which is the default). Th
These data nodes may be considered sensitive or vulnerable in some ese
network environments. Write operations (e.g., edit-config) to these data data nodes may be considered sensitive or vulnerable in some network
nodes without proper protection can have a negative effect on network environments. Write operations (e.g., edit-config) to these data nodes
operations. These are the subtrees and data nodes and their without proper protection can have a negative effect on network operations
sensitivity/vulnerability: <list style="symbols"> .
<t>/nw:networks/nw:network/nw:node/sap:service/sap:sap<vspace These are the subtrees and data nodes and their
blankLines="1" />This subtree specifies the configurations of the sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
<dt>/nw:networks/nw:network/nw:node/sap:service/sap:sap</dt>
<dd>This subtree specifies the configurations of the
nodes in a SAP network model. Unexpected changes to this subtree nodes in a SAP network model. Unexpected changes to this subtree
(e.g., associating a SAP with another parent termination point) (e.g., associating a SAP with another parent termination point)
could lead to service disruption and/or network misbehavior. Such could lead to service disruption and/or network misbehavior. Such
network misbehavior results mainly from a network configuration that network misbehavior results mainly from a network configuration that
is inconsistent with the intended behavior as defined by the is inconsistent with the intended behavior as defined by the
operator (e.g., Section 4.2.1 of <xref operator (e.g., <xref target="RFC8969" sectionFormat="of" section="4.2
target="RFC8969"></xref>).</t> .1"/>).</dd>
</list></t> </dl>
<t>Some of the readable data nodes in this YANG module may be considered <t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus important
important to control read access (e.g., via get, get-config, or to
notification) to these data nodes. These are the subtrees and data nodes control read access (e.g., via get, get-config, or notification) to these
and their sensitivity/vulnerability:<list style="symbols"> data nodes. These are the subtrees and data nodes and their
<t>/nw:networks/nw:network/nw:node/sap:service/sap:sap<vspace sensitivity/vulnerability:</t>
blankLines="1" />Unauthorized access to this subtree can disclose <dl newline="true" spacing="normal">
<dt>/nw:networks/nw:network/nw:node/sap:service/sap:sap</dt>
<dd>Unauthorized access to this subtree can disclose
the operational state information of the nodes in a SAP network the operational state information of the nodes in a SAP network
model (e.g., disclose the identity of a customer 'peer-sap-id').</t> model (e.g., can disclose the identity of a customer 'peer-sap-id').</
</list></t> dd>
</dl>
<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, Olga Havel, and Richard Roberts for the comments.</t>
<t>Thanks to Martin Bj&ouml;rklund for the YANG Doctors review, Menachem
Dodge for the opsdir review, Mach Chen for the rtgdir review, Linda
Dunbar for the genart review, and Ivaylo Petrov for the secdir
review.</t>
<t>Special thanks to Adrian Farrel for the Shepherd review and Rob
Wilton for the careful AD review.</t>
<t>Thanks to Lars Eggert, Roman Danyliw, and Zaheduzzaman Sarker for the
comments during the IESG review.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="reference.RFC.3688"?>
<?rfc include="reference.RFC.6020"?> <displayreference target="I-D.ietf-teas-enhanced-vpn" to="ENHANCED-VPN"/>
<?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'?>
<?rfc include='reference.RFC.6991'?>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>
</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.RFC.9291'?>
<?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'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
242.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
345.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
346.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
795.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
181.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
149.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
426.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
951.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
299.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
466.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
309.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
182.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
291.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
969.xml"/>
<?rfc include='reference.RFC.6215'?> <!-- draft-ietf-teas-ietf-network-slices (AD Evaluation::Revised I-D Needed)
("long way"/"Ed." designations were missing) -->
<reference anchor="IETF-NETWORK-SLICES">
<front>
<title>A Framework for IETF Network Slices</title>
<author initials="A." surname="Farrel" fullname="Adrian Farrel" role="edit
or">
</author>
<author initials="J." surname="Drake" fullname="John Drake" role="editor">
</author>
<author initials="R." surname="Rokui" fullname="Reza Rokui">
</author>
<author initials="S." surname="Homma" fullname="Shunsuke Homma">
</author>
<author initials="K." surname="Makhijani" fullname="Kiran Makhijani">
</author>
<author initials="L.M." surname="Contreras" fullname="Luis M. Contreras">
</author>
<author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
</author>
<date month="January" day="21" year="2023" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-teas-ietf-network-slices-
19" />
</reference>
<reference anchor="IEEE802.1AX"> <!-- draft-ietf-teas-enhanced-vpn (I-D Exists) -->
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<title>Link Aggregation</title> .ietf-teas-enhanced-vpn.xml"/>
<author> <!-- draft-ietf-bess-bgp-sdwan-usage (I-D Exists)
<organization></organization> ("long way"/A. Banerjee was missing) -->
</author> <reference anchor="BGP-SDWAN-USAGE">
<front>
<title>BGP Usage for SD-WAN Overlay Networks</title>
<author initials="L." surname="Dunbar" fullname="Linda Dunbar">
</author>
<author initials="J." surname="Guichard" fullname="Jim Guichard">
</author>
<author initials="A." surname="Sajassi" fullname="Ali Sajassi">
</author>
<author initials="J." surname="Drake" fullname="John Drake">
</author>
<author initials="B." surname="Najem" fullname="Basil Najem">
</author>
<author initials="A." surname="Banerjee" fullname="Ayan Banerjee">
</author>
<author initials="D." surname="Carrel" fullname="David Carrel">
</author>
<date month="April" day="7" year="2023" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-bess-bgp-sdwan-usage-09"
/>
</reference>
<date month="" year="2020" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</front> 364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
761.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
762.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
214.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
623.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
432.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
453.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
224.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
026.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
135.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
004.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
215.xml"/>
<seriesInfo name="IEEE" value="Std 802.1AX-2020" /> <reference anchor="IEEE802.1AX">
</reference> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Link Ag
gregation</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2020"/>
</front>
<seriesInfo name='IEEE Std' value='802.1AX-2020' />
<seriesInfo name='DOI' value='10.1109/IEEESTD.2020.9105034' />
</reference>
<reference anchor="MEF6" <reference anchor="MEF6" target="https://www.mef.net/Assets/Technical_Sp
target="https://www.mef.net/Assets/Technical_Specifications/PDF ecifications/PDF/MEF_6.pdf">
/MEF_6.pdf"> <front>
<front> <title>Technical Specification MEF 6, Ethernet Services Definitions
<title>Technical Specification MEF 6, Ethernet Services Definitions
- Phase I</title> - Phase I</title>
<author>
<organization>The Metro Ethernet Forum</organization>
</author>
<date month="June" year="2004"/>
</front>
</reference>
<author fullname=""> <reference anchor="MEF17" target="https://www.mef.net/wp-content/uploads
<organization>The Metro Ethernet Forum</organization> /2015/04/MEF-17.pdf">
</author> <front>
<title>Technical Specification MEF 17, Service OAM Requirements
<date month="June" year="2004" />
</front>
</reference>
<reference anchor="MEF17"
target="https://www.mef.net/wp-content/uploads/2015/04/MEF-17.p
df">
<front>
<title>Technical Specification MEF 17, Service OAM Requirements
&amp; Framework - Phase 1</title> &amp; Framework - Phase 1</title>
<author>
<author fullname=""> <organization>The Metro Ethernet Forum</organization>
<organization>The Metro Ethernet Forum</organization> </author>
</author> <date month="April" year="2007"/>
</front>
<date month="April" year="2007" /> </reference>
</front> </references>
</reference>
</references> </references>
<section anchor="app1" numbered="true" toc="default">
<section anchor="app1" title="A Simplified SAP Network Example"> <name>A Simplified SAP Network Example</name>
<t>An example of a SAP topology that is reported by a network controller <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 is depicted in <xref target="ex1" format="default"/>. This example echoes
topology shown in <xref target="fi3a"></xref>. Only a minimum set of the
information is provided for each SAP. Particularly, topology shown in <xref target="fi3a" format="default"/>. Only a minimum
information set is provided for each SAP. Particularly,
'parent-termination-point', 'attachment-interface', 'interface-type', 'parent-termination-point', 'attachment-interface', 'interface-type',
'encapsulation-type', and 'role' are not shown in the example. SAPs that 'encapsulation-type', and 'role' are not shown in the example. SAPs that
are capable of hosting a service, but not yet activated, are identified are capable of hosting a service but are not yet activated are identified
by the 'sap-status/status' set to 'ietf-vpn-common:op-down' and by 'sap-status/status' set to 'ietf-vpn-common:op-down' and
'service-status/admin-status/status' set to 'service-status/admin-status/status' set to
'ietf-vpn-common:admin-down'. SAPs that are enabled to deliver a service 'ietf-vpn-common:admin-down'. SAPs that are enabled to deliver a service
are identified by 'service-status/admin-status/status' set to are identified by 'service-status/admin-status/status' set to
'ietf-vpn-common:admin-up' and 'service-status/oper-status/status' set 'ietf-vpn-common:admin-up' and 'service-status/oper-status/status' set
to 'ietf-vpn-common:op-up'. Note that none of the anomalies discussed in to 'ietf-vpn-common:op-up'. Note that none of the anomalies discussed in
<xref target="tree"></xref> are detected for these SAPs.</t> <xref target="tree" format="default"/> are detected for these SAPs.
The message body depicted in the figures below is encoded following the
<t><figure anchor="ex1" title="A Simplified SAP Network Example"> JSON encoding of YANG-modeled data as per <xref target="RFC7951"/>.</t>
<artwork><![CDATA[{ <figure anchor="ex1">
<name>A Simplified SAP Network Example</name>
<sourcecode type="json"><![CDATA[{
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-types": { "network-types": {
"ietf-sap-ntw:sap-network": { "ietf-sap-ntw:sap-network": {
"service-type": [ "service-type": [
"ietf-vpn-common:l3vpn", "ietf-vpn-common:l3vpn",
"ietf-vpn-common:vpls" "ietf-vpn-common:vpls"
] ]
} }
skipping to change at line 1585 skipping to change at line 1426
} }
} }
] ]
} }
] ]
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode></figure>
<t></t>
</section> </section>
<section anchor="sample" numbered="true" toc="default">
<section anchor="sample" <name>A Simple Example of the SAP Network Model: Node Filter</name>
title="A Simple Example of SAP Network Model: Node Filter"> <t>In the example shown in <xref target="app-ex" format="default"/>, PE1 (
<t>In the example shown in <xref target="app-ex"></xref>, PE1 (with a with a
"node-id" set to "example:pe1") has two physical interfaces "GE0/6/1" "node-id" set to "example:pe1", as shown in <xref target="ex1"/>) has two
physical interfaces "GE0/6/1"
and "GE0/6/4". Two sub-interfaces "GE0/6/4.1" and "GE0/6/4.2" are 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 associated with the physical interface "GE0/6/4". Let us consider that
four SAPs are exposed to the service orchestrator and mapped to these four SAPs are exposed to the service orchestrator and mapped to these
physical interfaces and sub-interfaces.</t> physical interfaces and sub-interfaces.</t>
<figure anchor="app-ex">
<t><figure align="center" anchor="app-ex" <name>An Example of a PE and Its Physical/Logical Interfaces</name>
title="An Example of a PE and its Physical/Logical Interfaces"> <artwork align="center" name="" type="" alt=""><![CDATA[ .------------
<artwork align="center"><![CDATA[ .-------------------------. -------------.
| GE0/6/4 | | GE0/6/4 |
| PE1 .----+----. | PE1 .----+----.
| |sap#2 |GE0/6/4.1 | |sap#2 |GE0/6/4.1
| | .--+--. | | .--+--.
| | |sap#3| | | |sap#3|
| | '--+--' | | '--+--'
| | |GE0/6/4.2 | | |GE0/6/4.2
| | .--+--. | | .--+--.
| | |sap#4| | | |sap#4|
| | '--+--' | | '--+--'
| | | | | |
| +----+----+ | +----+----+
| | | |
| GE0/6/1| | GE0/6/1|
| .----+----. | .----+----.
| |sap#1 | | |sap#1 |
| '----+----' | '----+----'
| | | |
'-------------------------' '-------------------------'
]]></artwork> ]]></artwork></figure>
</figure></t>
<t>Let us assume that no service is enabled yet for the SAP associated <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 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 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 L3VPN services are activated on the two sub-interfaces "GE0/6/4.1" and
"GE0/6/4.2", respectively. Both "sap#1" and "sap#2" are tagged as being "GE0/6/4.2", respectively. Both "sap#1" and "sap#2" are tagged as being
capable of hosting per-service sub-interfaces ('allows-child-saps' is capable of hosting per-service sub-interfaces ('allows-child-saps' is
set to 'true').</t> set to 'true').</t>
<t>For example, a service orchestrator can query what services are provide
<t>A service orchestrator can query what services are provided on which d on which
SAPs of PE1 from the network controller by sending, e.g., a GET RESTCONF SAPs of PE1 from the network controller by sending a RESTCONF GET
request. <xref target="app-ex-res-body"></xref> shows an example of the request. <xref target="app-ex-res-body" format="default"/> shows an exampl
e of the
body of the RESTCONF response that is received from the network body of the RESTCONF response that is received from the network
controller.</t> controller.</t>
<figure anchor="app-ex-res-body">
<t><figure anchor="app-ex-res-body" <name>An Example of a Response Body to a Request with a Node Filter</nam
title="An Example of a Response Body to a Request with a Node Filter"> e>
<artwork><![CDATA[{ <sourcecode type="json"><![CDATA[{
"ietf-sap-ntw:service": [ "ietf-sap-ntw:service": [
{ {
"service-type": "ietf-vpn-common:l3vpn", "service-type": "ietf-vpn-common:l3vpn",
"sap": [ "sap": [
{ {
"sap-id": "sap#1", "sap-id": "sap#1",
"description": "Ready to host SAPs", "description": "Ready to host SAPs",
"attachment-interface": "GE0/6/1", "attachment-interface": "GE0/6/1",
"interface-type": "ietf-sap-ntw:phy", "interface-type": "ietf-sap-ntw:phy",
"role": "ietf-sap-ntw:uni", "role": "ietf-sap-ntw:uni",
skipping to change at line 1737 skipping to change at line 1570
}, },
"oper-status": { "oper-status": {
"status": "ietf-vpn-common:op-up" "status": "ietf-vpn-common:op-up"
} }
} }
} }
] ]
} }
] ]
} }
]]></artwork> ]]></sourcecode></figure>
</figure></t> <t><xref target="app-ex-res-body-filter" format="default"/> shows an examp
le of the
<t><xref target="app-ex-res-body-filter"></xref> shows an example of the
response message body that is received from the network controller if response message body that is received from the network controller if
the request includes a filter on the service type for a particular the request includes a filter on the service type for a particular
node:</t> node:</t>
<figure anchor="app-ex-res-body-filter">
<t><figure anchor="app-ex-res-body-filter" <name>An Example of a Response Body to a Request with a Service Filter</
title="An Example of a Response Body to a Request with a Service Filte name>
r"> <sourcecode type="json"><![CDATA[{
<artwork><![CDATA[{
"ietf-sap-ntw:service": [ "ietf-sap-ntw:service": [
{ {
"service-type": "ietf-vpn-common:l3vpn", "service-type": "ietf-vpn-common:l3vpn",
"sap": [ "sap": [
{ {
"sap-id": "sap#1", "sap-id": "sap#1",
"description": "Ready to host SAPs", "description": "Ready to host SAPs",
"attachment-interface": "GE0/6/1", "attachment-interface": "GE0/6/1",
"interface-type": "ietf-sap-ntw:phy", "interface-type": "ietf-sap-ntw:phy",
"role": "ietf-sap-ntw:uni", "role": "ietf-sap-ntw:uni",
skipping to change at line 1797 skipping to change at line 1627
}, },
"oper-status": { "oper-status": {
"status": "ietf-vpn-common:op-up" "status": "ietf-vpn-common:op-up"
} }
} }
} }
] ]
} }
] ]
} }
]]></artwork> ]]></sourcecode></figure>
</figure></t>
<t></t>
</section> </section>
<section anchor="nniapp" numbered="true" toc="default">
<section anchor="nniapp" <name>An Example of an NNI SAP: Inter-AS VPN Option A</name>
title="An Example of NNI SAP: Inter-AS VPN Option A"> <t><xref target="RFC4364" sectionFormat="of" section="10"/>
<t>Section 10 of <xref target="RFC4364"></xref> discuses several options discusses several options
to extend a VPN service beyond the scope of a single Autonomous System to extend a VPN service beyond the scope of a single Autonomous System
(AS). For illustration purposes, this section focuses on the so-called (AS). For illustration purposes, this section focuses on the so-called
"Option A" but similar examples can be considered for other options.</t> "Option A", but similar examples can be considered for other options.</t>
<t>In this option, an AS Border Router (ASBR) of an AS is directly connect
<t>In this option, an ASBR of an AS is directly connected to an ASBR of ed to an ASBR of
a neighboring AS. These two ASBRs are connected by multiple physical or a neighboring AS. These two ASBRs are connected by multiple physical or
logical interfaces. Also, at least one sub-interface is maintained by 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 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 from one AS to the other AS. Each ASBR behaves as a PE and treats the
other as if it were a CE.</t> other as if it were a CE.</t>
<t><xref target="optiona" format="default"/> shows a simplified (excerpt)
<t><xref target="optiona"></xref> shows a simplified (excerpt) topology topology
of two ASes A and B with a focus on the interconnection links between of two ASes A and B with a focus on the interconnection links between
these two ASes.</t> these two ASes.</t>
<figure anchor="optiona">
<t><figure align="center" anchor="optiona" <name>An Example of an Inter-AS VPN (Option A)</name>
title="An Example of Inter-AS VPN (Option A)"> <artwork align="center" name="" type="" alt=""><![CDATA[.---------------
<artwork align="center"><![CDATA[.--------------------. -----. .--------------------.
.--------------------.
| | | | | | | |
| A .--+--. .--+--. A | | A .--+--. .--+--. A |
| S | +================+ | S | | S | +================+ | S |
| B | (VRF1)----(VPN1)----(VRF1) | B | | B | (VRF1)----(VPN1)----(VRF1) | B |
| R | | | | R | | R | | | | R |
| | (VRF2)----(VPN2)----(VRF2) | | | | (VRF2)----(VPN2)----(VRF2) | |
| a | +================+ | b | | a | +================+ | b |
| 1 '--+--' '--+--' 1 | | 1 '--+--' '--+--' 1 |
| AS A | | AS B | | AS A | | AS B |
| A .--+--. .--+--. A | | A .--+--. .--+--. A |
| S | +================+ | S | | S | +================+ | S |
| B | (VRF1)----(VPN1)----(VRF1) | B | | B | (VRF1)----(VPN1)----(VRF1) | B |
| R | | | | R | | R | | | | R |
| | (VRF2)----(VPN2)----(VRF2) | | | | (VRF2)----(VPN2)----(VRF2) | |
| a | +================+ | b | | a | +================+ | b |
| 2 '--+--' '--+--' 2 | | 2 '--+--' '--+--' 2 |
| | | | | | | |
'--------------------' '--------------------']]></artwork> '--------------------' '--------------------'
</figure></t> ]]></artwork> </figure>
<t><xref target="nniex1" format="default"/> shows an example of a message
<t><xref target="nniex1"></xref> shows an example of a message body that body that
is received from the network controller of AS A (with a focus on the is received from the network controller of AS A (with a focus on the
NNIs shown in <xref target="optiona"></xref>).</t> NNIs shown in <xref target="optiona" format="default"/>).</t>
<figure anchor="nniex1">
<t><figure anchor="nniex1" title="An Example of SAP Usage for NNI"> <name>An Example of SAP Usage for an NNI</name>
<artwork><![CDATA[{ <sourcecode type="json"><![CDATA[{
"ietf-network:networks": { "ietf-network:networks": {
"network": [ "network": [
{ {
"network-types": { "network-types": {
"ietf-sap-ntw:sap-network": { "ietf-sap-ntw:sap-network": {
"service-type": [ "service-type": [
"ietf-vpn-common:l3vpn" "ietf-vpn-common:l3vpn"
] ]
} }
}, },
skipping to change at line 1994 skipping to change at line 1817
} }
} }
] ]
} }
] ]
} }
] ]
} }
] ]
} }
}]]></artwork> }
</figure></t> ]]></sourcecode></figure>
<t></t>
</section> </section>
<section anchor="servicesap" numbered="true" toc="default">
<section anchor="servicesap" <name>Examples of Using the SAP Network Model in Service Creation</name>
title="Examples of Using the SAP Network Model in Service Creation" <t>This section describes examples that illustrate the use of the SAP
>
<t>This section describes an example to illustrate the use of the SAP
model for service creation purposes.</t> model for service creation purposes.</t>
<t>An example of a SAP topology is presented in <xref target="ex1" format=
<t>An example of a SAP topology is presented in <xref "default"/>. This example includes four PEs with their SAPs, as
target="ex1"></xref>. This example includes four PEs with their SAPs, as
well as the customer information.</t> well as the customer information.</t>
<t>Let us assume that an operator wants to create an L3VPN service <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). 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 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>. a response similar to what is depicted in <xref target="ex1" format="defau lt"/>.
That response indicates that the SAPs having "sap#31" and "sap#43" as That response indicates that the SAPs having "sap#31" and "sap#43" as
attachment identifiers do not have any installed services. This is attachment identifiers do not have any installed services. This is
particularly inferred from the administrative 'service-status' which is particularly inferred from (1) the administrative 'service-status' that is
set to 'ietf-vpn-common:admin-down' for all the services that are set to 'ietf-vpn-common:admin-down' for all the services that are
supported by these two SAPs and that none of the anomalies discussed in supported by these two SAPs and (2) the absence of the anomalies discussed
<xref target="tree"></xref> are detected. Once the "free" SAPs are in <xref target="tree"/>. Note that none of the anomalies discussed in
<xref target="tree" format="default"/> are detected. Once the "free" SAPs
are
identified, the 'interface-type' and 'encapsulation-type' are checked to identified, the 'interface-type' and 'encapsulation-type' are checked to
see if the requested L3VPN service is compatible with the SAP see if the requested L3VPN service is compatible with the SAP
characteristics. If they are compatible, the 'attachment-id' value can characteristics. If they are compatible, the 'attachment-id' value can
be used as the VPN network access identifier in an L3NM create be used as the VPN network access identifier in an L3NM "create"
query.</t> query.</t>
<t>A similar process can be followed for creating the so-called <t>A similar process can be followed for creating the so-called
"Inter-AS VPN Option A" services. Unlike the previous example, let us "Inter-AS VPN Option A" services. Unlike the previous example, let us
assume that an operator wants to create an L3VPN service between two PEs assume that an operator wants to create an L3VPN service between two PEs
(PE3 and PE4) but these PEs are not in the same AS: PE3 belongs to AS A (PE3 and PE4) but these PEs are not in the same AS: PE3 belongs to AS A
while PE4 belongs to AS B. The NNIs between these ASes are represented while PE4 belongs to AS B. The NNIs between these ASes are represented
in <xref target="optiona"></xref>. The operator of AS A would query, via in <xref target="optiona" format="default"/>. The operator of AS A would q uery, via
the controller of its AS, the SAP topology and would obtain not only the the controller of its AS, the SAP topology and would obtain not only the
information that is depicted in <xref target="ex1"></xref>, but also the information that is depicted in <xref target="ex1" format="default"/> but
information shown in <xref target="nniex1"></xref> representing the also the
information shown in <xref target="nniex1" format="default"/> representing
the
NNIs. The operator would create the service in the AS A between PE3 and NNIs. The operator would create the service in the AS A between PE3 and
a free, compatible SAP in the ASBR A1. The same procedure is followed by a free, compatible SAP in the ASBR A1. The same procedure is followed by
the operator of AS B to create the service in the AS B between a free, the operator of AS B to create the service in the AS B between a free,
compatible SAP in the ASBR B1 and PE4. The services can be provisioned compatible SAP in the ASBR B1 and PE4. The services can be provisioned
in each of these ASes using the L3NM.</t> in each of these ASes using the L3NM.</t>
<t>Let us now assume that, instead of the L3VPN service, the operator <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 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 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 the service's needs (e.g., the 'encapsulation-type' attribute can be set
to 'ietf-vpn-common:vlan-type'). Once the logical SAP is created, the 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 'attachment-id' of the new SAP is used to create an L2NM instance
(Section 7.6 of <xref target="RFC9291"></xref>).</t> (<xref target="RFC9291" sectionFormat="of" section="7.6"/>).</t>
</section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Adrian Farrel"/>,
<contact fullname="Daniel King"/>, <contact fullname="Dhruv Dhody"/>,
<contact fullname="Benoit Claise"/>, <contact fullname="Bo Wu"/>,
<contact fullname="Erez Segev"/>, <contact fullname="Raul Arco"/>,
<contact fullname="Joe Clarke"/>,
<contact fullname="Riyas Valiyapalathingal"/>,
<contact fullname="Tom Petch"/>, <contact fullname="Olga Havel"/>, and
<contact fullname="Richard Roberts"/> for their comments.</t>
<t>Thanks to <contact fullname="Martin Björklund"/> for the YANG Doctors
review, <contact fullname="Menachem Dodge"/> for the opsdir review,
<contact fullname="Mach Chen"/> for the rtgdir review,
<contact fullname="Linda Dunbar"/> for the genart review, and
<contact fullname="Ivaylo Petrov"/> for the secdir
review.</t>
<t>Special thanks to <contact fullname="Adrian Farrel"/> for the Shepherd
review and <contact fullname="Rob Wilton"/> for the careful AD review.</t>
<t>Thanks to <contact fullname="Lars Eggert"/>,
<contact fullname="Roman Danyliw"/>, and
<contact fullname="Zaheduzzaman Sarker"/> for their
comments during the IESG review.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 205 change blocks. 
813 lines changed or deleted 792 lines changed or added

This html diff was produced by rfcdiff 1.48.