< draft-ietf-isis-yang-isis-cfg-11.txt   draft-ietf-isis-yang-isis-cfg-12.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 25, 2017 A. Lindem Expires: April 20, 2017 A. Lindem
Cisco Systems Cisco Systems
J. Zhang J. Zhang
Juniper Networks Juniper Networks
L. Lhotka L. Lhotka
CZ.NIC CZ.NIC
September 21, 2016 October 17, 2016
YANG Data Model for IS-IS protocol YANG Data Model for IS-IS protocol
draft-ietf-isis-yang-isis-cfg-11 draft-ietf-isis-yang-isis-cfg-12
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. It also defined an and manage IS-IS protocol on network elements. It also defined an
extension module for segment routing configuration and operation. extension module for segment routing configuration and operation.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 25, 2017. This Internet-Draft will expire on April 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . 10
2.2. Multitopology Parameters . . . . . . . . . . . . . . . . 10 2.2. Multitopology Parameters . . . . . . . . . . . . . . . . 10
2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10 2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10
2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 12 2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 12
2.5. ISO parameters . . . . . . . . . . . . . . . . . . . . . 15 2.5. Authentication Parameters . . . . . . . . . . . . . . . . 16
2.6. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6. IGP/LDP synchronization . . . . . . . . . . . . . . . . . 16
2.7. Operational State . . . . . . . . . . . . . . . . . . . . 16 2.7. ISO parameters . . . . . . . . . . . . . . . . . . . . . 16
3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 16 2.8. IP FRR . . . . . . . . . . . . . . . . . . . . . . . . . 16
4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 17 2.9. Operational State . . . . . . . . . . . . . . . . . . . . 17
5. Segment Routing . . . . . . . . . . . . . . . . . . . . . . . 21 3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Segment Routing activation . . . . . . . . . . . . . . . 23 4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Advertising mapping server policy . . . . . . . . . . . . 24 5. Segment Routing . . . . . . . . . . . . . . . . . . . . . . . 22
5.3. IP Fast reroute . . . . . . . . . . . . . . . . . . . . . 24 5.1. Segment Routing activation . . . . . . . . . . . . . . . 24
6. Interaction with Other YANG Modules . . . . . . . . . . . . . 24 5.2. Advertising mapping server policy . . . . . . . . . . . . 25
7. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 24 5.3. IP Fast reroute . . . . . . . . . . . . . . . . . . . . . 25
8. IS-IS Segment Routing YANG Module . . . . . . . . . . . . . . 104 6. Interaction with Other YANG Modules . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 119 7. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . . . 25
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 120 8. IS-IS Segment Routing YANG Module . . . . . . . . . . . . . . 100
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 120 9. Security Considerations . . . . . . . . . . . . . . . . . . . 114
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 120 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 115
13. Normative References . . . . . . . . . . . . . . . . . . . . 120 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 115
Appendix A. Example: NETCONF <get> Reply . . . . . . . . . . . . 121 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 13. Change log for ietf-isis-sr YANG module . . . . . . . . . . . 116
13.1. From version -09 to version -11 . . . . . . . . . . . . 116
13.2. From version -08 to version -09 . . . . . . . . . . . . 116
13.3. From version -07 to version -08 . . . . . . . . . . . . 116
14. Change log for ietf-isis YANG module . . . . . . . . . . . . 116
14.1. From version -09 to version -12 . . . . . . . . . . . . 116
14.2. From version -08 to version -09 . . . . . . . . . . . . 116
14.3. From version -07 to version -08 . . . . . . . . . . . . 116
14.4. From version -05 to version -07 . . . . . . . . . . . . 117
14.5. From version -03 to version -05 . . . . . . . . . . . . 117
14.6. From version -02 to version -03 . . . . . . . . . . . . 117
14.7. From version -01 to version -02 . . . . . . . . . . . . 117
14.8. From version -00 to version -01 . . . . . . . . . . . . 118
15. Normative References . . . . . . . . . . . . . . . . . . . . 119
Appendix A. Example of IS-IS configuration in XML . . . . . . . 120
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 122
1. Introduction 1. Introduction
This document defines a YANG data model for IS-IS routing protocol. This document defines a YANG data model for IS-IS routing 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 operational states.
1.1. Tree diagram 1.1. Tree diagram
skipping to change at page 3, line 45 skipping to change at page 4, line 8
2. Design of the Data Model 2. Design of the Data Model
The IS-IS YANG module is divided in two main "isis" containers that The IS-IS YANG module is divided in two main "isis" containers that
are augmenting the "control-plane-protocol" lists in ietf-routing are augmenting the "control-plane-protocol" lists in ietf-routing
module with specific IS-IS parameters. module with specific IS-IS parameters.
One container contains the writable parameters, while the other One container contains the writable parameters, while the other
contains the operational states. contains the operational states.
The figure below describe the overall structure of the isis YANG The figure below describes the overall structure of the isis YANG
module: module:
module: ietf-isis module: ietf-isis
augment /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route: augment /rt:routing-state/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 +--rw clns-mtu? uint16
augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol augment /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol
: :
+--rw isis +--rw isis
+--rw enable? boolean {admin-control}? +--rw enable? boolean {admin-control}?
+--rw level-type? level +--rw level-type? level
+--rw system-id? system-id +--rw system-id? system-id
+--rw maximum-area-addresses? uint8 {maximum-area-addresses}? +--rw maximum-area-addresses? uint8 {maximum-area-addresses}?
+--rw area-address* area-address +--rw area-address* area-address
+--rw mpls +--rw mpls
| +--rw ipv4-router-id? inet:ipv4-address {ipv4-router-id}? | +--rw ipv4-router-id? inet:ipv4-address {ipv4-router-id}?
| +--rw ipv6-router-id? inet:ipv6-address {ipv6-router-id}? | +--rw ipv6-router-id? inet:ipv6-address {ipv6-router-id}?
| +--rw igp-ldp-sync {igp-ldp-sync}? | +--rw igp-ldp-sync {igp-ldp-sync}?
+--rw reference-bandwidth? uint32 {reference-bandwidth}? +--rw reference-bandwidth? uint32 {reference-bandwidth}?
+--rw lsp-mtu? uint16 +--rw lsp-mtu? uint16
+--rw lsp-lifetime? uint16 +--rw lsp-lifetime? uint16
+--rw lsp-refresh? uint16 {lsp-refresh}? +--rw lsp-refresh? uint16 {lsp-refresh}?
+--rw graceful-restart {graceful-restart}? +--rw graceful-restart {graceful-restart}?
| +--rw enable? boolean | +--rw enable? boolean
+--rw node-tag {node-tag}? +--rw node-tags {node-tag}?
| +--rw node-tag* [tag] | +--rw node-tag* [tag]
| ... | ...
+--rw authentication +--rw authentication
| +--rw (authentication-type)? | +--rw (authentication-type)?
| | ... | | ...
| +--rw level-1 | +--rw level-1
| | ... | | ...
| +--rw level-2 | +--rw level-2
| ... | ...
+--rw metric-type +--rw metric-type
skipping to change at page 5, line 33 skipping to change at page 5, line 44
+--ro mpls +--ro mpls
| +--ro ipv4-router-id? inet:ipv4-address {ipv4-router-id}? | +--ro ipv4-router-id? inet:ipv4-address {ipv4-router-id}?
| +--ro ipv6-router-id? inet:ipv6-address {ipv6-router-id}? | +--ro ipv6-router-id? inet:ipv6-address {ipv6-router-id}?
| +--ro igp-ldp-sync {igp-ldp-sync}? | +--ro igp-ldp-sync {igp-ldp-sync}?
+--ro reference-bandwidth? uint32 {reference-bandwidth}? +--ro reference-bandwidth? uint32 {reference-bandwidth}?
+--ro lsp-mtu? uint16 +--ro lsp-mtu? uint16
+--ro lsp-lifetime? uint16 +--ro lsp-lifetime? uint16
+--ro lsp-refresh? uint16 {lsp-refresh}? +--ro lsp-refresh? uint16 {lsp-refresh}?
+--ro graceful-restart {graceful-restart}? +--ro graceful-restart {graceful-restart}?
| +--ro enable? boolean | +--ro enable? boolean
+--ro node-tag {node-tag}? +--ro node-tags {node-tag}?
| +--ro node-tag* [tag] | +--ro node-tag* [tag]
| ... | ...
+--ro authentication +--ro authentication
| +--ro (authentication-type)? | +--ro (authentication-type)?
| | ... | | ...
| +--ro level-1 | +--ro level-1
| | ... | | ...
| +--ro level-2 | +--ro level-2
| ... | ...
+--ro metric-type +--ro metric-type
skipping to change at page 10, line 8 skipping to change at page 10, line 18
2.1. IS-IS Configuration 2.1. IS-IS Configuration
The IS-IS configuration container is divided in: The IS-IS configuration container is divided in:
o Global parameters. o Global parameters.
o Per interface configuration (see Section 2.4). o Per interface configuration (see Section 2.4).
It would to up to extension modules to augment this model to support It would to up to extension modules to augment this model to support
vendor specific parameters. any additional parameter.
The model implements features, so 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 advises the client
that it supports the ability to shutdown a particular IS-IS instance.
The global configuration contains usual IS-IS parameters such as lsp-
mtu, lsp-lifetime, lsp-refresh, default-metric ... Within the global
configuration, a client can also activate one or more address-
families (IPv4, IPv6) through the "afs" container.
2.2. Multitopology Parameters 2.2. Multitopology Parameters
The "topologies" list is used to enable support of MT extensions for The model supports multitopology (MT) IS-IS as defined in [RFC5120].
specific address families.
Each topology should refer to an existing RIB. The "multi-topology" container is used to enable support of MT
extensions.
The "name" used in the topology list should refer to an existing RIB
of the device.
Some specific parameters could be defined for a specific topology at Some specific parameters could be defined for a specific topology at
global level and also at interface level. global level and also at interface level: for example, interface
metric can be defined per topology.
2.3. Per-Level Parameters 2.3. Per-Level Parameters
Some parameters support per level configuration. In this case, the Some parameters support per level configuration. In this case, the
parameter is built as a container with three levels of configuration parameter is built as a container with three configuration locations:
:
o top level : corresponds to level-1-2, so the configuration applies o top level container: corresponds to level-1-2, so the
to both levels. configuration applies to both levels.
o level-1 : corresponds to level-1 specific parameter. o level-1 container: corresponds to level-1 specific parameters.
o level-2 : corresponds to level-2 specific parameter. o 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 :
skipping to change at page 11, line 11 skipping to change at page 11, line 34
<value>200</value> <value>200</value>
</level-2> </level-2>
</priority> </priority>
An implementation SHOULD prefer a level specific parameter over An implementation SHOULD prefer a level specific parameter over
level-all parameter. As example, if priority is 100 for level-1, 200 level-all parameter. As example, if priority is 100 for level-1, 200
for level-2 and 250 for top level configuration, the implementation for level-2 and 250 for top level configuration, the implementation
should use 100 for level-1 and 200 for level-2. should use 100 for level-1 and 200 for level-2.
Some parameters like overload bit and route preference are not Some parameters like overload bit and route preference are not
modelled for per level configuration. If an implementation supports modeled for per level configuration. If an implementation supports
per level configuration for such parameter, the implementation SHOULD per level configuration for such parameter, the implementation SHOULD
augment the current model by adding level-1 and level-2 containers augment the current model by adding level-1 and level-2 containers
and reusing existing configuration groupings. and SHOULD reuse existing configuration 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";
} }
skipping to change at page 12, line 18 skipping to change at page 12, line 51
interface specific parameters. interface specific parameters.
The interface is a reference to an interface in the Interface YANG The interface is a reference to an interface in the Interface YANG
model. model.
Each interface has interface-specific parameters that may have a Each interface has interface-specific parameters that may have a
different value per level as described in previous section. An different value per level as described in previous section. An
interface-specific parameter always override an IS-IS global interface-specific parameter always override an IS-IS global
parameter . parameter .
Some parameters like hello-padding are defined as containers to Some parameters like hello-padding are defined as containers to allow
permit easy extension by vendor specific modules. 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 level-type? level +--rw level-type? level
+--rw lsp-pacing-interval? uint16 +--rw lsp-pacing-interval? uint16
+--rw lsp-retransmit-interval? uint16 +--rw lsp-retransmit-interval? uint16
+--rw passive? boolean +--rw passive? boolean
+--rw csnp-interval? uint16 +--rw csnp-interval? uint16
+--rw hello-padding +--rw hello-padding
skipping to change at page 15, line 30 skipping to change at page 16, line 14
| +--rw enable? boolean | +--rw enable? boolean
| +--rw remote-lfa {remote-lfa}? | +--rw remote-lfa {remote-lfa}?
| +--rw enable? boolean | +--rw enable? boolean
+--rw metric +--rw metric
+--rw value? wide-metric +--rw value? wide-metric
+--rw level-1 +--rw level-1
| +--rw value? wide-metric | +--rw value? wide-metric
+--rw level-2 +--rw level-2
+--rw value? wide-metric +--rw value? wide-metric
2.5. ISO parameters 2.5. Authentication Parameters
Some ISO parameters may be required. The module enables authentication configuration through the IETF key-
chain module ([I-D.ietf-rtgwg-yang-key-chain]). The IS-IS module
imports the "ietf-key-chain" module and reuses some groupings to
allow global and per interface authentication configuration. If
global authentication is configured, an implementation SHOULD
authenticate PSNP, CSNP and LSPs with the authentication parameters
supplied. On a per interface basis, the authentication of hello PDUs
can be activated.
2.6. IGP/LDP synchronization
[RFC5443] defines a mechanism where IGP needs to be synchronized with
LDP. An "igp-ldp-sync" feature has been defined in the model to
support this mechanism. The "mpls/igp-ldp-sync" container under
"interface" allows activation of the mechanism on a per interface
basis. The "mpls/igp-ldp-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.
2.7. ISO parameters
As IS-IS protocol is based on ISO protocol suite, some ISO parameters
may be required.
This module augments interface configuration model to support ISO This module augments interface configuration model to support ISO
configuration parameters. configuration parameters.
The clns-mtu can be defined under the interface. The clns-mtu can be defined under the interface.
2.6. IP FRR 2.8. IP FRR
This YANG model supports LFA and remote LFA as IP FRR techniques. This YANG model supports LFA ([RFC5286]) and remote LFA ([RFC7490])
The "fast-reroute" container may be augmented by other models to as IP FRR techniques. The "fast-reroute" container may be augmented
support other IPFRR flavors (MRT ...). by other models to support other IPFRR flavors (MRT, TILFA ...).
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 interface only. The global "lfa" container is present
but kept empty to permit augmentation with vendor specific properties but kept empty to allow augmentation with vendor specific properties
like policies. like policies.
Remote LFA is considered as a child of LFA. Remote LFA cannot be Remote LFA is considered as a child of LFA. Remote LFA cannot be
enabled if LFA is not enabled. enabled if LFA is not enabled.
The "candidate-disabled" permit to mark an interface to not be used The "candidate-disabled" allows to mark an interface to not be used
as a backup. as a backup.
2.7. Operational State 2.9. Operational State
"isis" container provides operational states for IS-IS. This A "isis" container provides operational states for IS-IS. This
container is divided in multiple components: container is divided in multiple components:
o system-counters : provides statistical informations about the o system-counters : provides statistical informations about the
global system. global system.
o interface : provides configuration state information for each o interface : provides configuration state information for each
interface. interface.
o adjacencies: provides state information about current IS-IS o adjacencies: provides state information about current IS-IS
adjacencies. adjacencies.
skipping to change at page 23, line 47 skipping to change at page 24, line 47
| +--ro address? string | +--ro address? string
+--ro unnumbered-interface-id-ero +--ro unnumbered-interface-id-ero
| +--ro router-id? string | +--ro router-id? string
| +--ro interface-id? uint32 | +--ro interface-id? uint32
+--ro backup-unnumbered-interface-id-ero +--ro backup-unnumbered-interface-id-ero
+--ro router-id? string +--ro router-id? string
+--ro interface-id? uint32 +--ro interface-id? uint32
5.1. Segment Routing activation 5.1. Segment Routing activation
Activation of segment-routing IS-IS is done by setting the "enabled" Activation of segment-routing IS-IS is done by setting the "enable"
leaf to true. This triggers advertisement of segment-routing leaf to true. This triggers advertisement of segment-routing
extensions based on the configuration parameters that have been setup extensions based on the configuration parameters that have been setup
using the base segment routing module. using the base segment routing module.
5.2. Advertising mapping server policy 5.2. Advertising mapping server policy
The base segment routing module defines mapping server policies. By The base segment routing module defines mapping server policies. By
default, IS-IS will not advertise nor receive any mapping server default, IS-IS will not advertise nor receive any mapping server
entry. The IS-IS segment-routing module permits to advertise one or entry. The IS-IS segment-routing module allows to advertise one or
multiple mapping server policies through the "bindings/advertise/ multiple mapping server policies through the "bindings/advertise/
policies" leaf-list. The "bindings/receive" leaf permits to enable policies" leaf-list. The "bindings/receive" leaf allows to enable
the reception of mapping server entries. the reception of mapping server entries.
5.3. IP Fast reroute 5.3. IP Fast reroute
IS-IS SR model augments the fast-reroute container under interface. IS-IS SR model augments the fast-reroute container under interface.
It brings the ability to activate TI-LFA (topology independent LFA) It brings the ability to activate TI-LFA (topology independent LFA)
and also enhances remote LFA to use segment-routing tunneling instead and also enhances remote LFA to use segment-routing tunneling instead
of LDP. of LDP.
6. Interaction with Other YANG Modules 6. Interaction with Other YANG Modules
skipping to change at page 24, line 46 skipping to change at page 25, line 46
Some IS-IS specific routes attributes are added to route objects of Some IS-IS specific routes attributes are added to route objects of
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 use some groupings from ietf-
keychain [I-D.ietf-rtgwg-yang-key-chain] and ietf-segment routing keychain [I-D.ietf-rtgwg-yang-key-chain] and ietf-segment routing
[I-D.ietf-spring-sr-yang]. [I-D.ietf-spring-sr-yang].
7. IS-IS YANG Module 7. IS-IS YANG Module
<CODE BEGINS> file "ietf-isis@2016-09-21.yang" <CODE BEGINS> file "ietf-isis@2016-10-17.yang"
module ietf-isis { module ietf-isis {
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";
} }
import ietf-inet-types { import ietf-inet-types {
skipping to change at page 26, line 11 skipping to change at page 27, line 11
&lt;mailto:yiqu@cisco.com&gt; &lt;mailto:yiqu@cisco.com&gt;
Jeff Tantsura Jeff Tantsura
&lt;mailto:jeff.tantsura@ericsson.com&gt; &lt;mailto:jeff.tantsura@ericsson.com&gt;
"; ";
description description
"The YANG module defines a generic configuration model for "The YANG module defines a generic configuration model for
ISIS common across all of the vendor implementations."; ISIS common across all of the vendor implementations.";
revision 2016-09-21 { revision 2016-10-17 {
description
"
Draft refresh
";
reference "draft-ietf-isis-yang-isis-cfg-11";
}
revision 2016-09-20 {
description
"
Align to draft-ietf-netmod-routing-cfg-23.
";
reference "draft-ietf-isis-yang-isis-cfg-09";
}
revision 2016-05-30 {
description
"
Added container before af list
Added container before topology list
Aligned LFA if per level cfg
";
reference "";
}
revision 2016-03-21 {
description
"
- remove routing-instance as per core routing model v21
- added BFD leaf (no more BFD protocol model)
- changed keychain module reference
";
reference "draft-ietf-isis-yang-isis-cfg-08";
}
revision 2015-12-17 {
description
"Moved lists to containers+groupings for per level
configuration.";
reference "";
}
revision 2015-11-25 {
description
"
* Remove selector from system-id type
* Added some defaults
";
reference "";
}
revision 2015-11-18 {
description description
" "Initial revision.";
* Move Overload config from list to container reference "draft-ietf-isis-yang-isis-cfg-12";
* Move Overload-max-metric config from list to container
* Move preference config from list to container
* Add Node flag in config
* Removed BFD config => moved to isis-bfd module
* Remove call to routing policy model
(waiting stabilization to add it)
";
reference "draft-ietf-isis-yang-isis-cfg-07";
} }
revision 2015-09-10 {
description
" * Correct invalid references to previous
versions core routing model.
* Moved BFD config to usage of ietf-bfd yang grouping
* Adding routing-policy support through routing-policy model
";
reference "draft-ietf-isis-yang-isis-05";
}
revision 2015-06-22 {
description
" * Segment routing is part os a separate module.";
reference "draft-ietf-isis-yang-isis-03";
}
revision 2015-03-03 {
description
" * Reviewed config and op state groupings.
* Add default value to lfa candidate-disabled
* Add enable leaf to isis container to reflect admin state
* Move to VRF centric only
";
reference "";
}
revision 2015-03-03 {
description
"
* Defining hierarchy for operational states
* Adding CLNS MTU
* Adding Keychain
";
reference "draft-ietf-isis-yang-isis-02";
}
revision 2015-02-20 {
description
"
* Removing igp-ldp-sync timer in IS-IS
";
reference "";
}
revision 2014-12-15 {
description
"
* Adding IPFRR
* Adding igp-ldp sync
* Adding segment routing
* Adding instance reference to operational states.
* Move AF type from string to identity
* Updated router-capability in LSDB description.
* packet counters moved to interface-packet-counters.
* Added modification information in lsp-log
";
reference "";
}
revision 2014-10-24 {
description
"
* Change hello-padding to container
* Change bfd to container
* Make BFD a feature
* Creates mpls-te container and put router-id
inside
* Remove GR helper disable and timers
";
reference "draft-ietf-isis-yang-isis-cfg-01";
}
revision 2014-10-21 {
description
"
* Interface metric move from af container to interface
container
* Hello-padding on interface moved to hello-padding-disable
with empty type
* three-way-handshake removed
* route preference changed to a choice
* csnp-authentication/psnp-authentication merged
to authentication container
* lsp-gen-interval-exp-delay removed
* Added overload-max-metric feature
* overload-max-metric is in a separate container
";
reference "";
}
revision 2014-10-07 {
description
"
* Removed spf parameters (should be part of
vendor specific extensions.
* Removed hello parameters at global level.
* Interface configuration uses a string rather
than a reference. This permits to map to some
vendor specific configuration.
";
reference "draft-ietf-isis-yang-isis-00";
}
revision 2014-09-26 {
description
"
* Add BFD support
* remove max-elements to max-area-addresses
";
reference "";
}
revision 2014-09-11 {
description
"
* Add level parameter to ispf and spf delay
* Add LSP generation as a feature
* Make lsp-refresh a feature
* Change parameter container to list
";
reference "";
}
revision 2014-09-05 {
description
" Rewrite of the global hierarchy.";
reference "";
}
revision 2014-08-06 {
description
"
* isis-state renamed to isis.
* Add GR support
* Add meshgroup support
* Add CLNS support
* Add 64bits tags
* Add notifications to be aligned with MIB4444
* Add packet-counters, interface-counters, system-counters
states
* Add 3-way handshake support
* Rename isis-adjacency-updown to adjacency-change
* Add notification for LSP reception
* Use feature for reference BW
* Add lsp-retransmit-interval on interfaces
* Rename lsp-interval to lsp-pacing-interval
* Add ispf support as feature
* Add spf delay support as feature (2step & exp backoff)
* Add maximum-area-addresses
* Add default-metric
";
reference "RFC XXXX: YANG Data Model for ISIS Protocol";
}
revision 2014-06-25 {
description "
* isis-cfg renamed to isis.
* Add precisions on authentication-keys in description
";
reference "draft-litkowski-isis-yang-isis-01";
}
revision 2014-06-20 {
description "
* isis-op renamed to isis-state.
* Multiple instances under ISIS are removed.
* interface-cfg grouping removed and content
is directly included in container isis.
* TLVxx renamed with human-readable name in isis-database.
TLV reference are putted in description.
* Reference to core routing module were fixed.
* Namespace fixed.
* Add simple-iso-address type.
* area-id and system-id in ISIS container are merged to
nsap-address.
* Add isis-system-id type.
* Add isis-lsp-id type.
* Add remaining-lifetime leaf in isis-database.
* Add TLV2 (is-neighbor) in isis-database.
* Renamed some container name for consistency
reason ('isis-' prefixed).
* Add new identities isis-cfg and isis-state.
* Add descriptions.
* Add notification isis-adjacency-updown.
* Add RPC clear-isis-adjacency and clear-isis-database. /* Identities */
";
reference "draft-litkowski-isis-yang-isis-00";
}
revision 2014-06-11 {
description "Initial revision.";
reference "draft-litkowski-netmod-isis-cfg-00";
}
identity isis { identity isis {
base rt:routing-protocol; base rt:routing-protocol;
description "Identity for the ISIS routing protocol."; description "Identity for the ISIS routing protocol.";
} }
identity isis-adjacency-change { identity isis-adjacency-change {
description "Identity for the ISIS routing protocol description "Identity for the ISIS routing protocol
adjacency state."; adjacency state.";
} }
skipping to change at page 60, line 51 skipping to change at page 57, line 4
"This leaf describes the capability of the node. "This leaf describes the capability of the node.
Format is binary according to the protocol encoding."; Format is binary according to the protocol encoding.";
} }
description description
"This container describes the capabilities of the node. "This container describes the capabilities of the node.
This container may be extended with detailed This container may be extended with detailed
information. information.
ISIS reference is TLV 242."; ISIS reference is TLV 242.";
} }
} }
grouping isis-node-tag-cfg { grouping isis-node-tag-cfg {
description description
"ISIS node tag config."; "ISIS node tag config.";
container node-tag { container node-tags {
if-feature node-tag; if-feature node-tag;
list node-tag { list node-tag {
key tag; key tag;
leaf tag { leaf tag {
type uint32; type uint32;
description description
"Node tag value."; "Node tag value.";
} }
description description
"List of tags."; "List of tags.";
skipping to change at page 104, line 7 skipping to change at page 100, line 11
The notification generation must be throttled with at least The notification generation must be throttled with at least
a 5 second gap. "; a 5 second gap. ";
} }
} }
<CODE ENDS> <CODE ENDS>
8. IS-IS Segment Routing YANG Module 8. IS-IS Segment Routing YANG Module
<CODE BEGINS> file "ietf-isis-sr@2016-09-21.yang" <CODE BEGINS> file "ietf-isis-sr@2016-10-17.yang"
module ietf-isis-sr { module ietf-isis-sr {
namespace "urn:ietf:params:xml:ns:" namespace "urn:ietf:params:xml:ns:"
+ "yang:ietf-isis-sr"; + "yang:ietf-isis-sr";
prefix isis-sr; prefix isis-sr;
import ietf-routing { import ietf-routing {
prefix "rt"; prefix "rt";
} }
skipping to change at page 105, line 5 skipping to change at page 101, line 10
Jeff Tantsura Jeff Tantsura
&lt;mailto:jeff.tantsura@ericsson.com&gt; &lt;mailto:jeff.tantsura@ericsson.com&gt;
"; ";
description description
"The YANG module defines a generic configuration model for "The YANG module defines a generic configuration model for
Segment routing ISIS extensions common across all of the vendor Segment routing ISIS extensions common across all of the vendor
implementations."; implementations.";
revision 2016-09-21 { revision 2016-10-17 {
description
"Fixed XPATH in 'when' expression";
reference "draft-ietf-isis-yang-isis-cfg-11";
}
revision 2016-09-20 {
description
"
Align to draft-ietf-netmod-routing-cfg-23.
";
reference "draft-ietf-isis-yang-isis-cfg-09";
}
revision 2016-03-21 {
description "
* Removed routing-instance in path as per
core routing model v21
";
reference "";
}
revision 2015-09-18 {
description "no modif";
reference "";
}
revision 2015-07-02 {
description description
" "Initial revision.";
* Add TILFA and rLFA SR reference "draft-ietf-isis-yang-isis-cfg-12";
* Add container to SRGB
";
reference "";
}
revision 2015-05-27 {
description "
* Initialization
";
reference "";
} }
/* Identities */ /* Identities */
/* Features */ /* Features */
feature remote-lfa-sr { feature remote-lfa-sr {
description description
"Enhance rLFA to use SR path."; "Enhance rLFA to use SR path.";
} }
skipping to change at page 119, line 4 skipping to change at page 114, line 17
when "/rt:routing-state/rt:control-plane-protocols/"+ when "/rt:routing-state/rt:control-plane-protocols/"+
"rt:control-plane-protocol/rt:type = 'isis:isis'" { "rt:control-plane-protocol/rt:type = 'isis:isis'" {
description description
"This augment ISIS routing protocol when used"; "This augment ISIS routing protocol when used";
} }
description description
"This augments ISIS protocol LSDB."; "This augments ISIS protocol LSDB.";
uses segment-routing-binding-tlv; uses segment-routing-binding-tlv;
} }
/* Notifications */ /* Notifications */
} }
<CODE ENDS> <CODE ENDS>
9. Security Considerations 9. Security Considerations
Configuration and state data defined in this document are designed to Configuration and state data defined in this document are designed to
be accessed via the NETCONF protocol [RFC6241]. be accessed via the NETCONF protocol [RFC6241].
As IS-IS is an IGP protocol (critical piece of the network), ensuring As IS-IS is an IGP protocol (critical piece of the network), ensuring
stability and security of the protocol is mandatory for the network stability and security of the protocol is mandatory for the network
service. service.
Authors recommends to implement NETCONF access control model Authors recommends to implement NETCONF access control model
([RFC6536]) to restrict access to all or part of the configuration to ([RFC6536]) to restrict access to all or part of the configuration to
specific users. Access control to RPCs is also critical as RPC specific users. Access control to RPCs is also critical as RPC
permits to clear protocol datastructures that would definitively allows to clear protocol datastructures that would definitively
impact the network service. This kind of RPC needs only to be used impact the network service. This kind of RPC needs only to be used
in specific cases by well-known experienced users. in specific cases by well-known experienced users.
Authors consider that all the configuration is considered as Authors consider that all the configuration is considered as
sensitive/vulnerable as well as RPCs. But security teams can decide sensitive/vulnerable as well as RPCs. But security teams can decide
to open some part of the configuration to less experienced users to open some part of the configuration to less experienced users
depending on the internal organization, for example: depending on the internal organization, for example:
o User FullWrite: would access to the whole data model. This kind o User FullWrite: would access to the whole data model. This kind
of profile may be restricted to few experienced people. of profile may be restricted to few experienced people.
skipping to change at page 119, line 48 skipping to change at page 115, line 16
o User Read: would only access to state part /isis-state. o User Read: would only access to state part /isis-state.
Unauthorized access to configuration or RPC may cause high damages to Unauthorized access to configuration or RPC may cause high damages to
the network service. the network service.
The /isis-state/database may contain authentication information. As The /isis-state/database may contain authentication information. As
presented in the description of the /isis-state/database/level- presented in the description of the /isis-state/database/level-
1/lsp/authentication/authentication-key, the authentication MUST 1/lsp/authentication/authentication-key, the authentication MUST
never be presented in plaintext format for security reason. Authors never be presented in plaintext format for security reason. Authors
recommends the usage of MD5 to present the authentication-key. recommend the usage of MD5 to display or return the authentication-
key.
Some authentication-key may also be present in the /isis Some authentication-key may also be present in the /isis
configuration. When configuring IS-IS using the NETCONF protocol, configuration. When configuring IS-IS using the NETCONF protocol,
authors recommends the usage of secure transport of NETCONF using SSH authors recommends the usage of secure transport of NETCONF using SSH
([RFC6242]). ([RFC6242]).
10. Contributors 10. Contributors
Authors would like to thank Kiran Agrahara Sreenivasa, Dean Authors would like to thank Kiran Agrahara Sreenivasa, Dean
Bogdanovic, Yingzhen Qu, Yi Yang for their major contributions to the Bogdanovic, Yingzhen Qu, Yi Yang for their major contributions to the
skipping to change at page 120, line 46 skipping to change at page 116, line 15
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
name: ietf-isis-sr name: ietf-isis-sr
namespace: urn:ietf:params:xml:ns:yang:ietf-isis-sr namespace: urn:ietf:params:xml:ns:yang:ietf-isis-sr
prefix: isis-sr prefix: isis-sr
reference: RFC XXXX reference: RFC XXXX
13. Normative References 13. Change log for ietf-isis-sr YANG module
13.1. From version -09 to version -11
o Fixed XPATH in 'when' expressions.
13.2. From version -08 to version -09
o Align to draft-ietf-netmod-routing-cfg-23.
13.3. From version -07 to version -08
o Align to draft-ietf-netmod-routing-cfg-21.
14. Change log for ietf-isis YANG module
14.1. From version -09 to version -12
o Rename node-tag container to node-tags.
14.2. From version -08 to version -09
o Added container before af list.
o Added container before topology list.
o Aligned LFA if per level cfg.
o Align to draft-ietf-netmod-routing-cfg-23.
14.3. From version -07 to version -08
o Remove selector from system-id type.
o Add some default values.
o Moved lists to containers+groupings for per level configuration.
o remove routing-instance as per core routing model v21.
o added BFD leaf (no more BFD protocol model).
o changed keychain module reference.
14.4. From version -05 to version -07
o Move Overload config from list to container.
o Move Overload-max-metric config from list to container.
o Move preference config from list to container.
o Add Node flag in config.
o Removed BFD config => moved to isis-bfd module.
o Remove call to routing policy model.
14.5. From version -03 to version -05
o Correct invalid references to previous versions of core routing
model.
o Remove BFD config and replace by groupings from ietf-bfd.
o Adding routing-policy support through routing-policy model.
14.6. From version -02 to version -03
o Reviewed config and op state groupings.
o Add default value to lfa candidate-disabled.
o Add enable leaf to isis container to reflect admin state.
o Move to VRF centric only.
o Segment routing is part os a separate module.
14.7. From version -01 to version -02
o Adding IPFRR.
o Adding igp-ldp-sync.
o Adding segment-routing.
o Adding instance reference to operational states.
o Move AF type from string to identity.
o Updated router-capability in LSDB description.
o packet counters moved to interface-packet-counters.
o Added modification information in lsp-log.
o Removing igp-ldp-sync timer in IS-IS.
o Defining hierarchy for operational states.
o Adding clns-mtu.
o Adding key-chain.
14.8. From version -00 to version -01
o Interface metric move from af container to interface container.
o Hello-padding on interface moved to hello-padding-disable with
empty type.
o three-way-handshake removed.
o route preference changed to a choice.
o csnp-authentication/psnp-authentication merged to authentication
container.
o lsp-gen-interval-exp-delay removed.
o Added overload-max-metric feature.
o overload-max-metric is in a separate container.
o Change hello-padding to container.
o Change bfd to container.
o Make BFD a feature.
o Create mpls-te container and put router-id inside.
o Remove GR helper disable and timers.
15. Normative References
[I-D.ietf-netmod-routing-cfg] [I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-23 (work in Management", draft-ietf-netmod-routing-cfg-23 (work in
progress), August 2016. progress), August 2016.
[I-D.ietf-rtgwg-yang-key-chain] [I-D.ietf-rtgwg-yang-key-chain]
Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, Z., and Y. Lindem, A., Qu, Y., Yeung, D., Chen, I., Zhang, Z., and Y.
Yang, "Routing Key Chain YANG Data Model", draft-ietf- Yang, "Routing Key Chain YANG Data Model", draft-ietf-
rtgwg-yang-key-chain-09 (work in progress), September rtgwg-yang-key-chain-09 (work in progress), September
skipping to change at page 121, line 25 skipping to change at page 119, line 32
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/
RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI
10.17487/RFC5286, September 2008,
<http://www.rfc-editor.org/info/rfc5286>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
2009, <http://www.rfc-editor.org/info/rfc5443>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<http://www.rfc-editor.org/info/rfc5880>. <http://www.rfc-editor.org/info/rfc5880>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
skipping to change at page 121, line 48 skipping to change at page 120, line 24
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<http://www.rfc-editor.org/info/rfc6242>. <http://www.rfc-editor.org/info/rfc6242>.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, DOI Protocol (NETCONF) Access Control Model", RFC 6536, DOI
10.17487/RFC6536, March 2012, 10.17487/RFC6536, March 2012,
<http://www.rfc-editor.org/info/rfc6536>. <http://www.rfc-editor.org/info/rfc6536>.
Appendix A. Example: NETCONF <get> Reply [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<http://www.rfc-editor.org/info/rfc7490>.
This section gives an example of a reply to the NETCONF <get> request Appendix A. Example of IS-IS configuration in XML
for a device that implements the data model defined in this document.
The example is written in XML. This section gives an example of configuration of an IS-IS instance
on a device. The example is written in XML.
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing"> <routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
<name>SLI</name> <name>SLI</name>
<router-id>1.1.1.1</router-id> <router-id>1.1.1.1</router-id>
<description/> <description/>
<interfaces> <interfaces>
<interface> <interface>
<name>Loopback0</name> <name>Loopback0</name>
 End of changes. 50 change blocks. 
345 lines changed or deleted 280 lines changed or added

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