--- 1/draft-ietf-isis-yang-isis-cfg-37.txt 2019-09-26 13:13:07.261480619 -0700
+++ 2/draft-ietf-isis-yang-isis-cfg-38.txt 2019-09-26 13:13:07.461485687 -0700
@@ -1,30 +1,30 @@
IS-IS Working Group S. Litkowski
Internet-Draft Orange
Intended status: Standards Track D. Yeung
-Expires: March 12, 2020 Arrcus, Inc
+Expires: March 29, 2020 Arrcus, Inc
A. Lindem
Cisco Systems
J. Zhang
Juniper Networks
L. Lhotka
CZ.NIC
- September 9, 2019
+ September 26, 2019
YANG Data Model for IS-IS Protocol
- draft-ietf-isis-yang-isis-cfg-37
+ draft-ietf-isis-yang-isis-cfg-38
Abstract
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
@@ -35,21 +35,21 @@
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
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 (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
@@ -57,63 +57,64 @@
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3
2.1. IS-IS Configuration . . . . . . . . . . . . . . . . . . . 9
- 2.2. Multitopology Parameters . . . . . . . . . . . . . . . . 9
+ 2.2. Multi-topology Parameters . . . . . . . . . . . . . . . . 9
2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10
2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 11
2.5. Authentication Parameters . . . . . . . . . . . . . . . . 18
2.6. IGP/LDP synchronization . . . . . . . . . . . . . . . . . 19
2.7. ISO parameters . . . . . . . . . . . . . . . . . . . . . 19
2.8. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 2.9. Operational States . . . . . . . . . . . . . . . . . . . 19
+ 2.9. Operational States . . . . . . . . . . . . . . . . . . . 20
3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 20
4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Interaction with Other YANG Modules . . . . . . . . . . . . . 22
6. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 105
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 107
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 107
- 10.1. Normative References . . . . . . . . . . . . . . . . . . 107
- 10.2. Informative References . . . . . . . . . . . . . . . . . 112
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 108
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . 108
+ 11.2. Informative References . . . . . . . . . . . . . . . . . 112
Appendix A. Example of IS-IS configuration in XML . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
1. Introduction
This document defines a YANG [RFC7950] data model for 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
Section 2. Tree diagrams used in this document follow the notation
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].
2. Design of the Data Model
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
- module:
+ The figure below describes the overall structure of the ietf-isis
+ YANG module:
module: ietf-isis
augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
+--ro metric? uint32
+--ro tag* uint64
+--ro route-type? enumeration
augment /if:interfaces/if:interface:
+--rw clns-mtu? uint16 {osi-interface}?
augment
| /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:
@@ -385,153 +385,152 @@
+---n lsp-generation
+--ro routing-protocol-name?
-> /rt:routing/control-plane-protocols/control-plane-protocol/name
+--ro isis-level? level
+--ro lsp-id? lsp-id
+--ro sequence? uint32
+--ro send-timestamp? yang:timestamp
2.1. IS-IS Configuration
- The IS-IS configuration is divided in:
+ The IS-IS configuration is divided into:
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
- parameters. These additional modules MUST augment the ietf-isis
- module.
+ Additional modules may be created to support additional parameters.
+ These additional modules MUST augment the ietf-isis module.
- The model implements features, thus some of the configuration
- statement becomes optional. As an example, the ability to control
- the administrative state of a particular IS-IS instance is optional.
- By advertising the feature "admin-control", a device communicates to
- the client that it supports the ability to shutdown a particular IS-
- IS instance.
+ The model includes optional features, for which the corresponding
+ configuration data nodes are also optional. As an example, the
+ ability to control the administrative state of a particular IS-IS
+ instance is optional. By advertising the feature "admin-control", a
+ device communicates to the client that it supports the ability to
+ shut down a particular IS-IS instance.
- The global configuration contains usual IS-IS parameters such as lsp-
- mtu, lsp-lifetime, lsp-refresh, default-metric...
+ The global configuration contains usual IS-IS parameters, such as,
+ 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.
- The "name" used in the topology list should refer to an existing RIB
- of the device.
+ The "name" used in the topology list should refer to an existing
+ Routing Information Base (RIB) defined for the device [RFC8349].
- Some specific parameters can be defined on a per topology basis both
- at global level and at interface level: for example, an interface
- metric can be defined per topology.
+ Some specific parameters can be defined on a per-topology basis, both
+ at the global level and at the interface level: for example, an
+ 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-
- families container (requiring "nlpid-control" feature to be
- advertised).
+ families container (requiring the "nlpid-control" feature to be
+ supported).
2.3. Per-Level Parameters
- Some parameters allow a per level configuration. In this case, the
- parameter is modeled as a container with three configuration
- locations:
+ Some parameters allow a per-level configuration. For such
+ parameters, the parameter is modeled as a container with three
+ 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.
- 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 value? uint8
| +--rw level-1
| | +--rw value? uint8
| +--rw level-2
| +--rw value? uint8
Example:
250
100
200
- An implementation MUST prefer a level specific parameter over a
- level-all parameter. As example, if the priority is 100 for the
- level-1, 200 for the level-2 and 250 for the top-level configuration,
- the implementation should use 100 for the level-1 and 200 for the
- level-2.
+ An implementation MUST prefer a level-specific parameter over a top-
+ level parameter. For example, if the priority is 100 for the level-
+ 1, 200 for the level-2 and 250 for the top-level configuration, the
+ implementation must use 100 for the level-1 priority and 200 for the
+ level-2 priority.
- Some parameters like "overload bit" and "route preference" are not
- modeled to support a per level configuration. If an implementation
- supports per level configuration for such parameter, this
- implementation MUST augment the current model by adding both level-1
- and level-2 containers and MUST reuse existing configuration
+ Some parameters, such as, "overload bit" and "route preference", are
+ not modeled to support a per-level configuration. If an
+ implementation supports per-level configuration for such parameter,
+ this implementation MUST augment the current model by adding both
+ level-1 and level-2 containers and MUST reuse existing configuration
groupings.
Example of augmentation:
augment "/rt:routing/" +
"rt:control-plane-protocols/rt:control-plane-protocol"+
"/isis:isis/isis:overload" {
when "rt:type = 'isis:isis'" {
description
"This augment IS-IS routing protocol when used";
}
description
"This augments IS-IS overload configuration
- with per level configuration.";
+ with per-level configuration.";
container level-1 {
uses isis:overload-global-cfg;
description
"Level 1 configuration.";
}
container level-2 {
uses isis:overload-global-cfg;
description
"Level 2 configuration.";
}
}
- If an implementation does not support per level configuration for a
- parameter modeled with per level configuration, the implementation
- should advertise a deviation to announce the non-support of the
+ If an implementation does not support per-level configuration for a
+ parameter modeled with per-level configuration, the implementation
+ SHOULD advertise a deviation to announce the non-support of the
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
advertise a deviation.
2.4. Per-Interface Parameters
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
defined in the "ietf-interfaces" YANG model ([RFC8343].
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
parameter.
- Some parameters like hello-padding are defined as containers to allow
- easy extension by vendor specific modules.
+ Some parameters, such as, hello-padding are defined as containers to
+ allow easy extension by vendor-specific modules.
+--rw interfaces
+--rw interface* [name]
+--rw name if:interface-ref
+--rw enable? boolean {admin-control}?
+--rw level-type? level
+--rw lsp-pacing-interval?
| rt-types:timer-value-milliseconds
+--rw lsp-retransmit-interval?
| rt-types:timer-value-seconds16
@@ -849,120 +848,123 @@
-> /rt:routing/control-plane-protocols/control-plane-protocol/name
+--ro isis-level? level
+--ro lsp-id? lsp-id
+--ro sequence? uint32
+--ro send-timestamp? yang:timestamp
2.5. Authentication Parameters
The module enables authentication configuration through 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
- interface configuration of authentication. If a global
- authentication is configured, an implementation SHOULD authenticate
- PSNPs (Partial Sequence Number Packets), CSNPs (Complete Sequence
- Number Packets) and LSPs (Link State Packets) with the authentication
- parameters supplied. The authentication of HELLO PDUs (Protocol Data
- Units) can be activated on a per interface basis.
+ chain" module and reuses some groupings to allow global and per-
+ interface configuration of authentication. If global authentication
+ is configured, an implementation SHOULD authenticate PSNPs (Partial
+ Sequence Number Packets), CSNPs (Complete Sequence Number Packets)
+ and LSPs (Link State Packets) with the authentication parameters
+ supplied. The authentication of HELLO PDUs (Protocol Data Units) can
+ be activated on a per-interface basis.
2.6. IGP/LDP synchronization
[RFC5443] defines a mechanism where IGP (Interior Gateway Protocol)
needs to be synchronized with LDP (Label Distribution Protocol). An
"ldp-igp-sync" feature has been defined in the model to support this
- mechanism. The "mpls/ldp/igp-sync" leaf under "interface" allows
- activation of the mechanism on a per interface basis. The "mpls/ldp/
- igp-sync" container in the global configuration is empty on purpose
- and is not required for the activation. The goal of this empty
- container is to allow easy augmentation with additional parameters
- like timers for example.
+ functionality. The "mpls/ldp/igp-sync" leaf under "interface" allows
+ activation of the mechanism on a per-interface basis. The "mpls/ldp/
+ igp-sync" container in the global configuration is intentionally
+ empty and is not required for feature activation. The goal of this
+ empty container is to facilitate augmentation with additional
+ parameters, e.g., timers.
2.7. ISO parameters
- As IS-IS protocol is based on ISO protocol suite, some ISO parameters
- may be required.
+ As the IS-IS protocol is based on the ISO protocol suite, some ISO
+ parameters may be required.
- This module augments interface configuration model to support ISO
- configuration parameters.
+ This module augments interface configuration model to support
+ 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
This YANG module supports LFA (Loop Free Alternates) [RFC5286] and
- remote LFA [RFC7490] as IP FRR techniques. The "fast-reroute"
- container may be augmented by other models to support other IPFRR
- flavors (MRT, TILFA ...).
+ remote LFA [RFC7490] as IP Fast Re-Route (FRR) techniques. The
+ "fast-reroute" container may be augmented by other models to support
+ other IP FRR flavors (MRT, TI-LFA, etc.).
The current version of the model supports activation of LFA and
- remote LFA at interface only. The global "lfa" container is present
- but kept empty to allow augmentation with vendor specific properties
- like policies.
+ remote LFA at the interface-level only. The global "lfa" container
+ is present but kept empty to allow augmentation with vendor-specific
+ properties, e.g., policies.
- Remote LFA is considered as a child of LFA. Remote LFA cannot be
- enabled if LFA is not enabled.
+ Remote LFA is considered as an extension of LFA. Remote LFA cannot
+ be enabled if LFA is not enabled.
- The "candidate-enable" allows to mark an interface to be used as a
- backup.
+ The "candidate-enable" data leaf designates that an interface can be
+ used as a backup.
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
- global system.
+ o system-counters: Provides statistical information about the global
+ system.
- o interface : provides configuration state informations for each
+ o interface: Provides configuration state information for each
interface.
- o adjacencies: provides state informations about current IS-IS
+ o adjacencies: Provides state information about current IS-IS
adjacencies.
- o spf-log: provides informations about SPF events on the node. This
- SHOULD be implemented as a wrapping buffer.
+ o spf-log: Provides information about SPF events for an IS-IS
+ instance. This SHOULD be implemented as a wrapping buffer.
- o lsp-log: provides informations about LSP events on the node
- (reception of an LSP or modification of local LSP). This SHOULD
- be implemented as a wrapping buffer and an implementation MAY
- decide to log refresh LSPs or not.
+ o lsp-log: Provides information about LSP events for an IS-IS
+ instance (reception of an LSP or modification of a local LSP).
+ This SHOULD be implemented as a wrapping buffer and the
+ 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
- mappings [RFC5301].
+ o hostnames: Provides the system-id to hostname mappings [RFC5301].
- o fast-reroute: provides informations about IP FRR.
+ o fast-reroute: Provides IP FRR state information.
3. RPC Operations
The "ietf-isis" module defines two RPC operations:
- o clear-database: reset the content of a particular IS-IS database
- and restart database synchronization with the neighbors.
+ o clear-database: Reset the content of a particular IS-IS database
+ 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
- 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
- that is too large.
+ lsp-too-large: This notification is sent when the system tries to
+ 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
- that was stored in memory has become corrupted.
+ corrupted-lsp-detected: This notification is sent when the IS-IS
+ 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
system wraps the 32-bit sequence counter of an LSP.
id-len-mismatch: This notification is sent when we receive a PDU
with a different value for the System ID length.
max-area-addresses-mismatch: This notification is sent when we
receive a PDU with a different value for the Maximum Area
Addresses.
@@ -1002,52 +1004,51 @@
lsp-received: This notification is sent when an LSP is received.
lsp-generation: This notification is sent when an LSP is
regenerated.
5. Interaction with Other YANG Modules
The "isis" container augments the "/rt:routing/rt:control-plane-
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
[RFC8343] with ISO specific parameters.
The "isis" operational state container augments the "/rt:routing-
state/rt:control-plane-protocols/control-plane-protocol" container of
- the ietf-routing module by defining IS-IS specific operational
- states.
+ the ietf-routing module with IS-IS-specific operational 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-
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].
The module reuses types from [RFC6991] and [RFC8294].
To support BFD for fast detection, the module relies on
[I-D.ietf-bfd-yang].
6. IS-IS YANG Module
The following RFCs, drafts and external standards are not referenced
in the document text but are referenced in the ietf-isis.yang module:
[ISO-10589], [RFC1195], [RFC4090],[RFC5029], [RFC5130], [RFC5302],
[RFC5305], [RFC5306], [RFC5307], [RFC5308], [RFC5880], [RFC5881],
[RFC6119], [RFC6232], [RFC7794], [RFC7981], [RFC8570], [RFC7917],
[RFC8405].
- file "ietf-isis@2019-09-09.yang"
+ file "ietf-isis@2019-09-26.yang"
module ietf-isis {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-isis";
prefix isis;
import ietf-routing {
prefix "rt";
reference "RFC 8349 - A YANG Data Model for Routing
Management (NMDA Version)";
@@ -1143,21 +1144,21 @@
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
- revision 2019-09-09 {
+ revision 2019-09-26 {
description
"Initial revision.";
reference "RFC XXXX";
}
/* Identities */
identity isis {
base rt:routing-protocol;
description "Identity for the IS-IS routing protocol.";
@@ -1209,21 +1210,21 @@
identity frr-protection-available-link-type {
base frr-protection-available-type;
description "Link protection is provided by the alternate.";
}
identity frr-protection-available-srlg-type {
base frr-protection-available-type;
description "SRLG protection is provided by the alternate.";
}
identity frr-protection-available-downstream-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 {
base frr-protection-available-type;
description "The level of protection is unknown.";
}
identity unidirectional-link-delay-subtlv-flag {
description "Base identity for unidirectional-link-delay
subTLV flags. Flags are defined in RFC8570.";
}
@@ -1525,21 +1525,21 @@
description
"Broadcast interface type.";
}
enum point-to-point {
description
"Point-to-point interface type.";
}
}
description
"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
of hello message that is used.";
}
typedef level {
type enumeration {
enum "level-1" {
description
"This enum indicates L1-only capability.";
@@ -1614,34 +1614,34 @@
"This type defines the IS-IS LSP ID format using a
pattern. An example LSP ID is 0143.0438.AEF0.02-01";
}
typedef area-address {
type string {
pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}';
}
description
"This type defines the area address format.";
+
}
typedef snpa {
type string {
length "0 .. 20";
-
}
description
"This type defines the Subnetwork Point
of Attachment (SNPA) format.
The SNPA should be encoded according to the rules
specified for the particular type of 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'.";
}
typedef system-id {
type string {
pattern
'[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}';
}
description
"This type defines IS-IS system-id using pattern,
@@ -1834,22 +1834,22 @@
enum lfa {
description
"LFA alternate.";
}
enum remote-lfa {
description
"Remote LFA alternate.";
}
enum tunnel {
description
- "Tunnel based alternate
- (like RSVP-TE or GRE).";
+ "Tunnel based alternate (such as,
+ RSVP-TE or GRE).";
}
enum ti-lfa {
description
"TI-LFA alternate.";
}
enum mrt {
description
"MRT alternate.";
}
enum other {
@@ -1923,21 +1924,21 @@
leaf address-family {
type iana-rt-types:address-family;
description "Address-family";
}
leaf prefix {
type inet:ip-prefix;
description "Unprotected prefix.";
}
description
- "Per AF unprotected prefix statistics.";
+ "Per-AF unprotected prefix statistics.";
}
description
"List of prefixes that are not protected.";
}
list protection-statistics {
key frr-protection-method;
config false;
leaf frr-protection-method {
type identityref {
@@ -1960,32 +1962,32 @@
leaf unprotected-routes {
type uint32;
description
"Total prefixes that are not protected.";
}
leaf protected-routes {
type uint32;
description
"Total prefixes that are protected.";
}
- leaf linkprotected-routes {
+ leaf link-protected-routes {
type uint32;
description
"Total prefixes that are link protected.";
}
- leaf nodeprotected-routes {
+ leaf node-protected-routes {
type uint32;
description
"Total prefixes that are node protected.";
}
description
- "Per AF protected prefix statistics.";
+ "Per-AF protected prefix statistics.";
}
description "Global protection statistics.";
}
}
/* Route table and local RIB groupings */
grouping local-rib {
description "Local-rib - RIB for Routes computed by the local
@@ -2103,21 +2105,21 @@
"Circuit ID of the neighbor";
}
leaf neighbor-snpa {
type snpa;
description
"SNPA of the neighbor";
}
leaf usage {
type level;
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,
but on a LAN, the usage will be level 1
between neighbors at level 1 or level 2 between
neighbors at level 2.";
}
leaf hold-timer {
type rt-types:timer-value-seconds16;
units seconds;
description
"The holding time in seconds for this
@@ -2756,21 +2759,21 @@
uses spf-log;
uses lsp-log;
uses hostname-db;
uses lsdb;
uses local-rib;
uses system-counters;
uses instance-fast-reroute-state;
leaf discontinuity-time {
type yang:date-and-time;
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
discontinuity. If no such discontinuities have occurred
since the IS-IS instance was last re-initialized, then
this node contains the time the IS-IS instance was
re-initialized which normally occurs when it was
created.";
}
}
grouping multi-topology-config {
@@ -2847,21 +2850,21 @@
description
"Only valid when mesh-group-enable equals mesh-set";
}
type uint8;
description "IS-IS interface mesh-group ID.";
}
leaf interface-type {
type interface-type;
default "broadcast";
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.";
}
leaf-list tag {
if-feature prefix-tag;
type uint32;
description
"List of tags associated with the interface.";
}
leaf-list tag64 {
@@ -2999,31 +3002,32 @@
}
grouping interface-state {
description
"IS-IS interface operational state.";
uses adjacency-state;
uses event-counters;
uses packet-counters;
leaf discontinuity-time {
type yang:date-and-time;
description
- "The time on the most recent occasion at which any one
- or more of this IS-IS interfaces's counters suffered a
+ "The time of the most recent occasion at which any one
+ or more of this IS-IS interface's counters suffered a
discontinuity. If no such discontinuities have occurred
since the IS-IS interface was last re-initialized, then
this node contains the time the IS-IS interface was
re-initialized which normally occurs when it was
created.";
}
}
/* Grouping for the hostname database */
+
grouping hostname-db {
container hostnames {
config false;
list hostname {
key system-id;
leaf system-id {
type system-id;
description
"system-id associated with the hostname.";
}
@@ -3687,21 +3693,21 @@
type uint8;
description
"Switching capability of the link.";
}
leaf encoding {
type uint8;
description
"Type of encoding of the LSP being used.";
}
container max-lsp-bandwidths {
- description "Per priority max LSP bandwidths.";
+ description "Per-priority max LSP bandwidths.";
list max-lsp-bandwidth {
leaf priority {
type uint8 {
range "0 .. 7";
}
description "Priority from 0 to 7.";
}
leaf bandwidth {
type rt-types:bandwidth-ieee-float32;
description "max LSP bandwidth.";
@@ -5043,87 +5055,92 @@
For IS-IS, the ability to modify IS-IS configuration will allow the
entire IS-IS domain to be compromised including forming adjacencies
with unauthorized routers to misroute traffic or mount a massive
Denial-of-Service (DoS) attack. For example, adding IS-IS on any
unprotected interface could allow an IS-IS adjacency to be formed
with an unauthorized and malicious neighbor. Once an adjacency is
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
interface to be asymmetric such that a hard routing loop ensues. In
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.
Some of the readable data nodes in the ietf-isi.yang module may be
considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. The exposure of the Link State
Database (LSDB) will expose the detailed topology of the network.
The Link State Database (LSDB) is represented by the following schema
node:
/isis/database
Exposure of the Link State Database includes information beyond the
scope of the IS-IS router and this may be undesirable since exposure
may facilitate other attacks. Additionally, the complete IP network
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.
For IS-IS authentication, configuration is supported via the
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
"authentication" container inherits the security considerations of
[RFC8177]. This includes the considerations with respect to the
local storage and handling of authentication keys.
Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. The IS-IS YANG
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.
The actual authentication key data (whether locally specified or part
of a key-chain) is sensitive and needs to be kept secret from
unauthorized parties; compromise of the key data would allow an
attacker to forge IS-IS traffic that would be accepted as authentic,
potentially compromising the entirety IS-IS domain.
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
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
registry [RFC3688]. Authors are suggesting the following URI:
URI: urn:ietf:params:xml:ns:yang:ietf-isis
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace
This document also requests one new YANG module name in the YANG
Module Names registry [RFC6020] with the following suggestion:
name: ietf-isis
namespace: urn:ietf:params:xml:ns:yang:ietf-isis
prefix: isis
reference: RFC XXXX
-10. References
+11. References
-10.1. Normative References
+11.1. Normative References
[I-D.ietf-bfd-yang]
Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and
G. Mirsky, "YANG Data Model for Bidirectional Forwarding
Detection (BFD)", draft-ietf-bfd-yang-17 (work in
progress), August 2018.
[ISO-10589]
"Intermediate System to Intermediate System intra- domain
routeing information exchange protocol for use in
@@ -5304,21 +5321,21 @@
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, .
-10.2. Informative References
+11.2. Informative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
.
Appendix A. Example of IS-IS configuration in XML
This section gives an example of configuration of an IS-IS instance
on a device. The example is written in XML.