draft-ietf-isis-yang-isis-cfg-37.txt   draft-ietf-isis-yang-isis-cfg-38.txt 
IS-IS Working Group S. Litkowski IS-IS Working Group S. Litkowski
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track D. Yeung Intended status: Standards Track D. Yeung
Expires: March 12, 2020 Arrcus, Inc Expires: March 29, 2020 Arrcus, Inc
A. Lindem A. Lindem
Cisco Systems Cisco Systems
J. Zhang J. Zhang
Juniper Networks Juniper Networks
L. Lhotka L. Lhotka
CZ.NIC CZ.NIC
September 9, 2019 September 26, 2019
YANG Data Model for IS-IS Protocol YANG Data Model for IS-IS Protocol
draft-ietf-isis-yang-isis-cfg-37 draft-ietf-isis-yang-isis-cfg-38
Abstract Abstract
This document defines a YANG data model that can be used to configure This document defines a YANG data model that can be used to configure
and manage IS-IS protocol on network elements. and manage the IS-IS protocol on network elements.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Status of This Memo Status of This Memo
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2020. This Internet-Draft will expire on March 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3 2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3
2.1. IS-IS Configuration . . . . . . . . . . . . . . . . . . . 9 2.1. IS-IS Configuration . . . . . . . . . . . . . . . . . . . 9
2.2. Multitopology Parameters . . . . . . . . . . . . . . . . 9 2.2. Multi-topology Parameters . . . . . . . . . . . . . . . . 9
2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10 2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10
2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 11 2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 11
2.5. Authentication Parameters . . . . . . . . . . . . . . . . 18 2.5. Authentication Parameters . . . . . . . . . . . . . . . . 18
2.6. IGP/LDP synchronization . . . . . . . . . . . . . . . . . 19 2.6. IGP/LDP synchronization . . . . . . . . . . . . . . . . . 19
2.7. ISO parameters . . . . . . . . . . . . . . . . . . . . . 19 2.7. ISO parameters . . . . . . . . . . . . . . . . . . . . . 19
2.8. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.8. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.9. Operational States . . . . . . . . . . . . . . . . . . . 19 2.9. Operational States . . . . . . . . . . . . . . . . . . . 20
3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 20 3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 20
4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 20 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Interaction with Other YANG Modules . . . . . . . . . . . . . 22 5. Interaction with Other YANG Modules . . . . . . . . . . . . . 22
6. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 22 6. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 105 7. Security Considerations . . . . . . . . . . . . . . . . . . . 105
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 107 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 107
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
10.1. Normative References . . . . . . . . . . . . . . . . . . 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 108
10.2. Informative References . . . . . . . . . . . . . . . . . 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 108
11.2. Informative References . . . . . . . . . . . . . . . . . 112
Appendix A. Example of IS-IS configuration in XML . . . . . . . 112 Appendix A. Example of IS-IS configuration in XML . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
1. Introduction 1. Introduction
This document defines a YANG [RFC7950] data model for IS-IS routing This document defines a YANG [RFC7950] data model for IS-IS routing
protocol. protocol.
The data model covers configuration of an IS-IS routing protocol The data model covers configuration of an IS-IS routing protocol
instance as well as operational states. instance, as well as, the retrieval of IS-IS operational state.
A simplified tree representation of the data model is presented in A simplified tree representation of the data model is presented in
Section 2. Tree diagrams used in this document follow the notation Section 2. Tree diagrams used in this document follow the notation
defined in [RFC8340]. defined in [RFC8340].
The module is designed as per NMDA (Network Management Datastore The module is designed as per the NMDA (Network Management Datastore
Architecture) [RFC8342]. Architecture) [RFC8342].
2. Design of the Data Model 2. Design of the Data Model
The IS-IS YANG module augments the "control-plane-protocol" list in The IS-IS YANG module augments the "control-plane-protocol" list in
ietf-routing module [RFC8349] with specific IS-IS parameters. the ietf-routing module [RFC8349] with specific IS-IS parameters.
The figure below describes the overall structure of the isis YANG The figure below describes the overall structure of the ietf-isis
module: YANG module:
module: ietf-isis module: ietf-isis
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route: augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
+--ro metric? uint32 +--ro metric? uint32
+--ro tag* uint64 +--ro tag* uint64
+--ro route-type? enumeration +--ro route-type? enumeration
augment /if:interfaces/if:interface: augment /if:interfaces/if:interface:
+--rw clns-mtu? uint16 {osi-interface}? +--rw clns-mtu? uint16 {osi-interface}?
augment augment
| /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol: | /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:
skipping to change at page 9, line 13 skipping to change at page 9, line 16
+---n lsp-generation +---n lsp-generation
+--ro routing-protocol-name? +--ro routing-protocol-name?
-> /rt:routing/control-plane-protocols/control-plane-protocol/name -> /rt:routing/control-plane-protocols/control-plane-protocol/name
+--ro isis-level? level +--ro isis-level? level
+--ro lsp-id? lsp-id +--ro lsp-id? lsp-id
+--ro sequence? uint32 +--ro sequence? uint32
+--ro send-timestamp? yang:timestamp +--ro send-timestamp? yang:timestamp
2.1. IS-IS Configuration 2.1. IS-IS Configuration
The IS-IS configuration is divided in: The IS-IS configuration is divided into:
o Global parameters. o Global parameters.
o Per interface configuration (see Section 2.4). o Per-interface configuration (see Section 2.4).
Additional modules may be created to support any additional Additional modules may be created to support additional parameters.
parameters. These additional modules MUST augment the ietf-isis These additional modules MUST augment the ietf-isis module.
module.
The model implements features, thus some of the configuration The model includes optional features, for which the corresponding
statement becomes optional. As an example, the ability to control configuration data nodes are also optional. As an example, the
the administrative state of a particular IS-IS instance is optional. ability to control the administrative state of a particular IS-IS
By advertising the feature "admin-control", a device communicates to instance is optional. By advertising the feature "admin-control", a
the client that it supports the ability to shutdown a particular IS- device communicates to the client that it supports the ability to
IS instance. shut down a particular IS-IS instance.
The global configuration contains usual IS-IS parameters such as lsp- The global configuration contains usual IS-IS parameters, such as,
mtu, lsp-lifetime, lsp-refresh, default-metric... lsp-mtu, lsp-lifetime, lsp-refresh, default-metric, etc.
2.2. Multitopology Parameters 2.2. Multi-topology Parameters
The model supports multitopology (MT) IS-IS as defined in [RFC5120]. The model supports multi-topology (MT) IS-IS as defined in [RFC5120].
The "topologies" container is used to enable support of MT The "topologies" container is used to enable support of the MT
extensions. extensions.
The "name" used in the topology list should refer to an existing RIB The "name" used in the topology list should refer to an existing
of the device. Routing Information Base (RIB) defined for the device [RFC8349].
Some specific parameters can be defined on a per topology basis both Some specific parameters can be defined on a per-topology basis, both
at global level and at interface level: for example, an interface at the global level and at the interface level: for example, an
metric can be defined per topology. interface metric can be defined per-topology.
Multiple address families (like IPv4 or IPv6) can also be activated Multiple address families (such as, IPv4 or IPv6) can also be enabled
within the default topology. This can be achieved using the address- within the default topology. This can be achieved using the address-
families container (requiring "nlpid-control" feature to be families container (requiring the "nlpid-control" feature to be
advertised). supported).
2.3. Per-Level Parameters 2.3. Per-Level Parameters
Some parameters allow a per level configuration. In this case, the Some parameters allow a per-level configuration. For such
parameter is modeled as a container with three configuration parameters, the parameter is modeled as a container with three
locations: configuration locations:
o a top-level container: corresponds to level-1-2, so the o a Top-level container: Corresponds to level-1-2, so the
configuration applies to both levels. configuration applies to both levels.
o a level-1 container: corresponds to level-1 specific parameters. o a Level-1 container: Corresponds to level-1 specific parameters.
o a level-2 container: corresponds to level-2 specific parameters. o a Level-2 container: Corresponds to level-2 specific parameters.
+--rw priority +--rw priority
| +--rw value? uint8 | +--rw value? uint8
| +--rw level-1 | +--rw level-1
| | +--rw value? uint8 | | +--rw value? uint8
| +--rw level-2 | +--rw level-2
| +--rw value? uint8 | +--rw value? uint8
Example: Example:
<priority> <priority>
<value>250</value> <value>250</value>
<level-1> <level-1>
<value>100</value> <value>100</value>
</level-1> </level-1>
<level-2> <level-2>
<value>200</value> <value>200</value>
</level-2> </level-2>
</priority> </priority>
An implementation MUST prefer a level specific parameter over a An implementation MUST prefer a level-specific parameter over a top-
level-all parameter. As example, if the priority is 100 for the level parameter. For example, if the priority is 100 for the level-
level-1, 200 for the level-2 and 250 for the top-level configuration, 1, 200 for the level-2 and 250 for the top-level configuration, the
the implementation should use 100 for the level-1 and 200 for the implementation must use 100 for the level-1 priority and 200 for the
level-2. level-2 priority.
Some parameters like "overload bit" and "route preference" are not Some parameters, such as, "overload bit" and "route preference", are
modeled to support a per level configuration. If an implementation not modeled to support a per-level configuration. If an
supports per level configuration for such parameter, this implementation supports per-level configuration for such parameter,
implementation MUST augment the current model by adding both level-1 this implementation MUST augment the current model by adding both
and level-2 containers and MUST reuse existing configuration level-1 and level-2 containers and MUST reuse existing configuration
groupings. groupings.
Example of augmentation: Example of augmentation:
augment "/rt:routing/" + augment "/rt:routing/" +
"rt:control-plane-protocols/rt:control-plane-protocol"+ "rt:control-plane-protocols/rt:control-plane-protocol"+
"/isis:isis/isis:overload" { "/isis:isis/isis:overload" {
when "rt:type = 'isis:isis'" { when "rt:type = 'isis:isis'" {
description description
"This augment IS-IS routing protocol when used"; "This augment IS-IS routing protocol when used";
} }
description description
"This augments IS-IS overload configuration "This augments IS-IS overload configuration
with per level configuration."; with per-level configuration.";
container level-1 { container level-1 {
uses isis:overload-global-cfg; uses isis:overload-global-cfg;
description description
"Level 1 configuration."; "Level 1 configuration.";
} }
container level-2 { container level-2 {
uses isis:overload-global-cfg; uses isis:overload-global-cfg;
description description
"Level 2 configuration."; "Level 2 configuration.";
} }
} }
If an implementation does not support per level configuration for a If an implementation does not support per-level configuration for a
parameter modeled with per level configuration, the implementation parameter modeled with per-level configuration, the implementation
should advertise a deviation to announce the non-support of the SHOULD advertise a deviation to announce the non-support of the
level-1 and level-2 containers. level-1 and level-2 containers.
Finally, if an implementation supports per level configuration but Finally, if an implementation supports per-level configuration but
does not support the level-1-2 configuration, it SHOULD also does not support the level-1-2 configuration, it SHOULD also
advertise a deviation. advertise a deviation.
2.4. Per-Interface Parameters 2.4. Per-Interface Parameters
The per-interface section of the IS-IS instance describes the The per-interface section of the IS-IS instance describes the
interface specific parameters. interface-specific parameters.
The interface is modeled as a reference to an existing interface The interface is modeled as a reference to an existing interface
defined in the "ietf-interfaces" YANG model ([RFC8343]. defined in the "ietf-interfaces" YANG model ([RFC8343].
Each interface has some interface-specific parameters that may have a Each interface has some interface-specific parameters that may have a
different per level value as described in previous section. An different per-level value as described in the previous section. An
interface-specific parameter MUST be preferred over an IS-IS global interface-specific parameter MUST be preferred over an IS-IS global
parameter. parameter.
Some parameters like hello-padding are defined as containers to allow Some parameters, such as, hello-padding are defined as containers to
easy extension by vendor specific modules. allow easy extension by vendor-specific modules.
+--rw interfaces +--rw interfaces
+--rw interface* [name] +--rw interface* [name]
+--rw name if:interface-ref +--rw name if:interface-ref
+--rw enable? boolean {admin-control}? +--rw enable? boolean {admin-control}?
+--rw level-type? level +--rw level-type? level
+--rw lsp-pacing-interval? +--rw lsp-pacing-interval?
| rt-types:timer-value-milliseconds | rt-types:timer-value-milliseconds
+--rw lsp-retransmit-interval? +--rw lsp-retransmit-interval?
| rt-types:timer-value-seconds16 | rt-types:timer-value-seconds16
skipping to change at page 18, line 46 skipping to change at page 18, line 49
-> /rt:routing/control-plane-protocols/control-plane-protocol/name -> /rt:routing/control-plane-protocols/control-plane-protocol/name
+--ro isis-level? level +--ro isis-level? level
+--ro lsp-id? lsp-id +--ro lsp-id? lsp-id
+--ro sequence? uint32 +--ro sequence? uint32
+--ro send-timestamp? yang:timestamp +--ro send-timestamp? yang:timestamp
2.5. Authentication Parameters 2.5. Authentication Parameters
The module enables authentication configuration through the IETF key- The module enables authentication configuration through the IETF key-
chain module [RFC8177]. The IS-IS module imports the "ietf-key- chain module [RFC8177]. The IS-IS module imports the "ietf-key-
chain" module and reuses some groupings to allow global and per chain" module and reuses some groupings to allow global and per-
interface configuration of authentication. If a global interface configuration of authentication. If global authentication
authentication is configured, an implementation SHOULD authenticate is configured, an implementation SHOULD authenticate PSNPs (Partial
PSNPs (Partial Sequence Number Packets), CSNPs (Complete Sequence Sequence Number Packets), CSNPs (Complete Sequence Number Packets)
Number Packets) and LSPs (Link State Packets) with the authentication and LSPs (Link State Packets) with the authentication parameters
parameters supplied. The authentication of HELLO PDUs (Protocol Data supplied. The authentication of HELLO PDUs (Protocol Data Units) can
Units) can be activated on a per interface basis. be activated on a per-interface basis.
2.6. IGP/LDP synchronization 2.6. IGP/LDP synchronization
[RFC5443] defines a mechanism where IGP (Interior Gateway Protocol) [RFC5443] defines a mechanism where IGP (Interior Gateway Protocol)
needs to be synchronized with LDP (Label Distribution Protocol). An needs to be synchronized with LDP (Label Distribution Protocol). An
"ldp-igp-sync" feature has been defined in the model to support this "ldp-igp-sync" feature has been defined in the model to support this
mechanism. The "mpls/ldp/igp-sync" leaf under "interface" allows functionality. The "mpls/ldp/igp-sync" leaf under "interface" allows
activation of the mechanism on a per interface basis. The "mpls/ldp/ activation of the mechanism on a per-interface basis. The "mpls/ldp/
igp-sync" container in the global configuration is empty on purpose igp-sync" container in the global configuration is intentionally
and is not required for the activation. The goal of this empty empty and is not required for feature activation. The goal of this
container is to allow easy augmentation with additional parameters empty container is to facilitate augmentation with additional
like timers for example. parameters, e.g., timers.
2.7. ISO parameters 2.7. ISO parameters
As IS-IS protocol is based on ISO protocol suite, some ISO parameters As the IS-IS protocol is based on the ISO protocol suite, some ISO
may be required. parameters may be required.
This module augments interface configuration model to support ISO This module augments interface configuration model to support
configuration parameters. selected ISO configuration parameters.
The clns-mtu can be defined under the interface. The clns-mtu can be configured for an interface.
2.8. IP FRR 2.8. IP FRR
This YANG module supports LFA (Loop Free Alternates) [RFC5286] and This YANG module supports LFA (Loop Free Alternates) [RFC5286] and
remote LFA [RFC7490] as IP FRR techniques. The "fast-reroute" remote LFA [RFC7490] as IP Fast Re-Route (FRR) techniques. The
container may be augmented by other models to support other IPFRR "fast-reroute" container may be augmented by other models to support
flavors (MRT, TILFA ...). other IP FRR flavors (MRT, TI-LFA, etc.).
The current version of the model supports activation of LFA and The current version of the model supports activation of LFA and
remote LFA at interface only. The global "lfa" container is present remote LFA at the interface-level only. The global "lfa" container
but kept empty to allow augmentation with vendor specific properties is present but kept empty to allow augmentation with vendor-specific
like policies. properties, e.g., policies.
Remote LFA is considered as a child of LFA. Remote LFA cannot be Remote LFA is considered as an extension of LFA. Remote LFA cannot
enabled if LFA is not enabled. be enabled if LFA is not enabled.
The "candidate-enable" allows to mark an interface to be used as a The "candidate-enable" data leaf designates that an interface can be
backup. used as a backup.
2.9. Operational States 2.9. Operational States
Operational states are provided in the module in various places: Operational state is defined in module in various containers at
various levels:
o system-counters: provides statistical informations about the o system-counters: Provides statistical information about the global
global system. system.
o interface : provides configuration state informations for each o interface: Provides configuration state information for each
interface. interface.
o adjacencies: provides state informations about current IS-IS o adjacencies: Provides state information about current IS-IS
adjacencies. adjacencies.
o spf-log: provides informations about SPF events on the node. This o spf-log: Provides information about SPF events for an IS-IS
SHOULD be implemented as a wrapping buffer. instance. This SHOULD be implemented as a wrapping buffer.
o lsp-log: provides informations about LSP events on the node o lsp-log: Provides information about LSP events for an IS-IS
(reception of an LSP or modification of local LSP). This SHOULD instance (reception of an LSP or modification of a local LSP).
be implemented as a wrapping buffer and an implementation MAY This SHOULD be implemented as a wrapping buffer and the
decide to log refresh LSPs or not. implementation MAY optionally log LSP refreshes.
o local-rib: provides the IS-IS internal routing table view. o local-rib: Provides the IS-IS internal routing table.
o database: provides details on the current LSDB. o database: Provides contents of the current Link State Database.
o hostnames: provides informations about system-id to hostname o hostnames: Provides the system-id to hostname mappings [RFC5301].
mappings [RFC5301].
o fast-reroute: provides informations about IP FRR. o fast-reroute: Provides IP FRR state information.
3. RPC Operations 3. RPC Operations
The "ietf-isis" module defines two RPC operations: The "ietf-isis" module defines two RPC operations:
o clear-database: reset the content of a particular IS-IS database o clear-database: Reset the content of a particular IS-IS database
and restart database synchronization with the neighbors. and restart database synchronization with all neighbors.
o clear-adjacency: restart a particular set of IS-IS adjacencies. o clear-adjacency: Restart a particular set of IS-IS adjacencies.
4. Notifications 4. Notifications
The "ietf-isis" module introduces some notifications : The "ietf-isis" module defines the following notifications :
database-overload: raised when overload condition is changed. database-overload: This notification is sent when the IS-IS Node
overload condition changes.
lsp-too-large: raised when the system tries to propagate a PDU lsp-too-large: This notification is sent when the system tries to
that is too large. propagate a PDU that is too large.
if-state-change: raised when the state of an interface changes. if-state-change: This notification is sent when the state of an
interface's state changes.
corrupted-lsp-detected: raised when the system finds that an LSP corrupted-lsp-detected: This notification is sent when the IS-IS
that was stored in memory has become corrupted. node discovers that an LSP that was previously stored in the Link
State Database, i.e., local memory, has become corrupted.
attempt-to-exceed-max-sequence: This notification is sent when the attempt-to-exceed-max-sequence: This notification is sent when the
system wraps the 32-bit sequence counter of an LSP. system wraps the 32-bit sequence counter of an LSP.
id-len-mismatch: This notification is sent when we receive a PDU id-len-mismatch: This notification is sent when we receive a PDU
with a different value for the System ID length. with a different value for the System ID length.
max-area-addresses-mismatch: This notification is sent when we max-area-addresses-mismatch: This notification is sent when we
receive a PDU with a different value for the Maximum Area receive a PDU with a different value for the Maximum Area
Addresses. Addresses.
skipping to change at page 22, line 12 skipping to change at page 22, line 20
lsp-received: This notification is sent when an LSP is received. lsp-received: This notification is sent when an LSP is received.
lsp-generation: This notification is sent when an LSP is lsp-generation: This notification is sent when an LSP is
regenerated. regenerated.
5. Interaction with Other YANG Modules 5. Interaction with Other YANG Modules
The "isis" container augments the "/rt:routing/rt:control-plane- The "isis" container augments the "/rt:routing/rt:control-plane-
protocols/control-plane-protocol" container of the ietf-routing protocols/control-plane-protocol" container of the ietf-routing
[RFC8349] module by defining IS-IS specific parameters. [RFC8349] module by with IS-IS-specific parameters.
The "isis" module augments "/if:interfaces/if:interface" defined by The "isis" module augments "/if:interfaces/if:interface" defined by
[RFC8343] with ISO specific parameters. [RFC8343] with ISO specific parameters.
The "isis" operational state container augments the "/rt:routing- The "isis" operational state container augments the "/rt:routing-
state/rt:control-plane-protocols/control-plane-protocol" container of state/rt:control-plane-protocols/control-plane-protocol" container of
the ietf-routing module by defining IS-IS specific operational the ietf-routing module with IS-IS-specific operational states.
states.
Some IS-IS specific routes attributes are added to route objects of Some IS-IS-specific route attributes are added to route objects in
the ietf-routing module by augmenting "/rt:routing- the ietf-routing module by augmenting "/rt:routing-
state/rt:ribs/rt:rib/rt:routes/rt:route". state/rt:ribs/rt:rib/rt:routes/rt:route".
The modules defined in this document use some groupings from ietf- The modules defined in this document uses some groupings from ietf-
keychain [RFC8177]. keychain [RFC8177].
The module reuses types from [RFC6991] and [RFC8294]. The module reuses types from [RFC6991] and [RFC8294].
To support BFD for fast detection, the module relies on To support BFD for fast detection, the module relies on
[I-D.ietf-bfd-yang]. [I-D.ietf-bfd-yang].
6. IS-IS YANG Module 6. IS-IS YANG Module
The following RFCs, drafts and external standards are not referenced The following RFCs, drafts and external standards are not referenced
in the document text but are referenced in the ietf-isis.yang module: in the document text but are referenced in the ietf-isis.yang module:
[ISO-10589], [RFC1195], [RFC4090],[RFC5029], [RFC5130], [RFC5302], [ISO-10589], [RFC1195], [RFC4090],[RFC5029], [RFC5130], [RFC5302],
[RFC5305], [RFC5306], [RFC5307], [RFC5308], [RFC5880], [RFC5881], [RFC5305], [RFC5306], [RFC5307], [RFC5308], [RFC5880], [RFC5881],
[RFC6119], [RFC6232], [RFC7794], [RFC7981], [RFC8570], [RFC7917], [RFC6119], [RFC6232], [RFC7794], [RFC7981], [RFC8570], [RFC7917],
[RFC8405]. [RFC8405].
<CODE BEGINS> file "ietf-isis@2019-09-09.yang" <CODE BEGINS> file "ietf-isis@2019-09-26.yang"
module ietf-isis { module ietf-isis {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-isis"; namespace "urn:ietf:params:xml:ns:yang:ietf-isis";
prefix isis; prefix isis;
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
reference "RFC 8349 - A YANG Data Model for Routing reference "RFC 8349 - A YANG Data Model for Routing
Management (NMDA Version)"; Management (NMDA Version)";
skipping to change at page 24, line 25 skipping to change at page 24, line 32
<mailto:acee@cisco.com> <mailto:acee@cisco.com>
Jeffrey Zhang Jeffrey Zhang
<mailto:zzhang@juniper.net> <mailto:zzhang@juniper.net>
Ladislav Lhotka Ladislav Lhotka
<mailto:llhotka@nic.cz> <mailto:llhotka@nic.cz>
"; ";
description description
"This YANG module defines the generic configuration and "This YANG module defines the generic configuration and
operational state for the IS-IS protocol common to all operational state for the IS-IS protocol common to all
vendor implementations. It is intended that the module vendor implementations. It is intended that the module
will be extended by vendors to define vendor-specific will be extended by vendors to define vendor-specific
IS-IS configuration parameters and policies, IS-IS configuration parameters and policies,
for example, route maps or route policies. for example, route maps or route policies.
This YANG model conforms to the Network Management This YANG model conforms to the Network Management
Datastore Architecture (NMDA) as described in RFC 8242. Datastore Architecture (NMDA) as described in RFC 8242.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2018 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 Simplified 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 XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices. for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX; This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices."; see the RFC itself for full legal notices.";
revision 2019-09-09 { revision 2019-09-26 {
description description
"Initial revision."; "Initial revision.";
reference "RFC XXXX"; reference "RFC XXXX";
} }
/* Identities */ /* Identities */
identity isis { identity isis {
base rt:routing-protocol; base rt:routing-protocol;
description "Identity for the IS-IS routing protocol."; description "Identity for the IS-IS routing protocol.";
skipping to change at page 26, line 27 skipping to change at page 26, line 33
identity frr-protection-available-link-type { identity frr-protection-available-link-type {
base frr-protection-available-type; base frr-protection-available-type;
description "Link protection is provided by the alternate."; description "Link protection is provided by the alternate.";
} }
identity frr-protection-available-srlg-type { identity frr-protection-available-srlg-type {
base frr-protection-available-type; base frr-protection-available-type;
description "SRLG protection is provided by the alternate."; description "SRLG protection is provided by the alternate.";
} }
identity frr-protection-available-downstream-type { identity frr-protection-available-downstream-type {
base frr-protection-available-type; base frr-protection-available-type;
description "The alternate is downstream on the path."; description "The alternate is downstream of node in the path.";
} }
identity frr-protection-available-other-type { identity frr-protection-available-other-type {
base frr-protection-available-type; base frr-protection-available-type;
description "The level of protection is unknown."; description "The level of protection is unknown.";
} }
identity unidirectional-link-delay-subtlv-flag { identity unidirectional-link-delay-subtlv-flag {
description "Base identity for unidirectional-link-delay description "Base identity for unidirectional-link-delay
subTLV flags. Flags are defined in RFC8570."; subTLV flags. Flags are defined in RFC8570.";
} }
skipping to change at page 33, line 6 skipping to change at page 33, line 11
description description
"Broadcast interface type."; "Broadcast interface type.";
} }
enum point-to-point { enum point-to-point {
description description
"Point-to-point interface type."; "Point-to-point interface type.";
} }
} }
description description
"This type defines the type of adjacency "This type defines the type of adjacency
to be established on the interface. to be established for the interface.
The interface-type determines the type The interface-type determines the type
of hello message that is used."; of hello message that is used.";
} }
typedef level { typedef level {
type enumeration { type enumeration {
enum "level-1" { enum "level-1" {
description description
"This enum indicates L1-only capability."; "This enum indicates L1-only capability.";
skipping to change at page 34, line 47 skipping to change at page 35, line 4
"This type defines the IS-IS LSP ID format using a "This type defines the IS-IS LSP ID format using a
pattern. An example LSP ID is 0143.0438.AEF0.02-01"; pattern. An example LSP ID is 0143.0438.AEF0.02-01";
} }
typedef area-address { typedef area-address {
type string { type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
} }
description description
"This type defines the area address format."; "This type defines the area address format.";
} }
typedef snpa { typedef snpa {
type string { type string {
length "0 .. 20"; length "0 .. 20";
} }
description description
"This type defines the Subnetwork Point "This type defines the Subnetwork Point
of Attachment (SNPA) format. of Attachment (SNPA) format.
The SNPA should be encoded according to the rules The SNPA should be encoded according to the rules
specified for the particular type of subnetwork specified for the particular type of subnetwork
being used. As an example, for an ethernet subnetwork, being used. As an example, for an ethernet subnetwork,
the SNPA is encoded as a MAC address like the SNPA is encoded as a MAC address, such as,
'00aa.bbcc.ddee'."; '00aa.bbcc.ddee'.";
} }
typedef system-id { typedef system-id {
type string { type string {
pattern pattern
'[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}'; '[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}';
} }
description description
"This type defines IS-IS system-id using pattern, "This type defines IS-IS system-id using pattern,
skipping to change at page 39, line 27 skipping to change at page 39, line 32
enum lfa { enum lfa {
description description
"LFA alternate."; "LFA alternate.";
} }
enum remote-lfa { enum remote-lfa {
description description
"Remote LFA alternate."; "Remote LFA alternate.";
} }
enum tunnel { enum tunnel {
description description
"Tunnel based alternate "Tunnel based alternate (such as,
(like RSVP-TE or GRE)."; RSVP-TE or GRE).";
} }
enum ti-lfa { enum ti-lfa {
description description
"TI-LFA alternate."; "TI-LFA alternate.";
} }
enum mrt { enum mrt {
description description
"MRT alternate."; "MRT alternate.";
} }
enum other { enum other {
skipping to change at page 41, line 19 skipping to change at page 41, line 26
leaf address-family { leaf address-family {
type iana-rt-types:address-family; type iana-rt-types:address-family;
description "Address-family"; description "Address-family";
} }
leaf prefix { leaf prefix {
type inet:ip-prefix; type inet:ip-prefix;
description "Unprotected prefix."; description "Unprotected prefix.";
} }
description description
"Per AF unprotected prefix statistics."; "Per-AF unprotected prefix statistics.";
} }
description description
"List of prefixes that are not protected."; "List of prefixes that are not protected.";
} }
list protection-statistics { list protection-statistics {
key frr-protection-method; key frr-protection-method;
config false; config false;
leaf frr-protection-method { leaf frr-protection-method {
type identityref { type identityref {
skipping to change at page 42, line 8 skipping to change at page 42, line 16
leaf unprotected-routes { leaf unprotected-routes {
type uint32; type uint32;
description description
"Total prefixes that are not protected."; "Total prefixes that are not protected.";
} }
leaf protected-routes { leaf protected-routes {
type uint32; type uint32;
description description
"Total prefixes that are protected."; "Total prefixes that are protected.";
} }
leaf linkprotected-routes { leaf link-protected-routes {
type uint32; type uint32;
description description
"Total prefixes that are link protected."; "Total prefixes that are link protected.";
} }
leaf nodeprotected-routes { leaf node-protected-routes {
type uint32; type uint32;
description description
"Total prefixes that are node protected."; "Total prefixes that are node protected.";
} }
description description
"Per AF protected prefix statistics."; "Per-AF protected prefix statistics.";
} }
description "Global protection statistics."; description "Global protection statistics.";
} }
} }
/* Route table and local RIB groupings */ /* Route table and local RIB groupings */
grouping local-rib { grouping local-rib {
description "Local-rib - RIB for Routes computed by the local description "Local-rib - RIB for Routes computed by the local
skipping to change at page 45, line 9 skipping to change at page 45, line 16
"Circuit ID of the neighbor"; "Circuit ID of the neighbor";
} }
leaf neighbor-snpa { leaf neighbor-snpa {
type snpa; type snpa;
description description
"SNPA of the neighbor"; "SNPA of the neighbor";
} }
leaf usage { leaf usage {
type level; type level;
description description
"Define the level(s) activated on the adjacency. "Define the level(s) activated for the adjacency.
On a p2p link this might be level 1 and 2, On a p2p link this might be level 1 and 2,
but on a LAN, the usage will be level 1 but on a LAN, the usage will be level 1
between neighbors at level 1 or level 2 between between neighbors at level 1 or level 2 between
neighbors at level 2."; neighbors at level 2.";
} }
leaf hold-timer { leaf hold-timer {
type rt-types:timer-value-seconds16; type rt-types:timer-value-seconds16;
units seconds; units seconds;
description description
"The holding time in seconds for this "The holding time in seconds for this
skipping to change at page 58, line 38 skipping to change at page 58, line 47
uses spf-log; uses spf-log;
uses lsp-log; uses lsp-log;
uses hostname-db; uses hostname-db;
uses lsdb; uses lsdb;
uses local-rib; uses local-rib;
uses system-counters; uses system-counters;
uses instance-fast-reroute-state; uses instance-fast-reroute-state;
leaf discontinuity-time { leaf discontinuity-time {
type yang:date-and-time; type yang:date-and-time;
description description
"The time on the most recent occasion at which any one "The time of the most recent occasion at which any one
or more of this IS-IS instance's counters suffered a or more of this IS-IS instance's counters suffered a
discontinuity. If no such discontinuities have occurred discontinuity. If no such discontinuities have occurred
since the IS-IS instance was last re-initialized, then since the IS-IS instance was last re-initialized, then
this node contains the time the IS-IS instance was this node contains the time the IS-IS instance was
re-initialized which normally occurs when it was re-initialized which normally occurs when it was
created."; created.";
} }
} }
grouping multi-topology-config { grouping multi-topology-config {
skipping to change at page 60, line 33 skipping to change at page 60, line 42
description description
"Only valid when mesh-group-enable equals mesh-set"; "Only valid when mesh-group-enable equals mesh-set";
} }
type uint8; type uint8;
description "IS-IS interface mesh-group ID."; description "IS-IS interface mesh-group ID.";
} }
leaf interface-type { leaf interface-type {
type interface-type; type interface-type;
default "broadcast"; default "broadcast";
description description
"Type of adjacency to be established on the interface. This "Type of adjacency to be established for the interface. This
dictates the type of hello messages that are used."; dictates the type of hello messages that are used.";
} }
leaf-list tag { leaf-list tag {
if-feature prefix-tag; if-feature prefix-tag;
type uint32; type uint32;
description description
"List of tags associated with the interface."; "List of tags associated with the interface.";
} }
leaf-list tag64 { leaf-list tag64 {
skipping to change at page 63, line 41 skipping to change at page 63, line 50
} }
grouping interface-state { grouping interface-state {
description description
"IS-IS interface operational state."; "IS-IS interface operational state.";
uses adjacency-state; uses adjacency-state;
uses event-counters; uses event-counters;
uses packet-counters; uses packet-counters;
leaf discontinuity-time { leaf discontinuity-time {
type yang:date-and-time; type yang:date-and-time;
description description
"The time on the most recent occasion at which any one "The time of the most recent occasion at which any one
or more of this IS-IS interfaces's counters suffered a or more of this IS-IS interface's counters suffered a
discontinuity. If no such discontinuities have occurred discontinuity. If no such discontinuities have occurred
since the IS-IS interface was last re-initialized, then since the IS-IS interface was last re-initialized, then
this node contains the time the IS-IS interface was this node contains the time the IS-IS interface was
re-initialized which normally occurs when it was re-initialized which normally occurs when it was
created."; created.";
} }
} }
/* Grouping for the hostname database */ /* Grouping for the hostname database */
grouping hostname-db { grouping hostname-db {
container hostnames { container hostnames {
config false; config false;
list hostname { list hostname {
key system-id; key system-id;
leaf system-id { leaf system-id {
type system-id; type system-id;
description description
"system-id associated with the hostname."; "system-id associated with the hostname.";
} }
skipping to change at page 78, line 7 skipping to change at page 78, line 18
type uint8; type uint8;
description description
"Switching capability of the link."; "Switching capability of the link.";
} }
leaf encoding { leaf encoding {
type uint8; type uint8;
description description
"Type of encoding of the LSP being used."; "Type of encoding of the LSP being used.";
} }
container max-lsp-bandwidths { container max-lsp-bandwidths {
description "Per priority max LSP bandwidths."; description "Per-priority max LSP bandwidths.";
list max-lsp-bandwidth { list max-lsp-bandwidth {
leaf priority { leaf priority {
type uint8 { type uint8 {
range "0 .. 7"; range "0 .. 7";
} }
description "Priority from 0 to 7."; description "Priority from 0 to 7.";
} }
leaf bandwidth { leaf bandwidth {
type rt-types:bandwidth-ieee-float32; type rt-types:bandwidth-ieee-float32;
description "max LSP bandwidth."; description "max LSP bandwidth.";
skipping to change at page 106, line 21 skipping to change at page 106, line 35
For IS-IS, the ability to modify IS-IS configuration will allow the For IS-IS, the ability to modify IS-IS configuration will allow the
entire IS-IS domain to be compromised including forming adjacencies entire IS-IS domain to be compromised including forming adjacencies
with unauthorized routers to misroute traffic or mount a massive with unauthorized routers to misroute traffic or mount a massive
Denial-of-Service (DoS) attack. For example, adding IS-IS on any Denial-of-Service (DoS) attack. For example, adding IS-IS on any
unprotected interface could allow an IS-IS adjacency to be formed unprotected interface could allow an IS-IS adjacency to be formed
with an unauthorized and malicious neighbor. Once an adjacency is with an unauthorized and malicious neighbor. Once an adjacency is
formed, traffic could be hijacked. As a simpler example, a Denial- formed, traffic could be hijacked. As a simpler example, a Denial-
of-Service attack could be mounted by changing the cost of an IS-IS of-Service attack could be mounted by changing the cost of an IS-IS
interface to be asymmetric such that a hard routing loop ensues. In interface to be asymmetric such that a hard routing loop ensues. In
general, unauthorized modification of most IS-IS features will pose general, unauthorized modification of most IS-IS features will pose
there own set of security risks and the "Security Considerations" in their own set of security risks and the "Security Considerations" in
the respective reference RFCs should be consulted. the respective reference RFCs should be consulted.
Some of the readable data nodes in the ietf-isi.yang module may be Some of the readable data nodes in the ietf-isi.yang module may be
considered sensitive or vulnerable in some network environments. It considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config, is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. The exposure of the Link State or notification) to these data nodes. The exposure of the Link State
Database (LSDB) will expose the detailed topology of the network. Database (LSDB) will expose the detailed topology of the network.
The Link State Database (LSDB) is represented by the following schema The Link State Database (LSDB) is represented by the following schema
node: node:
/isis/database /isis/database
Exposure of the Link State Database includes information beyond the Exposure of the Link State Database includes information beyond the
scope of the IS-IS router and this may be undesirable since exposure scope of the IS-IS router and this may be undesirable since exposure
may facilitate other attacks. Additionally, the complete IP network may facilitate other attacks. Additionally, the complete IP network
topology and, if deployed, the traffic engineering topology of the topology and, if deployed, the traffic engineering topology of the
IS-IS domain can be reconstucted. Network operators may consider IS-IS domain can be reconstructed. Network operators may consider
their topologies to be sensitive confidential data. their topologies to be sensitive confidential data.
For IS-IS authentication, configuration is supported via the For IS-IS authentication, configuration is supported via the
specification of key-chain [RFC8177] or the direction specification specification of key-chain [RFC8177] or the direction specification
of key and authentication algorithm. Hence, authentification of key and authentication algorithm. Hence, authentication
configuration using the "auth-table-trailer" case in the configuration using the "auth-table-trailer" case in the
"authentication" container inherits the security considerations of "authentication" container inherits the security considerations of
[RFC8177]. This includes the considerations with respect to the [RFC8177]. This includes the considerations with respect to the
local storage and handling of authentication keys. local storage and handling of authentication keys.
Some of the RPC operations in this YANG module may be considered Some of the RPC operations 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 access to these operations. The IS-IS YANG important to control access to these operations. The IS-IS YANG
module support the "clear-adjacency" and "clear-database" RPCs. If module support the "clear-adjacency" and "clear-database" RPCs. If
access too either of these is compromised, they can result in access to either of these is compromised, they can result in
temporary network outages be employed to mount DoS attacks. temporary network outages be employed to mount DoS attacks.
The actual authentication key data (whether locally specified or part The actual authentication key data (whether locally specified or part
of a key-chain) is sensitive and needs to be kept secret from of a key-chain) is sensitive and needs to be kept secret from
unauthorized parties; compromise of the key data would allow an unauthorized parties; compromise of the key data would allow an
attacker to forge IS-IS traffic that would be accepted as authentic, attacker to forge IS-IS traffic that would be accepted as authentic,
potentially compromising the entirety IS-IS domain. potentially compromising the entirety IS-IS domain.
8. Contributors 8. Contributors
Authors would like to thank Kiran Agrahara Sreenivasa, Dean The authors would like to thank Kiran Agrahara Sreenivasa, Dean
Bogdanovic, Yingzhen Qu, Yi Yang, Jeff Tanstura for their major Bogdanovic, Yingzhen Qu, Yi Yang, Jeff Tanstura for their major
contributions to the draft. contributions to the draft.
9. IANA Considerations 9. Acknowledgements
The authors would like to thank Tom Petch, Alvaro Retena, Stewart
Bryant, and Barry Leiba for their review and comments.
10. IANA Considerations
The IANA is requested to assign two new URIs from the IETF XML The IANA is requested to assign two new URIs from the IETF XML
registry [RFC3688]. Authors are suggesting the following URI: registry [RFC3688]. Authors are suggesting the following URI:
URI: urn:ietf:params:xml:ns:yang:ietf-isis URI: urn:ietf:params:xml:ns:yang:ietf-isis
Registrant Contact: The IESG Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace XML: N/A, the requested URI is an XML namespace
This document also requests one new YANG module name in the YANG This document also requests one new YANG module name in the YANG
Module Names registry [RFC6020] with the following suggestion: Module Names registry [RFC6020] with the following suggestion:
name: ietf-isis name: ietf-isis
namespace: urn:ietf:params:xml:ns:yang:ietf-isis namespace: urn:ietf:params:xml:ns:yang:ietf-isis
prefix: isis prefix: isis
reference: RFC XXXX reference: RFC XXXX
10. References 11. References
10.1. Normative References 11.1. Normative References
[I-D.ietf-bfd-yang] [I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and
G. Mirsky, "YANG Data Model for Bidirectional Forwarding G. Mirsky, "YANG Data Model for Bidirectional Forwarding
Detection (BFD)", draft-ietf-bfd-yang-17 (work in Detection (BFD)", draft-ietf-bfd-yang-17 (work in
progress), August 2018. progress), August 2018.
[ISO-10589] [ISO-10589]
"Intermediate System to Intermediate System intra- domain "Intermediate System to Intermediate System intra- domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
skipping to change at page 112, line 5 skipping to change at page 112, line 25
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>. 2019, <https://www.rfc-editor.org/info/rfc8570>.
10.2. Informative References 11.2. Informative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
Appendix A. Example of IS-IS configuration in XML Appendix A. Example of IS-IS configuration in XML
This section gives an example of configuration of an IS-IS instance This section gives an example of configuration of an IS-IS instance
on a device. The example is written in XML. on a device. The example is written in XML.
 End of changes. 100 change blocks. 
176 lines changed or deleted 184 lines changed or added

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