rfc8960xml2.original.xml   rfc8960.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-mpls-base-yang-17" category="std">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
docName="draft-ietf-mpls-base-yang-17" number="8960" category="std"
obsoletes="" updates="" submissionType="IETF" consensus="true"
xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"
version="3">
<!-- xml2rfc v2v3 conversion 3.3.0 -->
<front> <front>
<title abbrev="MPLS Base YANG Data Model">A YANG Data Model for MPLS Base</t itle> <title abbrev="MPLS Base YANG Data Model">A YANG Data Model for MPLS Base</t itle>
<seriesInfo name="RFC" value="8960"/>
<author initials="T." surname="Saad" fullname="Tarek Saad"> <author initials="T." surname="Saad" fullname="Tarek Saad">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>tsaad@juniper.net</email> <email>tsaad@juniper.net</email>
</address> </address>
</author> </author>
<author initials="K." surname="Raza" fullname="Kamran Raza"> <author initials="K." surname="Raza" fullname="Kamran Raza">
<organization>Cisco Systems Inc</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>skraza@cisco.com</email> <email>skraza@cisco.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Gandhi" fullname="Rakesh Gandhi"> <author initials="R." surname="Gandhi" fullname="Rakesh Gandhi">
<organization>Cisco Systems Inc</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<email>rgandhi@cisco.com</email> <email>rgandhi@cisco.com</email>
</address> </address>
</author> </author>
<author initials="X." surname="Liu" fullname="Xufeng Liu"> <author initials="X." surname="Liu" fullname="Xufeng Liu">
<organization>Volta Networks</organization> <organization>Volta Networks</organization>
<address> <address>
<email>xufeng.liu.ietf@gmail.com</email> <email>xufeng.liu.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author initials="V.P." surname="Beeram" fullname="Vishnu Pavan Beeram"> <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>vbeeram@juniper.net</email> <email>vbeeram@juniper.net</email>
</address> </address>
</author> </author>
<date year="2020" month="December"/>
<date year="2020" month="October" day="26"/> <keyword>MPLS YANG Data Model</keyword>
<keyword>MPLS Model</keyword>
<workgroup>MPLS Working Group</workgroup> <keyword>MPLS RIB</keyword>
<keyword>Internet-Draft</keyword> <keyword>MPLS Routing Information Base</keyword>
<abstract> <abstract>
<t>This document contains a specification of the MPLS base YANG data model
<t>This document contains a specification of the MPLS base YANG data model. The . The MPLS
MPLS
base YANG data model serves as a base framework for configuring and managing an MPLS base YANG data model serves as a base framework for configuring and managing an MPLS
switching subsystem on an MPLS-enabled router. It is expected that other MPLS switching subsystem on an MPLS-enabled router. It is expected that other MPLS
YANG data models (e.g. MPLS Label Switched Path (LSP) Static, LDP or RSVP-TE YAN YANG data models (e.g., MPLS Label Switched Path (LSP) static, LDP, or RSVP-TE
G YANG data models) will augment the MPLS base YANG data model.
models) will augment the MPLS base YANG data model.</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>A core routing YANG data model is defined in <xref target="RFC8349" for
<t>A core routing YANG data model is defined in <xref target="RFC8349"/>, and it mat="default"/>; it provides a basis
provides a basis
for the development of routing data models for specific Address Families (AFs). for the development of routing data models for specific Address Families (AFs).
Specifically, <xref target="RFC8349"/> defines a model for a generic Routing Inf Specifically, <xref target="RFC8349" format="default"/> defines a model for a ge
ormation neric Routing Information
Base (RIB) that is Address-Family (AF) agnostic. <xref target="RFC8349"/> also d Base (RIB) that is AF agnostic. <xref target="RFC8349" format="default"/> also d
efines two efines two
instances of RIBs based on the generic RIB model for IPv4 and IPv6 AFs.</t> instances of RIBs based on the generic RIB model for IPv4 and IPv6 AFs.</t>
<t>The MPLS base model defined in this document augments the generic RIB m
<t>The MPLS base model that is defined in this document augments the generic RIB odel
model defined in <xref target="RFC8349" format="default"/> with additional data that e
defined in <xref target="RFC8349"/> with additional data that enables MPLS nables MPLS
forwarding for the specific destination prefix(es) present in the AF RIB(s) as d forwarding for one or more specific destination prefixes present in one or more
escribed in AF RIBs, as described in
the MPLS architecture document <xref target="RFC3031"/>.</t> the MPLS architecture document <xref target="RFC3031" format="default"/>.</t>
<t>The MPLS base model also defines a new instance of the generic RIB YANG
<t>The MPLS base model also defines a new instance of the generic RIB YANG data data model as
model as defined in <xref target="RFC8349" format="default"/> to store native MPLS routes
defined in <xref target="RFC8349"/> to store native MPLS routes. The native MPLS . The native MPLS RIB
RIB instance stores one or more routes that are not associated with other AF instanc
instance stores route(s) that are not associated with other AF instance RIBs e RIBs
(such as IPv4, or IPv6 instance RIB(s)), but are enabled for MPLS forwarding. (such as IPv4 or IPv6 instance RIBs) but are enabled for MPLS forwarding.
Examples of such native MPLS routes are routes programmed by RSVP on Examples of such native MPLS routes are routes programmed by RSVP on
transit MPLS router(s) along the path of a Label Switched Path (LSP). Other exam one or more transit MPLS routers along the path of a Label Switched Path (LSP).
ple(s) are Other examples are
MPLS routes that cross-connect to specific Layer-2 adjacencies, such as Layer-2 MPLS routes that cross-connect to specific Layer 2 adjacencies, such as Layer 2
Attachment Circuit(s) (ACs)), or Layer-3 adjacencies, such as Segment-Routing Attachment Circuits (ACs); or Layer 3 adjacencies, such as Segment Routing
(SR) Adjacency Segments (Adj-SIDs) described in <xref target="RFC8402"/>.</t> (SR) Adjacency Segments (Adj-SIDs) as described in <xref target="RFC8402" format
="default"/>.</t>
<t>The MPLS base YANG data model serves as a basis for future development of MPL <t>The MPLS base YANG data model serves as a basis for future development
S YANG data of MPLS YANG data
models covering more-sophisticated MPLS feature(s) and sub-system(s). The main models covering MPLS features and subsystems that are more
sophisticated. The main
purpose is to provide essential building blocks for other YANG data models invol ving purpose is to provide essential building blocks for other YANG data models invol ving
different control-plane protocols, and MPLS functions.</t> different control-plane protocols and MPLS functions.</t>
<t>To this end, it is expected that the MPLS base data model will be augme
<t>To this end, it is expected that the MPLS base data model will be augmented b nted by
y a number of other YANG modules developed by the IETF (e.g., by the TEAS and MPLS
a number of other YANG modules developed at IETF (e.g. by TEAS and MPLS working Working
groups).</t> Groups).</t>
<t>The YANG module defined in this document conforms to the Network Manage
<t>The YANG module in this document conforms to the Network Management Datastore ment Datastore
Architecture (NMDA) <xref target="RFC8342"/>.</t> Architecture (NMDA) <xref target="RFC8342" format="default"/>.</t>
<section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The terminology for describing YANG data models is found in <xref tar
<t>The terminology for describing YANG data models is found in <xref target="RFC get="RFC7950" format="default"/>.</t>
7950"/>.</t> </section>
<section anchor="acronyms-and-abbreviations" numbered="true" toc="default"
</section> >
<section anchor="acronyms-and-abbreviations" title="Acronyms and Abbreviations"> <name>Acronyms and Abbreviations</name>
<dl newline="false" spacing="normal">
<t><list style='empty'> <dt>MPLS:</dt><dd>Multiprotocol Label Switching</dd>
<t>MPLS: Multiprotocol Label Switching</t> <dt>RIB:</dt><dd>Routing Information Base</dd>
</list></t> <dt>LSP:</dt><dd>Label Switched Path</dd>
<dt>LSR:</dt><dd>Label Switching Router</dd>
<t><list style='empty'> <dt>NHLFE:</dt><dd>Next Hop Label Forwarding Entry</dd>
<t>RIB: Routing Information Base</t> </dl>
</list></t> </section>
</section>
<t><list style='empty'> <section anchor="mpls-base-model" numbered="true" toc="default">
<t>LSP: Label Switched Path</t> <name>MPLS Base Model</name>
</list></t> <t>This document describes the "ietf-mpls" YANG module, which provides bas
e components
<t><list style='empty'>
<t>LSR: Label Switching Router</t>
</list></t>
<t><list style='empty'>
<t>LER: Label Edge Router</t>
</list></t>
<t><list style='empty'>
<t>FEC: Forwarding Equivalence Class</t>
</list></t>
<t><list style='empty'>
<t>NHLFE: Next Hop Label Forwarding Entry</t>
</list></t>
<t><list style='empty'>
<t>ILM: Incoming Label Map</t>
</list></t>
</section>
</section>
<section anchor="mpls-base-model" title="MPLS Base Model">
<t>This document describes the ‘ietf-mpls’ YANG module that provides base compon
ents
of the MPLS data model. It is expected that other MPLS YANG modules will of the MPLS data model. It is expected that other MPLS YANG modules will
augment ‘ietf-mpls’ YANG module for other MPLS extension to provision Label Swit augment the "ietf-mpls" YANG module for other MPLS extensions to provision
ched Paths (LSPs) LSPs (e.g., MPLS static, MPLS LDP, or MPLS RSVP-TE LSPs).</t>
(e.g. MPLS Static, MPLS LDP or MPLS RSVP-TE LSP(s)).</t> <section anchor="model-overview" numbered="true" toc="default">
<name>Model Overview</name>
<section anchor="model-overview" title="Model Overview"> <t>This document models MPLS-labeled routes as an
augmentation of the generic routing RIB data model as defined in <xref target="R
<t>This document models MPLS labeled routes as an FC8349" format="default"/>.
augmentation of the generic routing RIB data model as defined in <xref target="R For example, IP prefix routes (e.g., routes stored in IPv4 or IPv6 RIBs) are
FC8349"/>. augmented to carry additional data to enable them for MPLS forwarding.
For example, IP prefix routes (e.g. routes stored in IPv4 or IPv6 RIBs) are </t>
augmented to carry additional data to enable it for MPLS forwarding.</t> <t>This document also defines a new instance of the generic RIB model de
fined in
<t>This document also defines a new instance of the generic RIB defined in <xref target="RFC8349" format="default"/> to store one or more native MPLS route
<xref target="RFC8349"/> to store native MPLS route(s) (described further in s (described further in
<xref target="model-design"/>) by extending the identity ‘address-family’ define <xref target="model-design" format="default"/>) by extending the identity "addre
d in ss-family" defined in
<xref target="RFC8349"/> with a new “mpls” identity as suggested in Section 3 of <xref target="RFC8349" format="default"/> with a new "mpls" identity;
<xref target="RFC8349"/>.</t> see <xref target="RFC8349" sectionFormat="of" section="3"/>.
</t>
</section> </section>
<section anchor="model-organization" title="Model Organization"> <section anchor="model-organization" numbered="true" toc="default">
<name>Model Organization</name>
<figure title="Relationship between MPLS modules" anchor="fig-mpls-relation"><ar <figure anchor="fig-mpls-relation">
twork><![CDATA[ <name>Relationship between MPLS Modules</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Routing +---------------+ v: import Routing +---------------+ v: import
YANG module | ietf-routing | o: augment YANG module | ietf-routing | o: augment
+---------------+ +---------------+
o o
| |
v v
MPLS base +-----------+ v: import MPLS base +-----------+ v: import
YANG module | ietf-mpls | o: augment YANG module | ietf-mpls | o: augment
+-----------+ +-----------+
o o------+ o o------+
| \ | \
v v v v
+-------------------+ +---------------------+ +-------------------+ +---------------------+
MPLS Static | ietf-mpls-static@ | | ietf-mpls-ldp.yang@ | . . MPLS static | ietf-mpls-static@ | | ietf-mpls-ldp.yang@ | . .
LSP YANG +-------------------+ +---------------------+ LSP YANG +-------------------+ +---------------------+
module module
@: not in this document, shown for illustration only
]]></artwork></figure>
<t>The ‘ietf-mpls’ YANG module defines the following identities:</t> @: not in this document; shown for illustration only]]></artwork>
</figure>
<t>mpls:</t> <t>The "ietf-mpls" YANG module defines the following identities:</t>
<t><list style='empty'>
<t>This identity extends the ‘address-family’ identity for RIB instance(s) ide
ntity as defined in <xref target="RFC8349"/> to represent the native MPLS RIB in
stance.</t>
</list></t>
<t>label-block-alloc-mode:</t>
<t><list style='empty'>
<t>A base YANG identity for supported label block allocation mode(s).</t>
</list></t>
<t>The ‘ietf-mpls’ YANG module contains the following high-level types and group
ings:</t>
<t>mpls-operations-type:</t>
<t><list style='empty'>
<t>An enumeration type that represents support for possible MPLS operation typ
es (impose-and-forward, pop-and-forward, pop-impose-and-forward, and pop-and-loo
kup)</t>
</list></t>
<t>nhlfe-role:</t>
<t><list style='empty'>
<t>An enumeration type that represents the role of the NHLFE entry.</t>
</list></t>
<t>nhlfe-single-contents:</t>
<t><list style='empty'>
<t>A YANG grouping that describes single Next Hop Label Forwarding Entry (NHLF
E) and its associated parameters as described in the MPLS architecture document
<xref target="RFC3031"/>. This grouping is
specific to the case when a single next-hop is associated with the route.</t>
</list></t>
<t>The NHLFE is used when forwarding labeled packet. It contains the following
information:</t>
<t><list style="numbers"> <dl newline="true" spacing="normal">
<t>the packet’s next hop. For ‘nhlfe-single-contents’ only a single next hop i <dt>mpls:</dt>
s expected, while for <dd>Identity that extends the "address-family" identity of RIB
‘nhlfe-multiple-contents’ multiple next hops are possible.</t> instances, as defined in <xref target="RFC8349"
<t>the operation to perform on the packet’s label stack; this can be one format="default"/>, to represent the native MPLS RIB instance.</dd>
of the following operations: <dt>label-block-alloc-mode:</dt>
a) replace the label at the top of the label stack with one or more <dd>A base YANG identity for one or more supported label-block allocat
specified new label ion modes.</dd>
b) pop the label stack </dl>
c) replace the label at the top of the label stack with a <t>The "ietf-mpls" YANG module contains the following high-level types
and groupings:</t>
<dl newline="true" spacing="normal">
<dt>mpls-operations-type:</dt>
<dd>An enumeration type that represents support for possible MPLS oper
ation types (impose-and-forward, pop-and-forward, pop-impose-and-forward, and po
p-and-lookup).</dd>
<dt>nhlfe-role:</dt>
<dd>An enumeration type that represents the role of the
Next Hop Label Forwarding Entry (NHLFE).</dd>
<dt>nhlfe-single-contents:</dt>
<dd>A YANG grouping that describes a single NHLFE and its associated p
arameters as described in the MPLS architecture document <xref target="RFC3031"
format="default"/>. This grouping is
specific to the case when a single next hop is associated with the route.</dd>
</dl>
<t>The NHLFE is used when forwarding a labeled packet. It contains the
following information:</t>
<ol spacing="normal" type="1">
<li>The packet's next hop. For "nhlfe-single-contents", only a single
next hop is expected, while for
"nhlfe-multiple-contents", multiple next hops are possible.</li>
<li><t>The operation to perform on the packet's label stack. This
can be one of the following operations:</t>
<ol type="%c.">
<li>Replace the label at the top of the label stack with one or more
specified new labels.</li>
<li>Pop the label stack.</li>
<li>Replace the label at the top of the label stack with a
specified new label, and then push one or more specified new specified new label, and then push one or more specified new
labels onto the label stack. labels onto the label stack.</li>
d) push one or more label(s) on an unlabeled packet</t> <li>Push one or more labels onto an unlabeled packet.</li>
</list></t> </ol>
</li>
<t>It may also contain:</t> </ol>
<t>The NHLFE may also contain:</t>
<figure><artwork><![CDATA[ <ol spacing="normal" type="1">
d) the data link encapsulation to use when transmitting the packet <li>The data-link encapsulation to use when transmitting the packet.</li>
<li>The way to encode the label stack when transmitting the packet.</li>
e) the way to encode the label stack when transmitting the packet <li>Any other information needed in order to properly dispose of
the packet.</li>
f) any other information needed in order to properly dispose of </ol>
the packet.
]]></artwork></figure>
<t>nhlfe-multiple-contents:</t>
<t><list style='empty'>
<t>A YANG grouping that describes a set of NHLFE(s) and their associated param
eters as described in the MPLS architecture document <xref target="RFC3031"/>. T
his grouping
is used when multiple next-hops are associated with the route.</t>
</list></t>
<t>interfaces-mpls:</t>
<t><list style='empty'>
<t>A YANG grouping that describes the list of MPLS enabled interfaces on a dev
ice.</t>
</list></t>
<t>label-blocks:</t>
<t><list style='empty'>
<t>A YANG grouping that describes the list of assigned MPLS label blocks and t
heir properties.</t>
</list></t>
<t>rib-mpls-properties:</t>
<t><list style='empty'>
<t>A YANG grouping for the augmentation of the generic RIB with MPLS label for
warding data as defined in <xref target="RFC3031"/>.</t>
</list></t>
<t>rib-active-route-mpls-input:</t>
<t><list style='empty'>
<t>A YANG grouping for the augmentation to the ‘active-route’ RPC that is spec
ific to the MPLS RIB instance.</t>
</list></t>
</section>
<section anchor="model-design" title="Model Design">
<t>The MPLS routing model is based on the core routing data model defined in <xr
ef target="RFC8349"/>.
<xref target="fig-mpls-rib-relation"/> shows the extensions introduced by the MP
LS base model on defined RIB(s).</t>
<figure title="Relationship between MPLS model and RIB instances" anchor="fig-mp <dl newline="true" spacing="normal">
ls-rib-relation"><artwork><![CDATA[ <dt>nhlfe-multiple-contents:</dt>
<dd>A YANG grouping that describes a set of NHLFEs and their associate
d parameters as described in the MPLS architecture document <xref target="RFC303
1" format="default"/>. This grouping
is used when multiple next hops are associated with the route.</dd>
<dt>interfaces-mpls:</dt>
<dd>A YANG grouping that describes the list of MPLS-enabled interfaces
on a device.</dd>
<dt>label-blocks:</dt>
<dd>A YANG grouping that describes the list of assigned MPLS label blo
cks and their properties.</dd>
<dt>rib-mpls-properties:</dt>
<dd>A YANG grouping for the augmentation of the generic RIB with MPLS
label forwarding data as defined in <xref target="RFC3031" format="default"/>.</
dd>
<dt>rib-active-route-mpls-input:</dt>
<dd>A YANG grouping for the augmentation to the "active-route" RPC tha
t is specific to the MPLS RIB instance.</dd>
</dl>
</section>
<section anchor="model-design" numbered="true" toc="default">
<name>Model Design</name>
<t>The MPLS routing model is based on the core routing data model define
d in <xref target="RFC8349" format="default"/>.
<xref target="fig-mpls-rib-relation" format="default"/> shows the extensions int
roduced by the MPLS base model on defined RIBs.</t>
<figure anchor="fig-mpls-rib-relation">
<name>Relationship between MPLS Model and RIB Instances</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+-----------------+ +-----------------+
| MPLS base model | | MPLS base model |
+-----------------+ +-----------------+
____/ | |_____ |________ ____/ | |_____ |________
/ | \ \ / | \ \
/ | \ \ / | \ \
o o o + o o o +
+---------+ +---------+ +--------+ +-----------+ +---------+ +---------+ +--------+ +-----------+
| RIB(v4) | | RIB(v6) | | RIB(x) | | RIB(mpls) | | RIB(v4) | | RIB(v6) | | RIB(x) | | RIB(mpls) |
+---------+ +---------+ +--------+ +-----------+ +---------+ +---------+ +--------+ +-----------+
+: created by the MPLS base model +: created by the MPLS base model
o: augmented by the MPLS base model o: augmented by the MPLS base model]]></artwork>
]]></artwork></figure> </figure>
<t>As shown in <xref target="fig-mpls-rib-relation" format="default"/>,
<t>As shown in <xref target="fig-mpls-rib-relation"/>, the MPLS base YANG data m the MPLS base YANG data model augments
odel augments defined instances of AF RIBs with additional data that enables MPLS
defined instance(s) of AF RIB(s) with additional data that enables MPLS forwarding for destination prefixes stored in such RIBs. For example, an IPv4 pr
forwarding for destination prefix(es) store in such RIB(s). For example, an IPv4 efix
prefix stored in RIB(v4) is augmented to carry an MPLS local label and one or more per-
stored in RIB(v4) is augmented to carry a MPLS local label and per next-hop next-hop
remote label(s) to enable MPLS forwarding for such prefix.</t> remote labels to enable MPLS forwarding for such a prefix.</t>
<t>The MPLS base model also creates a separate instance of the generic R
<t>The MPLS base model also creates a separate instance of the generic RIB model IB model
defined in <xref target="RFC8349"/> to store MPLS native route(s) that are enabl defined in <xref target="RFC8349" format="default"/> to store one or more MPLS
ed for MPLS forwarding, native routes that are enabled for MPLS forwarding but are not stored in one or
but not stored in other AF RIB(s).</t> more other AF RIBs.</t>
<t>Some examples of such native MPLS routes are:</t>
<t>Some examples of such native MPLS routes are:</t> <ul spacing="normal">
<li>Routes programmed by RSVP on Label Switching Routers (LSRs) along
<t><list style="symbols"> the path of an LSP,</li>
<t>routes programmed by RSVP on Label Switched Router(s) (LSRs) along the path <li>Routes that cross-connect an MPLS local label to a Layer 2 or
of a Label Switched Path (LSP),</t> Layer 3 Virtual Routing and Forwarding (VRF) entity,</li>
<t>routes that cross-connect an MPLS local label to a Layer-2, or Layer-3 VRF, <li>Routes that cross-connect an MPLS local label to a specific
</t> Layer 2
<t>routes that cross-connect an MPLS local label to a specific Layer-2 adjacency or interface, such as Layer 2 Attachment Circuits (ACs), or</li>
adjacency or interface, such as Layer-2 Attachment Circuit(s) (ACs), or</t> <li>Routes that cross-connect an MPLS local label to a Layer 3 adjacen
<t>routes that cross-connect an MPLS local label to a Layer-3 adjacency or int cy or interface,
erface - such as MPLS Segment Routing (SR) Adjacency Segments (Adj-SIDs) or SR MPLS Bindi
such as MPLS Segment-Routing (SR) Adjacency Segments (Adj-SIDs), SR MPLS Binding ng SIDs as defined in <xref target="RFC8402" format="default"/>.</li>
SIDs, </ul>
etc. as defined in <xref target="RFC8402"/>.</t> </section>
</list></t> <section anchor="model-tree-diagram" numbered="true" toc="default">
<name>Model Tree Diagram</name>
</section> <t>The MPLS base tree diagram, which follows the notation defined in <xr
<section anchor="model-tree-diagram" title="Model Tree Diagram"> ef target="RFC8340" format="default"/>, is shown in <xref target="fig-mpls-base-
tree" format="default"/>.</t>
<t>The MPLS base tree diagram that follows the notation defined in <xref target= <figure anchor="fig-mpls-base-tree">
"RFC8340"/> is shown in <xref target="fig-mpls-base-tree"/>.</t> <name>MPLS Base Tree Diagram</name>
<sourcecode name="" type="yangtree"><![CDATA[
<figure title="MPLS Base tree diagram" anchor="fig-mpls-base-tree"><artwork><![C
DATA[
module: ietf-mpls module: ietf-mpls
augment /rt:routing: augment /rt:routing:
+--rw mpls +--rw mpls
+--rw ttl-propagate? boolean +--rw ttl-propagate? boolean
+--rw mpls-label-blocks +--rw mpls-label-blocks
| +--rw mpls-label-block* [index] | +--rw mpls-label-block* [index]
| +--rw index string | +--rw index string
| +--rw start-label? rt-types:mpls-label | +--rw start-label? rt-types:mpls-label
| +--rw end-label? rt-types:mpls-label | +--rw end-label? rt-types:mpls-label
| +--rw block-allocation-mode? identityref | +--rw block-allocation-mode? identityref
skipping to change at line 395 skipping to change at line 324
/rt:next-hop-list/rt:next-hop-list/rt:next-hop: /rt:next-hop-list/rt:next-hop-list/rt:next-hop:
+-- index? string +-- index? string
+-- backup-index? string +-- backup-index? string
+-- loadshare? uint16 +-- loadshare? uint16
+-- role? nhlfe-role +-- role? nhlfe-role
+-- mpls-label-stack +-- mpls-label-stack
+-- entry* [id] +-- entry* [id]
+-- id uint8 +-- id uint8
+-- label? rt-types:mpls-label +-- label? rt-types:mpls-label
+-- ttl? uint8 +-- ttl? uint8
+-- traffic-class? uint8 +-- traffic-class? uint8]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="model-yang-module" numbered="true" toc="default">
<section anchor="model-yang-module" title="Model YANG Module"> <name>MPLS Base YANG Module</name>
<t>This section describes the "ietf-mpls" YANG module, which provides ba
<t>This section describes the ‘ietf-mpls’ YANG module that provides base se
components of the MPLS data model. Other YANG module(s) may import and augment components of the MPLS data model. Other YANG modules may import and augment
the base MPLS module to add feature specific data.</t> the MPLS base module to add feature-specific data.</t>
<t>The "ietf-mpls" YANG module imports the following YANG modules:</t>
<t>The ietf-mpls YANG module imports the following YANG modules:</t> <ul spacing="normal">
<li>"ietf-routing" as defined in <xref target="RFC8349" format="defaul
<t><list style="symbols"> t"/></li>
<t>ietf-routing defined in <xref target="RFC8349"/></t> <li>"ietf-routing-types" as defined in <xref target="RFC8294" format="
<t>ietf-routing-types defined in <xref target="RFC8294"/></t> default"/></li>
<t>ietf-interfaces defined in <xref target="RFC8343"/></t> <li>"ietf-yang-types" as defined in <xref target="RFC6991"/></li>
</list></t> <li>"ietf-interfaces" as defined in <xref target="RFC8343" format="def
ault"/></li>
</ul>
<t>This YANG module also references the following RFCs in defining the types and <t>This YANG module also references the following RFCs in defining the
YANG grouping of the YANG module: types, YANG groupings, and other features of the YANG module:
<xref target="RFC3032"/>, <xref target="RFC3031"/>, and <xref target="RFC7424"/> <xref target="RFC3031" format="default"/>,
.</t> <xref target="RFC3032" format="default"/>,
<xref target="RFC4090"/>, <xref target="RFC5714"/>, and
<xref target="RFC7424" format="default"/>.</t>
<figure title="MPLS base YANG module." anchor="fig-module-mpls-base"><artwork><! <figure anchor="fig-module-mpls-base">
[CDATA[ <name>MPLS Base YANG Module</name>
<CODE BEGINS> file "ietf-mpls@2020-10-26.yang" <sourcecode name="ietf-mpls@2020-11-19.yang" type="yang" markers="true
"><![CDATA[
module ietf-mpls { module ietf-mpls {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-mpls"; namespace "urn:ietf:params:xml:ns:yang:ietf-mpls";
/* Replace with IANA when assigned */
prefix mpls; prefix mpls;
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC8349: A YANG Data Model for Routing Management"; "RFC 8349: A YANG Data Model for Routing Management
(NMDA Version)";
} }
import ietf-routing-types { import ietf-routing-types {
prefix rt-types; prefix rt-types;
reference reference
"RFC8294:Common YANG Data Types for the Routing Area"; "RFC 8294: Common YANG Data Types for the Routing Area";
} }
import ietf-yang-types { import ietf-yang-types {
prefix yang; prefix yang;
reference reference
"RFC6991: Common YANG Data Types"; "RFC 6991: Common YANG Data Types";
} }
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
reference reference
"RFC8343: A YANG Data Model for Interface Management"; "RFC 8343: A YANG Data Model for Interface Management";
} }
organization organization
"IETF MPLS Working Group"; "IETF MPLS Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/mpls/> "WG Web: <https://datatracker.ietf.org/wg/mpls/>
WG List: <mailto:mpls@ietf.org> WG List: <mailto:mpls@ietf.org>
Editor: Tarek Saad Editor: Tarek Saad
<mailto:tsaad@juniper.net> <mailto:tsaad@juniper.net>
Editor: Kamran Raza Editor: Kamran Raza
<mailto:skraza@cisco.com> <mailto:skraza@cisco.com>
Editor: Rakesh Gandhi Editor: Rakesh Gandhi
<mailto:rgandhi@cisco.com> <mailto:rgandhi@cisco.com>
Editor: Xufeng Liu Editor: Xufeng Liu
<mailto: xufeng.liu.ietf@gmail.com> <mailto:xufeng.liu.ietf@gmail.com>
Editor: Vishnu Pavan Beeram Editor: Vishnu Pavan Beeram
<mailto:vbeeram@juniper.net>"; <mailto:vbeeram@juniper.net>";
description description
"This YANG module defines the essential components for the "This YANG module defines the essential components for the
management of the MPLS subsystem. The model fully conforms management of the MPLS subsystem. The model fully conforms
to the Network Management Datastore Architecture (NMDA). to the Network Management Datastore Architecture (NMDA).
Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2020 IETF Trust and the persons identified as
identified as authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this This version of this YANG module is part of RFC 8960; see the
// note. RFC itself for full legal notices.";
// RFC Ed.: update the date below with the date of RFC publication
// and remove this note.
revision 2020-10-26 { revision 2020-11-19 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for base MPLS"; "RFC 8960: A YANG Data Model for MPLS Base";
} }
/* Identities */ /* Identities */
identity mpls { identity mpls {
base rt:address-family; base rt:address-family;
description description
"This identity represents the MPLS address family."; "This identity represents the MPLS address family.";
} }
skipping to change at line 519 skipping to change at line 445
} }
identity label-block-alloc-mode { identity label-block-alloc-mode {
description description
"Base identity for label-block allocation mode."; "Base identity for label-block allocation mode.";
} }
identity label-block-alloc-mode-manager { identity label-block-alloc-mode-manager {
base label-block-alloc-mode; base label-block-alloc-mode;
description description
"Label block allocation on reserved block "Label-block allocation on the reserved block
is managed by label manager."; is managed by the label manager.";
} }
identity label-block-alloc-mode-application { identity label-block-alloc-mode-application {
base label-block-alloc-mode; base label-block-alloc-mode;
description description
"Label block allocation on reserved block "Label-block allocation on the reserved block
is managed by application."; is managed by the application.";
} }
/** /**
* Typedefs * Typedefs
*/ */
typedef mpls-operations-type { typedef mpls-operations-type {
type enumeration { type enumeration {
enum impose-and-forward { enum impose-and-forward {
description description
"Operation impose outgoing label(s) and forward to "Operation to impose one or more outgoing labels and
next-hop."; forward to the next hop.";
} }
enum pop-and-forward { enum pop-and-forward {
description description
"Operation pop incoming label and forward to next-hop."; "Operation to pop the incoming label and forward to the
next hop.";
} }
enum pop-impose-and-forward { enum pop-impose-and-forward {
description description
"Operation pop incoming label, impose one or more "Operation to pop the incoming label, impose one or more
outgoing label(s) and forward to next-hop."; outgoing labels, and forward to the next hop.";
} }
enum swap-and-forward { enum swap-and-forward {
description description
"Operation swap incoming label, with outgoing label and "Operation to swap the incoming label with the outgoing
forward to next-hop."; label and forward to the next hop.";
} }
enum pop-and-lookup { enum pop-and-lookup {
description description
"Operation pop incoming label and perform a lookup."; "Operation to pop the incoming label and perform
a lookup.";
} }
} }
description description
"MPLS operations types."; "Types of MPLS operations.";
} }
typedef nhlfe-role { typedef nhlfe-role {
type enumeration { type enumeration {
enum primary { enum primary {
description description
"Next-hop acts as primary for carrying traffic."; "The next hop acts as the primary for carrying traffic.";
} }
enum backup { enum backup {
description description
"Next-hop acts as backup."; "The next hop acts as the backup.";
} }
enum primary-and-backup { enum primary-and-backup {
description description
"Next-hop acts as primary and backup simultaneously "The next hop simultaneously acts as both the primary and
for carry traffic."; the backup for carrying traffic.";
} }
} }
description description
"The next-hop role."; "Role of the next hop.";
} }
grouping nhlfe-single-contents { grouping nhlfe-single-contents {
description description
"A grouping that describes single Next Hop Label Forwarding "A grouping that describes a single Next Hop Label Forwarding
Entry (NHLFE) and its associated parameters as described in Entry (NHLFE) and its associated parameters as described in
the MPLS architecture. This grouping is specific to the case the MPLS architecture. This grouping is specific to the case
when a single next-hop is associated with the route."; when a single next hop is associated with the route.";
uses rt-types:mpls-label-stack; uses rt-types:mpls-label-stack;
} }
grouping nhlfe-multiple-contents { grouping nhlfe-multiple-contents {
description description
"A grouping that describes a set of NHLFE(s) and their "A grouping that describes a set of NHLFEs and their
associated parameters as described in the MPLS architecture. associated parameters as described in the MPLS
This grouping is used when multiple next-hops are associated architecture. This grouping is used when multiple next hops
with the route."; are associated with the route.";
leaf index { leaf index {
type string; type string;
description description
"A user-specified identifier utilised to uniquely "A user-specified identifier utilized to uniquely
reference the next-hop entry in the next-hop list. reference the next-hop entry in the next-hop list.
The value of this index has no semantic meaning The value of this index has no semantic meaning
other than for referencing the entry."; other than for referencing the entry.";
} }
leaf backup-index { leaf backup-index {
type string; type string;
description description
"A user-specified identifier utilised to uniquely "A user-specified identifier utilized to uniquely
reference the backup next-hop entry in the NHLFE list. reference the backup next-hop entry in the NHLFE list.
The value of this index has no semantic meaning The value of this index has no semantic meaning
other than for referencing the entry."; other than for referencing the entry.";
reference reference
"RFC4090 and RFC5714"; "RFC 4090: Fast Reroute Extensions to RSVP-TE for LSP Tunnels
RFC 5714: IP Fast Reroute Framework";
} }
leaf loadshare { leaf loadshare {
type uint16; type uint16;
default "1"; default "1";
description description
"This value is used to compute a loadshare to perform un-equal "This value is used to compute a load share to perform
load balancing when multiple outgoing next-hop(s) are unequal load balancing when multiple outgoing next hops are
specified. A share is computed as a ratio of this number to the specified. A share is computed as a ratio of this number to
total under all next-hops(s)."; the total under all next hops.";
reference reference
"RFC7424, section 5.4, "RFC 3031: Multiprotocol Label Switching Architecture,
RFC3031, section 3.11 and 3.12."; Sections 3.11 and 3.12
RFC 7424: Mechanisms for Optimizing Link Aggregation Group
(LAG) and Equal-Cost Multipath (ECMP) Component Link
Utilization in Networks, Section 5.4";
} }
leaf role { leaf role {
type nhlfe-role; type nhlfe-role;
description description
"NHLFE role."; "Role of the NHLFE.";
} }
uses nhlfe-single-contents; uses nhlfe-single-contents;
} }
grouping interfaces-mpls { grouping interfaces-mpls {
description description
"List of MPLS interfaces."; "List of MPLS interfaces.";
container interfaces { container interfaces {
description description
"List of MPLS enabled interaces."; "List of MPLS-enabled interfaces.";
list interface { list interface {
key "name"; key "name";
description description
"MPLS enabled interface entry."; "MPLS-enabled interface entry.";
leaf name { leaf name {
type if:interface-ref; type if:interface-ref;
description description
"A reference to the name of a interface in the system that "A reference to the name of an interface in the system
is to be enabled for MPLS."; that is to be enabled for MPLS.";
} }
leaf mpls-enabled { leaf mpls-enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"'true' if mpls encapsulation is enabled on the interface. "'true' if MPLS encapsulation is enabled on the
'false' if mpls encapsulation is disabled on the interface.
'false' if MPLS encapsulation is disabled on the
interface."; interface.";
} }
leaf maximum-labeled-packet { leaf maximum-labeled-packet {
type uint32; type uint32;
units "octets"; units "octets";
description description
"Maximum labeled packet size."; "Maximum labeled packet size.";
reference reference
"RFC3032, section 3.2."; "RFC 3032: MPLS Label Stack Encoding, Section 3.2";
} }
} }
} }
} }
grouping globals { grouping globals {
description description
"MPLS global configuration grouping."; "MPLS global configuration grouping.";
leaf ttl-propagate { leaf ttl-propagate {
type boolean; type boolean;
skipping to change at line 693 skipping to change at line 626
grouping label-blocks { grouping label-blocks {
description description
"Label-block allocation grouping."; "Label-block allocation grouping.";
container mpls-label-blocks { container mpls-label-blocks {
description description
"Label-block allocation container."; "Label-block allocation container.";
list mpls-label-block { list mpls-label-block {
key "index"; key "index";
description description
"List of MPLS label-blocks."; "List of MPLS label blocks.";
leaf index { leaf index {
type string; type string;
description description
"A user-specified identifier utilised to uniquely "A user-specified identifier utilized to uniquely
reference an MPLS label block."; reference an MPLS label block.";
} }
leaf start-label { leaf start-label {
type rt-types:mpls-label; type rt-types:mpls-label;
must '. <= ../end-label' { must '. <= ../end-label' {
error-message error-message "'start-label' must be less than or equal "
"The start-label must be less than or equal " + "to 'end-label'";
+ "to end-label";
} }
description description
"Label-block start."; "Label-block start.";
} }
leaf end-label { leaf end-label {
type rt-types:mpls-label; type rt-types:mpls-label;
must '. >= ../start-label' { must '. >= ../start-label' {
error-message error-message "'end-label' must be greater than or "
"The end-label must be greater than or equal " + "equal to 'start-label'";
+ "to start-label";
} }
description description
"Label-block end."; "Label-block end.";
} }
leaf block-allocation-mode { leaf block-allocation-mode {
type identityref { type identityref {
base label-block-alloc-mode; base label-block-alloc-mode;
} }
description description
"Label-block allocation mode."; "Label-block allocation mode.";
} }
leaf inuse-labels-count { leaf inuse-labels-count {
when "derived-from-or-self(../block-allocation-mode, " when "derived-from-or-self(../block-allocation-mode, "
+ "'mpls:label-block-alloc-mode-manager')"; + "'mpls:label-block-alloc-mode-manager')";
type yang:gauge32; type yang:gauge32;
config false; config false;
description description
"Label-block inuse labels count."; "Number of labels in use in the label block.";
} }
} }
} }
} }
grouping rib-mpls-properties { grouping rib-mpls-properties {
description description
"A grouping of native MPLS RIB properties."; "A grouping of native MPLS RIB properties.";
leaf destination-prefix { leaf destination-prefix {
type leafref { type leafref {
skipping to change at line 765 skipping to change at line 696
grouping rib-active-route-mpls-input { grouping rib-active-route-mpls-input {
description description
"A grouping applicable to native MPLS RIB 'active-route' "A grouping applicable to native MPLS RIB 'active-route'
RPC input augmentation."; RPC input augmentation.";
leaf destination-address { leaf destination-address {
type leafref { type leafref {
path "../mpls-local-label"; path "../mpls-local-label";
} }
description description
"MPLS native active route destination."; "MPLS native 'active-route' destination.";
} }
leaf mpls-local-label { leaf mpls-local-label {
type rt-types:mpls-label; type rt-types:mpls-label;
description description
"MPLS local label."; "MPLS local label.";
} }
} }
augment "/rt:routing" { augment "/rt:routing" {
description description
"MPLS augmentation."; "MPLS augmentation.";
container mpls { container mpls {
description description
"MPLS container, to be used as an augmentation target node "MPLS container to be used as an augmentation target node
other MPLS sub-features config, e.g. MPLS static LSP, MPLS for the configuration of other MPLS sub-features, e.g.,
LDP LSPs, and Trafic Engineering MPLS LSP Tunnels, etc."; MPLS static Label Switched Paths (LSPs), MPLS LDP LSPs,
and Traffic Engineering MPLS LSP Tunnels.";
uses globals; uses globals;
uses label-blocks; uses label-blocks;
uses interfaces-mpls; uses interfaces-mpls;
} }
} }
/* MPLS routes augmentation */ /* Augmentation of MPLS routes */
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
description description
"This augmentation is applicable to all MPLS routes."; "This augmentation is applicable to all MPLS routes.";
leaf mpls-enabled { leaf mpls-enabled {
type boolean; type boolean;
default "false"; default "false";
description description
"Indicates whether MPLS is enabled for this route."; "Indicates whether MPLS is enabled for this route.";
} }
leaf mpls-local-label { leaf mpls-local-label {
when "../mpls-enabled = 'true'"; when "../mpls-enabled = 'true'";
type rt-types:mpls-label; type rt-types:mpls-label;
description description
"MPLS local label associated with the route."; "MPLS local label associated with the route.";
} }
uses rib-mpls-properties { uses rib-mpls-properties {
/* MPLS AF augmentation to native MPLS RIB */ /* MPLS Address Family (AF) augmentation to the
native MPLS RIB */
when "derived-from-or-self(../../rt:address-family, " when "derived-from-or-self(../../rt:address-family, "
+ "'mpls:mpls')" { + "'mpls:mpls')" {
description description
"This augment is valid only for routes of native MPLS "This augment is valid only for routes of the native MPLS
RIB."; RIB.";
} }
} }
} }
/* MPLS simple-next-hop augmentation */ /* MPLS simple-next-hop augmentation */
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
description description
"Augment 'simple-next-hop' case in IP unicast routes."; "Augments the 'simple-next-hop' case in IP unicast routes.";
uses nhlfe-single-contents { uses nhlfe-single-contents {
when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" when "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route"
+ "/mpls:mpls-enabled = 'true'"; + "/mpls:mpls-enabled = 'true'";
} }
} }
/* MPLS next-hop-list augmentation */ /* MPLS next-hop-list augmentation */
augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/" augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
skipping to change at line 849 skipping to change at line 782
} }
} }
/* MPLS RPC input augmentation */ /* MPLS RPC input augmentation */
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" { augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" {
description description
"Input MPLS augmentation for the 'active-route' action "Input MPLS augmentation for the 'active-route' action
statement."; statement.";
uses rib-active-route-mpls-input { uses rib-active-route-mpls-input {
/* MPLS AF augmentation to native MPLS RIB */ /* MPLS AF augmentation to the native MPLS RIB */
when "derived-from-or-self(../rt:address-family, " when "derived-from-or-self(../rt:address-family, "
+ "'mpls:mpls')" { + "'mpls:mpls')" {
description description
"This augment is valid only for routes of native MPLS "This augment is valid only for routes of the native MPLS
RIB."; RIB.";
} }
} }
} }
/* MPLS RPC output augmentation */ /* MPLS RPC output augmentation */
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/" + "rt:output/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" { + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
skipping to change at line 879 skipping to change at line 812
augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/" augment "/rt:routing/rt:ribs/rt:rib/rt:active-route/"
+ "rt:output/rt:route/" + "rt:output/rt:route/"
+ "rt:next-hop/rt:next-hop-options/rt:next-hop-list/" + "rt:next-hop/rt:next-hop-options/rt:next-hop-list/"
+ "rt:next-hop-list/rt:next-hop" { + "rt:next-hop-list/rt:next-hop" {
description description
"Output MPLS augmentation for the 'active-route' action "Output MPLS augmentation for the 'active-route' action
statement."; statement.";
uses nhlfe-multiple-contents; uses nhlfe-multiple-contents;
} }
} }]]></sourcecode>
<CODE ENDS> </figure>
]]></artwork></figure> </section>
</section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
</section> <name>IANA Considerations</name>
<section anchor="iana-considerations" title="IANA Considerations"> <t>This document registers the following URI in the "ns" subregistry of th
e "IETF XML Registry"
<t>This document registers the following URIs in the ‘ns’ sub-registry of the IE <xref target="RFC3688" format="default"/>.</t>
TF XML registry <dl newline="false" spacing="compact">
<xref target="RFC3688"/>. <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-mpls</dd>
Following the format in <xref target="RFC3688"/>, the following registration is <dt>Registrant Contact:</dt><dd>The MPLS WG of the IETF.</dd>
requested to be made.</t> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
</dl>
<figure><artwork><![CDATA[ <t>This document registers the following YANG module in the "YANG Module N
URI: urn:ietf:params:xml:ns:yang:ietf-mpls ames"
Registrant Contact: The MPLS WG of the IETF. registry <xref target="RFC6020" format="default"/>.</t>
XML: N/A, the requested URI is an XML namespace. <dl newline="false" spacing="compact">
]]></artwork></figure> <dt>Name:</dt><dd>ietf-mpls</dd>
<dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-mpls</dd>
<t>This document registers a YANG module in the YANG Module Names <dt>Prefix:</dt><dd>mpls</dd>
registry <xref target="RFC6020"/>.</t> <dt>Reference:</dt><dd>RFC 8960</dd>
</dl>
<figure><artwork><![CDATA[ </section>
name: ietf-mpls <section anchor="security-considerations" numbered="true" toc="default">
namespace: urn:ietf:params:xml:ns:yang:ietf-mpls <name>Security Considerations</name>
prefix: mpls
// RFC Ed.: replace XXXX with RFC number and remove this note
reference: RFCXXXX
]]></artwork></figure>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The YANG module specified in this document define a schema for data <t>The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such that is designed to be accessed via network management protocols such
as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. The l as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
owest NETCONF layer The lowest NETCONF layer is the secure transport layer, and the
is the secure transport layer, and the mandatory-to-implement secure mandatory-to-implement secure transport is Secure Shell (SSH)
transport is Secure Shell (SSH) <xref target="RFC6242"/>. The lowest RESTCONF l <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
ayer mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
is HTTPS, and the mandatory-to-implement secure transport is TLS <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/
<xref target="RFC8446"/>.</t> >
provides the means to restrict access for particular NETCONF or RESTCONF users
<t>The NETCONF access control model <xref target="RFC8341"/> provides the means to a preconfigured subset of all available NETCONF or RESTCONF protocol
to
restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.</t> operations and content.</t>
<t>There are a number of data nodes defined in this YANG module that are writabl <t>There are a number of data nodes defined in this YANG module that are
e/creatable/deletable (i.e., config true, which is the default). These data node writable/creatable/deletable (i.e., config true, which is the default). These
s may be considered sensitive or vulnerable in some network environments. Write data nodes may be considered sensitive or vulnerable in some network
operations (e.g., edit-config) to these data nodes without proper protection can environments. Write operations (e.g., edit-config) to these data nodes without
have a negative effect on network operations. These are the subtrees and data n proper protection can have a negative effect on network operations. These are
odes and their sensitivity/vulnerability:</t> the subtrees and data nodes and their sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
<t>“/rt:routing/mpls:mpls/mpls:label-blocks”: there are data nodes under this pa <dt>"/rt:routing/mpls:mpls/mpls:label-blocks":</dt><dd>There are data
th that are writeable such as ‘start-label’ and ‘end-label’. Write operations to nodes under this path that are writable, such as "start-label" and
those data npdes may cause disruptive action to existing traffic.</t> "end-label". Write operations to those data nodes may result in
disruption to existing traffic.</dd>
<t>Some of the readable data nodes in these YANG module may be </dl>
considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. These are the subtrees and
data nodes and their sensitivity/vulnerability:</t>
<t>“/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-option
s/rt:next-hop-list/rt:next-hop-list/rt:next-hop” and
“/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route/rt:next-hop/rt:ne
xt-hop-options/rt:simple-next-hop”: these two paths are augmented by additional
MPLS leaf(s) defined in this model. Access to this information may disclose the
next-hop or path per prefix and/or other information.</t>
<t>Some of the RPC operations in this YANG module may be considered sensitive or
vulnerable in some network environments. It is thus important to control access
to these operations. These are the operations and their sensitivity/vulnerabili
ty:</t>
<t>“/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input” and “/rt:routing/rt:rib
s/rt:rib/rt:active-route/rt:output/rt:route”: these two paths are augmented
by additional MPLS data node(s) that are defined in this model. Access to those
path(s) may may disclose information about per prefix route and/or other informa
tion and that may be further used for further attack(s).</t>
<t>The security considerations spelled out in <xref target="RFC3031"/> and <xref
target="RFC3032"/> apply for this document as well.</t>
</section>
<section anchor="acknowledgement" title="Acknowledgement">
<t>The authors would like to thank Xia Chen for her contributions to the early <t>Some of the readable data nodes in this YANG module may be considered
revisions of this document.</t> sensitive or vulnerable in some network environments. It is thus important to
control read access (e.g., via get, get-config, or notification) to these data
nodes. These are the subtrees and data nodes and their
sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
<dt>"/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route/rt:next-hop/rt:next-hop-optio
ns/rt:next-hop-list/rt:next-hop-list/rt:next-hop" and
"/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route/rt:next-hop/rt:ne
xt-hop-options/rt:simple-next-hop":</dt><dd>These
two paths are augmented by additional MPLS leafs defined in this model. Access
to this information may disclose the next-hop information for the prefix route a
nd/or other information.</dd>
</dl>
</section> <t>Some of the RPC operations in this YANG module may be considered sensitive or
<section anchor="appendix-a-data-tree-instance-example" title="Appendix A. Data vulnerable in some network environments. It is thus important to control
Tree Instance Example"> access to these operations. These are the operations and their
sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
<dt>"/rt:routing/rt:ribs/rt:rib/rt:active-route/rt:input" and "/rt:routing
/rt:ribs/rt:rib/rt:active-route/rt:output/rt:route":</dt><dd>These two paths are
augmented
by additional MPLS data nodes that are defined in this model. Access to
those paths may disclose information about per-prefix routes and/or other
information; such disclosure may be used for further attacks.</dd>
</dl>
<t>The security considerations spelled out in <xref target="RFC3031" forma
t="default"/> and <xref target="RFC3032" format="default"/> apply for this docum
ent as well.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6991.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8349.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8342.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7950.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8294.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8343.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3032.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3688.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6020.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6241.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8040.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6242.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8341.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3031.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4090.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5714.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7424.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7951.xml"/>
</references>
</references>
<t>A simple network setup is shown in Figure 5. R1 runs the ISIS routing <section anchor="appendix-a-data-tree-instance-example" numbered="true" toc=
protocol, and learns reachability about two IPv4 prefixes: "default">
P1: 198.51.100.1/32 and P2: 198.51.100.1/32, and two IPv6 prefixes P3: <name>Data Tree Instance Example</name>
2001:db8:0:10::1/64 and P4: 2001:db8:0:10::1/64. We also assume that <t>A simple network setup is shown in <xref target="fig-example"/>. R1 ru
ns the IS-IS routing
protocol and learns about the reachability of two IPv4 prefixes
(P1: 198.51.100.1/32 and P2: 198.51.100.2/32) and two IPv6 prefixes
(P3: 2001:db8:0:10::1/128 and P4: 2001:db8:0:10::2/128). We also assume that
R1 learns about local and remote MPLS label bindings for each prefix R1 learns about local and remote MPLS label bindings for each prefix
using ISIS (e.g. using Segment-Routing (SR) extensions).</t> using IS-IS (e.g., using Segment Routing (SR) extensions).</t>
<figure anchor="fig-example">
<figure title="Example of network configuration." anchor="fig-example"><artwork> <name>Example of Network Configuration</name>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
State on R1: State on R1:
============ ============
IPv4 Prefix MPLS Label IPv4 Prefix MPLS Label
P1: 198.51.100.1/32 16001 P1: 198.51.100.1/32 16001
P2: 198.51.100.2/32 16002 P2: 198.51.100.2/32 16002
IPv6 Prefix MPLS Label IPv6 Prefix MPLS Label
P3: 2001:db8:0:10::1/64 16003 P3: 2001:db8:0:10::1/128 16003
P4: 2001:db8:0:10::2/64 16004 P4: 2001:db8:0:10::2/128 16004
RSVP MPLS LSPv4-Tunnel: RSVP MPLS LSPv4-Tunnel:
Source: 198.51.100.3 Source: 198.51.100.3
Destination: 198.51.100.4 Destination: 198.51.100.4
Tunnel-ID: 10 Tunnel-ID: 10
LSP-ID: 1 LSP-ID: 1
192.0.2.5/30 192.0.2.5/30
2001:db8:0:1::1/64 2001:db8:0:1::1/64
eth0 eth0
+--- +---
/ /
+-----+ +-----+
| R1 | | R1 |
+-----+ +-----+
\ \
+--- +---
eth1 eth1
192.0.2.13/30 192.0.2.13/30
2001:db8:0:2::1/64 2001:db8:0:2::1/64]]></artwork>
</figure>
]]></artwork></figure> <t>The instance data tree could then be
illustrated as shown in <xref target="fib-ribs"/>, using JSON format <xref targe
<t>The instance data tree could then be as follows:</t> t="RFC7951"/>:</t>
<figure title="Foo bar." anchor="fib-ribs"><artwork><![CDATA[ <figure anchor="fib-ribs">
<name>Instance Data Tree Example</name>
<sourcecode name="" type="json"><![CDATA[
{ {
"ietf-routing:routing":{ "ietf-routing:routing":{
"ribs":{ "ribs":{
"rib":[ "rib":[
{ {
"name":"RIB-V4", "name":"RIB-V4",
"address-family": "address-family":
"ietf-ipv4-unicast-routing:v4ur:ipv4-unicast", "ietf-ipv4-unicast-routing:v4ur:ipv4-unicast",
"routes":{ "routes":{
"route":[ "route":[
skipping to change at line 1021 skipping to change at line 990
{ {
"id":1, "id":1,
"label":16001, "label":16001,
"ttl":255 "ttl":255
} }
] ]
}, },
"ietf-ipv4-unicast-routing:next-hop-address": "ietf-ipv4-unicast-routing:next-hop-address":
"192.0.2.5" "192.0.2.5"
}, },
"source-protocol":"isis:isis", "source-protocol":"ietf-isis:isis",
"ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-enabled":true,
"ietf-mpls:mpls-local-label":16001, "ietf-mpls:mpls-local-label":16001,
"ietf-ipv4-unicast-routing:destination-prefix": "ietf-ipv4-unicast-routing:destination-prefix":
"198.51.100.1/32", "198.51.100.1/32",
"ietf-mpls:route-context":"SID-IDX:1" "ietf-mpls:route-context":"SID-IDX:1"
}, },
{ {
"next-hop":{ "next-hop":{
"next-hop-list":{ "next-hop-list":{
"next-hop":[ "next-hop":[
skipping to change at line 1046 skipping to change at line 1015
"ietf-mpls:role":"primary-and-backup", "ietf-mpls:role":"primary-and-backup",
"ietf-mpls:mpls-label-stack":{ "ietf-mpls:mpls-label-stack":{
"entry":[ "entry":[
{ {
"id":1, "id":1,
"label":16002, "label":16002,
"ttl":255 "ttl":255
} }
] ]
}, },
"ietf-ipv4-unicast-routing:address":"192.0.2.5" "ietf-ipv4-unicast-routing:address":
"192.0.2.5"
}, },
{ {
"outgoing-interface":"eth1", "outgoing-interface":"eth1",
"ietf-mpls:index":"2", "ietf-mpls:index":"2",
"ietf-mpls:backup-index":"1", "ietf-mpls:backup-index":"1",
"ietf-mpls:role":"primary-and-backup", "ietf-mpls:role":"primary-and-backup",
"ietf-mpls:mpls-label-stack":{ "ietf-mpls:mpls-label-stack":{
"entry":[ "entry":[
{ {
"id":1, "id":1,
"label":16002, "label":16002,
"ttl":255 "ttl":255
} }
] ]
}, },
"ietf-ipv4-unicast-routing:address":"192.0.2.13" "ietf-ipv4-unicast-routing:address":
"192.0.2.13"
} }
] ]
} }
}, },
"source-protocol":"isis:isis", "source-protocol":"ietf-isis:isis",
"ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-enabled":true,
"ietf-mpls:mpls-local-label":16002, "ietf-mpls:mpls-local-label":16002,
"ietf-ipv4-unicast-routing:destination-prefix": "ietf-ipv4-unicast-routing:destination-prefix":
"198.51.100.2/32", "198.51.100.2/32",
"ietf-mpls:route-context":"SID-IDX:2" "ietf-mpls:route-context":"SID-IDX:2"
} }
] ]
} }
}, },
{ {
skipping to change at line 1098 skipping to change at line 1069
{ {
"id":1, "id":1,
"label":16003, "label":16003,
"ttl":255 "ttl":255
} }
] ]
}, },
"ietf-ipv6-unicast-routing:next-hop-address": "ietf-ipv6-unicast-routing:next-hop-address":
"2001:db8:0:1::1" "2001:db8:0:1::1"
}, },
"source-protocol":"isis:isis", "source-protocol":"ietf-isis:isis",
"ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-enabled":true,
"ietf-mpls:mpls-local-label":16001, "ietf-mpls:mpls-local-label":16003,
"ietf-ipv6-unicast-routing:destination-prefix": "ietf-ipv6-unicast-routing:destination-prefix":
"2001:db8:0:10::1/6", "2001:db8:0:10::1/128",
"ietf-mpls:route-context":"SID-IDX:1" "ietf-mpls:route-context":"SID-IDX:3"
}, },
{ {
"next-hop":{ "next-hop":{
"next-hop-list":{ "next-hop-list":{
"next-hop":[ "next-hop":[
{ {
"outgoing-interface":"eth0", "outgoing-interface":"eth0",
"ietf-mpls:index":"1", "ietf-mpls:index":"1",
"ietf-mpls:backup-index":"2", "ietf-mpls:backup-index":"2",
"ietf-mpls:role":"primary-and-backup", "ietf-mpls:role":"primary-and-backup",
skipping to change at line 1146 skipping to change at line 1117
"ttl":255 "ttl":255
} }
] ]
}, },
"ietf-ipv6-unicast-routing:address": "ietf-ipv6-unicast-routing:address":
"2001:db8:0:2::1" "2001:db8:0:2::1"
} }
] ]
} }
}, },
"source-protocol":"isis:isis", "source-protocol":"ietf-isis:isis",
"ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-enabled":true,
"ietf-mpls:mpls-local-label":16004, "ietf-mpls:mpls-local-label":16004,
"ietf-ipv6-unicast-routing:destination-prefix": "ietf-ipv6-unicast-routing:destination-prefix":
"2001:db8:0:10::2/64", "2001:db8:0:10::2/128",
"ietf-mpls:route-context":"SID-IDX:2" "ietf-mpls:route-context":"SID-IDX:4"
} }
] ]
} }
}, },
{ {
"name":"RIB-MPLS", "name":"RIB-MPLS",
"address-family":"ietf-mpls:mpls:mpls", "address-family":"ietf-mpls:mpls:mpls",
"routes":{ "routes":{
"route":[ "route":[
{ {
skipping to change at line 1176 skipping to change at line 1147
{ {
"id":1, "id":1,
"label":24002, "label":24002,
"ttl":255 "ttl":255
} }
] ]
}, },
"ietf-ipv4-unicast-routing:next-hop-address": "ietf-ipv4-unicast-routing:next-hop-address":
"192.0.2.5" "192.0.2.5"
}, },
"source-protocol":"rsvp:rsvp", "source-protocol":"ietf-rsvp:rsvp",
"ietf-mpls:mpls-enabled":true, "ietf-mpls:mpls-enabled":true,
"ietf-mpls:mpls-local-label":24001, "ietf-mpls:mpls-local-label":24001,
"ietf-mpls:destination-prefix":"24001", "ietf-mpls:destination-prefix":"24001",
"ietf-mpls:route-context": "ietf-mpls:route-context":
"RSVP Src:198.51.100.3,Dst:198.51.100.4,T:10,L:1" "RSVP Src:198.51.100.3,Dst:198.51.100.4,T:10,L:1"
} }
} ]
} }
} }
] ]
}, },
"ietf-mpls:mpls":{ "ietf-mpls:mpls":{
"mpls-label-blocks":{ "mpls-label-blocks":{
"mpls-label-block":[ "mpls-label-block":[
{ {
"index":"mpls-srgb-label-block", "index":"mpls-srgb-label-block",
"start-label":16000, "start-label":16000,
"end-label":16500, "end-label":16500,
"block-allocation-mode":"mpls:label-block-alloc-mode-manager" "block-allocation-mode":
"ietf-mpls:label-block-alloc-mode-manager"
} }
] ]
}, },
"interfaces":{ "interfaces":{
"interface":[ "interface":[
{ {
"name":"eth0", "name":"eth0",
"mpls-enabled":true, "mpls-enabled":true,
"maximum-labeled-packet":1488 "maximum-labeled-packet":1488
}, },
{ {
"name":"eth1", "name":"eth1",
"mpls-enabled":true, "mpls-enabled":true,
"maximum-labeled-packet":1488 "maximum-labeled-packet":1488
} }
] ]
} }
} }
} }
} }]]></sourcecode>
]]></artwork></figure> </figure>
</section>
</section>
<section anchor="contributors" title="Contributors">
<figure><artwork><![CDATA[
Igor Bryskin
Huawei Technologies
email: i_bryskin@yahoo.com
Himanshu Shah
Ciena
email: hshah@ciena.com
]]></artwork></figure>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor="RFC8349" target='https://www.rfc-editor.org/info/rfc8349'>
<front>
<title>A YANG Data Model for Routing Management (NMDA Version)</title>
<author initials='L.' surname='Lhotka' fullname='L. Lhotka'><organization /></au
thor>
<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></au
thor>
<author initials='Y.' surname='Qu' fullname='Y. Qu'><organization /></author>
<date year='2018' month='March' />
<abstract><t>This document specifies three YANG modules and one submodule. Toget
her, they form the core routing data model that serves as a framework for config
uring and managing a routing subsystem. It is expected that these modules will
be augmented by additional YANG modules defining data models for control-plane p
rotocols, route filters, and other functions. The core routing data model provi
des common building blocks for such extensions -- routes, Routing Information Ba
ses (RIBs), and control-plane protocols.</t><t>The YANG modules in this document
conform to the Network Management Datastore Architecture (NMDA). This document
obsoletes RFC 8022.</t></abstract>
</front>
<seriesInfo name='RFC' value='8349'/>
<seriesInfo name='DOI' value='10.17487/RFC8349'/>
</reference>
<reference anchor="RFC8402" target='https://www.rfc-editor.org/info/rfc8402'>
<front>
<title>Segment Routing Architecture</title>
<author initials='C.' surname='Filsfils' fullname='C. Filsfils' role='editor'><o
rganization /></author>
<author initials='S.' surname='Previdi' fullname='S. Previdi' role='editor'><org
anization /></author>
<author initials='L.' surname='Ginsberg' fullname='L. Ginsberg'><organization />
</author>
<author initials='B.' surname='Decraene' fullname='B. Decraene'><organization />
</author>
<author initials='S.' surname='Litkowski' fullname='S. Litkowski'><organization
/></author>
<author initials='R.' surname='Shakir' fullname='R. Shakir'><organization /></au
thor>
<date year='2018' month='July' />
<abstract><t>Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called &quot;segments&
quot;. A segment can represent any instruction, topological or service based.
A segment can have a semantic local to an SR node or global within an SR domain.
SR provides a mechanism that allows a flow to be restricted to a specific topo
logical path, while maintaining per-flow state only at the ingress node(s) to th
e SR domain.</t><t>SR can be directly applied to the MPLS architecture with no c
hange to the forwarding plane. A segment is encoded as an MPLS label. An order
ed list of segments is encoded as a stack of labels. The segment to process is
on the top of the stack. Upon completion of a segment, the related label is pop
ped from the stack.</t><t>SR can be applied to the IPv6 architecture, with a new
type of routing header. A segment is encoded as an IPv6 address. An ordered l
ist of segments is encoded as an ordered list of IPv6 addresses in the routing h
eader. The active segment is indicated by the Destination Address (DA) of the p
acket. The next active segment is indicated by a pointer in the new routing hea
der.</t></abstract>
</front>
<seriesInfo name='RFC' value='8402'/>
<seriesInfo name='DOI' value='10.17487/RFC8402'/>
</reference>
<reference anchor="RFC8342" target='https://www.rfc-editor.org/info/rfc8342'>
<front>
<title>Network Management Datastore Architecture (NMDA)</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organ
ization /></author>
<author initials='P.' surname='Shafer' fullname='P. Shafer'><organization /></au
thor>
<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></au
thor>
<author initials='R.' surname='Wilton' fullname='R. Wilton'><organization /></au
thor>
<date year='2018' month='March' />
<abstract><t>Datastores are a fundamental concept binding the data models writte
n in the YANG data modeling language to network management protocols such as the
Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an
architectural framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well supported in t
he initial model. This document updates RFC 7950.</t></abstract>
</front>
<seriesInfo name='RFC' value='8342'/>
<seriesInfo name='DOI' value='10.17487/RFC8342'/>
</reference>
<reference anchor="RFC7950" target='https://www.rfc-editor.org/info/rfc7950'>
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'>
<organization /></author>
<date year='2016' month='August' />
<abstract><t>YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network management pro
tocols. This document describes the syntax and semantics of version 1.1 of the
YANG language. YANG version 1.1 is a maintenance release of the YANG language,
addressing ambiguities and defects in the original specification. There are a s
mall number of backward incompatibilities from YANG version 1. This document al
so specifies the YANG mappings to the Network Configuration Protocol (NETCONF).<
/t></abstract>
</front>
<seriesInfo name='RFC' value='7950'/>
<seriesInfo name='DOI' value='10.17487/RFC7950'/>
</reference>
<reference anchor="RFC8340" target='https://www.rfc-editor.org/info/rfc8340'>
<front>
<title>YANG Tree Diagrams</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<author initials='L.' surname='Berger' fullname='L. Berger' role='editor'><organ
ization /></author>
<date year='2018' month='March' />
<abstract><t>This document captures the current syntax used in YANG module tree
diagrams. The purpose of this document is to provide a single location for this
definition. This syntax may be updated from time to time based on the evolutio
n of the YANG language.</t></abstract>
</front>
<seriesInfo name='BCP' value='215'/>
<seriesInfo name='RFC' value='8340'/>
<seriesInfo name='DOI' value='10.17487/RFC8340'/>
</reference>
<reference anchor="RFC8294" target='https://www.rfc-editor.org/info/rfc8294'>
<front>
<title>Common YANG Data Types for the Routing Area</title>
<author initials='X.' surname='Liu' fullname='X. Liu'><organization /></author>
<author initials='Y.' surname='Qu' fullname='Y. Qu'><organization /></author>
<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></au
thor>
<author initials='C.' surname='Hopps' fullname='C. Hopps'><organization /></auth
or>
<author initials='L.' surname='Berger' fullname='L. Berger'><organization /></au
thor>
<date year='2017' month='December' />
<abstract><t>This document defines a collection of common data types using the Y
ANG data modeling language. These derived common types are designed to be impor
ted by other modules defined in the routing area.</t></abstract>
</front>
<seriesInfo name='RFC' value='8294'/>
<seriesInfo name='DOI' value='10.17487/RFC8294'/>
</reference>
<reference anchor="RFC8343" target='https://www.rfc-editor.org/info/rfc8343'>
<front>
<title>A YANG Data Model for Interface Management</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<date year='2018' month='March' />
<abstract><t>This document defines a YANG data model for the management of netwo
rk interfaces. It is expected that interface-type-specific data models augment
the generic interfaces data model defined in this document. The data model inclu
des definitions for configuration and system state (status information and count
ers for the collection of statistics).</t><t>The YANG data model in this documen
t conforms to the Network Management Datastore Architecture (NMDA) defined in RF
C 8342.</t><t>This document obsoletes RFC 7223.</t></abstract>
</front>
<seriesInfo name='RFC' value='8343'/>
<seriesInfo name='DOI' value='10.17487/RFC8343'/>
</reference>
<reference anchor="RFC3032" target='https://www.rfc-editor.org/info/rfc3032'>
<front>
<title>MPLS Label Stack Encoding</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></auth
or>
<author initials='D.' surname='Tappan' fullname='D. Tappan'><organization /></au
thor>
<author initials='G.' surname='Fedorkow' fullname='G. Fedorkow'><organization />
</author>
<author initials='Y.' surname='Rekhter' fullname='Y. Rekhter'><organization /></
author>
<author initials='D.' surname='Farinacci' fullname='D. Farinacci'><organization
/></author>
<author initials='T.' surname='Li' fullname='T. Li'><organization /></author>
<author initials='A.' surname='Conta' fullname='A. Conta'><organization /></auth
or>
<date year='2001' month='January' />
<abstract><t>This document specifies the encoding to be used by an LSR in order
to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN
data links, and possibly on other data links as well. This document also specif
ies rules and procedures for processing the various fields of the label stack en
coding. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3032'/>
<seriesInfo name='DOI' value='10.17487/RFC3032'/>
</reference>
<reference anchor="RFC3688" target='https://www.rfc-editor.org/info/rfc3688'>
<front>
<title>The IETF XML Registry</title>
<author initials='M.' surname='Mealling' fullname='M. Mealling'><organization />
</author>
<date year='2004' month='January' />
<abstract><t>This document describes an IANA maintained registry for IETF standa
rds which use Extensible Markup Language (XML) related items such as Namespaces,
Document Type Declarations (DTDs), Schemas, and Resource Description Framework
(RDF) Schemas.</t></abstract>
</front>
<seriesInfo name='BCP' value='81'/>
<seriesInfo name='RFC' value='3688'/>
<seriesInfo name='DOI' value='10.17487/RFC3688'/>
</reference>
<reference anchor="RFC6020" target='https://www.rfc-editor.org/info/rfc6020'>
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (N
ETCONF)</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'>
<organization /></author>
<date year='2010' month='October' />
<abstract><t>YANG is a data modeling language used to model configuration and st
ate data manipulated by the Network Configuration Protocol (NETCONF), NETCONF re
mote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract
>
</front>
<seriesInfo name='RFC' value='6020'/>
<seriesInfo name='DOI' value='10.17487/RFC6020'/>
</reference>
<reference anchor="RFC6241" target='https://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials='R.' surname='Enns' fullname='R. Enns' role='editor'><organizat
ion /></author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role='editor'>
<organization /></author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role='
editor'><organization /></author>
<author initials='A.' surname='Bierman' fullname='A. Bierman' role='editor'><org
anization /></author>
<date year='2011' month='June' />
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this docume
nt provides mechanisms to install, manipulate, and delete the configuration of n
etwork devices. It uses an Extensible Markup Language (XML)-based data encoding
for the configuration data as well as the protocol messages. The NETCONF proto
col operations are realized as remote procedure calls (RPCs). This document obs
oletes RFC 4741. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6241'/>
<seriesInfo name='DOI' value='10.17487/RFC6241'/>
</reference>
<reference anchor="RFC8040" target='https://www.rfc-editor.org/info/rfc8040'>
<front>
<title>RESTCONF Protocol</title>
<author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></
author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></au
thor>
<date year='2017' month='January' />
<abstract><t>This document describes an HTTP-based protocol that provides a prog
rammatic interface for accessing data defined in YANG, using the datastore conce
pts defined in the Network Configuration Protocol (NETCONF).</t></abstract>
</front>
<seriesInfo name='RFC' value='8040'/>
<seriesInfo name='DOI' value='10.17487/RFC8040'/>
</reference>
<reference anchor="RFC6242" target='https://www.rfc-editor.org/info/rfc6242'>
<front>
<title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
<author initials='M.' surname='Wasserman' fullname='M. Wasserman'><organization
/></author>
<date year='2011' month='June' />
<abstract><t>This document describes a method for invoking and running the Netwo
rk Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SS
H subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t></abstract
>
</front>
<seriesInfo name='RFC' value='6242'/>
<seriesInfo name='DOI' value='10.17487/RFC6242'/>
</reference>
<reference anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization />
</author>
<date year='2018' month='August' />
<abstract><t>This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and mess
age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2
implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>
<reference anchor="RFC8341" target='https://www.rfc-editor.org/info/rfc8341'>
<front>
<title>Network Configuration Access Control Model</title>
<author initials='A.' surname='Bierman' fullname='A. Bierman'><organization /></
author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization
/></author>
<date year='2018' month='March' />
<abstract><t>The standardization of network configuration interfaces for use wit
h the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires
a structured and secure operating environment that promotes human usability and
multi-vendor interoperability. There is a need for standard mechanisms to rest
rict NETCONF or RESTCONF protocol access for particular users to a preconfigured
subset of all available NETCONF or RESTCONF protocol operations and content. T
his document defines such an access control model.</t><t>This document obsoletes
RFC 6536.</t></abstract>
</front>
<seriesInfo name='STD' value='91'/>
<seriesInfo name='RFC' value='8341'/>
<seriesInfo name='DOI' value='10.17487/RFC8341'/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="RFC3031" target='https://www.rfc-editor.org/info/rfc3031'>
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></auth
or>
<author initials='A.' surname='Viswanathan' fullname='A. Viswanathan'><organizat
ion /></author>
<author initials='R.' surname='Callon' fullname='R. Callon'><organization /></au
thor>
<date year='2001' month='January' />
<abstract><t>This document specifies the architecture for Multiprotocol Label Sw
itching (MPLS). [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3031'/>
<seriesInfo name='DOI' value='10.17487/RFC3031'/>
</reference>
<reference anchor="RFC7424" target='https://www.rfc-editor.org/info/rfc7424'>
<front>
<title>Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Mul
tipath (ECMP) Component Link Utilization in Networks</title>
<author initials='R.' surname='Krishnan' fullname='R. Krishnan'><organization />
</author>
<author initials='L.' surname='Yong' fullname='L. Yong'><organization /></author
>
<author initials='A.' surname='Ghanwani' fullname='A. Ghanwani'><organization />
</author>
<author initials='N.' surname='So' fullname='N. So'><organization /></author>
<author initials='B.' surname='Khasnabish' fullname='B. Khasnabish'><organizatio
n /></author>
<date year='2015' month='January' />
<abstract><t>Demands on networking infrastructure are growing exponentially due
to bandwidth-hungry applications such as rich media applications and inter-data-
center communications. In this context, it is important to optimally use the ba
ndwidth in wired networks that extensively use link aggregation groups and equal
-cost multipaths as techniques for bandwidth scaling. This document explores so
me of the mechanisms useful for achieving this.</t></abstract>
</front>
<seriesInfo name='RFC' value='7424'/>
<seriesInfo name='DOI' value='10.17487/RFC7424'/>
</reference>
</references>
<section anchor="acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Xia Chen"/> for
her contributions to the early draft revisions of this document.</t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Igor Bryskin">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>i_bryskin@yahoo.com</email>
</address>
</contact>
<contact fullname="Himanshu Shah">
<organization>Ciena</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>hshah@ciena.com</email>
</address>
</contact>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIANcKl18AA+09a3fbNrLf+Stw1Q+2W1G2ZcdN2FecxGl910l9bN+29+z2
9FASJLGhSJUPO97E97ffeQAgwIckO9l2u6c6u6lFAoPBzGAwM5iBfN/3iqiI
ZSCOxf8ev/5WvAiLULxKJzIW0zQTr87PLsWzMJfCC0ejTF4H1qNaB2+SjpNw
AbAmWTgt/EgWU3+xjHN/BK392zCZ+fufe+OwkLM0uw1EXky8aJkFosjKvBju
7T3ZG3o3afZmlqXlUo30I3yPkpn4Fp95b+QtNJgE4jQpZJbIwn+BY3leXoTJ
5JcwThMY/1bm3jIKxN+LdNwXeZoVmZzm8NftAv/42fOSNFuERXQtA0+Ii5fP
D/YOhtWf+4HnRcm0auOFZTFPM/hD+NBKiCjJA3E1EJdhOKEHPPGrMJNvqodp
NguT6J8AJE0C8d9lEi1lJl7LAieZUxO5CKMYKJBDn6e/cosBzMsd6W8DcRH+
M7RG+lu4yMKkeuoO9TzKx6m4vM0LuciBVmN7rPxNBr2ejrHNYJwu3KEuBuJb
IOU8sga7CN/IfG4/v8dw2BK6Ncej4X4aiLOo9MxQP5VTCdxWz9xhfkhjkDWb
fGqIt9RpEEflAIXu6QwfN6f2w0CcD8QzKbNwYc3uhyifJ6U4D6+BoNbbzbl3
PaJeLv9sGatJk+/7IhzlRRaOoeHVPMoFrJ1yIZNCjNOkCAFdEYp8KcfRNBoT
BiKdimIueVGMzPKb4PJb4PIbiCv12mt7LXKZXUsAi5CpwRRQljgXWukw7jSa
lRmuNWCYWIRJOOMvDDS/iYrxHJ/k5SgnXgtAS732ZRKOYjkRsExhZQ6EOC0E
zEu+hUkU8LyYh4VIYQasVLwaernYloPZgKd3Fo4A4UsaELqeh8VcbJ9dnu+I
ywKIAWv67MU58EdcXP5w7l+d0Fw9hrMjbqI4FmE5I3KuJhmzYhFNJrH0vE9Q
q2TppBwjwT3vGIiSSZoRTrtOUOSanEYJYBgl4t27/wLl8fjg8MndXZ8oGBVi
maXX0UQqkke5h5RGlCbyWsbpklAExuohbHpgUy0B4ngyyWSei5fhIoojALh9
/DLfGXiXWkTi+Lbv4KBww6EXRp2HYiYTmQHACzXiqRZMmDAp9e2L02c7zC2Y
oBrXp3FvcdQdEc6SNAcuDNzxwjhPzaCwRkDmUSmP4RvMEKDmxIMJCg2SwGBy
+szC8PT8+pCoB38cCZjkABeIzUNuqxG0OFA460gJQN4+ltfBORAekLVwMomQ
ImHMHKHBWMBzll5A9SbMJkhBzVLDK+A3kJYX7RL2m+jttgSxhD9zRCzi6R+/
RGy24UWIs8jHWTQifDwjsmEG662A5VOCFJqJvXv3jdql7u4Gop06Di9Ckcgb
obmh9YhNkrpkh3knfYoUtm1cFQkpMx6Z1nzOCsh+DrCNFHC3nNvitImoIUJK
4b95no6jEBUFcYAVBdDIdEcB8rbzcjxHgqGY9AXLy5HTCEDv9MWoZNhaKxlb
pmLcwDt5G4J5wvJJgJtzIiDqT1jMM1CZCwA3uiXVA6LsgRJPcljqVaeMmAqW
yIwIvUTtBSOE3WptIL6n+UpGiPpn0rPxIGqNsxTWImjqBISCWKFl7iy8lZk/
BMn9NRzLZAwqoi80sdRL77gowvGchOh5lI3LqMCRto+fE8mAQtzwoB3KpaQF
5SvN4W1fXuyAfuCWt/o1aqbJr/7l6QsAbYu1FqPDvSHIbV1s12xWEavDaclL
wVWeBMUAUNsAqO5rSZvZAsTOz9MlaIcC91LAhiVBhgiNiA36BjY1n3c1eMKi
DJt74i3LbJkChoACEFwpdAE6EUaPQEGMyigmPTCK0/EbxpOlt7HDRcl1Gl8j
7SbRdCozvd1naewv4zCRCB5M1jTOeQdhPMuE9iPShClrOZlM+ri/NDZYd7uz
CEqb4khqtUgy7IFmKBcjQBWoaOEMPUpcForO0BYgn55cvVR7NEj/1cnxZYXi
DdvoHtntuC0Rdy1YTfWM5gZsPERURFqZVeIVmh2SmqBnQUrDO7YV4fbrVy+O
dyqtxOL0ySfiSmaLKEnjdHbLCBTVA2KLEseWvTwXJGFlYknq508e7WnQx7Dy
klvAFqd8TI5QRAo+97yviQbgrZRxEWkGOmsdSQPNQDkFbfsuOVPYAFRB0KYk
+N1FUAdKwGRGr0/M65PJTFpvXp48D8TLars6+a2MrsNYorp8HoPexUavvzt7
eRIAE94W4rt0qSDZvUBKb7Hl6dkrdL7AtsbH3O5VuETjqXIM2R2sGbZaGfCO
vGW8wy1HUEiKjdlEUgxjLcGtA93i2TawbfmutjVdqcaV4GnzsAuNahUTAKCL
BC2PlovSAfSlhVc5afR8x7PMWW20sm3Llivvj8p8hR64bbGssfP9PWiv60je
1KmoxJW6xzi8NrlZWSZ6Zo7PoPd6bWbinu9s912G7MADGdDbUh82W2XQ6CF5
kuoLrVUCQUac3pxx4+b9rNI9QMVxmGW3TUsrVVs2arfWTbtGj3taOtU8vQ3N
Gtoiq41sWmYkFgSAyOfDy2iW3N3toGIkSaElg0ODEMMuUdyKrVAZ0lMypLc6
EWH7k+bRQ7HsVTCATXk5m4F1yVS+lLQviAOcqMs1S44sJ9bz/q/6eBjtUPJg
Pp/57uczfHgdiAhWYFZAD3uN0Oe9oBWkJQu+o+cc6H3GE81PY5C2RgSm68X7
rhfX8KLa/lrG23hCSPv7TqZrIqn6z+pW792v/+hodt0y5S6Eqlm3PWVULA1l
z93P6dFTeGY/jSfLAQby8PlADKA/6C4m4gPGZrqbCTwNyBeo2wpggs7Tm4TU
AejuEuMmrN2S+NYR6XeB+GQazRjVTMbcjAKcX/Uu1Pd8Hi3BEipupOTQhd4Z
endsNnTtCca3neP+EMfpDUq8Wp5gKgeeh50C3CZJSZmVy0pBbXx1TWBa4fxQ
R2n9hZrHXvwrXLJMau+yaLpgBiDoBdoyfDJV/RCmMPZRhxHKx5Yl7uCUl0tc
LDAy9WZDV1BvJjCC2DZmXxf5TGDLpd88ms39GC1NUdwuJZtYZEjCW01TH6xQ
ZnruYytGOIG9AiRESQM+553fUCPXuNM8wIzPI9xaiDAGohp2G1VCLn0Y3lf7
TR+6LJsP2hoi0rpxnKZvyuUORgDn8VSCbow3RxiJgx305kWWGXQD82ugAeZA
mViiH1hgH8U9orUmHMOtTC7uss7AA9sah9tR4avcdsuXIYYLwajM6wELca+A
Ba0Mg2aUe8aHVZ7AGKXwZg6LM9RoJ4C2Pwe0o7wRKWCCwUatxI8JBg1LjDUR
HCtYo02mZTh+IwuOUnYIZlRZ6Bj3F2J/oPx57LqVE1YCsBogHcVWK2+2SEm5
MxFqJtpc7QOWEducShUqWAvyKBxo+pEBxBEKLdoDQnTIiFoSDkarzHA6Ovhm
JsFLGvTD+M0XrHbHYYKOIrTUmlmJYkWaajUGqkm4g0Ich2NJTRmq8kcLmK4C
YY2m4jzg9ALx0Eev9jElEcAmNIOoj3o52sFVVgelXo4fiEO4cmRe2wXK0bLM
HYzd5hUU6pdDSyXR1ogD1Wqy04RGzVDpc1S9TFxhJdaCuC7CW7Z6ldyycDJM
Ci2jHR1HyRvQGuNwmZexEYJSrywKWi2ioohMkMoMAR/JkG5gJDLIx6Dgm7Tb
ANAUVcmt8qSsBQX0khNWHmk2gXfsVoFYwWKZRDlFXNJpRdIK9MDo1cby2EQR
wkqUFDUiPaGDPwA+yv7l2s5ztJKzlH2zlFfpNy/CU88pSHjuG1NjzYSJbVFe
Rcp0SLSCRQKH0Z6obiPcewTAHnwhHWKz7IXcojNzGk0mGA1gsL1WPW0dVIfZ
V/m3aOwQ0azRLeVPK6NuSFncYmTCMVpP5NFIxixKlmWxOVJq1W/ZgLbExflz
c2hR3/LaLDXjwb0g91K8+8TxNq0Aqva9zKmUc8ziHGFZTn+nx//uXWVCAzm0
GQ2GJprhzG4TD8GgJh+ZcVTcjT/ySICIHozj8wPXEW33czrdmU53kT/vG+N3
eosPGuEX+OySt/Ye//xF/xc+K7rtGuzU5x/Vuy5Pz+pmOYcbdUxb/rL/bJlh
RYbPur58VnOlm0DeE4evD3eIPvzlyPrydof8SfwTBWynjTf3R8TzDJTPAjHO
ZFh0SqNpWbn13W27fUtrYWzkX6IlkkycNU7+5nGunFtahh0Lr7/6FNscdVqH
dpUHCSqyOmp82Olmx4EmB8wAcTohUktbOAHDUMUCuZdXRQi1mKBB3xIVVAoc
HMxY23HoYIGhoDdLL5OLtLCMpipyWAsZKh8WUGQsOg6U2aQi2WErAU2AQq6M
Jq4+SjYxRRpKOeXN488VR5R9D88xMSZSUc6cjBpdepkupCb5urNMymBaeaBZ
D2pfmCPN7bPLi8bJJmXprDzc7FsjtpxiqvwRh9lAuVCfWjoHkz9cvHwouPpR
KSIemtNLDC1pe6g68jTHqitOThG/D5rhQQcanLmkUeEwnXsEK9YfwfbF5YU6
mIk4LI2P+5Q7VYwH7WElfURb2SBXmZTiRRSiuNSXT4HvJvyOp8+OIlsKILys
ONpWyR6skqhdA1LKIIImTJy4NceTgioqCbPR5zm7WREoY4ddU9goshuhWonq
SVHEZHGGM1jk36hXozSNZZi4LTnuadnE+vX7rhafir8DseXbn62WBhy9aWx6
yOkCj6vbuoACygoe4BunCzyl4FVQYdDWX2JQqtl74/5WuJB4STFDhKXDhKBX
m/1SmCp4OwwWV0OZFAoBjCAHM+CZPBi6xK6cEsswqL0C8mLi3s+u6cCN8EUb
cQHXaWAg+BbCdm8ig9LHLq1qkuF0Ct9Gi3LhK2/dZzcVu5cwIE2wRTrpz2iU
q//qNzI3f1Xym3YgZiNltSM9YzO8i83cx9rdfd4hsZf/tRgMduvwrG7sH5Hr
/bYwOBkhftCU8Q+zwduUtl/46ZLMLHyWR7jp+fpVg2S8KO0gkXpLAVVcp5Of
a4IGYjupiQ7y8XGjWWNFrVhNphOoHVew2mEXWTiFvcof4wH9N1az34es5hm6
9Y0HnSBs8pOaq+kbS8NxoxHwpVz6TttGozgNJ/kcbBcLGpJj/8iRxljWtVsV
ff9LLEgs7IAEfldxDQXfv3FUgTqmWq8L/JsOtdMx84fhCv8FZBui15DvNpFu
9OpSG6uko1s2NpKMB8jFRlLxsWXio9J5tR5pVR0bKI4N1MYGSmNDlfEfJBKd
0Qxja+tQRpXJZRv3GK8wHgHFIF7x+T2n5OQqHeWheV5elecluvK8vq8nKaIb
hgcinM9BUQKdrIEAyEGxzvjJ75pMdO6nlbMNg6jAQJX+4SQw0gD1M0I7sQzr
OtxkmI7AQK0Zs7yl8fDJYdXYita3gT24u1NssJGmmAaYdJhqOm5kLkBPDN8y
PH1+U53Bu5FuxRELeqASl7B0CmNU796ZSDqfmXFs/fPD4WHNh/O+fP79ixPx
7OTb09eXX4spHn72DNmfDveGe/7+nj88olSTnqdZYBjzzmMfwr+WGSXi7Q/2
v/C4nidfou/cK7MkwA4BneTkwdtFHCR5QJ6HAdT7AiOHu5+KC3VuSPGx0+PX
x+oAWp9mfLqLDVXuG/akjkroHJ6/o7Wos+SKL+irYYFaqD0lC11Vd9q/r5Jh
ewjorn1MJUC1kfnpivFBvILn6WIB5KtwuCJQ+lhD43GcybAVA2JCy/D4vHvo
oydP9gPRPnbrMJbwO8NE05X0Peii76mJsTQo7Ll1XwSwR7nPzWpE6kKnsGPe
MXs/fit+lKMA/vxyXhTLYHe3AB8tp6q0AcDdvZmRHbX7tQpZQ4cz2Aqhx5dY
SlakpPqf6va62ckkKtIM4dYqDK2PBtAoJWwCqRcPtkCpFwk2gTSLAlvANIr/
mnDcir82IN31fU1oXcV8LWBbqva+JpbyDras+N9QrHYqWFUKYG1gagXx0Isq
p93e2EwZnao2YPEs4/jWZMdz/w1S5EVLivxAEed5urzNotm8ENvjHTHc23/M
yfxXWHWrj2UxuJ4bG44DO5TZgFnFVPxqdmXMBhgIcRzHgsDmApOXsms50SNe
yEmEBtmoJIsAh8DUAzwqSMsMlh0+GYGnkVGG2SLvq2wQlQCDX0D1IElM/WMf
I4VLzOgv6IC+zPIyxIS3tK/rN36Vah1qisXRWCY5FwLkOl+Cdk4+UrlEP4Cn
+ezyBYggNWcQmCYAuAFWVqrt4WCsqVCRcCsXZ3IG/D/XieG5JgOe4ODGmnLz
FypJQL3fRh2Ro5JAMFJWakIh7mPKxI7KGSEh1BseIVETSqRPmJGMgf4TP8Hn
C5iGmg/pc3gcFbmMp6qcBlgYE+pJWsCQ+UDtiLvU9GQyCExKDYJT50cgZNAF
W6jyEaQ/nsdcS8KKIQBIOagBK5cTPFNRaSpgn0mwRao8B3qm0F+Wo1ixnoHU
BlHwPdT+Kh2/MhzUNlFfyKjKk4jWqu406HVvITTnrj3EmJbVxgGGxKnJBlU2
g8mkNIaL4K7oezmZoF90oezmktZyBTkTRVWHMqBBhZEzug96bgzqwsaCskjY
oHnw6Brseizas0+7mUUuiJOLakGoZ6BuPqDPCjmzCdHespMqZ+2ZsPA/rQv5
pd57gIY8KB218RmQwuIeeIfLpV4TfxjuFg4DW/Q/xeafkhEHuyNpOF4BBT8R
bXm8ahb0p50a+06Njc9EM9/WvG+bH83xe5P7yL0FbCez1GSA6rwvDa9wSg10
UELrBjZIDT61pOD7IIPJi5EunqoOtis0Nhn7w+jRRKFvaNSWjCnWkm4dzvlN
+GCCYd8GumwrOFghSjbO96NolbX9EZipM21DwSDr4951rUs3LT1nV9xaY3oh
VUGqjZbPMosWaGitndlrnWUNGzylPeqedD0EJmaQLcPBpQ5qcmjuAWNxxy4e
MSLEpwePoGdDticDySNMwgwTmZZ5fFuTH5WL0jHfTi5SDbweG5lkcdBEU1pz
xbv3weMH5/XrOX1Aer8G0Zr32sznbyQ3Yj6/hvGQtH5FeHAg8rYAKUdlu0jc
yBF+CJFX5AzriX1A6rBOCW9S8h65wobArbSLZThViQd63ZDO4KC5Fuy2hQRU
ASwyv8p0N65hJsC7i6OcE7fACPytlPYiMhY154FoXlPMXBPDPMXzgEHVFxfR
dRiX0jg6jP08RLsf2AEGCRasLWSYWFIuVHYU8I/LxTQOOrrJdTSKKncVbewT
hT+MREoptVOKy1r+CDI1fSP2jg73nuxxUuPL548+3z9sUtUcwrgk5XOYiqTT
EKRb9PZ7K6nM7i9NVi8NzBdMF0sQdNps9WBWtUuZ+PI3cFarmWMzoHQc8mzd
1WVsCs0DfROH6W6YPAC3kIfDkhnGgoMlgjZhwxHlIrMyrAAVaQFeaJlg8QMY
4dXCxpy+NZTHkHrfnLc8Ghz2K7gqBl+9Phjs7xOb4I9hi+hbdoTiT2VfrGQI
S2S1w2mopKhbN7imkq7VM3Qr5zO7gqHqpUfWoR0rfS43k2rF/qyzJMKGK7iw
ocrJq8yON/JW9PDAwTTtNEXayy7qq0zxgzKY3lndiSf17KUvrAbto5JishRM
qkpDF5LzNSs8lIZRV3rh3ueAUTefjJqZqjbud+4s7ISl5mxU4pI7CaUGpmGc
2zRdMb+tIivlFtCGgytuuRPdksLjq0oIM+OBO78tGnIFnEmU24Bq1DFQV1Cj
NUWsSRdOGLPnDnsG2Cy9dFzIIt+MKq94sFqpI9hc/3RQbFMu1F8d6dkaZNg2
t8oOdtf0LE5Bv65Yy7QcuJW5dY5prWE4douTqelqqpocGRlCuVi9m5wbgFdX
ZyZb//Tc3Glj6zR3fnYq6AqF1R6oqs+wUlyNNNM1+qsdvoFX02B16HVFRnbD
ek3maE0b2YYac00pwzHXnOoe6YPMKvxUms+kX1dhrxVL1cq1bWLf4n7YU1ng
ecrWQHz5FeZLmazbLQcQuLRZlmb+QuZ5OKspE3YfbRwIJujeGCOrZLBhfQXa
NKLn9P0MxD6tUn2dlX63Cb1tiSIMVlDJDPNgGn1NNLJmem8qVThoGs2oeiPb
gEzWuB9GKEBiBZlaE6dbNvcqjbpGhLXh3Qei3Ro6b51CM4fbQZHs5x4YsdE1
7GvTLF34wDU8YdoG9rbOv1/jCLJki84hVkfrt3YcVhHl7ERy+yVvK4I29o2U
jU0cmrIu4qYp32f7a6ln3SjmkE4b93ZYdbL2hthM2HZ3RWzkihJdQdhryeFs
hNta9xpOw2oUgbU6E1ZS+AMcad2zLRrUKGjq3qJXlPFuxAt1xjHihLE6W9zC
Xo0+1vfyCHYxcCfj9GHZ78A5hT9jzaSzUWlhY30wF8sVGr4bCav4qcE3nana
s1JVe2vsxzYiu8bUavuJgJgOfeXhUFiB7lGrlXSH2UxiJd7E2oqs++Hw8kiV
U5gr5dMX1QVwfJcSXpXEl8BVMPA2OLwvjnMYrrIQA6cnyQyQ4tsr+c64y3Nx
VSaJxIshsW7LcJ+cbWVxO89s48x5UXO5a6zY/dStGLSJwMd5bcxaX4Kwgp0U
2HEGwu/OCsQAiX3RrL2oWj3Nld6B62G2SsdpMqGrQnPc4Co2Wz4lJ/hEeVMV
rVtDvGXqJa3hfSXYmzV4fZSltj6sbsVsuneuSi6OXzbuOqirRxATe6JdtgH8
r5EC4ZgGxiyg5OGdnqUVO7wTW5IERwujCV/AQ1FOlml3o7XNAMC+7ZjHWRi1
0oGPt0J2q6nDzNdk2rcUMaxYYcf6sstaly2+a4kubDRZHO4S6w7m1eT5ftrA
4fKu4XLXamhwwakj+AN54NYzdPVuVDus04akQJwLzLccWIpxIMkV4/TYnfzr
Ogr7YzjYbi7dj3ut9UwraHtK4zXMB5PuXLuxJRzbCgb3cEq6dA8k11qa/wrd
+WdUnMhwLi76WByvLzeG/nso1O95Hh9VklafmPw70OfjK7t/HR0byo4peadK
T05ev7j82murh6JU2qosyqmIqi5f4WYDqojiepHnQKRoonN36rcUZ3IGVMGU
ALcE538uTnN9/rKV5FvkSHDj7NbJNP7p1ZnQL3ThzdHjx3xFswbHwPGONS4O
Mo36tXEVJG1ue5n8reR7hdkPWoQTySU7SFjAMhAbFdRg6wsFG+/K4NqIwPwy
DdY7WLOigxiYWSBe7x4zjhUmMCp5AgnN3ZT2DAirTvqGzWvnpV2sJl4jIM/Q
mEl5tDfc00VKiBP/MBB/nMkZNODtxhThcAnD089Wp1h351ZT2jMCMAHugA59
sS9T5hPMVi8zTCOtC2XjWn4ruF6/oJ9LHDD3ZTyXi5AvAsLfV6h+eUUVR7HI
hOMxVkJMxHWE11dzqYJV+WB+2oCuNPHAyX59cvX8+9cvNQuGh/t3d/SjPieX
9ovHe3hPyICzHUB+QTpM1xhvUMFr9egAE6ct+UpCqh2it+b+RkQGJpBmt36R
+qTrCTHu5lXdopwpKMXlXILnuX15+d1OheWwjozB12Dz3dXV+eWGAwtn4CvY
WPUtLIdH5ocy9HyZyPpHI1TJiCkCRPqZkkoaGNxfPLwFccfwG95FwwDoOtwQ
XLxxGYeZAW8THw9f6OA39EB+9TmdpEILlQ6Fbnl4HUYx+eltQDTTPSutEami
tDLPDhOZ8P/Wj1FQzSdGW5o/8NMoIsW+NyDuiMQuXeBEfwFlJP0ltqOBHPR1
TBitUrpxdTwXSnBUZIB/9UP/bAaPjrWlI7q7mBYSTh8vviMrCCZ6XcYJTGwU
q+KWhTSiL5PrKEsTMuEH4kdAUNrJnXRzfl/ISVT4jNmOOqN3EdClMOyTE0HV
sSze0zoPr4lwcsaGmZxO8cYhumCT0aiG1LOjFBlcLuUIq3uZIdaI1T2Neqqg
Snb1TKMYvgWe5xgixtrcrcfx816AwBSLrVE484U4SjFOh5WSKKqvPtpyTokQ
va3qbK2FtETG1JBxqfk4DjGuP4nyrFyaiCjb4fIt/jiMld2qbtVSexUI1YRQ
sibAW4trEChx8T5YXMRpwVqtzFUhJJc6mZWPGOnFrEQJ9e5MFn38R4lU34NB
sbRHF1G1yhhrsw7J8D5MMu51N8nDriNxbU1E+Z5uY90ufoCrECiiAi9JnFV6
pn2/oHXrHkfpwMffpt9IcvWbqnQ/Zt4Wqc7rq+7ORSEDKR7HKONOFiVpdVhM
rCnoZAjosWt+y8SCUpNw8s6qJdSmbD+WKuTfaukW7dCaOdK0W4PVNpUPFs2O
eALC/jCRWicfXot8mHXnXBa4gbSgVOAY+moER1xsOQpHtLFUssJHQ10So2gc
FloS9E+h0KEJ1xPygxBvy3tT/SJAru3RsWOPovUZU1pVafkrdIGAuj/A3C5A
5wG3VdC9+vkX2CEBCN6XC0R4k6Q3AJAtTh5b167epGU8EXH0RqXChckb8RNo
zOfqgniBiJMIqqpV88tUMsziW0/XC+YmsVPjwGMvl/izL2/F8UAVs+PFGaf6
7kj1S3P4k5KsOszaAFOqXDqX4L0kO0s8ArV8sS+yUl1Mf3p5aq769bRdxTYm
qJIswSrccDxXwq6Yi/JmXcCJl1Sc7wdi/8njwaP9wf7e3mB/92BIQM6HjefK
gmUYRwaGOD8IvOHe3n4wGT0O9oL9vSDY3z3in208PwxEyzuYzI/qPoowz4Fu
nGcIE1TIM758dKFdnkI6mTt8gSEbrzhVfatomdMPaiF9+PeI+EHrZYnVxcUo
nBQB8PDHT7D4CcgdeF9ZHwoqEPnOeYHoT/Ujpa3kxM/+ERDBqxF1aL8dehr+
0Sr4B630JAgHXgu1h/rtoefRlZ76BPH60OczxMATl1SGrT1cG8UDDy+c1mfD
gfvy0FPHkP7pC+68v+chbPMdH9mRwbbP/pPhAGgxeLR7sLeurT05nvmaHrKY
rwOKd1atbrLb+fqzNRdEv8c1u+LG6XX96bPiQmgDZD0ZNubD/sH9GDFUjPBU
5IwCZ+r+WR0vUwqPYsZK0zmpnhQ64+t2tI7ku4hRbY5JVxeomTGwkOsLRQM9
JCDbs29AMUkDAYcae7g96y/8tRf83UzRTmDiFO6gd3H6zP/hsNe3X7kx9l5g
v+N7SZawqNT5i8Hl+rDMAvuNC5Tt3wo5+7GNZBNVjbAxOpsv4bWuYaguTYHZ
4apw0HDnUR3fWCVV7fChC+WtN1HtRrkabNIL9tvQUO85syUg3bmiWVFAo+Gj
Rx0t7lqf/9zy9K6bJK2sNa6AkgxHJEx/o996jbctA/b4Sgxfb+nALTA08gD/
aWFZnWHqvK0XUFxjbXM7g6iLzisI0Ew9ayFBr7Yfrp6FkzIGk788fQG7yU/B
fp16Ddrdf204fmOnfFdAHiDi91t+qlNFDc7DDnr7mzW369agVxupW3phzQ60
blbVbtZ9U0WhOq5RF/xZBYGHX606VCtLsIdrG69RI/xpVyb8aVMpqtc6Qrau
LqNVVqmQNQM8QDQ3lLV7CllNNDcc5C/RpMZ/AtHcP+iUzc333z/BBtnCrI+5
QQ4fvEEOGxuk892md/XGom+nFXx0fyv4qGkFH7EVfPSXFdwYbHMr+OCPt4Kb
rN3MCq557n92W7hJhs2WejN285c5/Jc5/PvbHIf/7jZHc4GtUi+q81ols2b8
v6zlvyRX/NGSO1wluf9RtnQLKz/2BovHH/9e9jTdEbrSoq7Rjf75y1w2g21m
Lg8PVzrW//FB4yy/Xgb4z794HSOdOw1l6tO2bnvU7V4Ls9mUjjMvs3Fgn1f2
X+SF/eCwfwWKoH/WYjF7Xd+s9az+YsYrytfoYR0sNS7tsOW/8dYVf0fke3rn
pz55Nhs5HR269ezbC0iv7rnvq0sg4O2j+tvWonw18poS/F4rzfQiMXLaq2pM
HXpYyqWTEEZ1tmif3jrh7bVftANkOHxs/0iKs6I6h6+L68cbvkk6T/+LNQpW
RcIIfwo216eqL1P8zayMD0+9Tyi/nvJV0ixXZ6MI6HSWZuJZdpu/4dsbvyvD
GxmJKzmeJ2mcziL+dT2J9+AHIvplxE2f3obzlC7p5x/U/Q6syiSfl+JyHtLv
fD6PYPJWz3kOL56O8Sn3Igz+H6Q99kxUmgAA
</rfc> </rfc>
 End of changes. 108 change blocks. 
1123 lines changed or deleted 554 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/