File: rfc8969.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3817 lines) | stat: -rw-r--r-- 228,829 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8969: A Framework for Automating Service and Network Management with YANG</title>
<meta content="Qin Wu" name="author">
<meta content="Mohamed Boucadair" name="author">
<meta content="Diego R. Lopez" name="author">
<meta content="Chongfeng Xie" name="author">
<meta content="Liang Geng" name="author">
<meta content="
       Data models provide a programmatic approach to represent services and
      networks. Concretely, they can be used to derive configuration
      information for network and service components, and state information
      that will be monitored and tracked. 

Data models can be used during the service and network management life cycle
(e.g., service instantiation, service provisioning, service optimization,
service monitoring, service diagnosing, and service assurance).

Data models are also instrumental in the automation of network management, and
they can provide closed-loop control for adaptive and deterministic service
creation, delivery, and maintenance. 
       This document describes a framework for service and network
      management automation that takes advantage of YANG modeling
      technologies. This framework is drawn from a network operator
      perspective irrespective of the origin of a data model; thus, it can 
      accommodate YANG modules that are developed outside the IETF. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Model Driven" name="keyword">
<meta content="YANG Data Model" name="keyword">
<meta content="automation" name="keyword">
<meta content="service delivery" name="keyword">
<meta content="notification" name="keyword">
<meta content="SDN" name="keyword">
<meta content="8969" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8969.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8969" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework-10" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8969</td>
<td class="center">Service &amp; Network Management Automation</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Wu, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8969" class="eref">8969</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-01" class="published">January 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">Q. Wu, <span class="editor">Ed.</span>
</div>
<div class="org">Huawei</div>
</div>
<div class="author">
      <div class="author-name">M. Boucadair, <span class="editor">Ed.</span>
</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">D. Lopez</div>
<div class="org">Telefonica I+D</div>
</div>
<div class="author">
      <div class="author-name">C. Xie</div>
<div class="org">China Telecom</div>
</div>
<div class="author">
      <div class="author-name">L. Geng</div>
<div class="org">China Mobile</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8969</h1>
<h1 id="title">A Framework for Automating Service and Network Management with YANG</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">Data models provide a programmatic approach to represent services and
      networks. Concretely, they can be used to derive configuration
      information for network and service components, and state information
      that will be monitored and tracked. 

Data models can be used during the service and network management life cycle
(e.g., service instantiation, service provisioning, service optimization,
service monitoring, service diagnosing, and service assurance).

Data models are also instrumental in the automation of network management, and
they can provide closed-loop control for adaptive and deterministic service
creation, delivery, and maintenance.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document describes a framework for service and network
      management automation that takes advantage of YANG modeling
      technologies. This framework is drawn from a network operator
      perspective irrespective of the origin of a data model; thus, it can 
      accommodate YANG modules that are developed outside the IETF.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8969">https://www.rfc-editor.org/info/rfc8969</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology-and-abbreviatio" class="xref">Terminology and Abbreviations</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-abbreviations" class="xref">Abbreviations</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-architectural-concepts-and-" class="xref">Architectural Concepts and Goals</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-data-models-layering-and-re" class="xref">Data Models: Layering and Representation</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-automation-of-service-deliv" class="xref">Automation of Service Delivery Procedures</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-service-fulfillment-automat" class="xref">Service Fulfillment Automation</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-yang-module-integration" class="xref">YANG Module Integration</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-functional-blocks-and-inter" class="xref">Functional Blocks and Interactions</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-service-life-cycle-manageme" class="xref">Service Life-Cycle Management Procedure</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-service-exposure" class="xref">Service Exposure</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-service-creation-modificati" class="xref">Service Creation/Modification</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.3">
                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-service-assurance" class="xref">Service Assurance</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.4">
                    <p id="section-toc.1-1.4.2.1.2.4.1"><a href="#section-4.1.4" class="xref">4.1.4</a>.  <a href="#name-service-optimization" class="xref">Service Optimization</a><a href="#section-toc.1-1.4.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.5">
                    <p id="section-toc.1-1.4.2.1.2.5.1"><a href="#section-4.1.5" class="xref">4.1.5</a>.  <a href="#name-service-diagnosis" class="xref">Service Diagnosis</a><a href="#section-toc.1-1.4.2.1.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.1.2.6">
                    <p id="section-toc.1-1.4.2.1.2.6.1"><a href="#section-4.1.6" class="xref">4.1.6</a>.  <a href="#name-service-decommission" class="xref">Service Decommission</a><a href="#section-toc.1-1.4.2.1.2.6.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-service-fulfillment-managem" class="xref">Service Fulfillment Management Procedure</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-intended-configuration-prov" class="xref">Intended Configuration Provision</a><a href="#section-toc.1-1.4.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-configuration-validation" class="xref">Configuration Validation</a><a href="#section-toc.1-1.4.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2.2.3">
                    <p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="xref">4.2.3</a>.  <a href="#name-performance-monitoring" class="xref">Performance Monitoring</a><a href="#section-toc.1-1.4.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.2.2.4">
                    <p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="xref">4.2.4</a>.  <a href="#name-fault-diagnostic" class="xref">Fault Diagnostic</a><a href="#section-toc.1-1.4.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-multi-layer-multi-domain-se" class="xref">Multi-layer/Multi-domain Service Mapping</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-service-decomposition" class="xref">Service Decomposition</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-yang-data-model-integration" class="xref">YANG Data Model Integration Examples</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-l2vpn-l3vpn-service-deliver" class="xref">L2VPN/L3VPN Service Delivery</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-vn-life-cycle-management" class="xref">VN Life-Cycle Management</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-event-based-telemetry-in-th" class="xref">Event-Based Telemetry in the Device Self Management</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-service-level" class="xref">Service Level</a><a href="#section-toc.1-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-network-level" class="xref">Network Level</a><a href="#section-toc.1-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-device-level" class="xref">Device Level</a><a href="#section-toc.1-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-layered-yang-module-example" class="xref">Layered YANG Module Examples Overview</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-service-models-definition-a" class="xref">Service Models: Definition and Samples</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-schema-mount" class="xref">Schema Mount</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-a.3" class="xref">A.3</a>.  <a href="#name-network-models-samples" class="xref">Network Models: Samples</a><a href="#section-toc.1-1.9.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-a.4" class="xref">A.4</a>.  <a href="#name-device-models-samples" class="xref">Device Models: Samples</a><a href="#section-toc.1-1.9.2.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty toc compact">
<li class="ulEmpty toc compact" id="section-toc.1-1.9.2.4.2.1">
                    <p id="section-toc.1-1.9.2.4.2.1.1"><a href="#section-a.4.1" class="xref">A.4.1</a>.  <a href="#name-model-composition" class="xref">Model Composition</a><a href="#section-toc.1-1.9.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.4.2.2">
                    <p id="section-toc.1-1.9.2.4.2.2.1"><a href="#section-a.4.2" class="xref">A.4.2</a>.  <a href="#name-device-management" class="xref">Device Management</a><a href="#section-toc.1-1.9.2.4.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.4.2.3">
                    <p id="section-toc.1-1.9.2.4.2.3.1"><a href="#section-a.4.3" class="xref">A.4.3</a>.  <a href="#name-interface-management" class="xref">Interface Management</a><a href="#section-toc.1-1.9.2.4.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty toc compact" id="section-toc.1-1.9.2.4.2.4">
                    <p id="section-toc.1-1.9.2.4.2.4.1"><a href="#section-a.4.4" class="xref">A.4.4</a>.  <a href="#name-some-device-model-examples" class="xref">Some Device Model Examples</a><a href="#section-toc.1-1.9.2.4.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty toc compact" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Service management systems usually comprise service
      activation/provision and service operation. Current service delivery
      procedures, from the processing of customer requirements and orders to
      service delivery and operation, typically assume the manipulation of
      data sequentially into multiple Operations Support System (OSS) or
      Business Support System (BSS) applications that may be managed by
      different departments within the service provider's organization (e.g.,
      billing factory, design factory, network operation center). Many of
      these applications have been developed in house over the years and
      operate in a silo mode. As a result:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">The lack of standard data input/output (i.e., data model) raises
          many challenges in system integration and often results in manual
          configuration tasks.<a href="#section-1-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.2">Service fulfillment systems might have a limited visibility on
          the network state and may therefore have a slow response to network
          changes.<a href="#section-1-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-3">Software-Defined Networking (SDN) becomes crucial to address these
      challenges. SDN techniques are meant to automate the overall service
      delivery procedures and typically rely upon standard data models.  These
      models are used not only to reflect service providers' savoir faire, but
      also to dynamically instantiate and enforce a set of service-inferred
      policies that best accommodate what has been defined and possibly
      negotiated with the customer. <span>[<a href="#RFC7149" class="xref">RFC7149</a>]</span>
      provides a first tentative attempt to rationalize that service
      provider's view on the SDN space by identifying concrete technical
      domains that need to be considered and for which solutions can be
      provided. These include:<a href="#section-1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-4.1">Techniques for the dynamic discovery of topology, devices, and
          capabilities, along with relevant information and data models that
          are meant to precisely document such topology, devices, and their
          capabilities.<a href="#section-1-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.2">Techniques for exposing network services <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span> and their characteristics.<a href="#section-1-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.3">Techniques used by service-derived dynamic resource allocation
          and policy enforcement schemes, so that networks can be programmed
          accordingly.<a href="#section-1-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-4.4">Dynamic feedback mechanisms that are meant to assess how
          efficiently a given policy (or a set thereof) is enforced from a
          service fulfillment and assurance perspective.<a href="#section-1-4.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-5">Models are key for each of the four technical items above.
      Service and network management automation is an important step to
      improve the agility of network operations. Models are also important to
      ease integrating multi-vendor solutions.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">YANG module <span>[<a href="#RFC7950" class="xref">RFC7950</a>]</span> developers have
      taken both top-down and bottom-up approaches to develop modules <span>[<a href="#RFC8199" class="xref">RFC8199</a>]</span> and to establish a mapping between a
      network technology and customer requirements at the top or abstracting
      common constructs from various network technologies at the bottom. 


At the time of writing this document (2020), there are many YANG data models,
including configuration and service models, that have been specified or are
being specified by the IETF. They cover many of the networking protocols and
techniques. However, how these models work together to configure a function,
manage a set of devices involved in a service, or provide a service is
something that is not currently documented either within the IETF or other
Standards Development Organizations (SDOs).<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">Many of the YANG modules listed in this document are used to exchange
      data between NETCONF/RESTCONF clients and servers <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span><span>[<a href="#RFC8040" class="xref">RFC8040</a>]</span>. Nevertheless, YANG is a transport-independent data
      modeling language. It can thus be used independently of
      NETCONF/RESTCONF. For example, YANG can be used to define abstract data
      structures <span>[<a href="#RFC8791" class="xref">RFC8791</a>]</span> that can be
      manipulated by other protocols (e.g., <span>[<a href="#I-D.ietf-dots-rfc8782-bis" class="xref">DOTS-DDOS</a>]</span>).<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">This document describes an architectural framework for service and
      network management automation (<a href="#concept" class="xref">Section 3</a>) that takes advantage of YANG modeling technologies
      and investigates how YANG data models at different layers interact with
      each other (e.g., Service Mapping, model composition) in the context of
      service delivery and fulfillment (<a href="#compo" class="xref">Section 4</a>). Concretely, the following benefits can be provided:<a href="#section-1-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-9.1">Vendor-agnostic interfaces managing a service and the
          underlying network are allowed.<a href="#section-1-9.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-9.2">Movement from deployment schemes where vendor-specific network
          managers are required to a scheme where the entities that are
          responsible for orchestrating and controlling services and network
          resources provided by multi-vendor devices are unified is allowed.<a href="#section-1-9.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-9.3">Data inheritance and reusability among the various
          architecture layers thus promoting a network-wise provisioning
          instead of device-specific configuration is eased.<a href="#section-1-9.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-9.4">Dynamically feeding a decision-making process (e.g., Controllers,
          Orchestrators) with notifications that will trigger appropriate
          actions, allowing that decision-making process to continuously
          adjust a network (and thus the involved resources) to deliver the
          service that conforms to the intended parameters (service
          objectives) is allowed.<a href="#section-1-9.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-10">This framework is drawn from a network operator perspective
      irrespective of the origin of a data model; it can also accommodate YANG
      modules that are developed outside the IETF. The document covers service
      models that are used by an operator to expose its services and capture
      service requirements from the customers (including other operators).
      Nevertheless, the document does not elaborate on the communication
      protocol(s) that makes use of these service models in order to request
      and deliver a service. Such considerations are out of scope.<a href="#section-1-10" class="pilcrow">¶</a></p>
<p id="section-1-11">The document identifies a list of use cases to exemplify the proposed
      approach (<a href="#examples" class="xref">Section 5</a>), but it does not claim nor
      aim to be exhaustive. <a href="#app" class="xref">Appendix A</a> lists some examples to
      illustrate the layered YANG modules view.<a href="#section-1-11" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-2">
      <h2 id="name-terminology-and-abbreviatio">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology-and-abbreviatio" class="section-name selfRef">Terminology and Abbreviations</a>
      </h2>
<p id="section-2-1"></p>
<section id="section-2.1">
        <h3 id="name-terminology">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-2.1-1">The following terms are defined in <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span> and <span>[<a href="#RFC8199" class="xref">RFC8199</a>]</span> and are
        not redefined here:<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1-2.1">Network Operator<a href="#section-2.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.2">Customer<a href="#section-2.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.3">Service<a href="#section-2.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.4">Data Model<a href="#section-2.1-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.5">Service Model<a href="#section-2.1-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-2.1-2.6">Network Element Model<a href="#section-2.1-2.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.1-3">In addition, the document makes use of the following terms:<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.1-4">
          <dt id="section-2.1-4.1">Network Model:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.2">
            <p id="section-2.1-4.2.1">Describes a network-level abstraction
            (or a subset of aspects of a network infrastructure), including
            devices and their subsystems, and relevant protocols operating at
            the link and network layers across multiple devices. This model
            corresponds to the network configuration model discussed in <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span>.<a href="#section-2.1-4.2.1" class="pilcrow">¶</a></p>
<p id="section-2.1-4.2.2">It can be used
            by a network operator to allocate resources (e.g., tunnel
            resource, topology resource) for the service or schedule resources
            to meet the service requirements defined in a service model.<a href="#section-2.1-4.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-4.3">Network Domain:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.4">Refers to a network partitioning
            that is usually followed by network operators to delimit parts of
            their network. "access network" and "core network" are examples of
            network domains.<a href="#section-2.1-4.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-4.5">Device Model:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.6">
            <p id="section-2.1-4.6.1">Refers to the Network Element YANG
            data model described in <span>[<a href="#RFC8199" class="xref">RFC8199</a>]</span> or the
            device configuration model discussed in <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span>.<a href="#section-2.1-4.6.1" class="pilcrow">¶</a></p>
<p id="section-2.1-4.6.2">Device models
            are also used to refer to model a function embedded in a device
            (e.g., Network Address Translation (NAT) <span>[<a href="#RFC8512" class="xref">RFC8512</a>]</span>, Access Control Lists (ACLs) <span>[<a href="#RFC8519" class="xref">RFC8519</a>]</span>).<a href="#section-2.1-4.6.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-4.7">Pipe:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.8">Refers to a communication scope where only
            one-to-one (1:1) communications are allowed. The scope can be
            identified between ingress and egress nodes, two service sites,
            etc.<a href="#section-2.1-4.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-4.9">Hose:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.10">Refers to a communication scope where
            one-to-many (1:N) communications are allowed (e.g., one site to
            multiple sites).<a href="#section-2.1-4.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-4.11">Funnel:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.12">Refers to a communication scope where
            many-to-one (N:1) communications are allowed.<a href="#section-2.1-4.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-2.2">
        <h3 id="name-abbreviations">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-abbreviations" class="section-name selfRef">Abbreviations</a>
        </h3>
<p id="section-2.2-1">The following abbreviations are used in the document:<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-2.2-2">
          <dt id="section-2.2-2.1">ACL</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.2">Access Control List<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.3">AS</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.4">Autonomous System<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.5">AP</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.6">Access Point<a href="#section-2.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.7">CE</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.8">Customer Edge<a href="#section-2.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.9">DBE</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.10">Data Border Element<a href="#section-2.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.11">E2E</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.12">End-to-End<a href="#section-2.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.13">ECA</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.14">Event Condition Action<a href="#section-2.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.15">L2VPN</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.16">Layer 2 Virtual Private Network<a href="#section-2.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.17">L3VPN</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.18">Layer 3 Virtual Private Network<a href="#section-2.2-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.19">L3SM</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.20">L3VPN Service Model<a href="#section-2.2-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.21">L3NM</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.22">L3VPN Network Model<a href="#section-2.2-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.23">NAT</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.24">Network Address Translation<a href="#section-2.2-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.25">OAM</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.26">Operations, Administration, and Maintenance<a href="#section-2.2-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.27">OWD</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.28">One-Way Delay<a href="#section-2.2-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.29">PE</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.30">Provider Edge<a href="#section-2.2-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.31">PM</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.32">Performance Monitoring<a href="#section-2.2-2.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.33">QoS</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.34">Quality of Service<a href="#section-2.2-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.35">RD</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.36">Route Distinguisher<a href="#section-2.2-2.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.37">RT</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.38">Route Target<a href="#section-2.2-2.38" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.39">SBE</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.40">Session Border Element<a href="#section-2.2-2.40" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.41">SDN</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.42">Software-Defined Networking<a href="#section-2.2-2.42" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.43">SP</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.44">Service Provider<a href="#section-2.2-2.44" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.45">TE</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.46">Traffic Engineering<a href="#section-2.2-2.46" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.47">VN</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.48">Virtual Network<a href="#section-2.2-2.48" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.49">VPN</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.50">Virtual Private Network<a href="#section-2.2-2.50" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.51">VRF</dt>
          <dd style="margin-left: 4.0em" id="section-2.2-2.52">Virtual Routing and Forwarding<a href="#section-2.2-2.52" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-2.2-3"></p>
