Network Working Group N. Wu Internet-Draft L. Wang Intended status: Standards Track S. Hares Expires: March 14, 2015 Huawei September 10, 2014 Information model for IS-IS protocol draft-wu-i2rs-isis-info-model-00 Abstract IS-IS is a widely deployed link-state protocol in routing networks. During the past decades, it has been operated and maintained through typical CLI, SNMP and NETCONF. With the expansion and complication of modern networks, the necessity for rapid and dynamic control has been increased. The I2RS is a standard-based interface which provides a programmatic way to achieve this goal. This document specifies an information model for the IS-IS protocol to facilitate the definition of a standardized data model, which can be used to define interfaces to the IS-IS from an entity that may even be external to the routing system. Based on standardized data model and interfaces, use cases of IGP protocols defined by I2RS-WG can be supported. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 http://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 14, 2015. Wu, et al. Expires March 14, 2015 [Page 1] Internet-Draft IS-IS information model September 2014 Copyright Notice Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IS-IS data . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. IS-IS instance . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. I2RS Requirements Fulfilled by this Informational Model . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2. Instance parameters . . . . . . . . . . . . . . . . . 6 2.1.3. Multi-topology list(multi-topo*) . . . . . . . . . . 7 2.2. IS-IS multi-topology . . . . . . . . . . . . . . . . . . 8 2.2.1. Level list (level*) . . . . . . . . . . . . . . . . . 9 2.2.2. IS-IS MT RIB route . . . . . . . . . . . . . . . . . 9 2.2.3. Circuit list (circuit*) . . . . . . . . . . . . . . . 11 2.2.4. Policy list (policy*) . . . . . . . . . . . . . . . . 11 2.3. IS-IS level . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.1. Level I2RS YANG description . . . . . . . . . . . . . 11 2.3.2. Level parameters . . . . . . . . . . . . . . . . . . 12 2.3.3. Link State database . . . . . . . . . . . . . . . . . 12 2.3.4. Link State PDU . . . . . . . . . . . . . . . . . . . 12 2.4. IS-IS circuit . . . . . . . . . . . . . . . . . . . . . . 14 2.4.1. Circuit parameters . . . . . . . . . . . . . . . . . 16 2.4.2. Circuit traffic engineering . . . . . . . . . . . . . 16 2.4.3. Circuit neighbor . . . . . . . . . . . . . . . . . . 17 3. IS-IS notification . . . . . . . . . . . . . . . . . . . . . 17 3.1. Adjacency . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. Protocol statistics . . . . . . . . . . . . . . . . . . . 18 4. IS-IS I2RS Operational Examples . . . . . . . . . . . . . . . 18 4.1. Transient loop avoidance . . . . . . . . . . . . . . . . 18 4.2. Traffic blackhole prevention . . . . . . . . . . . . . . 19 5. IS-IS grammar . . . . . . . . . . . . . . . . . . . . . . . . 19 Wu, et al. Expires March 14, 2015 [Page 2] Internet-Draft IS-IS information model September 2014 5.1. Instance . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Multi-topology . . . . . . . . . . . . . . . . . . . . . 20 5.3. Level . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Circuit . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. I2RS YANG model of IS-IS . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 31 10.2. Informative References . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 1. Introduction IS-IS[ISO.10589.1992] is a widely deployed link-state protocol in routing networks. During the past decades, it has been operated and maintained through typical CLI, SNMP and NETCONF. With the expansion and complication of modern networks, the necessity for rapid and dynamic control has been increased. The I2RS[I-D.ietf-i2rs-architecture] is a standard-based interface which provides a programmatic way to achieve this goal. This document specifies an information model for the IS-IS protocol to facilitate the definition of a standardized data model, which can be used to define interfaces to the IS-IS from an entity that may even be external to the routing system. Based on standardized data model and interfaces, use cases of IGP protocols defined by [I-D.hares-i2rs-usecase-reqs-summary] can be supported. In order to support large intra-domain, IS-IS has been organized hierarchically into areas. Routing within an area is referred to as Level 1 routing while routing between areas is referred to as Level 2 routing. Each IS-IS routing system advertises and collects link- state information independently then makes decision in the distributed manner. The outcome of this decision is used to populate Routing Information Base (RIB) since IS-IS can be one of the clients of RIB as stated in [I-D.ietf-i2rs-rib-info-model]. 2. IS-IS data This section describes the data involved in the IS-IS information model in detail. IS-IS data includes information related to IS-IS instance, IS-IS level, IS-IS multi-topology, IS-IS circuits, IS-IS adjacencies and IS-IS routes. A high-level architecture of the IS-IS contents is shown as below. Wu, et al. Expires March 14, 2015 [Page 3] Internet-Draft IS-IS information model September 2014 IS-IS routing-protocol |0..N | IS-IS instance |1..N | Multi-topology | | +--------------------------+----------+----------+ |1..2 | |0..N |0..N | | | | Level MT-RIB Policy Circuit | | | | |0..N | LSDB Route +-----+--------+ |1..N | | |0..N |0..N | | | | | LSP +-------+------+ TE L1-NBR L2-NBR | | |1..N |0..1 | | | | | | |1..N |1..N +---------------+-------+ Prefix Nexthop Backup MT MT |0..N |0..N |0..N |3..N nexthop | | | | IS IPv4 IPv6 Area reach prefix prefix address | | | |1..N |1..N |1..N MT MT MT Figure 1: Architecture of IS-IS information model 2.1. IS-IS instance In the context of IS-IS information model, instance behaves like an independent virtual IS-IS routing system which contains the instance parameters and the multi-topology list. Multiple instances MAY be supported on one network device. The corresponding YANG description of the top level and instances is below. Wu, et al. Expires March 14, 2015 [Page 4] Internet-Draft IS-IS information model September 2014 module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] +--rw name string +--rw isis-vpn-name? string +--rw address-family address-family-def +--rw net* [area-id] | +--rw area-id string | +--rw system-id? string +--ro protocol-status? enumeration +--rw level-type? enumeration +--rw metric-style? enumeration +--rw lsp-mtu? uint32 +--rw lsp-refresh? uint32 +--rw lsp-lifetime? uint32 +--ro isis-instance-create-mode? enumeration +--rw preference? uint32 +--rw hostname? string +--rw domain-auth-info ... +--rw area-auth-info ... +--rw multi-topo-list* [mt-id] ... Figure 2 YANG model of IS-IS instance 2.1.1. I2RS Requirements Fulfilled by this Informational Model The following IGP requirements of I2RS Requirements Summary [I-D.hares-i2rs-usecase-reqs-summary] are fulfilled by this document: [IGP-REQ-01], [IGP-REQ-03], [IGP-REQ-04], [IGP-REQ-05], [IGP-REQ-06], [IGP-REQ-07], and [IGP-REQ-08]. This version of the ISIS IM only supports the monitoring of ISIS static and dynamic data within these requirements. Later versions will include the configuration requirements. The restatement of these requirements for ISIS for just monitoring is included below: o [IGP-REQ-01]: I2RS Client/Agent SHOULD be able to read/write the unique ISIS identification for IS within an AS (router-id, system- id, or others). I2RS agents may send a notification if another IS the detection of another router with the same unique ID. o [IGP-REQ-03]: I2RS client should be able to aid in IGP table reduction by actively monitoring ISIS tables for Level information L1 only, L1/L2 routers, L1/L2/external routers, and L2 external routers. The I2RS Client/Agent must allow for rapid cycle of querying ISIS topology information. Wu, et al. Expires March 14, 2015 [Page 5] Internet-Draft IS-IS information model September 2014 o [IGP-REQ-04]: The I2RS programmatic interface should allow the balancing of both ECMP traffic and end-to-end traffic flows in the IGP. The I2RS agent should support monitoring circuits under ISIS control, traffic engineering (TE) parameters, LSDBs, and maximum capacities (circuits, LSDB, and nodes), plus policy control ISIS traffic via query or notification mechanisms. o [IGP-REQ-05]: The I2RS interface (protocol and data models) should use the subscription service to filter the topology changes to the interested events and use the publish mechanism to control the pace these events are notified. This filtering should protect the client or applications who depend on topology data from being drowned by massive original events or duplicate events from different sources. o [IGP-REQ-06]: Since an IGP protocol is essential to the whole network, the I2RS Clients SHOULD monitor the protocol's running status before forwarding is impacted. Performance data can be collected by collecting static configuration and dynamic status. Static configuration includes the number of instances configured to run a protocol, the number of interfaces configured, the circuits configured the number if ISIS neighbors configured, and others. The dynamic state includes: actual number of instances running a protocol, number of multi-topology instances, and all data related to a MT instance (each level's LSDB, TE DB, MT-RIBs, Policy, and circuits). o [IGP-REQ-07]: The I2RS interface [protocol and IMs] should support a mechanism where the I2RS clients can subscribe to the I2RS agent's notification. ISIS critical events include: LSDB overflow, routing table overflow, circuit down or circuit's interface down. o [IGP-REQ-08]: The I2RS interface [protocol and IMs] shuld support the reporting of the ISIS statistics such as dropped packet statistics, LSDB overflows, circuit down, (Eric-Lixing - please add in others you want covered here.) 2.1.2. Instance parameters o name: A name uniquely identifying IS-IS instance across all of those supported on one network device. o isis-vpn-name: The name of the VPN instance which this instance is binded to. o address-family: The address family of this instance. Valid input MAY be IPv4, IPv6 or Both. Wu, et al. Expires March 14, 2015 [Page 6] Internet-Draft IS-IS information model September 2014 o net list (net*): The list of NET or NSAP-address which is used to identify the network device among interaction with other network devices. Each NET MUST be unique among the routing network. o protocol-status: The status of current instance. Valid status could include Active, Shutdown, Overload, Reset and etc. o level-type: The level type designated for current instance. Valid input could be Level-1-Only, Level-2-Only or Level-1-2-Both. o metric-style: The metric style of current process used to express metric according to different TLV. Valid input could be Narrow or Wide or Compatible. o lsp-mtu: The maximum size of LSP for current instance. Range from 512 to 16384 bytes with as 1497 as the default value. o lsp-refresh: The refresh interval of LSP for current instance. Range from 1 to 65534 bytes with as 900 as the default value. o lsp-lifetime: The refresh interval of LSP for current instance. Range from 2 to 65535 bytes with as 1200 as the default value. o isis-instance-create-mode: The mode used to create IS-IS instance through I2RS Agent. o preference: The IS-IS route preference for current instance. o hostname: The symbolic name used to represent current instance, which would be more preferable for human eyes. o area-auth-info: The information related to level-1 authentication, including password, authentication mode and other attributes. o domain-auth-info: The information related to level-2 authentication, including password, authentication mode and other attributes. 2.1.3. Multi-topology list(multi-topo*) This represents the list of topologies associated with this IS-IS instance. Each IS-IS routing protocol MAY support multiple topologies to represent different involvement within those topologies. The list is mandatory for IS-IS process and MUST support one topology at least. More discussion for this list is in the section below. Wu, et al. Expires March 14, 2015 [Page 7] Internet-Draft IS-IS information model September 2014 2.2. IS-IS multi-topology A set of independent Multi-Topologies (MTs) can be supported on the same IS-IS routing domain. This section describes the information model related to MT. This includes the following which is shown in the yang high-level description in figure 3. o mt-id: The identifier of this MT. This ID is globally unique across the routing domain. o mt-status: The status of this MT. Valid input MAY be Active or Inactive. o address-family: The address family supported on this MT. o level list (level*): This is the list of levels supported in this IS-IS MT. o mt-ipv4-rib: The IPv4 routing information base for this MT. o mt-ipv6-rib: The IPv6 routing information base for this MT. o circuit list (circuit*): This is the list of circuits supported in this IS-IS MT. o policy list (policy*): This is the list of policies supported in this IS-IS MT. Wu, et al. Expires March 14, 2015 [Page 8] Internet-Draft IS-IS information model September 2014 module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] ... +--rw multi-topo-list* [mt-id] +--rw mt-id uint16 +--ro mt-status? enumeration +--rw address-family address-family-def +--rw level-list* [level-id] | +--rw level-id string | +--rw lsdb ... | +--rw lsdb-status? enumeration | +--rw lsdb-size? uint32 | +--ro is-number? uint32 +--rw mt-ipv4-rib* [ipv4-prefix] ... +--rw mt-ipv6-rib* [ipv6-prefix] ... +--rw circuit-list* [circuit-id] ... +--rw policy-list* [policy-id] ... Figure 3 YANG model of ISIS MT 2.2.1. Level list (level*) This is the list of levels supported in this IS-IS MT. It is a mandatory component for IS-IS MT and it MUST contain one element at least in the list. The information model of level-list will be elaborated in the section below. 2.2.2. IS-IS MT RIB route o address-family: The address family of this route. Valid input MAY be IPv4 or IPv6. o prefix: The destination address of this route. o prefix-length: The length of this prefix. o mask: The mask of destination address. o nexthop list (nexthop*): The nexthops of this route. o backup-nexthop: The backup nexthop for this route. Wu, et al. Expires March 14, 2015 [Page 9] Internet-Draft IS-IS information model September 2014 o metric: The metric for this routes. o type: The type for this route. Valid input MAY be Level-1 or Level-2. o route-state: The current and previous state of this route and the reason for this change. o lsp-id-adv: The ID of corresponding LSP which advertised the route prefix. module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] ... +--rw multi-topo-list* [mt-id] ... +--rw mt-ipv4-rib* [ipv4-prefix] | +--rw ipv4-prefix inet:ipv4-prefix | +--rw nexthop-list* [nexthop] | | +--rw nexthop inet:ipv4-prefix | +--rw back-nexthop? inet:ipv4-prefix | +--rw ipv4-isis-route-para | +--rw metric? uint32 | +--ro type? enumeration | +--ro route-current-state? route-state-def | +--ro route-previous-state? route-state-def | +--rw lsp-id? inet:ipv4-prefix | +--ro route-chg-reason? enumeration +--rw mt-ipv6-rib* [ipv6-prefix] | +--rw ipv6-prefix inet:ipv6-prefix | +--rw nexthop-list* [nexthop] | | +--rw nexthop inet:ipv6-prefix | +--rw back-nexthop? inet:ipv4-prefix | +--rw ipv6-isis-route-para | +--rw metric? uint32 | +--ro type? enumeration | +--ro route-current-state? route-state-def | +--ro route-previous-state? route-state-def | +--rw lsp-id? inet:ipv4-prefix | +--ro route-chg-reason? enumeration Figure 4 YANG model of ISIS MT RIB Wu, et al. Expires March 14, 2015 [Page 10] Internet-Draft IS-IS information model September 2014 2.2.3. Circuit list (circuit*) This list indicates those circuits which have been involved into the IS-IS MT. It is optional for the protocol and will be explained in the section below. 2.2.4. Policy list (policy*) This list contains those policies referenced within this IS-IS MT. It is optional for the protocol to reference policy or not. 2.3. IS-IS level IS-IS level is used to organize routing in a hierarchical manner. According to the level-type of current IS-IS MT, the elements in level-list MAY contain level-1 or level-2 or both. Each level SHOULD contain information related to level parameters, link-state database and so on. Below is the description of the level parameters followed by the high level yang description. 2.3.1. Level I2RS YANG description The IGP requirement(IGP-REQ-02) of I2RS Requirements Summary specifies the I2RS agent SHOULD be able to aid IGP table reduction by actively monitoring the IGP tables and allowing temporary changes to IGPs in order to partition the IGPs and place ABR and ASBRs. The Level information has both LSDB and TE information as shown below. module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] ... +--rw multi-topo-list* [mt-id] ... +--rw level-list* [level-id] | +--rw level-id string | +--rw lsdb | +--rw lsp* [lsp-id sequence-number checksum] ... | +--rw lsdb-status? enumeration | +--rw lsdb-size? uint32 | +--ro is-number? uint32 Figure 5 YANG model of IS-IS LSDB Wu, et al. Expires March 14, 2015 [Page 11] Internet-Draft IS-IS information model September 2014 2.3.2. Level parameters This section demonstrates those parameters in level scope. Mandatory fields MUST be contained in the IS-IS level. o level-id: The identification of this level which SHOULD be level-1 or level-2. 2.3.3. Link State database Link State Database (LSDB) is composed of all link-state information advertised in the corresponding level. These pieces of link-state information are organized in the form of Link State PDU (LSP) which can be divided into two groups: self-originated LSP and remote- generated LSP. Some attributes of database can also be included in the information model. o lsp list (lsp*): This list indicates those LSPs which are advertised in current level by either remote IS or self- origination. o lsdb-status: This represents the current status for database. It MAY be Normal or Overflow or something else. o lsdb-size: The size of database in the form of LSP number or bytes or percentage of maximum size. o is-number: The total number of IS in this level. 2.3.4. Link State PDU Link State PDU (LSP) is a data unit used to hold and organize link- state information in the level scope. Intermediate-Systems in the same level depend on the exchange of LSPs to synchronize their database which is the basis for per-hop forwarding paradigm. This section demonstrates some important components of LSP. o maximum-area-addresses: The maxinum number of area addresses supported by the originator of this lsp. o pdu-length: The length in bytes of this LSP PDU. o rem-lifetime: Remaining lifetime of one LSP. Those with zero lifetime will be handled in special way. o lsp-id: The identifier of one LSP. It uniquely identify one LSP in the level scope. Wu, et al. Expires March 14, 2015 [Page 12] Internet-Draft IS-IS information model September 2014 o sequence-number: The sequence number of a LSP. It is used to differentiate between the old instance and the new one for the LSP from the same place. o checksum: The calculated checksum of one LSP. o p-bit: This indicates when set that the issuing Intermediate System supports the Partition Repair optional function. o lspdbol-bit: A value of 0 indicates no LSP Database Overload, and a value of 1 indicates that the LSP Database is Overloaded. An LSP with this bit set will not be used by any decision process to calculate routes to another IS through the originating system o is-type-bit: Bits 1 and 2 indicate the type of Intermediate System. Valid choice SHOULD be level-1 or level-2. module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] ... +--rw multi-topo-list* [mt-id] ... +--rw level-list* [level-id] ... | +--rw lsdb | +--rw lsp* [lsp-id sequence-number checksum] | | +--rw maximum-area-addresses uint8 | | +--rw pdu-length uint16 | | +--rw remaining-lifetime uint16 | | +--rw lsp-id string | | +--rw sequence-number uint32 | | +--rw checksum uint16 | | +--rw p-bit boolean | | +--rw error-metric-bit boolean | | +--rw expense-metric-bit boolean | | +--rw delay-metric-bit boolean | | +--rw default-metric-bit boolean | | +--rw lspdbol-bit? enumeration | | +--rw is-type-bit? enumeration | | +--rw area-addresse--tlv ... | | +--rw intermediate-system-neighbours-tlv ... | | +--rw nlpid-tlv ... | | +--rw ip-interface-addresses-tlv ... Wu, et al. Expires March 14, 2015 [Page 13] Internet-Draft IS-IS information model September 2014 | | +--rw ip-internal-reachability-tlv ... | | +--rw ip-external-reachability-tlv ... | | +--rw inter-domain-information-tlv ... | | +--rw extended-is-reachability-tlv ... | | +--rw extended-ip-reachability-tlv ... | | +--rw ipv6-reachability-tlv ... | | +--rw ipv6-interface-address-tlv ... | | +--rw ipv6-te-router-id-tlv ... | | +--rw ipv6-srlg-tlv ... | | +--rw multi-topology-tlv ... | | +--rw mt-intermediate-systems-tlv ... | | +--rw mt-topology-reachable-ipv4-prefixes-tlv ... | | +--rw mt-topology-reachable-ipv6-prefixes-tlv ... Figure 6 YANG model of IS-IS LSP 2.4. IS-IS circuit IS-IS circuits are used to help to constrain the boundaries of IS-IS PDU sending and receiving. PDUs handled on these circuits are directly associated with the same process. This section demonstrates the information model of IS-IS circuits shown below in figure 7 in the yang high level language. module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] ... +--rw multi-topo-list* [mt-id] ... +--rw circuit-list* [circuit-id] | +--rw circuit-id uint32 | +--rw circuit-name? string | +--rw ip-address? inet:ip-address | +--ro circuit-status? enumeration Wu, et al. Expires March 14, 2015 [Page 14] Internet-Draft IS-IS information model September 2014 | +--ro circuit-down-reason? enumeration | +--rw circuit-net-type? enumeration | +--rw circuit-level-type? enumeration | +--rw circuit-auth-info | | +--rw auth-mode | | | +--rw (auth-mode-type)? | | | +--:(mode-simple) | | | | +--rw simple-password? string | | | +--:(mode-md5) | | | | +--rw md5-password? string | | | +--:(mode-hmac-sha256) | | | | +--rw hmac-key-id? uint32 | | | | +--rw hmac-password? string | | | +--:(mode-keychain) | | | +--rw keychain-key-id? uint32 | | | +--rw keychain-password? string | | | +--rw keychain-mode? enumeration | | | +--rw keychain-periodic? enumeration | | | +--rw send_time? uint32 | | | +--rw receive_tim? uint32 | | +--rw snp-auth-status? enumeration | | +--rw auth-scope? enumeration | +--rw l1-dis-id? inet:ipv4-prefix | +--rw l2-dis-id? inet:ipv4-prefix | +--rw l1-nbr-list* [l1nbr-system-id] | | +--rw l1nbr-system-id uint32 | | +--rw snpa? uint32 | | +--ro nbr-status? enumeration | | +--ro nbr-down-reason? enumeration | | +--rw nbr-type? enumeration | +--rw l2-nbr-list* [l2nbr-system-id] | | +--rw l2nbr-system-id uint32 | | +--rw snpa? uint32 | | +--ro nbr-status? enumeration | | +--ro nbr-down-reason? enumeration | | +--rw nbr-type? enumeration | +--rw circuit-te | +--rw admin-group? uint32 | +--rw ipv4-addr? inet:ipv4-prefix | +--rw nbr-ipv4-addr? inet:ipv4-prefix | +--rw max-bandwidth? uint32 | +--rw max-rsv-bandwidth? uint32 | +--rw unrsv-bandwidth? uint32 Figure 7 YANG model of IS-IS circuit Wu, et al. Expires March 14, 2015 [Page 15] Internet-Draft IS-IS information model September 2014 2.4.1. Circuit parameters o circuit-id: The index for this circuit. It MUST be unique globally in the same routing system. o circuit-name: The name used to refer to this circuit. o ip-address: The IP address of this circuit. o circuit-status: The status of this circuit. Valid choice SHOULD be UP or DOWN. o circuit-down-reason: The reason why this circuit is brought to down. Valid reason SHOULD be Physical-down, Admin-shutdown, IP- down and MTU-down. o circuit-net-type: The network type simulated on this circuit. Valid choice SHOULD be P2P, Broadcast or NBMA. o circuit-level-type: The level type supported on this circuit. Valid choice SHOULD be Level-1-Only, Level-2-Only or Level- 1-2-Both. o circuit-auth-info: The information related to circuit authentication, including password, authentication mode and other attributes. o l1-dis-id: The identifier for DIS in level-1. o l2-dis-id: The identifier for DIS in level-2. o l1-nbr list (l1-nbr*): The IS reachability list on this circuit for level-1. o l2-nbr list (l2-nbr*): The IS reachability list on this circuit for level-2. o circuit-te: The traffic-engineer information related to this circuit. 2.4.2. Circuit traffic engineering This section describes the TE related data on this circuit. o admin-group: The bit mask assigned by operators used for identifying administrative group. Wu, et al. Expires March 14, 2015 [Page 16] Internet-Draft IS-IS information model September 2014 o ipv4-address: A 4-octet IPv4 address for the circuit described by Circuit-index. o nbr-ipv4-addr: A single IPv4 address for a neighboring router on this link. o max-bandwidth: The maximum bandwidth that can be used on this link in this direction. o max-rsv-bandwidth: The maximum amount of bandwidth that can be reserved in this direction on this link. o unrsv-bandwidth: The amount of bandwidth reservable in this direction on this link. 2.4.3. Circuit neighbor This section describes the neighbor information related to one circuit. o nbr-system-id: The system-id of one neighbor supported on this circuit. o snpa: The SNPA address of corresponding neighbor. o nbr-status: The status for the adjacency with this neighbor. o nbr-down-reason: The reason this adjacency was brought. Valid choice SHOULD be Circuit-down, BFD-down, Expired, CFG-change and I2RS-down. o nbr-type: The system type of corresponding neighbor. 3. IS-IS notification With the help of IS-IS information model, the I2RS Client can collect IS-IS state data through publish/subscription mechanism. This section describes several data which is important for operating and maintaining of IS-IS routing-protocol. 3.1. Adjacency Information related to adjacencies SHOULD be readable through I2RS Agent. This includes total number of adjacencies in the network and their current status and even their history of transition. For certain specific adjacencies, the I2RS Client MAY subscribe for their data when events happened. Wu, et al. Expires March 14, 2015 [Page 17] Internet-Draft IS-IS information model September 2014 3.2. LSDB Link state database is the most important part in IS-IS information model. It contains the whole topology information from the network. The I2RS Agent SHOULD support reading LSDB information related to size, status and contents. It MAY be useful to subscribe some critical reachability information from LSP when specific events happened. 3.3. Route Since the IS-IS routing-table is one client for the RIB, it MAY be beneficial to read data from ISIS routes. This data may contain the size and status of the routing-table and even the detailed contents of routes. It MAY be necessary to subscribe the data and status of certain specific routes especially when the reachability was lost. Through the IS-IS information model, it will be more convenient for operators to get corresponding LSP and even the adjacency when one route disappeared. 3.4. TE It MAY be helpful to read the traffic engineering information for one level or for one specific circuit. This can help to find out mistakes or data loss during the procedure of advertising and flooding. 3.5. Protocol statistics It SHOULD be necessary to subscribe protocol statistics for health diagnostics. This statistics may contain packet discard for different reasons, adjacency transition frequency, the size of LSDB and routing-table, SPF-trigger frequency and etc. 4. IS-IS I2RS Operational Examples Based on the standardized information model of IS-IS protocol as described above, use cases defined in [I-D.hares-i2rs-usecase-reqs-summary] can be supported. This section provides several specific examples of these use cases. 4.1. Transient loop avoidance Link-state protocols may need to reconverge when the network topology changes. During this phase packet loss and transient loops are frequently observed since inconsistent RIBs exist, even the reachability of the destinations is not compromised after the topology change. [IGP-REQ-02] in Wu, et al. Expires March 14, 2015 [Page 18] Internet-Draft IS-IS information model September 2014 [I-D.hares-i2rs-usecase-reqs-summary] suggests that the there should be rapid cycle of querying and configuration change. Monitoring via the mechanisms in [IGP-REQ-04] and [IGP-REQ-05], [IGP-REQ-06], [IGP- REQ-07], and [IGP-REQ-08] in [I-D.hares-i2rs-usecase-reqs-summary] may aid in detecting the condition. 4.2. Traffic blackhole prevention IS-IS Hello packet is used to discover and maintain adjacencies among different IS-IS nodes. Without the deployment of fast detection techniques, one node has to wait for several seconds before it realized the adjacency had broken. This kind of issue can cause one device is cut off from its network and lose connectivity completely. No matter planned or accidentally it may cause traffic blackhole before damage can be controlled. [IGP-REQ-01] and [IGP-REQ-02] plus the monitoring requirements in [IGP-REQ-04] and [IGP-REQ-05], [IGP- REQ-06], [IGP-REQ-07], and [IGP-REQ-08] in [I-D.hares-i2rs-usecase-reqs-summary] may aid in detecting the condition. Under the scenario of I2RS and IS-IS information model deployed, it is RECOMMENDED that the adjacency data of the other end side can be removed simultaneously or LSP can be updated directly by I2RS Agent when IS-IS is disabled or detached on one side. The configuration of [IGP-REQ-02] can aid in configuring. (Note: configuration will be added in a future version. 5. IS-IS grammar This section demonstrates the information model of IS-IS routing- protocol using the syntax stated in [RFC5511] 5.1. Instance ::= [ ... ] ::= ::= [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] ::= [ ... ] ::= Wu, et al. Expires March 14, 2015 [Page 19] Internet-Draft IS-IS information model September 2014 ::= | | ::= | | ::= | | ::= | | | ::= [ ... ] ::= ::= | | | ::= ::= ::= ::= [ ] [ ] ::= | ::= | | | ::= ::= | | | ::= 5.2. Multi-topology ::= [ ] [ ] [ ] [ ] ::= | ::= | ::= [ ] ::= [ ... ] Wu, et al. Expires March 14, 2015 [Page 20] Internet-Draft IS-IS information model September 2014 ::= [ ... ] ::= ::= ::= [ ... ] ::= ( | ) [ ] [ ] ::= and SHOULD follow the definition in the RIB iformation model as stated in [I-D.ietf-i2rs-rib-info-model]. ::= [ [ ] ] [ ] ::= ( | ) ( | ) ::= ( | ) ( | ) ::= | | | 5.3. Level ::= ::= [ ] ::= | ::= [ ] ::= | ::= [ ... ] ::= [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] 5.4. Circuit ::= [ ... ] ::= [ ] [ [ ] ] [ ] [ ] ::= | | ::= | | ::= | ::= | | | ::= ::= [ ... ] ::= [ ... ] ::= [ ] ::= | | ::= | | ::= | | | | ::= Wu, et al. Expires March 14, 2015 [Page 22] Internet-Draft IS-IS information model September 2014 6. I2RS YANG model of IS-IS module: i2rs-isis-protocol +--rw isis-routing-protocol +--rw isis-instance* [name] +--rw name string +--rw isis-vpn-name? string +--rw address-family address-family-def +--rw net* [area-id] | +--rw area-id string | +--rw system-id? string +--ro protocol-status? enumeration +--rw level-type? enumeration +--rw metric-style? enumeration +--rw lsp-mtu? uint32 +--rw lsp-refresh? uint32 +--rw lsp-lifetime? uint32 +--ro isis-instance-create-mode? enumeration +--rw preference? uint32 +--rw hostname? string +--rw domain-auth-info | +--rw auth-mode | | +--rw (auth-mode-type)? | | +--:(mode-simple) | | | +--rw simple-password? string | | +--:(mode-md5) | | | +--rw md5-password? string | | +--:(mode-hmac-sha256) | | | +--rw hmac-key-id? uint32 | | | +--rw hmac-password? string | | +--:(mode-keychain) | | +--rw keychain-key-id? uint32 | | +--rw keychain-password? string | | +--rw keychain-mode? enumeration | | +--rw keychain-periodic? enumeration | | +--rw send_time? uint32 | | +--rw receive_tim? uint32 | +--rw snp-auth-status? enumeration | +--rw auth-scope? enumeration +--rw area-auth-info | +--rw auth-mode | | +--rw (auth-mode-type)? | | +--:(mode-simple) | | | +--rw simple-password? string | | +--:(mode-md5) | | | +--rw md5-password? string | | +--:(mode-hmac-sha256) | | | +--rw hmac-key-id? uint32 Wu, et al. Expires March 14, 2015 [Page 23] Internet-Draft IS-IS information model September 2014 | | | +--rw hmac-password? string | | +--:(mode-keychain) | | +--rw keychain-key-id? uint32 | | +--rw keychain-password? string | | +--rw keychain-mode? enumeration | | +--rw keychain-periodic? enumeration | | +--rw send_time? uint32 | | +--rw receive_tim? uint32 | +--rw snp-auth-status? enumeration | +--rw auth-scope? enumeration +--rw multi-topo-list* [mt-id] +--rw mt-id uint16 +--ro mt-status? enumeration +--rw address-family address-family-def +--rw level-list* [level-id] | +--rw level-id string | +--rw lsdb | +--rw lsp* [lsp-id sequence-number checksum] | | +--rw maximum-area-addresses uint8 | | +--rw pdu-length uint16 | | +--rw remaining-lifetime uint16 | | +--rw lsp-id string | | +--rw sequence-number uint32 | | +--rw checksum uint16 | | +--rw p-bit boolean | | +--rw error-metric-bit boolean | | +--rw expense-metric-bit boolean | | +--rw delay-metric-bit boolean | | +--rw default-metric-bit boolean | | +--rw lspdbol-bit? enumeration | | +--rw is-type-bit? enumeration | | +--rw area-addresse--tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [area-addresse] | | | +--rw address-length uint8 | | | +--rw area-addresse uint8 | | +--rw intermediate-system-neighbours-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw virtual-flag boolean | | | +--rw value* [neighbor-id] | | | +--rw default-metric uint8 | | | +--rw delay-metric uint8 | | | +--rw expense-metric uint8 | | | +--rw error-metric uint8 | | | +--rw neighbor-id string | | +--rw nlpid-tlv Wu, et al. Expires March 14, 2015 [Page 24] Internet-Draft IS-IS information model September 2014 | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [nlpid] | | | +--rw nlpid uint8 | | +--rw ip-interface-addresses-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [ip-address] | | | +--rw ip-address inet:ipv4-address | | +--rw ip-internal-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [ip-prefix] | | | +--rw i-e-bit boolean | | | +--rw default-metric uint8 | | | +--rw s-bit boolean | | | +--rw delay-metric uint8 | | | +--rw s-bit-expense-metric boolean | | | +--rw expense-metric uint8 | | | +--rw s-bit-error-metric boolean | | | +--rw error-metric uint8 | | | +--rw ip-prefix inet:ipv4-prefix | | +--rw ip-external-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [ip-prefix] | | | +--rw i-e-bit boolean | | | +--rw default-metric uint8 | | | +--rw s-bit boolean | | | +--rw delay-metric uint8 | | | +--rw s-bit-expense-metric boolean | | | +--rw expense-metric uint8 | | | +--rw s-bit-error-metric boolean | | | +--rw error-metric uint8 | | | +--rw ip-prefix inet:ipv4-prefix | | +--rw inter-domain-information-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [inter-domain-information-type external-information] | | | +--rw inter-domain-information-type uint8 | | | +--rw external-information uint32 | | +--rw extended-is-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [neighbor-system-id] | | | +--rw neighbor-system-id uint32 | | | +--rw metric uint32 | | | +--rw sub-tlv-length uint8 Wu, et al. Expires March 14, 2015 [Page 25] Internet-Draft IS-IS information model September 2014 | | | +--rw administrative-group-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw value? uint32 | | | +--rw ipv4-interface-address--stlv* [ipv4-interface-address] | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw ipv4-interface-address inet:ipv4-address | | | +--rw ipv4-neighbor-address--stlv* [ipv4-neighbor-address] | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw ipv4-neighbor-address inet:ipv4-address | | | +--rw maximum-bandwidth--stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw maximum-bandwidth? uint32 | | | +--rw maximum-reservable-link-bandwidth-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw maximum-bandwidth? uint32 | | | +--rw unreserved-bandwidth-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw unreserved-bandwidth? uint32 | | | +--rw traffic-engineering-default-metric-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw utraffic-engineering-default-metric? uint32 | | | +--rw ipv6-interface-address--stlv* [ipv6-interface-address] | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw ipv6-interface-address inet:ipv6-address | | | +--rw ipv6-neighbor-address--stlv* [ipv6-neighbor-address] | | | +--rw type enumeration | | | +--rw length? uint32 | | | +--rw ipv6-neighbor-address inet:ipv6-address | | +--rw extended-ip-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [ip-prefix] | | | +--rw metric uint32 | | | +--rw up-down-bit boolean | | | +--rw sub-TLV-bit boolean | | | +--rw prefix-length uint8 | | | +--rw ip-prefix inet:ipv4-prefix | | | +--rw length-sub-TLVs? uint8 | | | +--rw sub-tlv* [type value] | | | +--rw type uint8 Wu, et al. Expires March 14, 2015 [Page 26] Internet-Draft IS-IS information model September 2014 | | | +--rw length? uint32 | | | +--rw value string | | +--rw ipv6-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value | | | +--rw metric uint32 | | | +--rw u-bit boolean | | | +--rw x-bit boolean | | | +--rw s-bit boolean | | | +--rw prefix-len uint8 | | | +--rw prifix-list* [ipv6-prifix] | | | +--rw ipv6-prifix inet:ipv6-prefix | | +--rw ipv6-interface-address-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value | | | +--rw ipv6-interface-address-list* [ipv6-interface-address] | | | +--rw ipv6-interface-address inet:ipv6-address | | +--rw ipv6-te-router-id-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value | | | +--rw ipv6-te-router-id? inet:ipv6-address | | +--rw ipv6-srlg-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value | | | +--rw system-id uint64 | | | +--rw pseudonode-number uint8 | | | +--rw flags uint8 | | | +--rw ipv6-interface-address inet:ipv6-address | | | +--rw ipv6-neighbor-address inet:ipv6-address | | | +--rw srlg-list* [srlg] | | | +--rw srlg uint32 | | +--rw multi-topology-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value | | | +--rw o-bit boolean | | | +--rw a-bit boolean | | | +--rw mt-id uint16 | | +--rw mt-intermediate-systems-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value | | | +--rw mt-id uint16 | | | +--rw mt-intermediate-systems-list* [mt-intermediate-systems-index] Wu, et al. Expires March 14, 2015 [Page 27] Internet-Draft IS-IS information model September 2014 | | | +--rw mt-intermediate-systems-index uint32 | | | +--rw extended-is-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [neighbor-system-id] | | | +--rw neighbor-system-id uint32 | | | +--rw metric uint32 | | | +--rw sub-tlv-length uint8 | | | +--rw administrative-group-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw value? uint32 | | | +--rw ipv4-interface-address--stlv* [ipv4-interface-address] | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw ipv4-interface-address inet:ipv4-address | | | +--rw ipv4-neighbor-address--stlv* [ipv4-neighbor-address] | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw ipv4-neighbor-address inet:ipv4-address | | | +--rw maximum-bandwidth--stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw maximum-bandwidth? uint32 | | | +--rw maximum-reservable-link-bandwidth-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw maximum-bandwidth? uint32 | | | +--rw unreserved-bandwidth-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw unreserved-bandwidth? uint32 | | | +--rw traffic-engineering-default-metric-stlv | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw utraffic-engineering-default-metric? uint32 | | | +--rw ipv6-interface-address--stlv* [ipv6-interface-address] | | | | +--rw type enumeration | | | | +--rw length? uint32 | | | | +--rw ipv6-interface-address inet:ipv6-address | | | +--rw ipv6-neighbor-address--stlv* [ipv6-neighbor-address] | | | +--rw type enumeration | | | +--rw length? uint32 | | | +--rw ipv6-neighbor-address inet:ipv6-address | | +--rw mt-topology-reachable-ipv4-prefixes-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value Wu, et al. Expires March 14, 2015 [Page 28] Internet-Draft IS-IS information model September 2014 | | | +--rw mt-id uint16 | | | +--rw mt-topology-reachable-ipv4-prefixes-list* [mt-topology-reachable-ipv4-prefixes-index] | | | +--rw mt-topology-reachable-ipv4-prefixes-index uint32 | | | +--rw extended-ip-reachability-tlv | | | +--rw code enumeration | | | +--rw length uint8 | | | +--rw value* [ip-prefix] | | | +--rw metric uint32 | | | +--rw up-down-bit boolean | | | +--rw sub-TLV-bit boolean | | | +--rw prefix-length uint8 | | | +--rw ip-prefix inet:ipv4-prefix | | | +--rw length-sub-TLVs? uint8 | | | +--rw sub-tlv* [type value] | | | +--rw type uint8 | | | +--rw length? uint32 | | | +--rw value string | | +--rw mt-topology-reachable-ipv6-prefixes-tlv | | +--rw code enumeration | | +--rw length uint8 | | +--rw value | | +--rw mt-id uint16 | | +--rw mt-topology-reachable-ipv6-prefixes-list* [mt-topology-reachable-ipv6-prefixes-index] | | +--rw mt-topology-reachable-ipv6-prefixes-index uint32 | | +--rw ipv6-reachability-tlv | | +--rw code enumeration | | +--rw length uint8 | | +--rw value | | +--rw metric uint32 | | +--rw u-bit boolean | | +--rw x-bit boolean | | +--rw s-bit boolean | | +--rw prefix-len uint8 | | +--rw prifix-list* [ipv6-prifix] | | +--rw ipv6-prifix inet:ipv6-prefix | +--rw lsdb-status? enumeration | +--rw lsdb-size? uint32 | +--ro is-number? uint32 +--rw mt-ipv4-rib* [ipv4-prefix] | +--rw ipv4-prefix inet:ipv4-prefix | +--rw nexthop-list* [nexthop] | | +--rw nexthop inet:ipv4-prefix | +--rw back-nexthop? inet:ipv4-prefix | +--rw ipv4-isis-route-para | +--rw metric? uint32 | +--ro type? enumeration | +--ro route-current-state? route-state-def | +--ro route-previous-state? route-state-def Wu, et al. Expires March 14, 2015 [Page 29] Internet-Draft IS-IS information model September 2014 | +--rw lsp-id? inet:ipv4-prefix | +--ro route-chg-reason? enumeration +--rw mt-ipv6-rib* [ipv6-prefix] | +--rw ipv6-prefix inet:ipv6-prefix | +--rw nexthop-list* [nexthop] | | +--rw nexthop inet:ipv6-prefix | +--rw back-nexthop? inet:ipv4-prefix | +--rw ipv6-isis-route-para | +--rw metric? uint32 | +--ro type? enumeration | +--ro route-current-state? route-state-def | +--ro route-previous-state? route-state-def | +--rw lsp-id? inet:ipv4-prefix | +--ro route-chg-reason? enumeration +--rw circuit-list* [circuit-id] | +--rw circuit-id uint32 | +--rw circuit-name? string | +--rw ip-address? inet:ip-address | +--ro circuit-status? enumeration | +--ro circuit-down-reason? enumeration | +--rw circuit-net-type? enumeration | +--rw circuit-level-type? enumeration | +--rw circuit-auth-info | | +--rw auth-mode | | | +--rw (auth-mode-type)? | | | +--:(mode-simple) | | | | +--rw simple-password? string | | | +--:(mode-md5) | | | | +--rw md5-password? string | | | +--:(mode-hmac-sha256) | | | | +--rw hmac-key-id? uint32 | | | | +--rw hmac-password? string | | | +--:(mode-keychain) | | | +--rw keychain-key-id? uint32 | | | +--rw keychain-password? string | | | +--rw keychain-mode? enumeration | | | +--rw keychain-periodic? enumeration | | | +--rw send_time? uint32 | | | +--rw receive_tim? uint32 | | +--rw snp-auth-status? enumeration | | +--rw auth-scope? enumeration | +--rw l1-dis-id? inet:ipv4-prefix | +--rw l2-dis-id? inet:ipv4-prefix | +--rw l1-nbr-list* [l1nbr-system-id] | | +--rw l1nbr-system-id uint32 | | +--rw snpa? uint32 | | +--ro nbr-status? enumeration | | +--ro nbr-down-reason? enumeration Wu, et al. Expires March 14, 2015 [Page 30] Internet-Draft IS-IS information model September 2014 | | +--rw nbr-type? enumeration | +--rw l2-nbr-list* [l2nbr-system-id] | | +--rw l2nbr-system-id uint32 | | +--rw snpa? uint32 | | +--ro nbr-status? enumeration | | +--ro nbr-down-reason? enumeration | | +--rw nbr-type? enumeration | +--rw circuit-te | +--rw admin-group? uint32 | +--rw ipv4-addr? inet:ipv4-prefix | +--rw nbr-ipv4-addr? inet:ipv4-prefix | +--rw max-bandwidth? uint32 | +--rw max-rsv-bandwidth? uint32 | +--rw unrsv-bandwidth? uint32 +--rw policy-list* [policy-id] +--rw policy-id string Figure 8 The I2RS YANG model of IS-IS 7. IANA Considerations This draft includes no request to IANA. 8. Security Considerations This document introduces no new security threat and SHOULD follow the security requirements as stated in [I-D.ietf-i2rs-architecture]. 9. Acknowledgements TBD 10. References 10.1. Normative References [I-D.hares-i2rs-usecase-reqs-summary] Hares, S., "Summary of I2RS Use Case Requirements", draft- hares-i2rs-usecase-reqs-summary-00 (work in progress), July 2014. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-05 (work in progress), July 2014. Wu, et al. Expires March 14, 2015 [Page 31] Internet-Draft IS-IS information model September 2014 [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", draft-ietf-i2rs-rib-info- model-03 (work in progress), May 2014. [I-D.wu-i2rs-igp-usecases] Wu, N., Li, Z., and S. Hares, "Use Cases for an Interface to IGP Protocol", draft-wu-i2rs-igp-usecases-00 (work in progress), July 2014. 10.2. Informative References [I-D.ietf-isis-oper-enhance] Shen, N., Li, T., Amante, S., and M. Abrahamsson, "IS-IS Operational Enhancements for Network Maintenance Events", draft-ietf-isis-oper-enhance-03 (work in progress), February 2013. [I-D.litkowski-rtgwg-uloop-delay] Litkowski, S., Decraene, B., Filsfils, C., and P. Francois, "Microloop prevention by introducing a local convergence delay", draft-litkowski-rtgwg-uloop-delay-03 (work in progress), February 2014. [ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain- routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, July 2013. Wu, et al. Expires March 14, 2015 [Page 32] Internet-Draft IS-IS information model September 2014 Authors' Addresses Nan Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Lixing Wang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 10095 China Email: wanglixing@huawei.com Susan Hares Huawei 7453 Hickory Hill Saline, MA 48176 USA Email: shares@ndzh.com Wu, et al. Expires March 14, 2015 [Page 33]