rfc9194.original.xml   rfc9194.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902"
category="std"
docName="draft-ietf-lsr-yang-isis-reverse-metric-06" submissionType="IE
TF"
consensus="true" tocInclude="true" version="3">
<front>
<title abbrev="YANG Module for IS-IS Reverse Metric">YANG Module for IS-IS R
everse Metric</title>
<author initials='C.' surname='Hopps' fullname='Christian Hopps'><organization>L
abN Consulting, L.L.C.</organization><address><email>chopps@chopps.org</email></
address></author> <date/><abstract><t>This document defines a YANG module for m
anaging the reverse metric
extension to the Intermediate System to Intermediate System
intra-domain routeing information exchange protocol (IS-IS).</t></abstract> </f
ront> <middle>
<section title="Introduction"> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
docName="draft-ietf-lsr-yang-isis-reverse-metric-06" number="9194" ipr="trust200
902" obsoletes="" updates="" submissionType="IETF" consensus="true" tocInclude="
true" xml:lang="en" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="YANG Module for IS-IS Reverse Metric">A YANG Module for IS-IS R
everse Metric</title>
<seriesInfo name="RFC" value="9194"/>
<author initials='C.' surname='Hopps' fullname='Christian Hopps'>
<organization>LabN Consulting, L.L.C.</organization>
<address>
<email>chopps@chopps.org</email>
</address>
</author>
<date month="October" year="2022"/>
<abstract>
<t>This document defines a YANG module for managing the reverse metric <t>This document defines a YANG module for managing the reverse metric
extension to IS-IS <xref target="RFC8500"/>, <xref target="ISO10589"/>. Please r extension to the Intermediate System to Intermediate System (IS-IS)
efer to <xref target="RFC8500"/> for the intra-domain routing information exchange protocol.
</t>
</abstract>
</front>
<middle>
<section numbered="true" toc="default">
<name>Introduction</name>
<t>This document defines a YANG module for managing the reverse metric
extension to IS-IS <xref target="RFC8500"/> <xref target="ISO-10589"/>. Please r
efer to <xref target="RFC8500"/> for the
description and definition of the functionality managed by this description and definition of the functionality managed by this
module.</t> module.</t>
<t>The YANG data model described in this document conforms to the <t>The YANG data model described in this document conforms to the
Network Management Datastore Architecture defined in <xref target="RFC8342"/>.</ t> Network Management Datastore Architecture defined in <xref target="RFC8342"/>.</ t>
</section> </section>
<section title="YANG Management"> <section numbered="true" toc="default">
<section title="YANG Tree"> <name>YANG Management</name>
<t>The following is the YANG tree diagram (<xref target="RFC8340"/>) for the IS- <section numbered="true" toc="default">
IS <name>YANG Tree</name>
<t>The following is the YANG tree diagram <xref target="RFC8340"/> for the IS-IS
reverse metric extension additions.</t> reverse metric extension additions.</t>
<artwork><![CDATA[ <sourcecode name="" type="yangtree"><![CDATA[
module: ietf-isis-reverse-metric module: ietf-isis-reverse-metric
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis: /rt:control-plane-protocol/isis:isis:
+--rw reverse-metric +--rw reverse-metric
+--rw enable-receive? boolean +--rw enable-receive? boolean
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces /rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface: /isis:interface:
+--rw reverse-metric +--rw reverse-metric
+--rw metric? isis:wide-metric +--rw metric? isis:wide-metric
skipping to change at line 73 skipping to change at line 90
+--rw exclude-te-metric? boolean +--rw exclude-te-metric? boolean
augment /rt:routing/rt:control-plane-protocols augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/isis:isis/isis:interfaces /rt:control-plane-protocol/isis:isis/isis:interfaces
/isis:interface/isis:adjacencies/isis:adjacency: /isis:interface/isis:adjacencies/isis:adjacency:
+--ro reverse-metric +--ro reverse-metric
+--ro metric? isis:wide-metric +--ro metric? isis:wide-metric
+--ro flags +--ro flags
| +--ro whole-lan? boolean | +--ro whole-lan? boolean
| +--ro allow-unreachable? boolean | +--ro allow-unreachable? boolean
+--ro te-metric? uint32 +--ro te-metric? uint32
]]></artwork> ]]></sourcecode>
</section> </section>
<section title="YANG Module"> <section numbered="true" toc="default">
<name>YANG Module</name>
<t>The following is the YANG module for managing the IS-IS reverse <t>The following is the YANG module for managing the IS-IS reverse
metric functionality defined in <xref target="RFC8500"/>. It imports modules fro metric functionality defined in <xref target="RFC8500"/>. It imports modules fro
m the m <xref target="RFC8349"/> and <xref target="RFC9130"/>.</t>
following RFCs: <xref target="RFC8349"/>, <xref target="I-D.ietf-isis-yang-isis-
cfg"/>.</t>
<t>This YANG module uses the same "Per-Level" hierarchical configuration
structure as is defined in the augmented base module.</t>
<sourcecode><![CDATA[ <t>This YANG module uses the same per-level hierarchical configuration
<CODE BEGINS> file "ietf-isis-reverse-metric@2022-01-01.yang" structure as that defined in the augmented base module.</t>
<sourcecode name="" type="yang" markers="true"><![CDATA[
file "ietf-isis-reverse-metric@2022-02-03.yang"
module ietf-isis-reverse-metric { module ietf-isis-reverse-metric {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric"; namespace "urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric";
prefix isis-rmetric; prefix isis-rmetric;
import ietf-routing { import ietf-routing {
prefix rt; prefix rt;
reference reference
"RFC8349: "RFC 8349: A YANG Data Model for Routing Management
A YANG Data Model for Routing Management (NMDA Version)"; (NMDA Version)";
} }
import ietf-isis { import ietf-isis {
prefix isis; prefix isis;
reference reference
"draft-ietf-isis-yang-isis-cfg-42: "RFC 9130: YANG Data Model for the IS-IS Protocol";
YANG Data Model for IS-IS Protocol";
} }
organization organization
"IETF LSR Working Group (LSR)"; "IETF LSR Working Group (LSR)";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/lsr/> "WG Web: <https://datatracker.ietf.org/wg/lsr/>
WG List: <mailto:lsr@ietf.org> WG List: <mailto:lsr@ietf.org>
Author: Christian Hopps Author: Christian Hopps
<mailto:chopps@chopps.org>"; <mailto:chopps@chopps.org>";
// RFC Ed.: replace XXXX with actual RFC number and
// remove this note.
description description
"This module defines the configuration and operational state for "This module defines the configuration and operational state
managing the IS-IS reverse metric functionality [RFC8500]. for managing the IS-IS reverse metric functionality
(RFC 8500).
Copyright (c) 2022 IETF Trust and the persons identified as Copyright (c) 2022 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Revised BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC 9194; see the
(https://www.rfc-editor.org/info/rfcXXXX>); see the RFC itself RFC itself for full legal notices.";
for full legal notices."; reference
"RFC 8500: IS-IS Routing with Reverse Metric";
revision 2022-01-01 { revision 2022-02-03 {
description "Initial Revision"; description
reference "RFC XXXX: YANG IS-IS Reverse Metric"; "Initial revision.";
reference
"RFC 9194: A YANG Module for IS-IS Reverse Metric";
} }
grouping reverse-metric-data { grouping reverse-metric-data {
description "IS-IS reverse metric data."; description
"IS-IS reverse metric data.";
leaf metric { leaf metric {
type isis:wide-metric; type isis:wide-metric;
description "The reverse metric value."; description
reference "RFC8500, Section 2"; "The reverse metric value.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric, Section 2";
} }
container flags { container flags {
description "The reverse metric flag values."; description
"The reverse metric flag values.";
leaf whole-lan { leaf whole-lan {
type boolean; type boolean;
description description
"The 'whole LAN' or W-bit. If true then a DIS processing "The 'Whole LAN' bit (W bit) (RFC 8500). If true, then
this reverse metric will add the metric value to all the a Designated Intermediate System (DIS) processing this
nodes it advertises in the pseudo-node LSP for this reverse metric will add the metric value to all the
interface. Otherwise, it will only increment the metric nodes it advertises in the pseudonode Link State
for the advertising node in the pseudo-node LSP for this Protocol Data Unit (LSP) for this interface.
interface."; Otherwise, it will only increment the metric for the
reference "RFC8500, Section 2"; advertising node in the pseudonode LSP for this
interface.";
reference
"RFC 8500: IS-IS Routing with Reverse Metric,
Section 2";
} }
leaf allow-unreachable { leaf allow-unreachable {
type boolean; type boolean;
description description
"The 'allow-unreachable' or U-bit. If true it allows the "The 'Unreachable' bit (U bit) (RFC 8500). If true, it
neighbor to increment the overall metric up to 2^24-1 allows the neighbor to increment the overall metric up
rather than the lesser maximum of 2^24-2. If the metric to 2^24-1 rather than the lesser maximum of 2^24-2.
is then set by the neighbor to 2^24-1, it will cause If the metric is then set by the neighbor to 2^24-1,
traffic to stop using, rather than avoid using, the it will cause traffic to stop using, rather than avoid
interface."; using, the interface.";
reference "RFC8500, Section 2"; reference
"RFC 8500: IS-IS Routing with Reverse Metric,
Section 2";
} }
} }
} }
grouping reverse-metric-if-config-data { grouping reverse-metric-if-config-data {
description "IS-IS reverse metric config data."; description
"IS-IS reverse metric config data.";
uses reverse-metric-data; uses reverse-metric-data;
leaf exclude-te-metric { leaf exclude-te-metric {
type boolean; type boolean;
default false; default "false";
description description
"If true and there is a TE metric defined for this "If true and there is a TE metric defined for this
interface then do not send the TE metric sub-TLV in the interface, then do not send the Traffic Engineering
reverse metric TLV."; Metric sub-TLV in the Reverse Metric TLV.";
reference "RFC8500, Section 2"; reference
"RFC 8500: IS-IS Routing with Reverse Metric, Section 2";
} }
} }
grouping tlv16-reverse-metric { grouping tlv16-reverse-metric {
description "IS-IS reverse metric TLV data."; description
"IS-IS Reverse Metric TLV data.";
uses reverse-metric-data; uses reverse-metric-data;
leaf te-metric { leaf te-metric {
type uint32; type uint32;
description description
"The TE metric value from the sub-TLV if present."; "The TE metric value from the sub-TLV, if present.";
reference "RFC8500, Section 2"; reference
"RFC 8500: IS-IS Routing with Reverse Metric, Section 2";
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+"rt:control-plane-protocol/" + "rt:control-plane-protocol/"
+"isis:isis" { + "isis:isis" {
when "derived-from-or-self(../rt:type, 'isis:isis')" { when "derived-from-or-self(../rt:type, 'isis:isis')" {
description description
"This augment is only valid when routing protocol instance "This augment is only valid when the routing protocol
type is 'isis'."; instance type is 'isis'.";
} }
description description
"The reverse metric configuration for an IS-IS instance."; "The reverse metric configuration for an IS-IS instance.";
container reverse-metric { container reverse-metric {
description "Global reverse metric configuration."; description
"Global reverse metric configuration.";
leaf enable-receive { leaf enable-receive {
type boolean; type boolean;
default false; default "false";
description description
"Enable handling of reverse metric announcements from "Enables handling of reverse metric announcements from
neighbors. By default, reverse metric handling is disabled neighbors. By default, reverse metric handling is
and must be explicitly enabled through this disabled and must be explicitly enabled through this
configuration."; configuration.";
} }
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+"rt:control-plane-protocol/" + "rt:control-plane-protocol/"
+"isis:isis/isis:interfaces/isis:interface" { + "isis:isis/isis:interfaces/isis:interface" {
when "derived-from-or-self(../../../rt:type, 'isis:isis')" { when "derived-from-or-self(../../../rt:type, 'isis:isis')" {
description description
"This augment is only valid when routing protocol instance "This augment is only valid when the routing protocol
type is 'isis'."; instance type is 'isis'.";
} }
description description
"The reverse metric configuration for an interface."; "The reverse metric configuration for an interface.";
container reverse-metric { container reverse-metric {
description description
"Announce a reverse metric to neighbors. The configuration "Announces a reverse metric to neighbors. The
is hierarchical and follows the same behavior as defined configuration is hierarchical and follows the same
for 'Per-Level' values in the augmented base module. behavior as that defined for per-level values in the
augmented base module.
Reverse metric operation is enabled by the configuration of Reverse metric operation is enabled by the configuration
a reverse-metric metric value at either the top level or of a 'reverse-metric' metric value either at the top
under a level-specific container node. If a reverse-metric level or under a level-specific container node. If a
metric value is only specified under a level-specific 'reverse-metric' metric value is only specified under a
container node then operation is only enabled at the level-specific container node, then operation is only
specified level. enabled at the specified level.
As the reverse metric is advertised in IIH PDUs, level As the reverse metric is advertised in IS-IS Hello
specific configuration is only available for broadcast Protocol Data Units (IIH PDUs), level-specific
interface types"; configuration is only available for broadcast interface
types.";
uses reverse-metric-if-config-data { uses reverse-metric-if-config-data {
refine "flags/whole-lan" { refine "flags/whole-lan" {
default false; default "false";
} }
refine "flags/allow-unreachable" { refine "flags/allow-unreachable" {
default false; default "false";
} }
} }
container level-1 { container level-1 {
when '../../isis:interface-type = "broadcast"'; when '../../isis:interface-type = "broadcast"';
description description
"Announce a reverse metric to level-1 neighbors."; "Announces a reverse metric to level-1 neighbors.";
uses reverse-metric-if-config-data; uses reverse-metric-if-config-data;
} }
container level-2 { container level-2 {
when '../../isis:interface-type = "broadcast"'; when '../../isis:interface-type = "broadcast"';
description description
"Announce a reverse metric to level-2 neighbors."; "Announces a reverse metric to level-2 neighbors.";
uses reverse-metric-if-config-data; uses reverse-metric-if-config-data;
} }
} }
} }
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+"rt:control-plane-protocol/" + "rt:control-plane-protocol/"
+"isis:isis/isis:interfaces/isis:interface/" + "isis:isis/isis:interfaces/isis:interface/"
+"isis:adjacencies/isis:adjacency" { + "isis:adjacencies/isis:adjacency" {
when "derived-from-or-self(../../../../../rt:type, when "derived-from-or-self(../../../../../rt:type,
'isis:isis')" { 'isis:isis')" {
description description
"This augment is only valid when routing protocol instance "This augment is only valid when the routing protocol
type is 'isis'"; instance type is 'isis'.";
} }
description description
"The reverse metric state advertised by an adjacency."; "The reverse metric state advertised by an adjacency.";
container reverse-metric { container reverse-metric {
description "IS-IS reverse metric TLV data."; description
"IS-IS Reverse Metric TLV data.";
uses tlv16-reverse-metric; uses tlv16-reverse-metric;
} }
} }
} }
<CODE ENDS>
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section title="IANA Considerations"> <section numbered="true" toc="default">
<section title="Updates to the IETF XML Registry"> <name>IANA Considerations</name>
<section numbered="true" toc="default">
<name>Updates to the IETF XML Registry</name>
<t>This document registers a URI in the "IETF XML Registry" <xref target="RFC368 8"/>. <t>This document registers a URI in the "IETF XML Registry" <xref target="RFC368 8"/>.
Following the format in <xref target="RFC3688"/>, the following registration has been Following the format in <xref target="RFC3688"/>, the following registration has been
made:</t> made:</t>
<dl spacing="compact">
<dl> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric</dd>
<dt>URI</dt><dd><t>urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric</t></dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd>
<dt>Registrant Contact</dt><dd><t>The IESG.</t></dd> <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
<dt>XML</dt><dd><t>N/A; the requested URI is an XML namespace.</t></dd>
</dl> </dl>
</section> </section>
<section title="Updates to the YANG Module Names Registry"> <section numbered="true" toc="default">
<name>Updates to the YANG Module Names Registry</name>
<t>This document registers one YANG module in the "YANG Module Names" <t>This document registers one YANG module in the "YANG Module Names"
registry <xref target="RFC6020"/>. Following the format in <xref target="RFC6020 "/>, the following registry <xref target="RFC6020"/>. Following the format in <xref target="RFC6020 "/>, the following
registration has been made:</t> registration has been made:</t>
<dl> <dl spacing="compact">
<dt>name</dt><dd><t>ietf-isis-reverse-metric</t></dd> <dt>Name:</dt><dd>ietf-isis-reverse-metric</dd>
<dt>namespace</dt><dd><t>urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric</t <dt>Maintained by IANA?</dt><dd>N</dd>
></dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric</dd>
<dt>prefix</dt><dd><t>isis-rmetric</t></dd> <dt>Prefix:</dt><dd>isis-rmetric</dd>
<dt>reference</dt><dd><t>RFC XXXX (RFC Ed.: replace XXX with actual RFC number a <dt>Reference:</dt><dd>RFC 9194</dd>
nd remove this note.)</t></dd>
</dl> </dl>
</section> </section>
</section> </section>
<section title="Security Considerations"> <section numbered="true" toc="default">
<name>Security Considerations</name>
<t>The YANG module specified in this document defines 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 lo as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.
west 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 la <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the
yer 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>The YANG module defined in this document can enable, disable, and
<t>The YANG module defined in this document can enable, disable and
modify the behavior of metrics used by routing. For the security modify the behavior of metrics used by routing. For the security
implications regarding these types of changes consult <xref target="RFC8500"/> implications regarding these types of changes, consult <xref target="RFC8500"/>
which defines the functionality as well as --
<xref target="I-D.ietf-isis-yang-isis-cfg"/>.</t> which defines the functionality -- as well as <xref target="RFC9130"/>.</t>
<t>There are a number of data nodes defined in this YANG module that are <t>There are a number of data nodes defined in this YANG module that are
writable/creatable/deletable (i.e., "config true", which is the writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config) to in some network environments. Write operations (e.g., edit-config)
these data nodes without proper protection can have a negative effect to these data nodes without proper protection can have a negative effect
on network operations. These YANG nodes correspond directly to the on network operations. These YANG nodes correspond directly to the
RFC 8500 functionality and the security considerations of the functionality provided in RFC 8500, and the security considerations of the
functionality are described in RFC 8500.</t> functionality are described in RFC 8500.
These are the subtrees and data nodes:</t>
<t>These are the subtrees and data nodes:</t> <artwork type="ascii-art"><![CDATA[
<artwork><![CDATA[
Under "/rt:routing/rt:control-plane-protocols/" + Under "/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis" "rt:control-plane-protocol/isis:isis"
- /isis-rmetric:reverse-metric/isis-rmetric:enable-receive - /isis-rmetric:reverse-metric/isis-rmetric:enable-receive
]]></artwork> ]]></artwork>
<artwork><![CDATA[ <artwork type="ascii-art"><![CDATA[
Under "/rt:routing/rt:control-plane-protocols/" + Under "/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" + "rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" + "isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric" "isis-rmetric:reverse-metric"
- /isis-rmetric:metric - /isis-rmetric:metric
- /isis-rmetric:flags/isis-rmetric:whole-lan - /isis-rmetric:flags/isis-rmetric:whole-lan
- /isis-rmetric:flags/isis-rmetric:allow-unreachable - /isis-rmetric:flags/isis-rmetric:allow-unreachable
- /isis-rmetric:exclude-te-metric - /isis-rmetric:exclude-te-metric
]]></artwork> ]]></artwork>
<artwork><![CDATA[ <artwork type="ascii-art"><![CDATA[
Under "/rt:routing/rt:control-plane-protocols/" + Under "/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" + "rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" + "isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric/" + "isis-rmetric:reverse-metric/" +
"isis-rmetric:level-1/" "isis-rmetric:level-1/"
- /isis-rmetric:metric - /isis-rmetric:metric
- /isis-rmetric:flags/isis-rmetric:whole-lan - /isis-rmetric:flags/isis-rmetric:whole-lan
- /isis-rmetric:flags/isis-rmetric:allow-unreachable - /isis-rmetric:flags/isis-rmetric:allow-unreachable
- /isis-rmetric:exclude-te-metric - /isis-rmetric:exclude-te-metric
]]></artwork> ]]></artwork>
<artwork><![CDATA[ <artwork type="ascii-art"><![CDATA[
Under "/rt:routing/rt:control-plane-protocols/" + Under "/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" + "rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" + "isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric/" + "isis-rmetric:reverse-metric/" +
"isis-rmetric:level-2/" "isis-rmetric:level-2/"
- /isis-rmetric:metric - /isis-rmetric:metric
- /isis-rmetric:flags/isis-rmetric:whole-lan - /isis-rmetric:flags/isis-rmetric:whole-lan
- /isis-rmetric:flags/isis-rmetric:allow-unreachable - /isis-rmetric:flags/isis-rmetric:allow-unreachable
- /isis-rmetric:exclude-te-metric - /isis-rmetric:exclude-te-metric
skipping to change at line 408 skipping to change at line 439
"rt:control-plane-protocol/isis:isis/" + "rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" + "isis:interfaces/isis:interface/" +
"isis-rmetric:reverse-metric/" + "isis-rmetric:reverse-metric/" +
"isis-rmetric:level-2/" "isis-rmetric:level-2/"
- /isis-rmetric:metric - /isis-rmetric:metric
- /isis-rmetric:flags/isis-rmetric:whole-lan - /isis-rmetric:flags/isis-rmetric:whole-lan
- /isis-rmetric:flags/isis-rmetric:allow-unreachable - /isis-rmetric:flags/isis-rmetric:allow-unreachable
- /isis-rmetric:exclude-te-metric - /isis-rmetric:exclude-te-metric
]]></artwork> ]]></artwork>
<t>Some of the readable data nodes in this YANG module may be considered <t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or important to control read access (e.g., via get, get-config, or
notification) to these data nodes. These YANG nodes correspond notification) to these data nodes. These YANG nodes correspond
directly to the RFC 8500 functionality and the security directly to the functionality provided in RFC 8500, and the security
considerations of the functionality are described in RFC 8500. These considerations of the functionality are described in RFC 8500.
are the subtrees and data nodes:</t> These are the subtrees and data nodes:</t>
<artwork type="ascii-art"><![CDATA[
<artwork><![CDATA[
Under "/rt:routing/rt:control-plane-protocols/" + Under "/rt:routing/rt:control-plane-protocols/" +
"rt:control-plane-protocol/isis:isis/" + "rt:control-plane-protocol/isis:isis/" +
"isis:interfaces/isis:interface/" + "isis:interfaces/isis:interface/" +
"isis:adjacencies/isis:adjacency/" + "isis:adjacencies/isis:adjacency/" +
"isis-rmetric:reverse-metric" "isis-rmetric:reverse-metric"
- /isis-rmetric:metric - /isis-rmetric:metric
- /isis-rmetric:flags/isis-rmetric:whole-lan - /isis-rmetric:flags/isis-rmetric:whole-lan
- /isis-rmetric:flags/isis-rmetric:allow-unreachable - /isis-rmetric:flags/isis-rmetric:allow-unreachable
- /isis-rmetric:te-metric - /isis-rmetric:te-metric
]]></artwork> ]]></artwork>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<reference anchor="ISO10589"> <name>Normative References</name>
<front> <reference anchor="ISO-10589" target="https://www.iso.org/standard/30932.html"
<title>Intermediate System to Intermediate System intra-domain routeing informat >
ion exchange protocol for use in conjunction with the protocol for providing the <front>
connectionless-mode network service (ISO 8473)</title> <title>Intermediate System to Intermediate System intra-
<author><organization>International Organization for Standardization</organizati domain routeing information exchange protocol for use in
on></author> conjunction with the protocol for providing the
<date year="2002"/> connectionless-mode network service (ISO 8473)</title>
</front><refcontent>ISO Standard 10589:2002</refcontent> <author><organization>ISO</organization></author>
</reference> <date year="2002"/>
</front>
<reference anchor='RFC3688' target='https://www.rfc-editor.org/info/rfc3688'> <refcontent>International Standard 10589: 2002, Second Edition</refcontent>
<front> </reference>
<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='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>
<reference anchor='RFC8342' target='https://www.rfc-editor.org/info/rfc8342'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3688.
<front> xml"/>
<title>Network Management Datastore Architecture (NMDA)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6020.
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'><organization xml"/>
/></author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder'><organ xml"/>
ization /></author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6242.
<author initials='P.' surname='Shafer' fullname='P. Shafer'><organization /></au xml"/>
thor> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8040.
<author initials='K.' surname='Watsen' fullname='K. Watsen'><organization /></au xml"/>
thor> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8340.
<author initials='R.' surname='Wilton' fullname='R. Wilton'><organization /></au xml"/>
thor> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8341.
<date year='2018' month='March' /> xml"/>
<abstract><t>Datastores are a fundamental concept binding the data models writte <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8342.
n in the YANG data modeling language to network management protocols such as the xml"/>
Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8349.
architectural framework for datastores based on the experience gained with the xml"/>
initial simpler model, addressing requirements that were not well supported in t <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
he initial model. This document updates RFC 7950.</t></abstract> xml"/>
</front>
<seriesInfo name='RFC' value='8342'/>
<seriesInfo name='DOI' value='10.17487/RFC8342'/>
</reference>
<reference anchor='RFC8349' target='https://www.rfc-editor.org/info/rfc8349'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8500.
<front> xml"/>
<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='RFC8500' target='https://www.rfc-editor.org/info/rfc8500'> <!-- draft-ietf-isis-yang-isis-cfg (RFC-to-be 9130 / AUTH48-DONE) -->
<reference anchor='RFC9130' target="https://www.rfc-editor.org/info/rfc9130">
<front> <front>
<title>IS-IS Routing with Reverse Metric</title> <title>YANG Data Model for the IS-IS Protocol</title>
<author initials='N.' surname='Shen' fullname='N. Shen'><organization /></author <author initials='S' surname='Litkowski' fullname='Stephane Litkowski' role="edi
> tor">
<author initials='S.' surname='Amante' fullname='S. Amante'><organization /></au <organization />
thor> </author>
<author initials='M.' surname='Abrahamsson' fullname='M. Abrahamsson'><organizat <author initials='D' surname='Yeung' fullname='Derek Yeung'>
ion /></author> <organization />
<date year='2019' month='February' /> </author>
<abstract><t>This document describes a mechanism to allow IS-IS routing to quick <author initials='A' surname='Lindem' fullname='Acee Lindem'>
ly and accurately shift traffic away from either a point-to-point or multi-acces <organization />
s LAN interface during network maintenance or other operational events. This is </author>
accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric <author initials='J' surname='Zhang' fullname='Jeffrey Zhang'>
, i.e., the metric towards the signaling IS-IS router.</t></abstract> <organization />
</author>
<author initials='L' surname='Lhotka' fullname='Ladislav Lhotka'>
<organization />
</author>
<date month='October' year='2022' />
</front> </front>
<seriesInfo name='RFC' value='8500'/> <seriesInfo name="RFC" value="9130"/>
<seriesInfo name='DOI' value='10.17487/RFC8500'/> <seriesInfo name="DOI" value="10.17487/RFC9130"/>
</reference> </reference>
<reference anchor="I-D.ietf-isis-yang-isis-cfg"> <reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2008/
<front> REC-xml-20081126" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
<title>YANG Data Model for IS-IS Protocol</title> <front>
<author fullname="Stephane Litkowski"> <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<organization>Cisco Systems</organization> <author initials="T." surname="Bray" fullname="Tim Bray">
</author> <organization showOnFrontPage="true"/>
<author fullname="Derek Yeung"> </author>
<organization>Arrcus, Inc</organization> <author initials="J." surname="Paoli" fullname="Jean Paoli">
</author> <organization showOnFrontPage="true"/>
<author fullname="Acee Lindem"> </author>
<organization>Cisco Systems</organization> <author initials="M." surname="Sperberg-McQueen" fullname="Michael S
</author> perberg-McQueen">
<author fullname="Jeffrey Zhang"> <organization showOnFrontPage="true"/>
<organization>Juniper Networks</organization> </author>
</author> <author initials="E." surname="Maler" fullname="Eve Maler">
<author fullname="Ladislav Lhotka"> <organization showOnFrontPage="true"/>
<organization>CZ.NIC</organization> </author>
</author> <author initials="F." surname="Yergeau" fullname="Francois Yergeau">
<date month="October" day="15" year="2019" /> <organization showOnFrontPage="true"/>
<abstract> </author>
<t> This document defines a YANG data model that can be used to config <date month="November" year="2008"/>
ure </front>
and manage the IS-IS protocol on network elements. <refcontent>World Wide Web Consortium Recommendation REC-xml-20081126<
/refcontent>
</t> </reference>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-isis-yang-isis-cfg-42" />
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-isis-ya
ng-isis-cfg-42.txt" />
</reference>
</references> </references>
<references title="Informative References"> <references>
<name>Informative References</name>
<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='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='RFC7951' target='https://www.rfc-editor.org/info/rfc7951'>
<front>
<title>JSON Encoding of Data Modeled with YANG</title>
<author initials='L.' surname='Lhotka' fullname='L. Lhotka'><organization /></au
thor>
<date year='2016' month='August' />
<abstract><t>This document defines encoding rules for representing configuration
data, state data, parameters of Remote Procedure Call (RPC) operations or actio
ns, and notifications defined using YANG as JavaScript Object Notation (JSON) te
xt.</t></abstract>
</front>
<seriesInfo name='RFC' value='7951'/>
<seriesInfo name='DOI' value='10.17487/RFC7951'/>
</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='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='RFC8446' target='https://www.rfc-editor.org/info/rfc8446'> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7951.
<front> xml"/>
<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>
</references> </references>
<section title="Examples"> <section numbered="true" toc="default">
<section title="Enablement Example using XML YANG Instance Data"> <name>Examples</name>
<t>Below is an example of XML YANG instance data <xref target="RFC8342"/> to ena <section numbered="true" toc="default">
ble <name>Enablement Example Using XML YANG Instance Data</name>
reverse metric processing.</t> <t>Below is an example of XML <xref target="W3C.REC-xml-20081126"/> YANG instanc
e data <xref target="RFC8342"/> to enable reverse metric processing.
</t>
<figure><name>Example XML data to enable reverse metric processing.</name><sourc <figure>
ecode><![CDATA[ <name>Example XML Data to Enable Reverse Metric Processing</name>
<sourcecode type="xml"><![CDATA[
<rt:routing <rt:routing
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
xmlns:isis="urn:ietf:params:xml:ns:yang:ietf-isis" xmlns:isis="urn:ietf:params:xml:ns:yang:ietf-isis"
xmlns:isis-rmetric= xmlns:isis-rmetric=
"urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric"> "urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric">
<rt:control-plane-protocols> <rt:control-plane-protocols>
<rt:control-plane-protocol> <rt:control-plane-protocol>
<rt:type>isis:isis</rt:type> <rt:type>isis:isis</rt:type>
<rt:name>default</rt:name> <rt:name>default</rt:name>
<isis:isis> <isis:isis>
skipping to change at line 655 skipping to change at line 576
<isis-rmetric:enable-receive>true</isis-rmetric:enable-receive> <isis-rmetric:enable-receive>true</isis-rmetric:enable-receive>
</isis-rmetric:reverse-metric> </isis-rmetric:reverse-metric>
</isis:isis> </isis:isis>
</rt:control-plane-protocol> </rt:control-plane-protocol>
</rt:control-plane-protocols> </rt:control-plane-protocols>
</rt:routing> </rt:routing>
]]></sourcecode></figure> ]]></sourcecode></figure>
</section> </section>
<section title="Usage Example using XML YANG Instance Data"> <section numbered="true" toc="default">
<name>Usage Example Using XML YANG Instance Data</name>
<t>Below is an example of XML YANG instance data <xref target="RFC8342"/> for th e <t>Below is an example of XML YANG instance data <xref target="RFC8342"/> for th e
ietf-isis-reverse-metric module.</t> "ietf-isis-reverse-metric" module.</t>
<figure><name>Example XML data for ietf-isis-reverse-metric module.</name><sourc <figure>
ecode><![CDATA[ <name>Example XML Data for the &quot;ietf-isis-reverse-metric&quot; Module</name
>
<sourcecode type="xml"><![CDATA[
<if:interfaces <if:interfaces
xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces"
xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">
<if:interface> <if:interface>
<if:name>eth0</if:name> <if:name>eth0</if:name>
<if:type>ianaift:ethernetCsmacd</if:type> <if:type>ianaift:ethernetCsmacd</if:type>
</if:interface> </if:interface>
</if:interfaces> </if:interfaces>
<rt:routing <rt:routing
xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing" xmlns:rt="urn:ietf:params:xml:ns:yang:ietf-routing"
skipping to change at line 697 skipping to change at line 621
</isis:interface> </isis:interface>
</isis:interfaces> </isis:interfaces>
</isis:isis> </isis:isis>
</rt:control-plane-protocol> </rt:control-plane-protocol>
</rt:control-plane-protocols> </rt:control-plane-protocols>
</rt:routing> </rt:routing>
]]></sourcecode></figure> ]]></sourcecode></figure>
</section> </section>
<section title="Usage Example using JSON YANG Instance Data"> <section numbered="true" toc="default">
<name>Usage Example Using JSON YANG Instance Data</name>
<t>Below is an example of JSON YANG instance data <xref target="RFC7951"/> for t he <t>Below is an example of JSON YANG instance data <xref target="RFC7951"/> for t he
ietf-isis-reverse-metric module.</t> "ietf-isis-reverse-metric" module.</t>
<figure><name>Example JSON data for level-1 only reverse metric.</name><sourceco <figure>
de><![CDATA[ <name>Example JSON Data for the Level-1-Only Reverse Metric</name>
<sourcecode type="json"><![CDATA[
{ {
"ietf-interfaces:interfaces": { "ietf-interfaces:interfaces": {
"interface": [ "interface": [
{ {
"name": "eth0", "name": "eth0",
"type": "iana-if-type:ethernetCsmacd" "type": "iana-if-type:ethernetCsmacd"
} }
] ]
}, },
"ietf-routing:routing": { "ietf-routing:routing": {
 End of changes. 81 change blocks. 
462 lines changed or deleted 313 lines changed or added

This html diff was produced by rfcdiff 1.48.