</section>
</section>
<div id="concept">
<section id="section-3">
      <h2 id="name-architectural-concepts-and-">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-architectural-concepts-and-" class="section-name selfRef">Architectural Concepts and Goals</a>
      </h2>
<div id="lay">
<section id="section-3.1">
        <h3 id="name-data-models-layering-and-re">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-data-models-layering-and-re" class="section-name selfRef">Data Models: Layering and Representation</a>
        </h3>
<p id="section-3.1-1">As described in <span><a href="https://www.rfc-editor.org/rfc/rfc8199#section-2" class="relref">Section 2</a> of [<a href="#RFC8199" class="xref">RFC8199</a>]</span>,
        layering of modules allows for better reusability of lower-layer
        modules by higher-level modules while limiting duplication of features
        across layers.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">Data models in the context of network management can be classified
        into service, network, and device models. Different service models may
        rely on the same set of network and/or device models.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">Service models traditionally follow a top-down approach and are
        mostly customer-facing YANG modules providing a common model construct
        for higher-level network services (e.g., Layer 3 Virtual Private
        Network (L3VPN)). Such modules can be mapped to network
        technology-specific modules at lower layers (e.g., tunnel, routing,
        Quality of Service (QoS), security). For example, service models can
        be used to characterize the network service(s) to be ensured between
        service nodes (ingress/egress) such as:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<ul class="compact">
<li class="compact" id="section-3.1-4.1">the communication scope (pipe, hose, funnel, etc.),<a href="#section-3.1-4.1" class="pilcrow">¶</a>
</li>
          <li class="compact" id="section-3.1-4.2">the directionality (inbound/outbound),<a href="#section-3.1-4.2" class="pilcrow">¶</a>
</li>
          <li class="compact" id="section-3.1-4.3">the traffic performance guarantees expressed using metrics such
            as One-Way Delay (OWD) <span>[<a href="#RFC7679" class="xref">RFC7679</a>]</span> or One-Way
            Loss <span>[<a href="#RFC7680" class="xref">RFC7680</a>]</span>; a summary of performance
            metrics maintained by IANA can be found in <span>[<a href="#IPPM" class="xref">IPPM</a>]</span>,<a href="#section-3.1-4.3" class="pilcrow">¶</a>
</li>
          <li class="compact" id="section-3.1-4.4">link capacity <span>[<a href="#RFC5136" class="xref">RFC5136</a>]</span> <span>[<a href="#I-D.ietf-ippm-capacity-metric-method" class="xref">METRIC-METHOD</a>]</span>,<a href="#section-3.1-4.4" class="pilcrow">¶</a>
</li>
          <li class="compact" id="section-3.1-4.5">etc.<a href="#section-3.1-4.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.1-5"><a href="#service_ex" class="xref">Figure 1</a> depicts the example of
        a Voice over IP (VoIP) service that relies upon connectivity services
        offered by a network operator. In this example, the VoIP service is
        offered to the network operator's customers by Service Provider 1
        (SP1). In order to provide global VoIP reachability, SP1 Service Site
        interconnects with other Service Providers service sites typically by
        interconnecting Session Border Elements (SBEs) and Data Border
        Elements (DBEs) <span>[<a href="#RFC5486" class="xref">RFC5486</a>]</span><span>[<a href="#RFC6406" class="xref">RFC6406</a>]</span>. For other VoIP destinations,
        sessions are forwarded over the Internet. These connectivity services
        can be captured in a YANG service model that reflects the service
        attributes that are shown in <a href="#service_ex2" class="xref">Figure 2</a>. This example follows
        the IP Connectivity Provisioning Profile template defined in <span>[<a href="#RFC7297" class="xref">RFC7297</a>]</span>.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<span id="name-an-example-of-service-conne"></span><div id="service_ex">
<figure id="figure-1">
          <div class="artwork art-text alignCenter" id="section-3.1-6.1">
<pre>           ,--,--,--.              ,--,--,--.
        ,-'    SP1   `-.        ,-'   SP2     `-.
       ( Service Site   )      ( Service Site    )
        `-.          ,-'        `-.          ,-'
           `--'--'--'              `--'--'--'
            x  | o *                  * |
         (2)x  | o *                  * |
           ,x-,--o-*-.    (1)     ,--,*-,--.
        ,-' x    o  * * * * * * * * *       `-.
       (    x    o       +----(     Internet    )
User---(x x x      o o o o o o o o o o o o o o o o o o
        `-.          ,-'       `-.          ,-'   (3)
           `--'--'--'             `--'--'--'
        Network Operator

**** (1) Inter-SP connectivity
xxxx (2) Customer-to-SP connectivity
oooo (3) SP to any destination connectivity
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-an-example-of-service-conne" class="selfRef">An Example of Service Connectivity Components</a>
          </figcaption></figure>
</div>
<p id="section-3.1-7">In reference to <a href="#service_ex2" class="xref">Figure 2</a>, "Full traffic
        performance guarantees class" refers to a service class where all
        traffic performance metrics included in the service model (OWD, loss,
        delay variation) are guaranteed, while "Delay traffic performance
        guarantees class" refers to a service class where only OWD is
        guaranteed.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<span id="name-sample-attributes-captured-"></span><div id="service_ex2">
<figure id="figure-2">
          <div id="section-3.1-8.1">
<pre class="sourcecode">
Connectivity: Scope and Guarantees
   (1) Inter-SP connectivity
      - Pipe scope from the local to the remote SBE/DBE
      - Full traffic performance guarantees class
   (2) Customer-to-SP connectivity
      - Hose/Funnel scope connecting the local SBE/DBE
        to the customer access points
      - Full traffic performance guarantees class
   (3) SP to any destination connectivity
      - Hose/Funnel scope from the local SBE/DBE to the
        Internet gateway
      - Delay traffic performance guarantees class
Flow Identification
   * Destination IP address (SBE, DBE)
   * DSCP marking
Traffic Isolation
   * VPN
Routing &amp; Forwarding
   * Routing rule to exclude some ASes from the inter-domain
     paths
Notifications (including feedback)
   * Statistics on aggregate traffic to adjust capacity
   * Failures
   * Planned maintenance operations
   * Triggered by thresholds
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-sample-attributes-captured-" class="selfRef">Sample Attributes Captured in a Service Model</a>
          </figcaption></figure>
</div>
<p id="section-3.1-9">Network models are mainly network-resource-facing modules; they
        describe various aspects of a network infrastructure, including
        devices and their subsystems, and relevant protocols operating at the
        link and network layers across multiple devices (e.g., network
        topology and traffic-engineering tunnel modules).<a href="#section-3.1-9" class="pilcrow">¶</a></p>
<p id="section-3.1-10">Device (and function) models usually follow a bottom-up approach
        and are mostly technology-specific modules used to realize a service
        (e.g., BGP, ACL).<a href="#section-3.1-10" class="pilcrow">¶</a></p>
<p id="section-3.1-11">Each level maintains a view of the supported YANG modules provided
        by lower levels (see for example, <a href="#app" class="xref">Appendix A</a>).  Mechanisms such as the YANG library <span>[<a href="#RFC8525" class="xref">RFC8525</a>]</span> can be used to expose which YANG
        modules are supported by nodes in lower levels.<a href="#section-3.1-11" class="pilcrow">¶</a></p>
<p id="section-3.1-12"><a href="#layering" class="xref">Figure 3</a> illustrates the overall
        layering model. The reader may refer to <span><a href="https://www.rfc-editor.org/rfc/rfc8309#section-4" class="relref">Section 4</a> of [<a href="#RFC8309" class="xref">RFC8309</a>]</span> for an overview of "Orchestrator" and
        "Controller" elements. All these elements (i.e., Orchestrator(s),
        Controller(s), device(s)) are under the responsibility of the same
        operator.<a href="#section-3.1-12" class="pilcrow">¶</a></p>
<span id="name-layering-and-representation"></span><div id="layering">
<figure id="figure-3">
          <div class="artwork art-text alignCenter" id="section-3.1-13.1">
<pre>
+-----------------------------------------------------------------+
|                                         Hierarchy Abstraction   |
|                                                                 |
| +-----------------------+                    Service Model      |
| |    Orchestrator       |                 (Customer Oriented)   |
| |+---------------------+|               Scope: "1:1" Pipe model |
| ||  Service Modeling   ||                                       |
| |+---------------------+|                                       |
| |                       |                   Bidirectional       |
| |+---------------------+|              +-+  Capacity, OWD +-+   |
| ||Service Orchestration||              | +----------------+ |   |
| |+---------------------+|              +-+                +-+   |
| +-----------------------+            Ingress             Egress |
|                                                                 |
|                                                                 |
| +-----------------------+                Network Model          |
| |   Controller          |             (Operator Oriented)       |
| |+---------------------+|           +-+    +--+    +---+   +-+  |
| || Network Modeling    ||           | |    |  |    |   |   | |  |
| |+---------------------+|           | o----o--o----o---o---o |  |
| |                       |           +-+    +--+    +---+   +-+  |
| |+---------------------+|           src                    dst  |
| ||Network Orchestration||                L3VPN over TE          |
| |+---------------------+|        Instance Name/Access Interface |
| +-----------------------+      Protocol Type/Capacity/RD/RT/... |
|                                                                 |
|                                                                 |
| +-----------------------+                 Device Model          |
| |    Device             |                                       |
| |+--------------------+ |                                       |
| || Device Modeling    | |           Interface add, BGP Peer,    |
| |+--------------------+ |              Tunnel ID, QoS/TE, ...   |
| +-----------------------+                                       |
+-----------------------------------------------------------------+</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-layering-and-representation" class="selfRef">Layering and Representation within a Network Operator</a>
          </figcaption></figure>
</div>
<p id="section-3.1-14"></p>
<p id="section-3.1-15">A composite service offered by a network operator may rely on
        services from other operators. In such a case, the network operator acts
        as a customer to request services from other networks. The operators
        providing these services will then follow the layering depicted in
        <a href="#layering" class="xref">Figure 3</a>. The mapping between a
        composite service and a third-party service is maintained at the
        orchestration level. From a data-plane perspective, appropriate
        traffic steering policies (e.g., Service Function Chaining <span>[<a href="#RFC7665" class="xref">RFC7665</a>]</span>) are managed by the network
        controllers to guide how/when a third-party service is invoked for
        flows bound to a composite service.<a href="#section-3.1-15" class="pilcrow">¶</a></p>
<p id="section-3.1-16">The layering model depicted in <a href="#layering" class="xref">Figure 3</a> does
        not make any assumption about the location of the various entities
        (e.g., Controller, Orchestrator) within the network. As such, the
        architecture does not preclude deployments where, for example, the
        Controller is embedded on a device that hosts other functions that are
        controlled via YANG modules.<a href="#section-3.1-16" class="pilcrow">¶</a></p>
<p id="section-3.1-17">In order to ease the mapping between layers and data reuse, this
        document focuses on service models that are modeled using YANG.
        Nevertheless, fully compliant with <span><a href="https://www.rfc-editor.org/rfc/rfc8309#section-3" class="relref">Section 3</a> of [<a href="#RFC8309" class="xref">RFC8309</a>]</span>, <a href="#layering" class="xref">Figure 3</a> does not preclude service models to be modeled
        using data modeling languages other than YANG.<a href="#section-3.1-17" class="pilcrow">¶</a></p>
</section>
</div>
<div id="del">
<section id="section-3.2">
        <h3 id="name-automation-of-service-deliv">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-automation-of-service-deliv" class="section-name selfRef">Automation of Service Delivery Procedures</a>
        </h3>
<p id="section-3.2-1">Service models can be used by a network operator to expose its
        services to its customers. Exposing such models allows automation of the
        activation of service orders and thus the service delivery. One or
        more monolithic service models can be used in the context of a
        composite service activation request (e.g., delivery of a caching
        infrastructure over a VPN). Such models are used to feed a
        decision-making intelligence to adequately accommodate customer        needs.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">Also, such models may be used jointly with services that require
        dynamic invocation. An example is provided by the service modules
        defined by the DOTS WG to dynamically trigger requests to handle
        Distributed Denial-of-Service (DDoS) attacks <span>[<a href="#RFC8783" class="xref">RFC8783</a>]</span>. The service filtering request modeled using <span>[<a href="#RFC8783" class="xref">RFC8783</a>]</span> will be translated into
        device-specific filtering (e.g., ACLs defined in <span>[<a href="#RFC8519" class="xref">RFC8519</a>]</span>) that fulfills the service
        request.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">
 Network models can be derived from service models and used to provision,
 monitor, and instantiate the service. Also, they are used to provide
 life-cycle management of network resources.  Doing so is meant to:<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-4.1">expose network resources to customers (including other network
            operators) to provide service fulfillment and assurance.<a href="#section-3.2-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-4.2">allow customers (or network operators) to dynamically adjust the
          network resources based on service requirements as described in
          service models (e.g., <a href="#service_ex2" class="xref">Figure 2</a>) and the
          current network performance information described in the telemetry
          modules.<a href="#section-3.2-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.2-5">Note that it is out of the scope of this document to elaborate on
        the communication protocols that are used to implement the interface
        between the service ordering (customer) and service order handling
        (provider).<a href="#section-3.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ful">
<section id="section-3.3">
        <h3 id="name-service-fulfillment-automat">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-service-fulfillment-automat" class="section-name selfRef">Service Fulfillment Automation</a>
        </h3>
<p id="section-3.3-1">To operate a service, the settings of the parameters in the device
        models are derived from service models and/or network models and are
        used to:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-2.1">Provision each involved network function/device with the proper
            configuration information.<a href="#section-3.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.2">Operate the network based on service requirements as described
            in the service model(s) and local operational guidelines.<a href="#section-3.3-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-3">In addition, the operational state including configuration that is
        in effect together with statistics should be exposed to upper layers
        to provide better network visibility and assess to what extent the
        derived low-level modules are consistent with the upper-level
        inputs.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3-4">Filters are enforced on the notifications that are communicated to
        Service layers. The type and frequency of notifications may be agreed
        upon in the service model.<a href="#section-3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3-5">Note that it is important to correlate telemetry data with
        configuration data to be used for closed loops at the different stages
        of service delivery, from resource allocation to service operation, in
        particular.<a href="#section-3.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="int">
<section id="section-3.4">
        <h3 id="name-yang-module-integration">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-yang-module-integration" class="section-name selfRef">YANG Module Integration</a>
        </h3>
<p id="section-3.4-1">To support top-down service delivery, YANG modules at different
        levels or at the same level need to be integrated for proper
        service delivery (including proper network setup). For example, the
        service parameters captured in service models need to be decomposed
        into a set of configuration/notification parameters that may be
        specific to one or more technologies; these technology-specific
        parameters are grouped together to define technology-specific
        device-level models or network-level models.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">In addition, these technology-specific device or network models can
        be further integrated with each other using the schema mount mechanism
        <span>[<a href="#RFC8528" class="xref">RFC8528</a>]</span> to provision each involved network
        function/device or each involved network domain to support newly added
        modules or features. A collection of integrated device models 
        can be loaded and validated during implementation.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">High-level policies can be defined at service or network models
        (e.g., "Autonomous System Number (ASN) Exclude" in the example
        depicted in <a href="#service_ex2" class="xref">Figure 2</a>). Device models will be tweaked accordingly
        to provide policy-based management. Policies can also be used for
        telemetry automation, e.g., policies that contain conditions to
        trigger the generation and pushing of new telemetry data.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="compo">
<section id="section-4">
      <h2 id="name-functional-blocks-and-inter">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-functional-blocks-and-inter" class="section-name selfRef">Functional Blocks and Interactions</a>
      </h2>
<p id="section-4-1">The architectural considerations described in <a href="#concept" class="xref">Section 3</a> lead to the life-cycle management architecture
      illustrated in <a href="#arc" class="xref">Figure 4</a> and described in the following
      subsections.<a href="#section-4-1" class="pilcrow">¶</a></p>
<span id="name-service-and-network-life-cy"></span><div id="arc">
<figure id="figure-4">
        <div class="artwork art-text alignCenter" id="section-4-2.1">
<pre>

                +------------------+
............... |                  |
 Service level  |                  |
                V                  |
  E2E          E2E                E2E                    E2E
Service --&gt; Service ---------&gt;  Service  ------------&gt;  Service
Exposure    Creation     ^    Optimization   ^          Diagnosis
           /Modification |                   |              |
              ^ |        |Diff               |              |
    E2E       | |        |         E2E       |              |
  Service ----+ |        |        Service    |              |
 Decommission   |        +------ Assurance --+              |
                |                     ^                     |
 Multi-layer    |                     |                     |
 Multi-domain   |                     |                     |
 Service Mapping|                     |                     |
............... |&lt;-----------------+  |                     |
 Network level  |                  |  +-------+             v
                V                  |          |         Specific
            Specific           Specific       |          Service
            Service  --------&gt;  Service &lt;--+  |         Diagnosis
            Creation     ^    Optimization |  |             |
          /Modification  |                 |  |             |
                |        |Diff             |  |             |
                |        |      Specific --+  |             |
       Service  |        |       Service      |             |
  Decomposition |        +----- Assurance ----+             |
                |                  ^                        |
............... |                  |  Aggregation           |
 Device level   |                  +------------+           |
                V                               |           |
Service      Intent                             |           v
Fulfillment  Config  ----&gt; Config  ----&gt; Performance ----&gt; Fault
             Provision     Validation    Monitoring        Diagnostic
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-service-and-network-life-cy" class="selfRef">Service and Network Life-Cycle Management</a>
        </figcaption></figure>
</div>
<div id="details">
<section id="section-4.1">
        <h3 id="name-service-life-cycle-manageme">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-service-life-cycle-manageme" class="section-name selfRef">Service Life-Cycle Management Procedure</a>
        </h3>
<p id="section-4.1-1">Service life-cycle management includes end-to-end service life-cycle
        management at the service level and technology-specific network
        life-cycle management at the network level.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">The end-to-end service life-cycle management is
        technology-independent service management and spans across multiple
        network domains and/or multiple layers while technology-specific
        service life-cycle management is technology domain-specific or
        layer-specific service life-cycle management.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<div id="expo">
<section id="section-4.1.1">
          <h4 id="name-service-exposure">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-service-exposure" class="section-name selfRef">Service Exposure</a>
          </h4>
<p id="section-4.1.1-1">A service in the context of this document (sometimes called
          "Network Service") is some form of connectivity between customer sites
          and the Internet or between customer sites across the operator's
          network and across the Internet.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1.1-2">Service exposure is used to capture services offered to customers
          (ordering and order handling). One example is that a customer can
          use an L3VPN Service Model (L3SM) to request L3VPN service by
          providing the abstract technical characterization of the intended
          service between customer sites.<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1.1-3">Service model catalogs can be created to expose the various
          services and the information needed to invoke/order a given
          service.<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="crea">
<section id="section-4.1.2">
          <h4 id="name-service-creation-modificati">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-service-creation-modificati" class="section-name selfRef">Service Creation/Modification</a>
          </h4>
<p id="section-4.1.2-1">A customer is usually unaware of the technology that the network
          operator has available to deliver the service, so the customer does
          not make requests specific to the underlying technology but is
          limited to making requests specific to the service that is to be
          delivered. This service request can be filled using a service
          model.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<p id="section-4.1.2-2">Upon receiving a service request, and assuming that appropriate
          authentication and authorization checks have been made with success,
          the service Orchestrator/management system should verify whether the
          service requirements in the service request can be met (i.e.,
          whether there are sufficient resources that can be allocated with
          the requested guarantees).<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
<p id="section-4.1.2-3">If the request is accepted, the service Orchestrator/management
          system maps such a service request to its view. This view can be
          described as a technology-specific network model or a set of
          technology-specific device models, and this mapping may include a
          choice of which networks and technologies to use depending on which
          service features have been requested.<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
<p id="section-4.1.2-4">In addition, a customer may require a change in the underlying
          network infrastructure to adapt to new customers' needs and service
          requirements (e.g., service a new customer site, add a new access
          link, or provide disjoint paths). This service modification can be
          issued following the same service model used by the service
          request.<a href="#section-4.1.2-4" class="pilcrow">¶</a></p>
<p id="section-4.1.2-5">Withdrawing a service is discussed in <a href="#decom" class="xref">Section 4.1.6</a>.<a href="#section-4.1.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.1.3">
          <h4 id="name-service-assurance">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-service-assurance" class="section-name selfRef">Service Assurance</a>
          </h4>
<p id="section-4.1.3-1">The performance measurement telemetry (<a href="#tele" class="xref">Section 4.2.3</a>) can be used to provide service assurance at
          service and/or network levels. The performance measurement telemetry
          model can tie with service or network models to monitor network
          performance or Service Level Agreements.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
</section>
<div id="optim">
<section id="section-4.1.4">
          <h4 id="name-service-optimization">
<a href="#section-4.1.4" class="section-number selfRef">4.1.4. </a><a href="#name-service-optimization" class="section-name selfRef">Service Optimization</a>
          </h4>
<p id="section-4.1.4-1">Service optimization is a technique that gets the configuration
          of the network updated due to network changes, incident mitigation,
          or new service requirements. One example is once a tunnel or a VPN
          is set up, performance monitoring information or telemetry
          information per tunnel (or per VPN) can be collected and fed into
          the management system. If the network performance doesn't meet the
          service requirements, the management system can create new VPN
          policies capturing network service requirements and populate them
          into the network.<a href="#section-4.1.4-1" class="pilcrow">¶</a></p>
<p id="section-4.1.4-2">Both network performance information and policies can be modeled
          using YANG. With Policy-based management, self-configuration and
          self-optimization behavior can be specified and implemented.<a href="#section-4.1.4-2" class="pilcrow">¶</a></p>
<p id="section-4.1.4-3">The overall service optimization is managed at the service level,
          while the network level is responsible for the optimization of the
          specific network services it provides.<a href="#section-4.1.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="diag">
<section id="section-4.1.5">
          <h4 id="name-service-diagnosis">
<a href="#section-4.1.5" class="section-number selfRef">4.1.5. </a><a href="#name-service-diagnosis" class="section-name selfRef">Service Diagnosis</a>
          </h4>
<p id="section-4.1.5-1">Operations, Administration, and Maintenance (OAM) are important
          networking functions for service diagnosis that allow network
          operators to:<a href="#section-4.1.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1.5-2.1">monitor network communications (i.e., reachability
              verification and Continuity Check)<a href="#section-4.1.5-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.1.5-2.2">troubleshoot failures (i.e., fault verification and
              localization)<a href="#section-4.1.5-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.1.5-2.3">monitor service level agreements and performance (i.e.,
              performance management)<a href="#section-4.1.5-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.1.5-3">When the network is down, service diagnosis should be in place to
          pinpoint the problem and provide recommendations (or instructions)
          for network recovery.<a href="#section-4.1.5-3" class="pilcrow">¶</a></p>
<p id="section-4.1.5-4">The service diagnosis information can be modeled as
          technology-independent Remote Procedure Call (RPC) operations for
          OAM protocols and technology-independent abstraction of key OAM
          constructs for OAM protocols <span>[<a href="#RFC8531" class="xref">RFC8531</a>]</span><span>[<a href="#RFC8533" class="xref">RFC8533</a>]</span>. These models can be used to provide
          consistent configuration, reporting, and presentation for the OAM
          mechanisms used to manage the network.<a href="#section-4.1.5-4" class="pilcrow">¶</a></p>
<p id="section-4.1.5-5">Refer to <a href="#dev-diag" class="xref">Section 4.2.4</a> for the device-specific
          side.<a href="#section-4.1.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="decom">
<section id="section-4.1.6">
          <h4 id="name-service-decommission">
<a href="#section-4.1.6" class="section-number selfRef">4.1.6. </a><a href="#name-service-decommission" class="section-name selfRef">Service Decommission</a>
          </h4>
<p id="section-4.1.6-1">Service decommission allows a customer to stop the service by
          removing the service from active status, thus releasing the
          network resources that were allocated to the service. Customers can
          also use the service model to withdraw the subscription to a
          service.<a href="#section-4.1.6-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="fulm">
<section id="section-4.2">
        <h3 id="name-service-fulfillment-managem">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-service-fulfillment-managem" class="section-name selfRef">Service Fulfillment Management Procedure</a>
        </h3>
<div id="intended">
<section id="section-4.2.1">
          <h4 id="name-intended-configuration-prov">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-intended-configuration-prov" class="section-name selfRef">Intended Configuration Provision</a>
          </h4>
<p id="section-4.2.1-1">Intended configuration at the device level is derived from
          network models at the network level or service models at the service
          level and represents the configuration that the system attempts to
          apply. Take L3SM as a service model example to deliver an L3VPN
          service; there is a need to map the L3VPN service view defined in
          the service model into a detailed intended configuration view
          defined by specific configuration models for network elements. The
          configuration information includes:<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2.1-2.1">Virtual Routing and Forwarding (VRF) definition, including
              VPN policy expression<a href="#section-4.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.2">Physical Interface(s)<a href="#section-4.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.3">IP layer (IPv4, IPv6)<a href="#section-4.2.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.4">QoS features such as classification, profiles, etc.<a href="#section-4.2.1-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.5">Routing protocols: support of configuration of all protocols
              listed in a service request, as well as routing policies
              associated with those protocols<a href="#section-4.2.1-2.5" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.6">Multicast support<a href="#section-4.2.1-2.6" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.7">Address sharing<a href="#section-4.2.1-2.7" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.8">Security (e.g., access control, authentication,
              encryption)<a href="#section-4.2.1-2.8" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.2.1-3">These specific configuration models can be used to configure
          Provider Edge (PE) and Customer Edge (CE) devices within a site,
          e.g., a BGP policy model can be used to establish VPN membership
          between sites and VPN service topology.<a href="#section-4.2.1-3" class="pilcrow">¶</a></p>
<p id="section-4.2.1-4">Note that in networks with legacy devices (that support
          proprietary modules or do not support YANG at all), an adaptation
          layer is likely to be required at the network level so that these
          devices can be involved in the delivery of the network services.<a href="#section-4.2.1-4" class="pilcrow">¶</a></p>
<p id="section-4.2.1-5">This interface is also used to handle service withdrawal (<a href="#decom" class="xref">Section 4.1.6</a>).<a href="#section-4.2.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.2.2">
          <h4 id="name-configuration-validation">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-configuration-validation" class="section-name selfRef">Configuration Validation</a>
          </h4>
<p id="section-4.2.2-1">Configuration validation is used to validate intended
          configuration and ensure the configuration takes effect.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2.2-2">For example, if a customer creates an interface "eth-0/0/0" but
          the interface does not physically exist at this point, then
          configuration data appears in the &lt;intended&gt; status but does
          not appear in the &lt;operational&gt; datastore. More details about
          &lt;intended&gt; and &lt;operational&gt; datastores can be found in
          <span><a href="https://www.rfc-editor.org/rfc/rfc8342#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC8342" class="xref">RFC8342</a>]</span>.<a href="#section-4.2.2-2" class="pilcrow">¶</a></p>
</section>
<div id="tele">
<section id="section-4.2.3">
          <h4 id="name-performance-monitoring">
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-performance-monitoring" class="section-name selfRef">Performance Monitoring</a>
          </h4>
<p id="section-4.2.3-1">When a configuration is in
          effect in a device, the &lt;operational&gt; datastore holds the
          complete operational state of the device, including learned, system,
          default configuration, and system state. However, the configurations
          and state of a particular device do not have visibility on the
          whole network, nor can they show how packets are going to be
          forwarded through the entire network.  Therefore, it becomes more
          difficult to operate the entire network without understanding the
          current status of the network.<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
<p id="section-4.2.3-2">The management system should subscribe to updates of a YANG
          datastore in all the network devices for performance monitoring
          purposes and build a full topological visibility of the network by
          aggregating (and filtering) these operational states from different
          sources.<a href="#section-4.2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dev-diag">
<section id="section-4.2.4">
          <h4 id="name-fault-diagnostic">
<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-fault-diagnostic" class="section-name selfRef">Fault Diagnostic</a>
          </h4>
<p id="section-4.2.4-1">When configuration is in effect in a device, some devices may be
          misconfigured (e.g., device links are not consistent in both sides
          of the network connection) or network resources might be
          misallocated. Therefore, services may be negatively affected
          without knowing the root cause in the network.<a href="#section-4.2.4-1" class="pilcrow">¶</a></p>
<p id="section-4.2.4-2">Technology-dependent nodes and RPC commands are defined in
          technology-specific YANG data models, which can use and extend the
          base model described in <a href="#diag" class="xref">Section 4.1.5</a> to deal with
          these issues.<a href="#section-4.2.4-2" class="pilcrow">¶</a></p>
<p id="section-4.2.4-3">These RPC commands received in the technology-dependent node can
          be used to trigger technology-specific OAM message exchanges for
          fault verification and fault isolation. 



For example, Transparent Interconnection of Lots of Links (TRILL)
Multi-destination Tree Verification (MTV) RPC command <span>[<a href="#I-D.ietf-trill-yang-oam" class="xref">TRILL-YANG-OAM</a>]</span> can be used to trigger
Multi-Destination Tree Verification Messages (MTVMs) defined in <span>[<a href="#RFC7455" class="xref">RFC7455</a>]</span> to verify TRILL distribution tree
integrity.<a href="#section-4.2.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="inter">
<section id="section-4.3">
        <h3 id="name-multi-layer-multi-domain-se">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-multi-layer-multi-domain-se" class="section-name selfRef">Multi-layer/Multi-domain Service Mapping</a>
        </h3>
<p id="section-4.3-1">Multi-layer/Multi-domain Service Mapping allows the mapping of an
        end-to-end abstract view of the service segmented at different layers
        and/or different network domains into domain-specific views.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">One example is to map service parameters in the L3SM into
        configuration parameters such as Route Distinguisher (RD), Route
        Target (RT), and VRF in the L3VPN Network Model (L3NM).<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">Another example is to map service parameters in the L3SM into
        Traffic Engineered (TE) tunnel parameters (e.g., Tunnel ID) in TE
        model and Virtual Network (VN) parameters (e.g., Access Point (AP)
        list and VN members) in the YANG data model for VN operation <span>[<a href="#I-D.ietf-teas-actn-vn-yang" class="xref">ACTN-VN-YANG</a>]</span>.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dec">
<section id="section-4.4">
        <h3 id="name-service-decomposition">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-service-decomposition" class="section-name selfRef">Service Decomposition</a>
        </h3>
<p id="section-4.4-1">Service Decomposition allows to decompose service models at the
        service level or network models at the network level into a set of
        device models at the device level. These device models may be tied to
        specific device types or classified into a collection of related YANG
        modules based on service types and features offered, and they may load at the
        implementation time before configuration is loaded and validated.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="examples">
<section id="section-5">
      <h2 id="name-yang-data-model-integration">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-yang-data-model-integration" class="section-name selfRef">YANG Data Model Integration Examples</a>
      </h2>
<p id="section-5-1">The following subsections provide some YANG data model integration
      examples.<a href="#section-5-1" class="pilcrow">¶</a></p>
<section id="section-5.1">
        <h3 id="name-l2vpn-l3vpn-service-deliver">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-l2vpn-l3vpn-service-deliver" class="section-name selfRef">L2VPN/L3VPN Service Delivery</a>
        </h3>
<p id="section-5.1-1">In reference to <a href="#l3" class="xref">Figure 5</a>, the following steps are
        performed to deliver the L3VPN service within the network management
        automation architecture defined in <a href="#compo" class="xref">Section 4</a>:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.1-2">
<li id="section-5.1-2.1">
            <p id="section-5.1-2.1.1">The Customer requests to create two sites (as per Service
            Creation in <a href="#crea" class="xref">Section 4.1.2</a>) relying upon L3SM
            with each site having one network access connectivity, for
            example:<a href="#section-5.1-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-2.1.2.1">Site A: network-access A, link-capacity = 20 Mbps, class
                "foo", guaranteed-capacity-percent = 10, average-one-way-delay
                = 70 ms.<a href="#section-5.1-2.1.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-2.1.2.2">Site B: network-access B, link-capacity = 30 Mbps, class
                "foo1", guaranteed-capacity-percent = 15,
                average-one-way-delay = 60 ms.<a href="#section-5.1-2.1.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li id="section-5.1-2.2">The Orchestrator extracts the service parameters from the L3SM.
          Then, it uses them as input to the Service Mapping in <a href="#inter" class="xref">Section 4.3</a> to translate them into
          orchestrated configuration parameters (e.g., RD, RT, and VRF) that are
          part of the L3NM specified in <span>[<a href="#I-D.ietf-opsawg-l3sm-l3nm" class="xref">OPSAWG-L3SM-L3NM</a>]</span>.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-2.3">The Controller takes the orchestrated configuration parameters
            in the L3NM and translates them into an orchestrated (Service
            Decomposition in <a href="#dec" class="xref">Section 4.4</a>) configuration of
            network elements that are part of, e.g., BGP, QoS, Network
            Instance, IP management, and interface models.<a href="#section-5.1-2.3" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.1-3"><span>[<a href="#I-D.ogondio-opsawg-uni-topology" class="xref">UNI-TOPOLOGY</a>]</span> can be used
        for representing, managing, and controlling the User Network Interface
        (UNI) topology.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<span id="name-l3vpn-service-delivery-exam"></span><div id="l3">
<figure id="figure-5">
          <div class="artwork art-text alignCenter" id="section-5.1-4.1">
<pre>                  L3SM    |
                Service   |
                 Model    |
 +------------------------+------------------------+
 |               +--------V--------+               |
 |               | Service Mapping |               |
 |               +--------+--------+               |
 | Orchestrator           |                        |
 +------------------------+------------------------+
                  L3NM    |     ^ UNI Topology Model
                 Network  |     |
                  Model   |     |
 +------------------------+------------------------+
 |            +-----------V-----------+            |
 |            | Service Decomposition |            |
 |            +--++---------------++--+            |
 |               ||               ||               |
 | Controller    ||               ||               |
 +---------------++---------------++---------------+
                 ||               ||
                 ||     BGP,      ||
                 ||     QoS,      ||
                 ||   Interface,  ||
    +------------+|      NI,      |+------------+
    |             |      IP       |             |
 +--+--+       +--+--+         +--+--+       +--+--+
 | CE1 +-------+ PE1 |         | PE2 +-------+ CE2 |
 +-----+       +-----+         +-----+       +-----+</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-l3vpn-service-delivery-exam" class="selfRef">L3VPN Service Delivery Example (Current)</a>
          </figcaption></figure>
</div>
<p id="section-5.1-5">L3NM inherits some of the data elements from the L3SM. Nevertheless,
        the L3NM as designed in <span>[<a href="#I-D.ietf-opsawg-l3sm-l3nm" class="xref">OPSAWG-L3SM-L3NM</a>]</span> does not expose some
        information to the above layer such as the capabilities of an
        underlying network (which can be used to drive service order handling)
        or notifications (to notify subscribers about specific events or
        degradations as per agreed SLAs). Some of this information can be
        provided using, e.g., <span>[<a href="#I-D.www-opsawg-yang-vpn-service-pm" class="xref">OPSAWG-YANG-VPN</a>]</span>. A target overall
        model is depicted in <a href="#l3-target" class="xref">Figure 6</a>.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<span id="name-l3vpn-service-delivery-examp"></span><div id="l3-target">
<figure id="figure-6">
          <div class="artwork art-text alignCenter" id="section-5.1-6.1">
<pre>                  L3SM    |     ^
                Service   |     |  Notifications
                 Model    |     |
 +------------------------+------------------------+
 |               +--------V--------+               |
 |               | Service Mapping |               |
 |               +--------+--------+               |
 | Orchestrator           |                        |
 +------------------------+------------------------+
                    L3NM  |     ^ UNI Topology Model
                   Network|     | L3NM Notifications
                    Model |     | L3NM Capabilities
 +------------------------+------------------------+
 |            +-----------V-----------+            |
 |            | Service Decomposition |            |
 |            +--++---------------++--+            |
 |               ||               ||               |
 | Controller    ||               ||               |
 +---------------++---------------++---------------+
                 ||               ||
                 ||     BGP,      ||
                 ||     QoS,      ||
                 ||   Interface,  ||
    +------------+|      NI,      |+------------+
    |             |      IP       |             |
 +--+--+       +--+--+         +--+--+       +--+--+
 | CE1 +-------+ PE1 |         | PE2 +-------+ CE2 |
 +-----+       +-----+         +-----+       +-----+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-l3vpn-service-delivery-examp" class="selfRef">L3VPN Service Delivery Example (Target)</a>
          </figcaption></figure>
</div>
<p id="section-5.1-7">Note that a similar analysis can be performed for Layer 2 VPNs
        (L2VPNs). An L2VPN Service Model (L2SM) is defined in <span>[<a href="#RFC8466" class="xref">RFC8466</a>]</span>, while the YANG L2VPN Network
        Model (L2NM) is specified in <span>[<a href="#I-D.ietf-opsawg-l2nm" class="xref">OPSAWG-L2NM</a>]</span>.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-5.2">
        <h3 id="name-vn-life-cycle-management">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-vn-life-cycle-management" class="section-name selfRef">VN Life-Cycle Management</a>
        </h3>
<p id="section-5.2-1">In reference to <a href="#lc" class="xref">Figure 7</a>, the following steps are
        performed to deliver the VN service within the network management
        automation architecture defined in <a href="#compo" class="xref">Section 4</a>:<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.2-2">
<li id="section-5.2-2.1">A customer makes a request (Service
        Exposure in <a href="#expo" class="xref">Section 4.1.1</a>) to create a
        VN. The association between the VN, APs, and VN members is defined in
        the VN YANG model <span>[<a href="#I-D.ietf-teas-actn-vn-yang" class="xref">ACTN-VN-YANG</a>]</span>.<a href="#section-5.2-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-2.2">The Orchestrator creates the single abstract node topology based
          on the information captured in the request.<a href="#section-5.2-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-2.3">The customer exchanges with the Orchestrator the connectivity
          matrix on the abstract node topology and explicit paths using the TE
          topology model <span>[<a href="#RFC8795" class="xref">RFC8795</a>]</span>. This
          information can be used to instantiate the VN and set up tunnels
          between source and destination endpoints (Service Creation in <a href="#crea" class="xref">Section 4.1.2</a>).<a href="#section-5.2-2.3" class="pilcrow">¶</a>
</li>
          <li id="section-5.2-2.4">In order to provide service assurance (Service Optimization in
          <a href="#optim" class="xref">Section 4.1.4</a>), the telemetry model that
          augments the VN model and corresponding TE tunnel model can be used
          by the Orchestrator to subscribe to performance measurement
          data. The Controller will then notify the Orchestrator with all the
          parameter changes and network performance changes related to the VN
          topology and the tunnels <span>[<a href="#I-D.ietf-teas-actn-pm-telemetry-autonomics" class="xref">TEAS-ACTN-PM</a>]</span>.<a href="#section-5.2-2.4" class="pilcrow">¶</a>
</li>
        </ol>
<span id="name-a-vn-service-delivery-examp"></span><div id="lc">
<figure id="figure-7">
          <div class="artwork art-text alignCenter" id="section-5.2-3.1">
<pre>                        |
                VN      |
                Service |
                Model   |
 +----------------------|--------------------------+
 | Orchestrator         |                          |
 |             +--------V--------+                 |
 |             | Service Mapping |                 |
 |             +-----------------+                 |
 +----------------------+--------------------^-----+
               TE       |         Telemetry  |
               Tunnel   |         Model      |
               Model    |                    |
 +----------------------V--------------------+-----+
 | Controller                                      |
 |                                                 |
 +-------------------------------------------------+

 +-----+      +-----+           +-----+      +-----+
 | CE1 +------+ PE1 |           | PE2 +------+ CE2 |
 +-----+      +-----+           +-----+      +-----+</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-a-vn-service-delivery-examp" class="selfRef">A VN Service Delivery Example</a>
          </figcaption></figure>
</div>
</section>
<section id="section-5.3">
        <h3 id="name-event-based-telemetry-in-th">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-event-based-telemetry-in-th" class="section-name selfRef">Event-Based Telemetry in the Device Self Management</a>
        </h3>
<p id="section-5.3-1">In reference to <a href="#event" class="xref">Figure 8</a>, the
        following steps are performed to monitor state changes of managed
        resources in a network device and provide device self management
        within the network management automation architecture defined in <a href="#compo" class="xref">Section 4</a>:<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.3-2">
<li id="section-5.3-2.1">To control which state a network
        device should be in or is allowed to be in at any given time, a set of
        conditions and actions are defined and correlated with network events
        (e.g., allow the NETCONF server to send updates only when the value
        exceeds a certain threshold for the first time, but not again until
        the threshold is cleared), which constitute an Event Condition Action
        (ECA) policy or an event-driven policy control logic that can be
        executed on the device (e.g., <span>[<a href="#I-D.wwx-netmod-event-yang" class="xref">EVENT-YANG</a>]</span>).<a href="#section-5.3-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.3-2.2">To provide a rapid autonomic response that can exhibit
            self-management properties, the Controller pushes the ECA policy
            to the network device and delegates the network control logic to
            the network device.<a href="#section-5.3-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-5.3-2.3">The network device uses the ECA model to subscribe to the event
          source, e.g., an event stream or datastore state data conveyed to
          the server via YANG-Push subscription <span>[<a href="#RFC8641" class="xref">RFC8641</a>]</span>, monitors state parameters, and takes simple and
          instant actions when an associated event condition on state
          parameters is met. ECA notifications can be generated as the result
          of actions based on event stream subscription or datastore
          subscription (model-driven telemetry operation discussed in <a href="#tele" class="xref">Section 4.2.3</a>).<a href="#section-5.3-2.3" class="pilcrow">¶</a>
</li>
        </ol>
<span id="name-event-based-telemetry"></span><div id="event">
<figure id="figure-8">
          <div class="artwork art-text alignCenter" id="section-5.3-3.1">
<pre>     +----------------+
     |                &lt;----+
     |   Controller   |    |
     +-------+--------+    |
             |             |
             |             |
         ECA |             | ECA
       Model |             | Notification
             |             |
             |             |
+------------V-------------+-----+
|Device                    |     |
| +-------+ +---------+ +--+---+ |
| | Event +-&gt; Event   +-&gt;Event | |
| | Source| |Condition| |Action| |
| +-------+ +---------+ +------+ |
+--------------------------------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-event-based-telemetry" class="selfRef">Event-Based Telemetry</a>
          </figcaption></figure>
</div>
</section>
</section>
</div>
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">Many of the YANG modules cited in this document define schema for
      data that is designed to be accessed via network management protocols
      such as NETCONF <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span> or RESTCONF <span>[<a href="#RFC8040" class="xref">RFC8040</a>]</span>. The lowest NETCONF layer is the secure
      transport layer, and the mandatory-to-implement secure transport is
      Secure Shell (SSH) <span>[<a href="#RFC6242" class="xref">RFC6242</a>]</span>. The lowest RESTCONF
      layer is HTTPS, and the mandatory-to-implement secure transport is TLS
      <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">The NETCONF access control model <span>[<a href="#RFC8341" class="xref">RFC8341</a>]</span>
      provides the means to restrict access for particular NETCONF or RESTCONF
      users to a preconfigured subset of all available NETCONF or RESTCONF
      protocol operations and content.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Security considerations specific to each of the technologies and
      protocols listed in the document are discussed in the specification
      documents of each of these protocols.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">In order to prevent leaking sensitive information and the "confused
      deputy" problem <span>[<a href="#Hardy" class="xref">Hardy</a>]</span> in general, special care
      should be considered when translating between the various layers in
      <a href="#compo" class="xref">Section 4</a> or when aggregating data retrieved from
      various sources. Authorization and authentication checks should be
      performed to ensure that data is available to an authorized entity.
      The network operator must enforce means to protect privacy-related
      information included in customer-facing models.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">To detect misalignment between layers that might be induced by
      misbehaving nodes, upper layers should continuously monitor the
      perceived service (<a href="#optim" class="xref">Section 4.1.4</a>) and should proceed with
      checks to assess that the provided service complies with the expected
      service and that the data reported by an underlying layer is matching
      the perceived service by the above layer. Such checks are the
      responsibility of the service diagnosis (<a href="#diag" class="xref">Section 4.1.5</a>).<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">When a YANG module includes security-related parameters, it is
      recommended to include the relevant information as part of the service
      assurance to track the correct functioning of the security
      mechanisms.<a href="#section-6-6" class="pilcrow">¶</a></p>
<p id="section-6-7">Additional considerations are discussed in the following
      subsections.<a href="#section-6-7" class="pilcrow">¶</a></p>
<section id="section-6.1">
        <h3 id="name-service-level">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-service-level" class="section-name selfRef">Service Level</a>
        </h3>
<p id="section-6.1-1">A provider may rely on services offered by other providers to build
        composite services. Appropriate mechanisms should be enabled by the
        provider to monitor and detect a service disruption from these
        providers. The characterization of a service disruption (including
        mean time between failures and mean time to repair), the escalation
        procedure, and penalties are usually documented in contractual
        agreements (e.g., as described in <span><a href="https://www.rfc-editor.org/rfc/rfc4176#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC4176" class="xref">RFC4176</a>]</span>). Misbehaving peer providers will
        thus be identified and appropriate countermeasures will be
        applied.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">The communication protocols that make use of a service model
        between a customer and an operator are out of scope. Relevant security
        considerations should be discussed in the specification documents of
        these protocols.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-6.2">
        <h3 id="name-network-level">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-network-level" class="section-name selfRef">Network Level</a>
        </h3>
<p id="section-6.2-1">Security considerations specific to the network level are listed
        below:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">A controller may create forwarding loops by misconfiguring the
            underlying network nodes. It is recommended to proceed with tests
            to check the status of forwarding paths regularly or whenever
            changes are made to routing or forwarding processes. Such checks
            may be triggered from the service level owing to the means
            discussed in <a href="#diag" class="xref">Section 4.1.5</a>.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.2">Some service models may include a traffic isolation clause that
          is passed down to the network level so that appropriate
          technology-specific actions must be enforced at the underlying
          network (and thus involved network devices) to avoid that such
          traffic is accessible to non-authorized parties. In particular,
          network models may indicate whether encryption is enabled and, if so,
          expose a list of supported encryption schemes and parameters.  Refer,
          for example, to the encryption feature defined in <span>[<a href="#I-D.ietf-opsawg-vpn-common" class="xref">OPSAWG-VPN-COMMON</a>]</span> and its use
          in <span>[<a href="#I-D.ietf-opsawg-l3sm-l3nm" class="xref">OPSAWG-L3SM-L3NM</a>]</span>.<a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<section id="section-6.3">
        <h3 id="name-device-level">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-device-level" class="section-name selfRef">Device Level</a>
        </h3>
<p id="section-6.3-1">Network operators should monitor and audit their networks to detect
        misbehaving nodes and abnormal behaviors. For example, OAM, as
        discussed in <a href="#diag" class="xref">Section 4.1.5</a>, can be used for
        that purpose.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">Access to some data requires specific access privilege levels.
        Devices must check that a required access privilege is provided before
        granting access to specific data or performing specific actions.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">This document has no IANA actions.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC6241">[RFC6241]</dt>
        <dd>
<span class="refAuthor">Enns, R., Ed.</span><span class="refAuthor">, Bjorklund, M., Ed.</span><span class="refAuthor">, Schoenwaelder, J., Ed.</span><span class="refAuthor">, and A. Bierman, Ed.</span>, <span class="refTitle">"Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6241</span>, <span class="seriesInfo">DOI 10.17487/RFC6241</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6242">[RFC6242]</dt>
        <dd>
<span class="refAuthor">Wasserman, M.</span>, <span class="refTitle">"Using the NETCONF Protocol over Secure Shell (SSH)"</span>, <span class="seriesInfo">RFC 6242</span>, <span class="seriesInfo">DOI 10.17487/RFC6242</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6242">https://www.rfc-editor.org/info/rfc6242</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7950">[RFC7950]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M., Ed.</span>, <span class="refTitle">"The YANG 1.1 Data Modeling Language"</span>, <span class="seriesInfo">RFC 7950</span>, <span class="seriesInfo">DOI 10.17487/RFC7950</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7950">https://www.rfc-editor.org/info/rfc7950</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8040">[RFC8040]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor">, Bjorklund, M.</span><span class="refAuthor">, and K. Watsen</span>, <span class="refTitle">"RESTCONF Protocol"</span>, <span class="seriesInfo">RFC 8040</span>, <span class="seriesInfo">DOI 10.17487/RFC8040</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8040">https://www.rfc-editor.org/info/rfc8040</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8341">[RFC8341]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor"> and M. Bjorklund</span>, <span class="refTitle">"Network Configuration Access Control Model"</span>, <span class="seriesInfo">STD 91</span>, <span class="seriesInfo">RFC 8341</span>, <span class="seriesInfo">DOI 10.17487/RFC8341</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8341">https://www.rfc-editor.org/info/rfc8341</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-teas-actn-vn-yang">[ACTN-VN-YANG]</dt>
        <dd>
<span class="refAuthor">Lee, Y.</span><span class="refAuthor">, Dhody, D.</span><span class="refAuthor">, Ceccarelli, D.</span><span class="refAuthor">, Bryskin, I.</span><span class="refAuthor">, and B. Y. Yoon</span>, <span class="refTitle">"A YANG Data Model for VN Operation"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teas-actn-vn-yang-10</span>, <time datetime="2020-11-02" class="refDate">2 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-10">https://tools.ietf.org/html/draft-ietf-teas-actn-vn-yang-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-bfd-yang">[BFD-YANG]</dt>
        <dd>
<span class="refAuthor">Rahman, R.</span><span class="refAuthor">, Zheng, L.</span><span class="refAuthor">, Jethanandani, M.</span><span class="refAuthor">, Pallagatti, S.</span><span class="refAuthor">, and G. Mirsky</span>, <span class="refTitle">"YANG Data Model for Bidirectional Forwarding Detection (BFD)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-bfd-yang-17</span>, <time datetime="2018-08-02" class="refDate">2 August 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-bfd-yang-17">https://tools.ietf.org/html/draft-ietf-bfd-yang-17</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-dots-rfc8782-bis">[DOTS-DDOS]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Shallow, J.</span><span class="refAuthor">, and T. Reddy.K</span>, <span class="refTitle">"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-dots-rfc8782-bis-04</span>, <time datetime="2020-12-03" class="refDate">3 December 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-04">https://tools.ietf.org/html/draft-ietf-dots-rfc8782-bis-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.wwx-netmod-event-yang">[EVENT-YANG]</dt>
        <dd>
<span class="refAuthor">Wu, Q.</span><span class="refAuthor">, Bryskin, I.</span><span class="refAuthor">, Birkholz, H.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, and B. Claise</span>, <span class="refTitle">"A YANG Data model for ECA Policy Management"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-wwx-netmod-event-yang-10</span>, <time datetime="2020-11-01" class="refDate">1 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10">https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-bess-evpn-yang">[EVPN-YANG]</dt>
        <dd>
<span class="refAuthor">Brissette, P.</span><span class="refAuthor">, Shah, H.</span><span class="refAuthor">, Hussain, I.</span><span class="refAuthor">, Tiruveedhula, K.</span><span class="refAuthor">, and J. Rabadan</span>, <span class="refTitle">"Yang Data Model for EVPN"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-bess-evpn-yang-07</span>, <time datetime="2019-03-11" class="refDate">11 March 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-07">https://tools.ietf.org/html/draft-ietf-bess-evpn-yang-07</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Hardy">[Hardy]</dt>
        <dd>
<span class="refAuthor">Hardy, N.</span>, <span class="refTitle">"The Confused Deputy: (or why capabilities might have been invented)"</span>, <span class="seriesInfo">DOI 10.1145/54289.871709</span>, <time datetime="1988-10" class="refDate">October 1988</time>, <span>&lt;<a href="https://dl.acm.org/doi/10.1145/54289.871709">https://dl.acm.org/doi/10.1145/54289.871709</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-idr-bgp-model">[IDR-BGP-MODEL]</dt>
        <dd>
<span class="refAuthor">Jethanandani, M.</span><span class="refAuthor">, Patel, K.</span><span class="refAuthor">, Hares, S.</span><span class="refAuthor">, and J. Haas</span>, <span class="refTitle">"BGP YANG Model for Service Provider Networks"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-idr-bgp-model-10</span>, <time datetime="2020-11-15" class="refDate">15 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-idr-bgp-model-10">https://tools.ietf.org/html/draft-ietf-idr-bgp-model-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IPPM">[IPPM]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Performance Metrics"</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml">https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-bess-l2vpn-yang">[L2VPN-YANG]</dt>
        <dd>
<span class="refAuthor">Shah, H.</span><span class="refAuthor">, Brissette, P.</span><span class="refAuthor">, Chen, I.</span><span class="refAuthor">, Hussain, I.</span><span class="refAuthor">, Wen, B.</span><span class="refAuthor">, and K. Tiruveedhula</span>, <span class="refTitle">"YANG Data Model for MPLS-based L2VPN"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-bess-l2vpn-yang-10</span>, <time datetime="2019-07-02" class="refDate">2 July 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-10">https://tools.ietf.org/html/draft-ietf-bess-l2vpn-yang-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-bess-l3vpn-yang">[L3VPN-YANG]</dt>
        <dd>
<span class="refAuthor">Jain, D.</span><span class="refAuthor">, Patel, K.</span><span class="refAuthor">, Brissette, P.</span><span class="refAuthor">, Li, Z.</span><span class="refAuthor">, Zhuang, S.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, Haas, J.</span><span class="refAuthor">, Esale, S.</span><span class="refAuthor">, and B. Wen</span>, <span class="refTitle">"Yang Data Model for BGP/MPLS L3 VPNs"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-bess-l3vpn-yang-04</span>, <time datetime="2018-10-19" class="refDate">19 October 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-bess-l3vpn-yang-04">https://tools.ietf.org/html/draft-ietf-bess-l3vpn-yang-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ippm-capacity-metric-method">[METRIC-METHOD]</dt>
        <dd>
<span class="refAuthor">Morton, A.</span><span class="refAuthor">, Geib, R.</span><span class="refAuthor">, and L. Ciavattone</span>, <span class="refTitle">"Metrics and Methods for One-way IP Capacity"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ippm-capacity-metric-method-04</span>, <time datetime="2020-09-10" class="refDate">10 September 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-04">https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-bess-mvpn-yang">[MVPN-YANG]</dt>
        <dd>
<span class="refAuthor">Liu, Y.</span><span class="refAuthor">, Guo, F.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, Kebler, R.</span><span class="refAuthor">, and M. Sivakumar</span>, <span class="refTitle">"Yang Data Model for Multicast in MPLS/BGP IP VPNs"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-bess-mvpn-yang-04</span>, <time datetime="2020-06-30" class="refDate">30 June 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-bess-mvpn-yang-04">https://tools.ietf.org/html/draft-ietf-bess-mvpn-yang-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.clacla-netmod-model-catalog">[NETMOD-MODEL]</dt>
        <dd>
<span class="refAuthor">Clarke, J.</span><span class="refAuthor"> and B. Claise</span>, <span class="refTitle">"YANG module for yangcatalog.org"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-clacla-netmod-model-catalog-03</span>, <time datetime="2018-04-03" class="refDate">3 April 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-03">https://tools.ietf.org/html/draft-clacla-netmod-model-catalog-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsawg-l2nm">[OPSAWG-L2NM]</dt>
        <dd>
<span class="refAuthor">Barguil, S.</span><span class="refAuthor">, Dios, O. G. D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Munoz, L. A.</span><span class="refAuthor">, Jalil, L.</span><span class="refAuthor">, and J. Ma</span>, <span class="refTitle">"A Layer 2 VPN Network YANG Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsawg-l2nm-01</span>, <time datetime="2020-11-02" class="refDate">2 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-01">https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsawg-l3sm-l3nm">[OPSAWG-L3SM-L3NM]</dt>
        <dd>
<span class="refAuthor">Barguil, S.</span><span class="refAuthor">, Dios, O. G. D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Munoz, L. A.</span><span class="refAuthor">, and A. Aguado</span>, <span class="refTitle">"A Layer 3 VPN Network YANG Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05</span>, <time datetime="2020-10-16" class="refDate">16 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05">https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsawg-vpn-common">[OPSAWG-VPN-COMMON]</dt>
        <dd>
<span class="refAuthor">Barguil, S.</span><span class="refAuthor">, Dios, O. G. D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, and Q. Wu</span>, <span class="refTitle">"A Layer 2/3 VPN Common YANG Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsawg-vpn-common-03</span>, <time datetime="2021-01-14" class="refDate">14 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-03">https://tools.ietf.org/html/draft-ietf-opsawg-vpn-common-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.www-opsawg-yang-vpn-service-pm">[OPSAWG-YANG-VPN]</dt>
        <dd>
<span class="refAuthor">Wu, B.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Dios, O. G. D.</span><span class="refAuthor">, Wen, B.</span><span class="refAuthor">, Liu, C.</span><span class="refAuthor">, and H. Xu</span>, <span class="refTitle">"A YANG Model for Network and VPN Service Performance Monitoring"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-www-opsawg-yang-vpn-service-pm-03</span>, <time datetime="2021-01-21" class="refDate">21 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-03">https://tools.ietf.org/html/draft-www-opsawg-yang-vpn-service-pm-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-pim-yang">[PIM-YANG]</dt>
        <dd>
<span class="refAuthor">Liu, X.</span><span class="refAuthor">, McAllister, P.</span><span class="refAuthor">, Peter, A.</span><span class="refAuthor">, Sivakumar, M.</span><span class="refAuthor">, Liu, Y.</span><span class="refAuthor">, and F. Hu</span>, <span class="refTitle">"A YANG Data Model for Protocol Independent Multicast (PIM)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-pim-yang-17</span>, <time datetime="2018-05-19" class="refDate">19 May 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pim-yang-17">https://tools.ietf.org/html/draft-ietf-pim-yang-17</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rtgwg-qos-model">[QOS-MODEL]</dt>
        <dd>
<span class="refAuthor">Choudhary, A.</span><span class="refAuthor">, Jethanandani, M.</span><span class="refAuthor">, Strahle, N.</span><span class="refAuthor">, Aries, E.</span><span class="refAuthor">, and I. Chen</span>, <span class="refTitle">"YANG Model for QoS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rtgwg-qos-model-02</span>, <time datetime="2020-07-09" class="refDate">9 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rtgwg-qos-model-02">https://tools.ietf.org/html/draft-ietf-rtgwg-qos-model-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4176">[RFC4176]</dt>
        <dd>
<span class="refAuthor">El Mghazli, Y., Ed.</span><span class="refAuthor">, Nadeau, T.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Chan, K.</span><span class="refAuthor">, and A. Gonguet</span>, <span class="refTitle">"Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management"</span>, <span class="seriesInfo">RFC 4176</span>, <span class="seriesInfo">DOI 10.17487/RFC4176</span>, <time datetime="2005-10" class="refDate">October 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4176">https://www.rfc-editor.org/info/rfc4176</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4364">[RFC4364]</dt>
        <dd>
<span class="refAuthor">Rosen, E.</span><span class="refAuthor"> and Y. Rekhter</span>, <span class="refTitle">"BGP/MPLS IP Virtual Private Networks (VPNs)"</span>, <span class="seriesInfo">RFC 4364</span>, <span class="seriesInfo">DOI 10.17487/RFC4364</span>, <time datetime="2006-02" class="refDate">February 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4364">https://www.rfc-editor.org/info/rfc4364</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4664">[RFC4664]</dt>
        <dd>
<span class="refAuthor">Andersson, L., Ed.</span><span class="refAuthor"> and E. Rosen, Ed.</span>, <span class="refTitle">"Framework for Layer 2 Virtual Private Networks (L2VPNs)"</span>, <span class="seriesInfo">RFC 4664</span>, <span class="seriesInfo">DOI 10.17487/RFC4664</span>, <time datetime="2006-09" class="refDate">September 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4664">https://www.rfc-editor.org/info/rfc4664</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4761">[RFC4761]</dt>
        <dd>
<span class="refAuthor">Kompella, K., Ed.</span><span class="refAuthor"> and Y. Rekhter, Ed.</span>, <span class="refTitle">"Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling"</span>, <span class="seriesInfo">RFC 4761</span>, <span class="seriesInfo">DOI 10.17487/RFC4761</span>, <time datetime="2007-01" class="refDate">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4761">https://www.rfc-editor.org/info/rfc4761</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4762">[RFC4762]</dt>
        <dd>
<span class="refAuthor">Lasserre, M., Ed.</span><span class="refAuthor"> and V. Kompella, Ed.</span>, <span class="refTitle">"Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling"</span>, <span class="seriesInfo">RFC 4762</span>, <span class="seriesInfo">DOI 10.17487/RFC4762</span>, <time datetime="2007-01" class="refDate">January 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4762">https://www.rfc-editor.org/info/rfc4762</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5136">[RFC5136]</dt>
        <dd>
<span class="refAuthor">Chimento, P.</span><span class="refAuthor"> and J. Ishac</span>, <span class="refTitle">"Defining Network Capacity"</span>, <span class="seriesInfo">RFC 5136</span>, <span class="seriesInfo">DOI 10.17487/RFC5136</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5136">https://www.rfc-editor.org/info/rfc5136</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5486">[RFC5486]</dt>
        <dd>
<span class="refAuthor">Malas, D., Ed.</span><span class="refAuthor"> and D. Meyer, Ed.</span>, <span class="refTitle">"Session Peering for Multimedia Interconnect (SPEERMINT) Terminology"</span>, <span class="seriesInfo">RFC 5486</span>, <span class="seriesInfo">DOI 10.17487/RFC5486</span>, <time datetime="2009-03" class="refDate">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5486">https://www.rfc-editor.org/info/rfc5486</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5880">[RFC5880]</dt>
        <dd>
<span class="refAuthor">Katz, D.</span><span class="refAuthor"> and D. Ward</span>, <span class="refTitle">"Bidirectional Forwarding Detection (BFD)"</span>, <span class="seriesInfo">RFC 5880</span>, <span class="seriesInfo">DOI 10.17487/RFC5880</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5880">https://www.rfc-editor.org/info/rfc5880</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6406">[RFC6406]</dt>
        <dd>
<span class="refAuthor">Malas, D., Ed.</span><span class="refAuthor"> and J. Livingood, Ed.</span>, <span class="refTitle">"Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture"</span>, <span class="seriesInfo">RFC 6406</span>, <span class="seriesInfo">DOI 10.17487/RFC6406</span>, <time datetime="2011-11" class="refDate">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6406">https://www.rfc-editor.org/info/rfc6406</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7149">[RFC7149]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor"> and C. Jacquenet</span>, <span class="refTitle">"Software-Defined Networking: A Perspective from within a Service Provider Environment"</span>, <span class="seriesInfo">RFC 7149</span>, <span class="seriesInfo">DOI 10.17487/RFC7149</span>, <time datetime="2014-03" class="refDate">March 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7149">https://www.rfc-editor.org/info/rfc7149</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7224">[RFC7224]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span>, <span class="refTitle">"IANA Interface Type YANG Module"</span>, <span class="seriesInfo">RFC 7224</span>, <span class="seriesInfo">DOI 10.17487/RFC7224</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7224">https://www.rfc-editor.org/info/rfc7224</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7276">[RFC7276]</dt>
        <dd>
<span class="refAuthor">Mizrahi, T.</span><span class="refAuthor">, Sprecher, N.</span><span class="refAuthor">, Bellagamba, E.</span><span class="refAuthor">, and Y. Weingarten</span>, <span class="refTitle">"An Overview of Operations, Administration, and Maintenance (OAM) Tools"</span>, <span class="seriesInfo">RFC 7276</span>, <span class="seriesInfo">DOI 10.17487/RFC7276</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7276">https://www.rfc-editor.org/info/rfc7276</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7297">[RFC7297]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Jacquenet, C.</span><span class="refAuthor">, and N. Wang</span>, <span class="refTitle">"IP Connectivity Provisioning Profile (CPP)"</span>, <span class="seriesInfo">RFC 7297</span>, <span class="seriesInfo">DOI 10.17487/RFC7297</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7297">https://www.rfc-editor.org/info/rfc7297</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7317">[RFC7317]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor"> and M. Bjorklund</span>, <span class="refTitle">"A YANG Data Model for System Management"</span>, <span class="seriesInfo">RFC 7317</span>, <span class="seriesInfo">DOI 10.17487/RFC7317</span>, <time datetime="2014-08" class="refDate">August 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7317">https://www.rfc-editor.org/info/rfc7317</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7455">[RFC7455]</dt>
        <dd>
<span class="refAuthor">Senevirathne, T.</span><span class="refAuthor">, Finn, N.</span><span class="refAuthor">, Salam, S.</span><span class="refAuthor">, Kumar, D.</span><span class="refAuthor">, Eastlake 3rd, D.</span><span class="refAuthor">, Aldrin, S.</span><span class="refAuthor">, and Y. Li</span>, <span class="refTitle">"Transparent Interconnection of Lots of Links (TRILL): Fault Management"</span>, <span class="seriesInfo">RFC 7455</span>, <span class="seriesInfo">DOI 10.17487/RFC7455</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7455">https://www.rfc-editor.org/info/rfc7455</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7665">[RFC7665]</dt>
        <dd>
<span class="refAuthor">Halpern, J., Ed.</span><span class="refAuthor"> and C. Pignataro, Ed.</span>, <span class="refTitle">"Service Function Chaining (SFC) Architecture"</span>, <span class="seriesInfo">RFC 7665</span>, <span class="seriesInfo">DOI 10.17487/RFC7665</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7665">https://www.rfc-editor.org/info/rfc7665</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7679">[RFC7679]</dt>
        <dd>
<span class="refAuthor">Almes, G.</span><span class="refAuthor">, Kalidindi, S.</span><span class="refAuthor">, Zekauskas, M.</span><span class="refAuthor">, and A. Morton, Ed.</span>, <span class="refTitle">"A One-Way Delay Metric for IP Performance Metrics (IPPM)"</span>, <span class="seriesInfo">STD 81</span>, <span class="seriesInfo">RFC 7679</span>, <span class="seriesInfo">DOI 10.17487/RFC7679</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7679">https://www.rfc-editor.org/info/rfc7679</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7680">[RFC7680]</dt>
        <dd>
<span class="refAuthor">Almes, G.</span><span class="refAuthor">, Kalidindi, S.</span><span class="refAuthor">, Zekauskas, M.</span><span class="refAuthor">, and A. Morton, Ed.</span>, <span class="refTitle">"A One-Way Loss Metric for IP Performance Metrics (IPPM)"</span>, <span class="seriesInfo">STD 82</span>, <span class="seriesInfo">RFC 7680</span>, <span class="seriesInfo">DOI 10.17487/RFC7680</span>, <time datetime="2016-01" class="refDate">January 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7680">https://www.rfc-editor.org/info/rfc7680</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8077">[RFC8077]</dt>
        <dd>
<span class="refAuthor">Martini, L., Ed.</span><span class="refAuthor"> and G. Heron, Ed.</span>, <span class="refTitle">"Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"</span>, <span class="seriesInfo">STD 84</span>, <span class="seriesInfo">RFC 8077</span>, <span class="seriesInfo">DOI 10.17487/RFC8077</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8077">https://www.rfc-editor.org/info/rfc8077</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8194">[RFC8194]</dt>
        <dd>
<span class="refAuthor">Schoenwaelder, J.</span><span class="refAuthor"> and V. Bajpai</span>, <span class="refTitle">"A YANG Data Model for LMAP Measurement Agents"</span>, <span class="seriesInfo">RFC 8194</span>, <span class="seriesInfo">DOI 10.17487/RFC8194</span>, <time datetime="2017-08" class="refDate">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8194">https://www.rfc-editor.org/info/rfc8194</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8199">[RFC8199]</dt>
        <dd>
<span class="refAuthor">Bogdanovic, D.</span><span class="refAuthor">, Claise, B.</span><span class="refAuthor">, and C. Moberg</span>, <span class="refTitle">"YANG Module Classification"</span>, <span class="seriesInfo">RFC 8199</span>, <span class="seriesInfo">DOI 10.17487/RFC8199</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8199">https://www.rfc-editor.org/info/rfc8199</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8299">[RFC8299]</dt>
        <dd>
<span class="refAuthor">Wu, Q., Ed.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, Tomotaki, L.</span><span class="refAuthor">, and K. Ogaki</span>, <span class="refTitle">"YANG Data Model for L3VPN Service Delivery"</span>, <span class="seriesInfo">RFC 8299</span>, <span class="seriesInfo">DOI 10.17487/RFC8299</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8299">https://www.rfc-editor.org/info/rfc8299</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8309">[RFC8309]</dt>
        <dd>
<span class="refAuthor">Wu, Q.</span><span class="refAuthor">, Liu, W.</span><span class="refAuthor">, and A. Farrel</span>, <span class="refTitle">"Service Models Explained"</span>, <span class="seriesInfo">RFC 8309</span>, <span class="seriesInfo">DOI 10.17487/RFC8309</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8309">https://www.rfc-editor.org/info/rfc8309</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8342">[RFC8342]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span><span class="refAuthor">, Schoenwaelder, J.</span><span class="refAuthor">, Shafer, P.</span><span class="refAuthor">, Watsen, K.</span><span class="refAuthor">, and R. Wilton</span>, <span class="refTitle">"Network Management Datastore Architecture (NMDA)"</span>, <span class="seriesInfo">RFC 8342</span>, <span class="seriesInfo">DOI 10.17487/RFC8342</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8342">https://www.rfc-editor.org/info/rfc8342</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8343">[RFC8343]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span>, <span class="refTitle">"A YANG Data Model for Interface Management"</span>, <span class="seriesInfo">RFC 8343</span>, <span class="seriesInfo">DOI 10.17487/RFC8343</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8343">https://www.rfc-editor.org/info/rfc8343</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8345">[RFC8345]</dt>
        <dd>
<span class="refAuthor">Clemm, A.</span><span class="refAuthor">, Medved, J.</span><span class="refAuthor">, Varga, R.</span><span class="refAuthor">, Bahadur, N.</span><span class="refAuthor">, Ananthakrishnan, H.</span><span class="refAuthor">, and X. Liu</span>, <span class="refTitle">"A YANG Data Model for Network Topologies"</span>, <span class="seriesInfo">RFC 8345</span>, <span class="seriesInfo">DOI 10.17487/RFC8345</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8345">https://www.rfc-editor.org/info/rfc8345</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8346">[RFC8346]</dt>
        <dd>
<span class="refAuthor">Clemm, A.</span><span class="refAuthor">, Medved, J.</span><span class="refAuthor">, Varga, R.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, Ananthakrishnan, H.</span><span class="refAuthor">, and N. Bahadur</span>, <span class="refTitle">"A YANG Data Model for Layer 3 Topologies"</span>, <span class="seriesInfo">RFC 8346</span>, <span class="seriesInfo">DOI 10.17487/RFC8346</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8346">https://www.rfc-editor.org/info/rfc8346</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8348">[RFC8348]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor">, Bjorklund, M.</span><span class="refAuthor">, Dong, J.</span><span class="refAuthor">, and D. Romascanu</span>, <span class="refTitle">"A YANG Data Model for Hardware Management"</span>, <span class="seriesInfo">RFC 8348</span>, <span class="seriesInfo">DOI 10.17487/RFC8348</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8348">https://www.rfc-editor.org/info/rfc8348</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8349">[RFC8349]</dt>
        <dd>
<span class="refAuthor">Lhotka, L.</span><span class="refAuthor">, Lindem, A.</span><span class="refAuthor">, and Y. Qu</span>, <span class="refTitle">"A YANG Data Model for Routing Management (NMDA Version)"</span>, <span class="seriesInfo">RFC 8349</span>, <span class="seriesInfo">DOI 10.17487/RFC8349</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8349">https://www.rfc-editor.org/info/rfc8349</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8466">[RFC8466]</dt>
        <dd>
<span class="refAuthor">Wen, B.</span><span class="refAuthor">, Fioccola, G., Ed.</span><span class="refAuthor">, Xie, C.</span><span class="refAuthor">, and L. Jalil</span>, <span class="refTitle">"A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery"</span>, <span class="seriesInfo">RFC 8466</span>, <span class="seriesInfo">DOI 10.17487/RFC8466</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8466">https://www.rfc-editor.org/info/rfc8466</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8512">[RFC8512]</dt>
        <dd>
<span class="refAuthor">Boucadair, M., Ed.</span><span class="refAuthor">, Sivakumar, S.</span><span class="refAuthor">, Jacquenet, C.</span><span class="refAuthor">, Vinapamula, S.</span><span class="refAuthor">, and Q. Wu</span>, <span class="refTitle">"A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT)"</span>, <span class="seriesInfo">RFC 8512</span>, <span class="seriesInfo">DOI 10.17487/RFC8512</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8512">https://www.rfc-editor.org/info/rfc8512</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8513">[RFC8513]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Jacquenet, C.</span><span class="refAuthor">, and S. Sivakumar</span>, <span class="refTitle">"A YANG Data Model for Dual-Stack Lite (DS-Lite)"</span>, <span class="seriesInfo">RFC 8513</span>, <span class="seriesInfo">DOI 10.17487/RFC8513</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8513">https://www.rfc-editor.org/info/rfc8513</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8519">[RFC8519]</dt>
        <dd>
<span class="refAuthor">Jethanandani, M.</span><span class="refAuthor">, Agarwal, S.</span><span class="refAuthor">, Huang, L.</span><span class="refAuthor">, and D. Blair</span>, <span class="refTitle">"YANG Data Model for Network Access Control Lists (ACLs)"</span>, <span class="seriesInfo">RFC 8519</span>, <span class="seriesInfo">DOI 10.17487/RFC8519</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8519">https://www.rfc-editor.org/info/rfc8519</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8525">[RFC8525]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor">, Bjorklund, M.</span><span class="refAuthor">, Schoenwaelder, J.</span><span class="refAuthor">, Watsen, K.</span><span class="refAuthor">, and R. Wilton</span>, <span class="refTitle">"YANG Library"</span>, <span class="seriesInfo">RFC 8525</span>, <span class="seriesInfo">DOI 10.17487/RFC8525</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8525">https://www.rfc-editor.org/info/rfc8525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8528">[RFC8528]</dt>
        <dd>
<span class="refAuthor">Bjorklund, M.</span><span class="refAuthor"> and L. Lhotka</span>, <span class="refTitle">"YANG Schema Mount"</span>, <span class="seriesInfo">RFC 8528</span>, <span class="seriesInfo">DOI 10.17487/RFC8528</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8528">https://www.rfc-editor.org/info/rfc8528</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8529">[RFC8529]</dt>
        <dd>
<span class="refAuthor">Berger, L.</span><span class="refAuthor">, Hopps, C.</span><span class="refAuthor">, Lindem, A.</span><span class="refAuthor">, Bogdanovic, D.</span><span class="refAuthor">, and X. Liu</span>, <span class="refTitle">"YANG Data Model for Network Instances"</span>, <span class="seriesInfo">RFC 8529</span>, <span class="seriesInfo">DOI 10.17487/RFC8529</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8529">https://www.rfc-editor.org/info/rfc8529</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8530">[RFC8530]</dt>
        <dd>
<span class="refAuthor">Berger, L.</span><span class="refAuthor">, Hopps, C.</span><span class="refAuthor">, Lindem, A.</span><span class="refAuthor">, Bogdanovic, D.</span><span class="refAuthor">, and X. Liu</span>, <span class="refTitle">"YANG Model for Logical Network Elements"</span>, <span class="seriesInfo">RFC 8530</span>, <span class="seriesInfo">DOI 10.17487/RFC8530</span>, <time datetime="2019-03" class="refDate">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8530">https://www.rfc-editor.org/info/rfc8530</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8531">[RFC8531]</dt>
        <dd>
<span class="refAuthor">Kumar, D.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, and Z. Wang</span>, <span class="refTitle">"Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols"</span>, <span class="seriesInfo">RFC 8531</span>, <span class="seriesInfo">DOI 10.17487/RFC8531</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8531">https://www.rfc-editor.org/info/rfc8531</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8532">[RFC8532]</dt>
        <dd>
<span class="refAuthor">Kumar, D.</span><span class="refAuthor">, Wang, Z.</span><span class="refAuthor">, Wu, Q., Ed.</span><span class="refAuthor">, Rahman, R.</span><span class="refAuthor">, and S. Raghavan</span>, <span class="refTitle">"Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications"</span>, <span class="seriesInfo">RFC 8532</span>, <span class="seriesInfo">DOI 10.17487/RFC8532</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8532">https://www.rfc-editor.org/info/rfc8532</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8533">[RFC8533]</dt>
        <dd>
<span class="refAuthor">Kumar, D.</span><span class="refAuthor">, Wang, M.</span><span class="refAuthor">, Wu, Q., Ed.</span><span class="refAuthor">, Rahman, R.</span><span class="refAuthor">, and S. Raghavan</span>, <span class="refTitle">"A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications"</span>, <span class="seriesInfo">RFC 8533</span>, <span class="seriesInfo">DOI 10.17487/RFC8533</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8533">https://www.rfc-editor.org/info/rfc8533</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8632">[RFC8632]</dt>
        <dd>
<span class="refAuthor">Vallin, S.</span><span class="refAuthor"> and M. Bjorklund</span>, <span class="refTitle">"A YANG Data Model for Alarm Management"</span>, <span class="seriesInfo">RFC 8632</span>, <span class="seriesInfo">DOI 10.17487/RFC8632</span>, <time datetime="2019-09" class="refDate">September 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8632">https://www.rfc-editor.org/info/rfc8632</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8641">[RFC8641]</dt>
        <dd>
<span class="refAuthor">Clemm, A.</span><span class="refAuthor"> and E. Voit</span>, <span class="refTitle">"Subscription to YANG Notifications for Datastore Updates"</span>, <span class="seriesInfo">RFC 8641</span>, <span class="seriesInfo">DOI 10.17487/RFC8641</span>, <time datetime="2019-09" class="refDate">September 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8641">https://www.rfc-editor.org/info/rfc8641</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8652">[RFC8652]</dt>
        <dd>
<span class="refAuthor">Liu, X.</span><span class="refAuthor">, Guo, F.</span><span class="refAuthor">, Sivakumar, M.</span><span class="refAuthor">, McAllister, P.</span><span class="refAuthor">, and A. Peter</span>, <span class="refTitle">"A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD)"</span>, <span class="seriesInfo">RFC 8652</span>, <span class="seriesInfo">DOI 10.17487/RFC8652</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8652">https://www.rfc-editor.org/info/rfc8652</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8675">[RFC8675]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Farrer, I.</span><span class="refAuthor">, and R. Asati</span>, <span class="refTitle">"A YANG Data Model for Tunnel Interface Types"</span>, <span class="seriesInfo">RFC 8675</span>, <span class="seriesInfo">DOI 10.17487/RFC8675</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8675">https://www.rfc-editor.org/info/rfc8675</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8676">[RFC8676]</dt>
        <dd>
<span class="refAuthor">Farrer, I., Ed.</span><span class="refAuthor"> and M. Boucadair, Ed.</span>, <span class="refTitle">"YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires"</span>, <span class="seriesInfo">RFC 8676</span>, <span class="seriesInfo">DOI 10.17487/RFC8676</span>, <time datetime="2019-11" class="refDate">November 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8676">https://www.rfc-editor.org/info/rfc8676</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8783">[RFC8783]</dt>
        <dd>
<span class="refAuthor">Boucadair, M., Ed.</span><span class="refAuthor"> and T. Reddy.K, Ed.</span>, <span class="refTitle">"Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification"</span>, <span class="seriesInfo">RFC 8783</span>, <span class="seriesInfo">DOI 10.17487/RFC8783</span>, <time datetime="2020-05" class="refDate">May 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8783">https://www.rfc-editor.org/info/rfc8783</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8791">[RFC8791]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor">, Björklund, M.</span><span class="refAuthor">, and K. Watsen</span>, <span class="refTitle">"YANG Data Structure Extensions"</span>, <span class="seriesInfo">RFC 8791</span>, <span class="seriesInfo">DOI 10.17487/RFC8791</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8791">https://www.rfc-editor.org/info/rfc8791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8795">[RFC8795]</dt>
        <dd>
<span class="refAuthor">Liu, X.</span><span class="refAuthor">, Bryskin, I.</span><span class="refAuthor">, Beeram, V.</span><span class="refAuthor">, Saad, T.</span><span class="refAuthor">, Shah, H.</span><span class="refAuthor">, and O. Gonzalez de Dios</span>, <span class="refTitle">"YANG Data Model for Traffic Engineering (TE) Topologies"</span>, <span class="seriesInfo">RFC 8795</span>, <span class="seriesInfo">DOI 10.17487/RFC8795</span>, <time datetime="2020-08" class="refDate">August 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8795">https://www.rfc-editor.org/info/rfc8795</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8819">[RFC8819]</dt>
        <dd>
<span class="refAuthor">Hopps, C.</span><span class="refAuthor">, Berger, L.</span><span class="refAuthor">, and D. Bogdanovic</span>, <span class="refTitle">"YANG Module Tags"</span>, <span class="seriesInfo">RFC 8819</span>, <span class="seriesInfo">DOI 10.17487/RFC8819</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8819">https://www.rfc-editor.org/info/rfc8819</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8944">[RFC8944]</dt>
        <dd>
<span class="refAuthor">Dong, J.</span><span class="refAuthor">, Wei, X.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, and A. Liu</span>, <span class="refTitle">"A YANG Data Model for Layer 2 Network Topologies"</span>, <span class="seriesInfo">RFC 8944</span>, <span class="seriesInfo">DOI 10.17487/RFC8944</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8944">https://www.rfc-editor.org/info/rfc8944</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8960">[RFC8960]</dt>
        <dd>
<span class="refAuthor">Saad, T.</span><span class="refAuthor">, Raza, K.</span><span class="refAuthor">, Gandhi, R.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, and V. Beeram</span>, <span class="refTitle">"A YANG Data Model for MPLS Base"</span>, <span class="seriesInfo">RFC 8960</span>, <span class="seriesInfo">DOI 10.17487/RFC8960</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8960">https://www.rfc-editor.org/info/rfc8960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-rtgwg-policy-model">[RTGWG-POLICY]</dt>
        <dd>
<span class="refAuthor">Qu, Y.</span><span class="refAuthor">, Tantsura, J.</span><span class="refAuthor">, Lindem, A.</span><span class="refAuthor">, and X. Liu</span>, <span class="refTitle">"A YANG Data Model for Routing Policy"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rtgwg-policy-model-27</span>, <time datetime="2021-01-10" class="refDate">10 January 2021</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-27">https://tools.ietf.org/html/draft-ietf-rtgwg-policy-model-27</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-pim-igmp-mld-snooping-yang">[SNOOPING-YANG]</dt>
        <dd>
<span class="refAuthor">Zhao, H.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, Liu, Y.</span><span class="refAuthor">, Sivakumar, M.</span><span class="refAuthor">, and A. Peter</span>, <span class="refTitle">"A Yang Data Model for IGMP and MLD Snooping"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-pim-igmp-mld-snooping-yang-18</span>, <time datetime="2020-08-14" class="refDate">14 August 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-snooping-yang-18">https://tools.ietf.org/html/draft-ietf-pim-igmp-mld-snooping-yang-18</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-spring-sr-yang">[SPRING-SR-YANG]</dt>
        <dd>
<span class="refAuthor">Litkowski, S.</span><span class="refAuthor">, Qu, Y.</span><span class="refAuthor">, Lindem, A.</span><span class="refAuthor">, Sarkar, P.</span><span class="refAuthor">, and J. Tantsura</span>, <span class="refTitle">"YANG Data Model for Segment Routing"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-spring-sr-yang-29</span>, <time datetime="2020-12-08" class="refDate">8 December 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-spring-sr-yang-29">https://tools.ietf.org/html/draft-ietf-spring-sr-yang-29</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ippm-stamp-yang">[STAMP-YANG]</dt>
        <dd>
<span class="refAuthor">Mirsky, G.</span><span class="refAuthor">, Min, X.</span><span class="refAuthor">, and W. S. Luo</span>, <span class="refTitle">"Simple Two-way Active Measurement Protocol (STAMP) Data Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ippm-stamp-yang-06</span>, <time datetime="2020-10-07" class="refDate">7 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-06">https://tools.ietf.org/html/draft-ietf-ippm-stamp-yang-06</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-teas-actn-pm-telemetry-autonomics">[TEAS-ACTN-PM]</dt>
        <dd>
<span class="refAuthor">Lee, Y.</span><span class="refAuthor">, Dhody, D.</span><span class="refAuthor">, Karunanithi, S.</span><span class="refAuthor">, Vilalta, R.</span><span class="refAuthor">, King, D.</span><span class="refAuthor">, and D. Ceccarelli</span>, <span class="refTitle">"YANG models for VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teas-actn-pm-telemetry-autonomics-04</span>, <time datetime="2020-11-02" class="refDate">2 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-04">https://tools.ietf.org/html/draft-ietf-teas-actn-pm-telemetry-autonomics-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-teas-yang-path-computation">[TEAS-YANG-PATH-COMP]</dt>
        <dd>
<span class="refAuthor">Busi, I.</span><span class="refAuthor">, Belotti, S.</span><span class="refAuthor">, Lopez, V.</span><span class="refAuthor">, Sharma, A.</span><span class="refAuthor">, and Y. Shi</span>, <span class="refTitle">"Yang model for requesting Path Computation"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teas-yang-path-computation-11</span>, <time datetime="2020-11-16" class="refDate">16 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-11">https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-11</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-teas-yang-rsvp-te">[TEAS-YANG-RSVP]</dt>
        <dd>
<span class="refAuthor">Beeram, V. P.</span><span class="refAuthor">, Saad, T.</span><span class="refAuthor">, Gandhi, R.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, Bryskin, I.</span><span class="refAuthor">, and H. Shah</span>, <span class="refTitle">"A YANG Data Model for RSVP-TE Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teas-yang-rsvp-te-08</span>, <time datetime="2020-03-09" class="refDate">9 March 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-08">https://tools.ietf.org/html/draft-ietf-teas-yang-rsvp-te-08</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-teas-yang-te">[TEAS-YANG-TE]</dt>
        <dd>
<span class="refAuthor">Saad, T.</span><span class="refAuthor">, Gandhi, R.</span><span class="refAuthor">, Liu, X.</span><span class="refAuthor">, Beeram, V. P.</span><span class="refAuthor">, and I. Bryskin</span>, <span class="refTitle">"A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-teas-yang-te-25</span>, <time datetime="2020-07-27" class="refDate">27 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-teas-yang-te-25">https://tools.ietf.org/html/draft-ietf-teas-yang-te-25</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-trill-yang-oam">[TRILL-YANG-OAM]</dt>
        <dd>
<span class="refAuthor">Kumar, D.</span><span class="refAuthor">, Senevirathne, T.</span><span class="refAuthor">, Finn, N.</span><span class="refAuthor">, Salam, S.</span><span class="refAuthor">, Xia, L.</span><span class="refAuthor">, and W. Hao</span>, <span class="refTitle">"YANG Data Model for TRILL Operations, Administration, and Maintenance (OAM)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-trill-yang-oam-05</span>, <time datetime="2017-03-31" class="refDate">31 March 2017</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-trill-yang-oam-05">https://tools.ietf.org/html/draft-ietf-trill-yang-oam-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ippm-twamp-yang">[TWAMP-DATA-MODEL]</dt>
        <dd>
<span class="refAuthor">Civil, R.</span><span class="refAuthor">, Morton, A.</span><span class="refAuthor">, Rahman, R.</span><span class="refAuthor">, Jethanandani, M.</span><span class="refAuthor">, and K. Pentikousis</span>, <span class="refTitle">"Two-Way Active Measurement Protocol (TWAMP) Data Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ippm-twamp-yang-13</span>, <time datetime="2018-07-02" class="refDate">2 July 2018</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13">https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ogondio-opsawg-uni-topology">[UNI-TOPOLOGY]</dt>
      <dd>
<span class="refAuthor">Dios, O. G. D.</span><span class="refAuthor">, Barguil, S.</span><span class="refAuthor">, Wu, Q.</span><span class="refAuthor">, and M. Boucadair</span>, <span class="refTitle">"A YANG Model for User-Network Interface (UNI) Topologies"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ogondio-opsawg-uni-topology-01</span>, <time datetime="2020-04-02" class="refDate">2 April 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01">https://tools.ietf.org/html/draft-ogondio-opsawg-uni-topology-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="app">
<section id="section-appendix.a">
      <h2 id="name-layered-yang-module-example">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-layered-yang-module-example" class="section-name selfRef">Layered YANG Module Examples Overview</a>
      </h2>
<p id="section-appendix.a-1">This appendix lists a set of YANG data models that can be used for
      the delivery of connectivity services. These models can be classified as
      service, network, or device models.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">It is not the intent of this appendix to provide an inventory of
      tools and mechanisms used in specific network and service management
      domains; such inventory can be found in documents such as <span>[<a href="#RFC7276" class="xref">RFC7276</a>]</span>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">The reader may refer to the YANG Catalog (&lt;<span><a href="https://www.yangcatalog.org">https://www.yangcatalog.org</a></span>&gt;) or the public Github YANG
      repository (&lt;<span><a href="https://github.com/YangModels/yang">https://github.com/YangModels/yang</a></span>&gt;) to
      query existing YANG models. The YANG Catalog includes some metadata to
      indicate the module type ('module-classification') <span>[<a href="#I-D.clacla-netmod-model-catalog" class="xref">NETMOD-MODEL</a>]</span>. Note that
      the mechanism defined in <span>[<a href="#RFC8819" class="xref">RFC8819</a>]</span>
      allows to associate tags with YANG modules in order to help classifying
      the modules.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<div id="ns">
<section id="section-a.1">
        <h2 id="name-service-models-definition-a">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-service-models-definition-a" class="section-name selfRef">Service Models: Definition and Samples</a>
        </h2>
<p id="section-a.1-1">As described in <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span>, the
        service is "some form of connectivity between customer sites and the
        Internet or between customer sites across the network operator's
        network and across the Internet". More concretely, an IP connectivity
        service can be defined as the IP transfer capability characterized by
        a (Source Nets, Destination Nets, Guarantees, Scope) tuple where
        "Source Nets" is a group of unicast IP addresses, "Destination Nets"
        is a group of IP unicast and/or multicast addresses, and "Guarantees"
        reflects the guarantees (expressed, for example, in terms of QoS,
        performance, and availability) to properly forward traffic to the said
        "Destination" <span>[<a href="#RFC7297" class="xref">RFC7297</a>]</span>. The "Scope"
        denotes the network perimeter (e.g., between Provider Edge (PE)
        routers or Customer Nodes) where the said guarantees need to be
        provided.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<p id="section-a.1-2">For example:<a href="#section-a.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-a.1-3.1">The L3SM <span>[<a href="#RFC8299" class="xref">RFC8299</a>]</span> defines the L3VPN
            service ordered by a customer from a network operator.<a href="#section-a.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-3.2">The L2SM <span>[<a href="#RFC8466" class="xref">RFC8466</a>]</span> defines the L2VPN
            service ordered by a customer from a network operator.<a href="#section-a.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.1-3.3">The Virtual Network (VN) model <span>[<a href="#I-D.ietf-teas-actn-vn-yang" class="xref">ACTN-VN-YANG</a>]</span> provides a
          YANG data model applicable to any mode of VN operation.<a href="#section-a.1-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-a.1-4">L2SM and L3SM are customer service models as per <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span>.<a href="#section-a.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-a.2">
        <h2 id="name-schema-mount">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-schema-mount" class="section-name selfRef">Schema Mount</a>
        </h2>
<p id="section-a.2-1">Modularity and extensibility were among the leading design
        principles of the YANG data modeling language. As a result, the same
        YANG module can be combined with various sets of other modules and
        thus form a data model that is tailored to meet the requirements of a
        specific use case. <span>[<a href="#RFC8528" class="xref">RFC8528</a>]</span> defines a mechanism,
        denoted "schema mount", that allows for mounting one data model
        consisting of any number of YANG modules at a specified location of
        another (parent) schema.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
</section>
<div id="rm">
<section id="section-a.3">
        <h2 id="name-network-models-samples">
<a href="#section-a.3" class="section-number selfRef">A.3. </a><a href="#name-network-models-samples" class="section-name selfRef">Network Models: Samples</a>
        </h2>
<p id="section-a.3-1">L2NM <span>[<a href="#I-D.ietf-opsawg-l2nm" class="xref">OPSAWG-L2NM</a>]</span> and L3NM <span>[<a href="#I-D.ietf-opsawg-l3sm-l3nm" class="xref">OPSAWG-L3SM-L3NM</a>]</span> are examples of YANG
        network models.<a href="#section-a.3-1" class="pilcrow">¶</a></p>
<p id="section-a.3-2"><a href="#rfn" class="xref">Figure 9</a> depicts a set of additional network
        models such as topology and tunnel models:<a href="#section-a.3-2" class="pilcrow">¶</a></p>
<span id="name-sample-resource-facing-netw"></span><div id="rfn">
<figure id="figure-9">
          <div class="artwork art-text alignCenter" id="section-a.3-3.1">
<pre>+-------------------------------+-------------------------------+
|      Topology YANG modules    |     Tunnel YANG modules       |
+-------------------------------+-------------------------------+
|  +------------------+         |                               |
|  |Network Topologies|         | +------+  +-----------+       |
|  |       Model      |         | |Other |  | TE Tunnel |       |
|  +--------+---------+         | |Tunnel|  +----+------+       |
|           |   +---------+     | +------+       |              |
|           +---+Service  |     |     +----------+---------+    |
|           |   |Topology |     |     |          |         |    |
|           |   +---------+     |     |          |         |    |
|           |   +---------+     |+----+---+ +----+---+ +---+---+|
|           +---+Layer 3  |     ||MPLS-TE | |RSVP-TE | | SR-TE ||
|           |   |Topology |     || Tunnel | | Tunnel | |Tunnel ||
|           |   +---------+     |+--------+ +--------+ +-------+|
|           |   +---------+     |                               |
|           +---+TE       |     |                               |
|           |   |Topology |     |                               |
|           |   +---------+     |                               |
|           |   +---------+     |                               |
|           +---+Layer 3  |     |                               |
|               |Topology |     |                               |
|               +---------+     |                               |
+-------------------------------+-------------------------------+</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-sample-resource-facing-netw" class="selfRef">Sample Resource-Facing Network Models</a>
          </figcaption></figure>
</div>
<p id="section-a.3-4"></p>
<p id="section-a.3-5">Examples of topology YANG modules are listed below:<a href="#section-a.3-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-a.3-6">
          <dt id="section-a.3-6.1">Network Topologies Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-6.2">
            <span>[<a href="#RFC8345" class="xref">RFC8345</a>]</span> defines a base model for network
topology and inventories. Network topology data includes link, node, and
terminate-point resources.<a href="#section-a.3-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-6.3">TE Topology Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-6.4">
            <p id="section-a.3-6.4.1"><span>[<a href="#RFC8795" class="xref">RFC8795</a>]</span> defines a YANG data model for
representing and manipulating TE topologies.<a href="#section-a.3-6.4.1" class="pilcrow">¶</a></p>
<p id="section-a.3-6.4.2">This module is extended from the network topology model defined in <span>[<a href="#RFC8345" class="xref">RFC8345</a>]</span> and includes content related to TE
  topologies. This model contains technology-agnostic TE topology building
  blocks that can be augmented and used by other technology-specific TE
  topology models.<a href="#section-a.3-6.4.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-6.5">Layer 3 Topology Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-6.6">
            <p id="section-a.3-6.6.1"><span>[<a href="#RFC8346" class="xref">RFC8346</a>]</span> defines a YANG data model
for representing and manipulating Layer 3 topologies. This model is extended
from the network topology model defined in <span>[<a href="#RFC8345" class="xref">RFC8345</a>]</span> and includes content related to Layer 3 topology specifics.<a href="#section-a.3-6.6.1" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-6.7">Layer 2 Topology Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-6.8">
            <p id="section-a.3-6.8.1"><span>[<a href="#RFC8944" class="xref">RFC8944</a>]</span> defines a YANG data model
for representing and manipulating Layer 2 topologies. This model is extended
from the network topology model defined in <span>[<a href="#RFC8345" class="xref">RFC8345</a>]</span> and includes content related to Layer 2 topology specifics.<a href="#section-a.3-6.8.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-a.3-7">Examples of tunnel YANG modules are provided below:<a href="#section-a.3-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-a.3-8">
          <dt id="section-a.3-8.1">Tunnel Identities:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-8.2">
            <span>[<a href="#RFC8675" class="xref">RFC8675</a>]</span> defines a collection of YANG
identities used as interface types for tunnel interfaces.<a href="#section-a.3-8.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-8.3">TE Tunnel Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-8.4">
            <span>[<a href="#I-D.ietf-teas-yang-te" class="xref">TEAS-YANG-TE</a>]</span> defines a YANG
module for the configuration and management of TE interfaces, tunnels, and
LSPs.<a href="#section-a.3-8.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-8.5">Segment Routing (SR) Traffic Engineering (TE) Tunnel Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-8.6">
            <span>[<a href="#I-D.ietf-teas-yang-te" class="xref">TEAS-YANG-TE</a>]</span> augments the TE
generic and MPLS-TE model(s) and defines a YANG module for SR-TE-specific
data.<a href="#section-a.3-8.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-8.7">MPLS-TE Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-8.8">
            <span>[<a href="#I-D.ietf-teas-yang-te" class="xref">TEAS-YANG-TE</a>]</span> augments the TE
generic and MPLS-TE model(s) and defines a YANG module for MPLS-TE
configurations, state, RPC, and notifications.<a href="#section-a.3-8.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-8.9">RSVP-TE MPLS Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-8.10">
            <span>[<a href="#I-D.ietf-teas-yang-rsvp-te" class="xref">TEAS-YANG-RSVP</a>]</span> augments the
RSVP-TE generic module with parameters to configure and manage signaling of
MPLS RSVP-TE LSPs.<a href="#section-a.3-8.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-a.3-9">Other sample network models are listed hereafter:<a href="#section-a.3-9" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-a.3-10">
          <dt id="section-a.3-10.1">Path Computation API Model:
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-10.2">
            <span>[<a href="#I-D.ietf-teas-yang-path-computation" class="xref">TEAS-YANG-PATH-COMP</a>]</span>
defines a YANG module for a stateless RPC that complements the stateful
solution defined in <span>[<a href="#I-D.ietf-teas-yang-te" class="xref">TEAS-YANG-TE</a>]</span>.<a href="#section-a.3-10.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-a.3-10.3">OAM Models (including Fault Management (FM) and Performance Monitoring):
</dt>
          <dd style="margin-left: 1.5em" id="section-a.3-10.4">
            <p id="section-a.3-10.4.1"><span>[<a href="#RFC8532" class="xref">RFC8532</a>]</span> defines a base YANG module for
 the management of OAM protocols that use Connectionless Communications. <span>[<a href="#RFC8533" class="xref">RFC8533</a>]</span> defines a retrieval method YANG module
 for connectionless OAM protocols. <span>[<a href="#RFC8531" class="xref">RFC8531</a>]</span>
 defines a base YANG module for connection-oriented OAM protocols. These three
 models are intended to provide consistent reporting, configuration, and
 representation for connectionless OAM and connection-oriented OAM
 separately.<a href="#section-a.3-10.4.1" class="pilcrow">¶</a></p>
<p id="section-a.3-10.4.2">Alarm monitoring is a fundamental part of monitoring the
            network. Raw alarms from devices do not always tell the status of
            the network services or necessarily point to the root cause. <span>[<a href="#RFC8632" class="xref">RFC8632</a>]</span> defines a YANG module for
            alarm management.<a href="#section-a.3-10.4.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<section id="section-a.4">
        <h2 id="name-device-models-samples">
<a href="#section-a.4" class="section-number selfRef">A.4. </a><a href="#name-device-models-samples" class="section-name selfRef">Device Models: Samples</a>
        </h2>
<p id="section-a.4-1">Network Element models (listed in <a href="#device" class="xref">Figure 10</a>)
        are used to describe how a service can be implemented by activating
        and tweaking a set of functions (enabled in one or multiple devices,
        or hosted in cloud infrastructures) that are involved in the service
        delivery. For example, the L3VPN service will involve many PEs and
        require manipulating the following modules:<a href="#section-a.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-a.4-2.1">Routing management <span>[<a href="#RFC8349" class="xref">RFC8349</a>]</span><a href="#section-a.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-2.2">BGP <span>[<a href="#I-D.ietf-idr-bgp-model" class="xref">IDR-BGP-MODEL</a>]</span><a href="#section-a.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-2.3">PIM <span>[<a href="#I-D.ietf-pim-yang" class="xref">PIM-YANG</a>]</span><a href="#section-a.4-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-2.4">NAT management <span>[<a href="#RFC8512" class="xref">RFC8512</a>]</span><a href="#section-a.4-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-2.5">QoS management <span>[<a href="#I-D.ietf-rtgwg-qos-model" class="xref">QOS-MODEL</a>]</span><a href="#section-a.4-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-a.4-2.6">ACLs <span>[<a href="#RFC8519" class="xref">RFC8519</a>]</span><a href="#section-a.4-2.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-a.4-3"><a href="#device" class="xref">Figure 10</a> uses IETF-defined data models
        as an example.<a href="#section-a.4-3" class="pilcrow">¶</a></p>
<span id="name-network-element-models-over"></span><div id="device">
<figure id="figure-10">
          <div class="artwork art-text alignLeft" id="section-a.4-4.1">
<pre>                                        +------------------------+
                                      +-+     Device Model       |
                                      | +------------------------+
                                      | +------------------------+
                  +---------------+   | |   Logical Network      |
                  |               |   +-+     Element Model      |
                  | Architecture  |   | +------------------------+
                  |               |   | +------------------------+
                  +-------+-------+   +-+ Network Instance Model |
                          |           | +------------------------+
                          |           | +------------------------+
                          |           +-+   Routing Type Model   |
                          |             +------------------------+
  +-------+----------+----+------+------------+-----------+------+
  |       |          |           |            |           |      |
+-+-+ +---+---+ +----+----+   +--+--+    +----+----+   +--+--+   |
|ACL| |Routing| |Transport|   | OAM |    |Multicast|   |  PM | Others
+---+ +-+-----+ +----+----+   +--+--+    +-----+---+   +--+--+
        | +-------+  | +------+  | +--------+  | +-----+  | +-----+
        +-+Core   |  +-+ MPLS |  +-+  BFD   |  +-+IGMP |  +-+TWAMP|
        | |Routing|  | | Base |  | +--------+  | |/MLD |  | +-----+
        | +-------+  | +------+  | +--------+  | +-----+  | +-----+
        | +-------+  | +------+  +-+LSP Ping|  | +-----+  +-+OWAMP|
        +-+  BGP  |  +-+ MPLS |  | +--------+  +-+ PIM |  | +-----+
        | +-------+  | | LDP  |  | +--------+  | +-----+  | +-----+
        | +-------+  | +------+  +-+MPLS-TP |  | +-----+  +-+LMAP |
        +-+  ISIS |  | +------+    +--------+  +-+ MVPN|    +-----+
        | +-------+  +-+ MPLS |                  +-----+
        | +-------+    |Static|
        +-+  OSPF |    +------+
        | +-------+
        | +-------+
        +-+  RIP  |
        | +-------+
        | +-------+
        +-+  VRRP |
        | +-------+
        | +-------+
        +-+SR/SRv6|
        | +-------+
        | +-------+
        +-+ISIS-SR|
        | +-------+
        | +-------+
        +-+OSPF-SR|
          +-------+</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-network-element-models-over" class="selfRef">Network Element Models Overview</a>
          </figcaption></figure>
</div>
<section id="section-a.4.1">
          <h3 id="name-model-composition">
<a href="#section-a.4.1" class="section-number selfRef">A.4.1. </a><a href="#name-model-composition" class="section-name selfRef">Model Composition</a>
          </h3>
<span class="break"></span><dl class="dlNewline" id="section-a.4.1-1">
            <dt id="section-a.4.1-1.1">Logical Network Element Model:
</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.1-1.2">
              <span>[<a href="#RFC8530" class="xref">RFC8530</a>]</span> defines a logical network
element model that can be used to manage the logical resource partitioning
that may be present on a network device. Examples of common industry terms for
logical resource partitioning are Logical Systems or Logical Routers.<a href="#section-a.4.1-1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.1-1.3">Network Instance Model:
</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.1-1.4">
              <span>[<a href="#RFC8529" class="xref">RFC8529</a>]</span> defines a network instance
module. This module can be used to manage the virtual resource partitioning
that may be present on a network device. Examples of common industry terms for
virtual resource partitioning are VRF instances and Virtual Switch Instances
(VSIs).<a href="#section-a.4.1-1.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
<section id="section-a.4.2">
          <h3 id="name-device-management">
<a href="#section-a.4.2" class="section-number selfRef">A.4.2. </a><a href="#name-device-management" class="section-name selfRef">Device Management</a>
          </h3>
<p id="section-a.4.2-1">The following list enumerates some YANG modules that can be used
          for device management:<a href="#section-a.4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-a.4.2-2.1">
              <span>[<a href="#RFC8348" class="xref">RFC8348</a>]</span> defines a YANG module for the
              management of hardware.<a href="#section-a.4.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-a.4.2-2.2">
              <span>[<a href="#RFC7317" class="xref">RFC7317</a>]</span> defines the "ietf-system"
              YANG module that provides many features such as the
              configuration and the monitoring of system or system control
              operations (e.g., shutdown, restart, and setting time)
              identification.<a href="#section-a.4.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-a.4.2-2.3">
              <span>[<a href="#RFC8341" class="xref">RFC8341</a>]</span> defines a network
              configuration access control YANG module.<a href="#section-a.4.2-2.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
<section id="section-a.4.3">
          <h3 id="name-interface-management">
<a href="#section-a.4.3" class="section-number selfRef">A.4.3. </a><a href="#name-interface-management" class="section-name selfRef">Interface Management</a>
          </h3>
<p id="section-a.4.3-1">The following provides some YANG modules that can be used for
          interface management:<a href="#section-a.4.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-a.4.3-2.1">
              <span>[<a href="#RFC7224" class="xref">RFC7224</a>]</span> defines a YANG module for
              interface type definitions.<a href="#section-a.4.3-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-a.4.3-2.2">
              <span>[<a href="#RFC8343" class="xref">RFC8343</a>]</span> defines a YANG module for the
              management of network interfaces.<a href="#section-a.4.3-2.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
<div id="sample">
<section id="section-a.4.4">
          <h3 id="name-some-device-model-examples">
<a href="#section-a.4.4" class="section-number selfRef">A.4.4. </a><a href="#name-some-device-model-examples" class="section-name selfRef">Some Device Model Examples</a>
          </h3>
<p id="section-a.4.4-1">The following provides an overview of some device models that can
          be used within a network. This list is not comprehensive.<a href="#section-a.4.4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-a.4.4-2">
            <dt id="section-a.4.4-2.1">L2VPN:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.2">
              <span>[<a href="#I-D.ietf-bess-l2vpn-yang" class="xref">L2VPN-YANG</a>]</span>
              defines a YANG module for MPLS-based Layer 2 VPN services
              (L2VPN) <span>[<a href="#RFC4664" class="xref">RFC4664</a>]</span> and includes
              switching between the local attachment circuits. The L2VPN model
              covers point-to-point Virtual Private Wire Service (VPWS) and
              Multipoint Virtual Private LAN Service (VPLS). These
              services use signaling of Pseudowires across MPLS networks using
              LDP <span>[<a href="#RFC8077" class="xref">RFC8077</a>]</span><span>[<a href="#RFC4762" class="xref">RFC4762</a>]</span> or BGP <span>[<a href="#RFC4761" class="xref">RFC4761</a>]</span>.<a href="#section-a.4.4-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.3">EVPN:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.4">
              <span>[<a href="#I-D.ietf-bess-evpn-yang" class="xref">EVPN-YANG</a>]</span>
              defines a YANG module for Ethernet VPN services. The model is
              agnostic of the underlay. It applies to MPLS as well as to
              Virtual eXtensible Local Area Network (VxLAN) encapsulation.
              The module is also agnostic to the services, including E-LAN,
              E-LINE, and E-TREE services.<a href="#section-a.4.4-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.5">L3VPN:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.6">
              <span>[<a href="#I-D.ietf-bess-l3vpn-yang" class="xref">L3VPN-YANG</a>]</span>
              defines a YANG module that can be used to configure and manage
              BGP L3VPNs <span>[<a href="#RFC4364" class="xref">RFC4364</a>]</span>. It
              contains VRF-specific parameters as well as BGP-specific
              parameters applicable for L3VPNs.<a href="#section-a.4.4-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.7">Core Routing:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.8">
              <span>[<a href="#RFC8349" class="xref">RFC8349</a>]</span>
              defines the core routing YANG data model, which is intended as a
              basis for future data model development covering
              more-sophisticated routing systems. It is expected that other
              Routing technology YANG modules (e.g., VRRP, RIP, ISIS, or OSPF
              models) will augment the Core Routing base YANG module.<a href="#section-a.4.4-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.9">MPLS:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.10">
              <span>[<a href="#RFC8960" class="xref">RFC8960</a>]</span> defines a base model
              for MPLS that serves as a base framework for configuring and
              managing an MPLS switching subsystem. It is expected that other
              MPLS technology YANG modules (e.g., MPLS LSP Static, LDP, or
              RSVP-TE models) will augment the MPLS base YANG module.<a href="#section-a.4.4-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.11">BGP:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.12">
              <span>[<a href="#I-D.ietf-idr-bgp-model" class="xref">IDR-BGP-MODEL</a>]</span>
              defines a YANG module for configuring and managing BGP,
              including protocol, policy, and operational aspects based on
              data center, carrier, and content provider operational
              requirements.<a href="#section-a.4.4-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.13">Routing Policy:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.14">
              <span>[<a href="#I-D.ietf-rtgwg-policy-model" class="xref">RTGWG-POLICY</a>]</span> defines a YANG
              module for configuring and managing routing policies based on
              operational practice. The module provides a generic policy
              framework that can be augmented with protocol-specific policy
              configuration.<a href="#section-a.4.4-2.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.15">SR/SRv6:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.16">
              <p id="section-a.4.4-2.16.1"><span>[<a href="#I-D.ietf-spring-sr-yang" class="xref">SPRING-SR-YANG</a>]</span> 
              defines a YANG module for segment routing configuration and
              operation.<a href="#section-a.4.4-2.16.1" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.16.2"></p>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.17">BFD:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.18">Bidirectional Forwarding Detection (BFD)
              <span>[<a href="#RFC5880" class="xref">RFC5880</a>]</span> is a network protocol that is
              used for liveness detection of arbitrary paths between systems.
              <span>[<a href="#I-D.ietf-bfd-yang" class="xref">BFD-YANG</a>]</span> defines a YANG module
              that can be used to configure and manage BFD.<a href="#section-a.4.4-2.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.19">Multicast:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.20">
              <p id="section-a.4.4-2.20.1"><span>[<a href="#I-D.ietf-pim-yang" class="xref">PIM-YANG</a>]</span> defines a YANG module that
              can be used to configure and manage Protocol Independent
              Multicast (PIM) devices.<a href="#section-a.4.4-2.20.1" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.20.2"><span>[<a href="#RFC8652" class="xref">RFC8652</a>]</span> defines a YANG module that can be used
              to configure and manage Internet Group Management Protocol
              (IGMP) and Multicast Listener Discovery (MLD) devices.<a href="#section-a.4.4-2.20.2" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.20.3"><span>[<a href="#I-D.ietf-pim-igmp-mld-snooping-yang" class="xref">SNOOPING-YANG</a>]</span> defines a
              YANG module that can be used to configure and manage Internet
              Group Management Protocol (IGMP) and Multicast Listener
              Discovery (MLD) snooping devices.<a href="#section-a.4.4-2.20.3" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.20.4"><span>[<a href="#I-D.ietf-bess-mvpn-yang" class="xref">MVPN-YANG</a>]</span> defines a YANG data
              model to configure and manage Multicast in MPLS/BGP IP VPNs
              (MVPNs).<a href="#section-a.4.4-2.20.4" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.21">PM:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.22">
              <p id="section-a.4.4-2.22.1"><span>[<a href="#I-D.ietf-ippm-twamp-yang" class="xref">TWAMP-DATA-MODEL</a>]</span> defines a YANG data
              model for client and server implementations of the Two-Way
              Active Measurement Protocol (TWAMP).<a href="#section-a.4.4-2.22.1" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.22.2"><span>[<a href="#I-D.ietf-ippm-stamp-yang" class="xref">STAMP-YANG</a>]</span>
              defines the data model for implementations of Session-Sender and
              Session-Reflector for Simple Two-way Active Measurement Protocol
              (STAMP) mode using YANG.<a href="#section-a.4.4-2.22.2" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.22.3"><span>[<a href="#RFC8194" class="xref">RFC8194</a>]</span> defines a YANG data model for
              Large-Scale Measurement Platforms (LMAPs).<a href="#section-a.4.4-2.22.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.23">ACL:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.24">An Access Control List (ACL) is one of the basic
              elements used to configure device-forwarding behavior. It is
              used in many networking technologies such as Policy-Based
              Routing, firewalls, etc. <span>[<a href="#RFC8519" class="xref">RFC8519</a>]</span>
              describes a YANG data model of ACL basic building blocks.<a href="#section-a.4.4-2.24" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.25">QoS:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.26">
              <span>[<a href="#I-D.ietf-rtgwg-qos-model" class="xref">QOS-MODEL</a>]</span> describes a YANG
              module of Differentiated Services for configuration and
              operations.<a href="#section-a.4.4-2.26" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.27">NAT:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.28">
              <p id="section-a.4.4-2.28.1">For the sake of network automation and the need for
              programming the Network Address Translation (NAT) function in
              particular, a YANG data model for configuring and managing the
              NAT is essential.<a href="#section-a.4.4-2.28.1" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.28.2"><span>[<a href="#RFC8512" class="xref">RFC8512</a>]</span> defines a YANG module for the NAT
              function covering a variety of NAT flavors such as Network
              Address Translation from IPv4 to IPv4 (NAT44), Network Address
              and Protocol Translation from IPv6 Clients to IPv4 Servers
              (NAT64), customer-side translator (CLAT), Stateless IP/ICMP
              Translation (SIIT), Explicit Address Mappings (EAMs) for SIIT,
              IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination
              NAT.<a href="#section-a.4.4-2.28.2" class="pilcrow">¶</a></p>
<p id="section-a.4.4-2.28.3"><span>[<a href="#RFC8513" class="xref">RFC8513</a>]</span>
              specifies a Dual-Stack Lite (DS-Lite) YANG module.<a href="#section-a.4.4-2.28.3" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
<dt id="section-a.4.4-2.29">Stateless Address Sharing:</dt>
            <dd style="margin-left: 1.5em" id="section-a.4.4-2.30">
              <span>[<a href="#RFC8676" class="xref">RFC8676</a>]</span> specifies a YANG
              module for Address plus Port (A+P) address sharing, including
              Lightweight 4over6, Mapping of Address and Port with
              Encapsulation (MAP-E), and Mapping of Address and Port using
              Translation (MAP-T) softwire mechanisms.<a href="#section-a.4.4-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</section>
</div>
<div id="ack">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">Thanks to <span class="contact-name">Joe Clark</span>, <span class="contact-name">Greg       Mirsky</span>, <span class="contact-name">Shunsuke Homma</span>, <span class="contact-name">Brian Carpenter</span>,
      <span class="contact-name">Adrian Farrel</span>, <span class="contact-name">Christian       Huitema</span>, <span class="contact-name">Tommy Pauly</span>, <span class="contact-name">Ines       Robles</span>, and <span class="contact-name">Olivier       Augizeau</span> for the review.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">Many thanks to <span class="contact-name">Robert Wilton</span> for the detailed AD review.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
<p id="section-appendix.b-3">Thanks to <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Roman       Danyliw</span>, <span class="contact-name">Erik Kline</span>, and <span class="contact-name">Benjamin       Kaduk</span> for the IESG review.<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-appendix.c">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christian Jacquenet</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left"><span class="locality">Rennes, 35000</span></div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Christian.jacquenet@orange.com" class="email">Christian.jacquenet@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Luis Miguel Contreras Murillo</span></div>
<div dir="auto" class="left"><span class="org">Telefonica</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:luismiguel.contrerasmurillo@telefonica.com" class="email">luismiguel.contrerasmurillo@telefonica.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Oscar Gonzalez de Dios</span></div>
<div dir="auto" class="left"><span class="org">Telefonica</span></div>
<div dir="auto" class="left">
<span class="locality">Madrid</span> </div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:oscar.gonzalezdedios@telefonica.com" class="email">oscar.gonzalezdedios@telefonica.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Weiqiang Cheng</span></div>
<div dir="auto" class="left"><span class="org">China Mobile</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:chengweiqiang@chinamobile.com" class="email">chengweiqiang@chinamobile.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Young Lee</span></div>
<div dir="auto" class="left"><span class="org">Sung Kyun Kwan University</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:younglee.tx@gmail.com" class="email">younglee.tx@gmail.com</a>
</div>
</address>
</section>
<div id="authors-addresses">
<section id="section-appendix.d">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Qin Wu (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Huawei</span></div>
<div dir="auto" class="left"><span class="street-address">101 Software Avenue</span></div>
<div dir="auto" class="left"><span class="locality">Yuhua District</span></div>
<div dir="auto" class="left"><span class="locality">Nanjing</span></div>
<div dir="auto" class="left">
<span class="region">Jiangsu</span>, <span class="postal-code">210012</span>
</div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:bill.wu@huawei.com" class="email">bill.wu@huawei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mohamed Boucadair (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left"><span class="street-address">Rennes 35000</span></div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mohamed.boucadair@orange.com" class="email">mohamed.boucadair@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Diego R. Lopez</span></div>
<div dir="auto" class="left"><span class="org">Telefonica I+D</span></div>
<div dir="auto" class="left"><span class="country-name">Spain</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:diego.r.lopez@telefonica.com" class="email">diego.r.lopez@telefonica.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Chongfeng Xie</span></div>
<div dir="auto" class="left"><span class="org">China Telecom</span></div>
<div dir="auto" class="left"><span class="locality">Beijing</span></div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:xiechf@chinatelecom.cn" class="email">xiechf@chinatelecom.cn</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Liang Geng</span></div>
<div dir="auto" class="left"><span class="org">China Mobile</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:gengliang@chinamobile.com" class="email">gengliang@chinamobile.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>