idnits 2.17.1 draft-gu-network-mornitoring-protol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 02, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 661, but no explicit reference was found in the text == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-17 ** Downref: Normative reference to an Informational draft: draft-openconfig-rtgwg-gnmi-spec (ref. 'I-D.openconfig-rtgwg-gnmi-spec') ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Experimental RFC: RFC 3988 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Gu 3 Internet-Draft S. Zhuang 4 Intended status: Standards Track Z. Li 5 Expires: January 3, 2019 Huawei 6 July 02, 2018 8 Network Monitoring Protocol (NMP) 9 draft-gu-network-mornitoring-protol-00 11 Abstract 13 To enable automated network OAM (Operations, administration and 14 management), the availability of network protocol running status 15 information is a fundamental step. In this document, a network 16 monitoring protocol (NMP) is proposed to provision the information 17 related to running status of IGP (Interior Gateway Protocol) and 18 other control protocols. It can facilitate the network 19 troubleshooting of control protocols in a network domain. Typical 20 network issues are illustrated as the usecases of NMP for ISIS to 21 showcase the necessity of NMP. Then the operations and the message 22 formats of NMP for ISIS are defined. In this document ISIS is used 23 as the illustration protocol, and the case of OSPF and other control 24 protocols will be included in the future version. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 3, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. ISIS Adjacency Issues . . . . . . . . . . . . . . . . . . 4 72 3.2. Forwarding Path Disconnection . . . . . . . . . . . . . . 5 73 3.3. ISIS LSP Synchronization Failure . . . . . . . . . . . . 5 74 4. Extensions of NMP for ISIS . . . . . . . . . . . . . . . . . 6 75 4.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 6 76 4.2. Message Format . . . . . . . . . . . . . . . . . . . . . 7 77 4.2.1. Common Header . . . . . . . . . . . . . . . . . . . . 7 78 4.2.2. Per Peer Header . . . . . . . . . . . . . . . . . . . 7 79 4.2.3. Initiation Message . . . . . . . . . . . . . . . . . 8 80 4.2.4. Peer Status Change Notification . . . . . . . . . . . 9 81 4.2.5. Statistic Report Message . . . . . . . . . . . . . . 10 82 4.2.6. ISIS PDU Monitoring Message . . . . . . . . . . . . . 12 83 4.2.7. Termination Message . . . . . . . . . . . . . . . . . 12 84 5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 86 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 1.1. Motivation 94 The requirement for better network OAM approaches has been greatly 95 driven by the network evolvement. Network OAM provides visibility to 96 the network health conditions, and is beneficial for faster network 97 troubleshooting and self-healing, network OpEx (operating 98 expenditure) reduction, and network optimization. Network OAM 99 statistics show that a relatively large part of the network issues 100 are caused by the disfunction of various routing protocols and MPLS 101 signalings. 103 The general troubleshooting logic nowadays is to log in a faulty 104 router, physically or through Telnet, and by using CLI to display 105 related information/logs for fault source localization and further 106 analysis. There are several concerns with the conventional 107 troubleshooting: 109 1. It requires rich OAM experience for the OAM operator to know what 110 information to check on the device, and the operation is complex; 112 2. In a multi-vendor network, it requires the understanding and 113 familiarity of vendor specific operations and configurations; 115 3. Locating the fault source device could be non-trivial work, and 116 is often realized through network-wide device-by-device check, which 117 is both time-consuming and labor-consuming; and finally, 119 4. The acquisition of troubleshooting data can be difficult under 120 some cases, e.g., when auto recovery is used. 122 Alternatively, the idea of collecting information from devices and 123 exporting to the centralized controller/server for further analysis 124 is also used to gain more insight on the management plane information 125 for OAM purposes. For example, SNMP (Simple Network Management 126 Protocol) [RFC1157], NETCONF (Network Configuration Protocol) 127 [RFC6241], gNMI/gRPC [I-D.openconfig-rtgwg-gnmi-spec], etc. are used 128 for the purpose. However, the approaches are mainly used for data 129 SET/GET of the management plane which are insufficient for the 130 troubleshooting of control plane issues. 132 BGP monitoring protocol (BMP) [RFC7854] has been proposed to monitor 133 BGP routes and peer status which provides the control plane 134 information and thus more insight for troubleshooting. This document 135 extends BMP to collect information of other control protocols for 136 monitoring to facilitate the trouble shooting of control plane issues 137 which call as Network Monitoring Protocols (NMP). 139 1.2. Overview 141 Like BMP, an NMP session is established between each monitored router 142 (NMP client) and the NMP monitoring station (NMP server) through TCP 143 connection. Information are collected directly from each monitored 144 router and reported to the NMP server. The NMP message can be both 145 periodic and event-triggered, depending on the message type. 147 ISIS [RFC1195], as one of the most commonly adopted network layer 148 protocols, builds the fundamental network connectivity of an 149 autonomous system (AS). The disfunction of ISIS, e.g., ISIS neighbor 150 down, route flapping, MTU mismatch, and so on, could lead to network- 151 wide instability and service interruption. Thus, it is critical to 152 keep track of the health condition of ISIS, and the availability of 153 information, related to ISIS running status, is the fundamental 154 requirement. In this document, typical network issues are 155 illustrated as the use cases of NMP for ISIS to showcase the 156 necessity of NMP. Then the operations and the message formats of NMP 157 for ISIS are defined. In this document ISIS is used as the 158 illustration protocol, and the case of OSPF and other control 159 protocols will be included in the future version. 161 2. Terminology 163 IGP: Interior Gateway Protocol 165 NMP: Network Monitoring Protocol 167 IMP: Network Monitoring Protocol for IGP 169 3. Use Cases 171 We have identified several typical network issues due to ISIS 172 disfunction that are currently difficult to detect or localize. The 173 usage of NMP is not limited to the solve the following listed issues. 175 3.1. ISIS Adjacency Issues 177 ISIS adjacency issues are identified as top network issues and may 178 take hours to localize. The adjacency issues can be classified into 179 two situations: 181 1. An existing established adjacency goes down; 183 2. An adjacency fails to be established. 185 In Case 1, the adjacency down can be caused by factors such as 186 circuit down, hold timer expiration, device memory low, user 187 configuration change, and so on. Case 2 can be caused by mismatch 188 link MTU, mismatch authentication, mismatch area ID, system ID 189 conflict, and so on. Typically, such adjacency failure events are 190 logged/recorded in the device, but currently there is no real-time 191 report/alarm of such issue. The conventional troubleshooting process 192 for adjacency issue is to find the faulty devices and then log in to 193 check the logs or the Hello statistics for further analysis. 195 Using NMP, the ISIS adjacency status: up, down and initial, is 196 reported to the NMP server in real time, together with the possible 197 recorded reasons. Then the NMP server can solve such issue in about 198 minutes. For example, for an adjacency set up failure due to 199 different authentications, the NMP server can recognize the 200 difference by comparing the Hello PDUs collected from both devices. 202 3.2. Forwarding Path Disconnection 204 Mismatched MTU values for devices along a certain path can lead to 205 packet forwarding failure while the control plane is working 206 properly. The failure may not be detected by Ping, but the 207 forwarding plane appears disconnected for certain size of data 208 packets. It can be quite common since vendors have different 209 understanding and configuration of MTU. There are methods proposed 210 to discover the path MTU. For example, router's link MTU is conveyed 211 in the MPLS LDP/RSVP-TE path set up signaling, and the path MTU is 212 decided at the ingress or egress node[RFC3988] [RFC3209]. For IPv4 213 packets, by setting the DF flag bit of the outgoing packet, any 214 device along the path with smaller MTU will drop the packet, and send 215 back an ICMP Fragmentation Needed message containing its MTU, 216 allowing the source to reduce the MTU. The process is repeated until 217 the MTU is small enough to traverse the entire path without 218 fragmentation[RFC1191]. Apparently, such method is too time- 219 consuming. 221 Using NMP, each device can report its link MTU to the monitoring 222 station directly. The mismatch can be recognized at the NMP server 223 in seconds. 225 3.3. ISIS LSP Synchronization Failure 227 It happens that two ISIS neighbors fail to learn the LSPs sent from 228 each other in the following two cases: in Case 1, the LSP fails to be 229 received, and in Case 2, the LSP is received but the LSP information 230 shown in the receiver's LSDB is not the same as the one sent from the 231 transmitter (e.g., one or more prefixes missing, the LSP sequence 232 number modified). Case 1 can be caused by link failure, similar to 233 the adjacency down issue. In Case 2, the received LSP can be 234 processed incorrectly due to hardware/software bugs. In fact, the 235 LSDB synchronization issue is usually hard to localize once happens. 237 Using NMP, the NMP server can detect the failure by comparing the 238 sent/received LSP statistics from the two neighbors. In the case 239 that the received LSPs are improperly processed within the device, 240 the NMP monitoring station can recognize the LSP synchronization 241 failure by comparing the LSPs sent out from the two neighbors. 243 4. Extensions of NMP for ISIS 245 4.1. Message Types 247 The variety of ISIS troubleshooting use cases requires a systematic 248 information report of NMP, so that the NMP server or any third party 249 analyzer could efficiently utilize the reported messages to localize 250 and recover various network issues. We define NMP messages for ISIS 251 uses the following types: 253 o Initiation Message: A message used for the monitored device to 254 inform the NMP monitoring station of its capabilities, vendor, 255 software version and so on. For example, the link MTU can be 256 included within the message. The initiation message is sent once 257 the TCP connection between the monitoring station and monitored 258 router is set up. During the monitoring session, any change of 259 the initiation message could trigger an Initiation Message update. 261 o Peer Status Change Notification Message: A message used to inform 262 the monitoring station of the adjacency status change of the 263 monitored device, i.e., from up to down, from down/initiation to 264 up, with possible alarms/logs recorded in the device. This 265 message notifies the NMP server of the ongoing ISIS adjacency 266 change event and possible reasons. If no reason is provided or 267 the provided reason is not specific enough, the NMP server can 268 further analyze the ISIS PDU or the ISIS statistics. 270 o Statistic Report Message: A message used to report the statistics 271 of the ongoing ISIS process at the monitored device. For example, 272 abnormal LSP count of the monitored device can be a sign of route 273 flapping. This message can be sent periodically or event 274 triggered. If sent periodically, the frequency can be configured 275 by the operator depending on the monitoring requirement. If it's 276 event triggered, it could be triggered by a counter/timer 277 exceeding the threshold. 279 o ISIS PDU Monitoring Message: A message used to update the NMP 280 server of any PDU sent from and received at the monitored device. 281 For example, the Hello PDUs collected from two neighbors can be 282 used for analyzing the adjacency set up failure issue. The LSPs 283 collected from two neighbors can be analyzed for the LSP 284 synchronization issue. 286 o Termination Message: A message for the monitored router to inform 287 the monitoring station of why it is closing the NMP session. This 288 message is sent when the monitoring session is to be closed. 290 4.2. Message Format 292 4.2.1. Common Header 294 The common header is encapsulated in all NMP messages. It includes 295 the Version, Message Length and Message Type fields. 297 o Version (1 byte): Indicates the NMP version and is set to '1' for 298 all messages. 300 o Message Length (4 bytes): Length of the message in bytes 301 (including headers, data, and encapsulated messages, if any). 303 o Message Type (1 byte): This indicates the type of the NMP message, 304 which are listed as follows. 306 * Type = 0: Initiation 308 * Type = 1: Peer Status Change Notification 310 * Type = 2: Statistic Report 312 * Type = 3: ISIS PDU Monitoring 314 * Type = 4: Termination Message 316 0 1 2 3 317 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 318 +---------------+ 319 | Version | 320 +---------------------------------------------------------------+ 321 | Message Length | 322 +---------------------------------------------------------------+ 323 | Msg. Type | 324 +---------------+ 326 4.2.2. Per Peer Header 328 Except the Initiation and Termination Message, all the rest messages 329 are per adjacency based. Thus, a per peer header is defined as 330 follows. 332 0 1 2 3 333 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 334 +---------------------------------------------------------------+ 335 | Reserved |CT| Neighbor System ID | 336 +---------------------------------------------------------------+ 337 | Neighbor System ID | 338 +-------------------------------+-------------------------------+ 339 | Neighbor Area ID | | 340 +-------------------------------+-------------------------------+ 341 | Timestamp (seconds) | 342 +---------------------------------------------------------------+ 343 | Timestamp (microseconds) | 344 +---------------------------------------------------------------+ 346 o Peer Flag (2 bytes): The Circuit Type (2 bits) flag specifies if 347 the router is an L1(01), L2(10), or L1/L2(11). If both bits are 348 zeroes (00), the Per Peer Header is ignored. This configuration 349 is used when the statistic is not per-peer based, e.g., when 350 reporting the number of adjacencies. 352 o Neighbor System ID (6 bytes): identifies the system ID of the 353 remote router. 355 o Neighbor Area ID (2 bytes): identifies the area ID of the remote 356 router. 358 o Timestamp (4 bytes): records the time when the message is sent/ 359 received, expressed in seconds and microseconds since midnight 360 (zero hour), January 1, 1970 (UTC). 362 4.2.3. Initiation Message 364 The Initiation Message indicates the monitored router's capabilities, 365 vendor, software version and so on. It consists of the Common Header 366 and the Router Capability TLV. The Common Header can be followed by 367 multiple Router Capability TLVs. 369 The Router Capability TLV is defined as follows. 371 0 1 2 3 372 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 373 +-------------------------------+-------------------------------+ 374 | Router Cap.Type | Router Cap. Length | 375 +-------------------------------+-------------------------------+ 376 + Router Cap. Value (variable) + 377 ~ ~ 378 +---------------------------------------------------------------+ 379 o Router Capability Type: provides the type of the router capability 380 information. Currently defined types are: 382 * Type = 0: sysDescr. The corresponding Router Capability Value 383 field should contain an ASCII string whose value MUST be set to 384 be equal to the value of the sysDescr MIB-II [RFC1213] object. 386 * Type = 1: sysName. The corresponding Router Capability Value 387 field should contain an ASCII string whose value MUST be set to 388 be equal to the value of the sysName MIB-II [RFC1213] object. 390 * Type = 2: Local System ID. The corresponding Router Capability 391 Value field should indicate the router's System ID 393 * Type = 3: Link MTU. The corresponding Router Capability Value 394 field should indicate the router's link MTU. 396 * Type = 4: String. The corresponding Router Capability Value 397 field contains a free-form UTF-8 string whose length is given 398 by the Information Length field. 400 4.2.4. Peer Status Change Notification 402 The Peer Status Change Notification Message indicates an ISIS 403 adjacency status change: from up to down or from initiation/down to 404 up. It consists of the Common Header, Per Peer Header and the Reason 405 TLV. The Notification is triggered whenever the status changes. The 406 Reason TLV is optional, and is defined as follows. More Reason types 407 can be defined if necessary. 409 0 1 2 3 410 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 411 +-------------------------------+-------------------------------+ 412 | Reserved |S| Reason Type | Reason Length | 413 +-------------------------------+-------------------------------+ 414 + Reason Value (variable) + 415 ~ ~ 416 +---------------------------------------------------------------+ 418 o Reason Flags (1 byte): The S flag (1 bit) indicates if the Peer 419 status is from up to down (set to 0) or from down/initial to up 420 (set to 1). The rest bits of the Flag field are reserved. When 421 the S flag is set to 1, the Reason Type should be set to all 422 zeroes (i.e., Type 0), the Reason Length fields should be set to 423 all zeroes, and the Reason Value field should be set empty. 425 o Reason Type (1 byte): indicates the possible reason that caused 426 the peer status change. Currently defined types are: 428 * Type = 0: Adjacency Up. This type indicates the establishment 429 of an adjacency. For this reason type, the S flag MUST be set 430 to 1, indicating it's a peer-up event. There's no further 431 reason to be provided. The reason Length field should be set 432 to all zeroes, and the Reason Value field should be set empty. 434 * Type = 1: Circuit Down. For this data type, the S flag MUST be 435 set to 0, indicating it's a peer-down event. The length field 436 is set to all zeroes, and the value field is set empty. 438 * Type = 2: Memory Low. For this data type, the S flag MUST be 439 set to 0, indicating it's a peer-down event. The length field 440 is set to all zeroes, and the value field is set empty. 442 * Type = 3: Hold timer expired. For this data type, the S flag 443 MUST be set to 0, indicating it's a peer-down event. The 444 length field is set to all zeroes, and the value field is set 445 empty. 447 * Type = 4: String. For this data type, the S flag MUST be set 448 to 0, indicating it's a peer-down event. The corresponding 449 Reason Value field indicates the reason specified by the 450 monitored router in a free-form UTF-8 string whose length is 451 given by the Reason Length field. 453 o Reason Length (2 bytes): indicates the length of the Reason Value 454 field. 456 o Reason Value (variable): includes the possible reason why the 457 Adjacency is down. 459 4.2.5. Statistic Report Message 461 The Statistic Report Message reports the statistics of the parameters 462 that are of interest to the operator. The message consists of the 463 NMP Common Header, the Per Adjacency Header and the Statistic TLV. 464 The message include both per-peer based statistics and non per-peer 465 based statistics. For example, the received/sent LSP counts are per- 466 peer based statistics, and the local LSP change times count and the 467 number of established adjacencies are non per-peer based statistics. 468 For the non per-peer based statistics, the CT Flag (2 bits) in the 469 Per Peer Header MUST be set to 00. Upon receiving any message with 470 CT flag set to 00, the Per Peer Header should be ignored (the total 471 length of the Per Peer Header is 18 bytes as defined in 472 Section 3.2.2, and the message reading/analysis should resume from 473 the Statistic TLV part. 475 The Statistic TLV is defined as follows. 477 0 1 2 3 478 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 479 +---------------------------------------------------------------+ 480 | Reserved |T| Statistic Type| Statistic Length | 481 +---------------------------------------------------------------+ 482 | Statistic Value | 483 +---------------------------------------------------------------+ 485 o Statistic Flags (1 byte): provides information for the reported 486 statistics. 488 * T flag (1 bit): indicates if the statistic is for the received- 489 from direction (set to 1) or sent-to direction the neighbor 490 (set to 0) 492 o Statistic Type (1 byte): specifies the statistic type of the 493 counter. Currently defined types are: 495 * Type = 0: Hello PDU count. The T flag indicates if it's a sent 496 or received Hello PDU. It is a per-peer based statistic type, 497 and the CT flag in the Per Peer Header MUST NOT be set to 00. 499 * Type = 1: Incorrect Hello PDU received count. For this type, 500 the T flag MUST be set to 1. It is a per-peer based statistic 501 type, and the CT flag in the Per Peer Header MUST NOT be set to 502 00. 504 * Type = 2: LSP count. The T flag indicates if it's a sent or 505 received LSP. It is a per-peer based statistic type, and the 506 CT flag in the Per Peer Header MUST NOT be set to 00. 508 * Type = 3: Incorrect LSP received count. For this type, the T 509 flag MUST be set to 1. It is a per-peer based statistic type, 510 and the CT flag in the Per Peer Header MUST NOT be set to 00. 512 * Type = 4: Retransmitted LSP count. For this type, the T flag 513 MUST be set to 0. It is a per-peer based statistic type, and 514 the CT flag in the Per Peer Header MUST NOT be set to 00. 516 * Type = 5: CSNP count. The T flag indicates if it's a sent or 517 received CSNP. It is a per-peer based statistic type, and the 518 CT flag in the Per Peer Header MUST NOT be set to 00. 520 * Type = 6: PSNP count. The T flag indicates if it's a sent or 521 received PSNP. It is a per-peer based statistic type, and the 522 CT flag in the Per Peer Header MUST NOT be set to 00. 524 * Type = 7: Number of established adjacencies. It's a non per- 525 peer based statistic type, and thus for the monitoring station 526 to recognize this type, the CT flag in the Per Peer Header MUST 527 be set to 00. 529 * Type = 8: LSP change time count. It's a non per-peer based 530 statistic type, and thus for the monitoring station to 531 recognize this type, the CT flag in the Per Peer Header MUST be 532 set to 00. 534 o Statistic Length (2 bytes): indicates the length of the Statistic 535 Value field. 537 o Statistic Value (4 bytes): specifies the counter value, which is a 538 non-negative integer. 540 4.2.6. ISIS PDU Monitoring Message 542 The ISIS PDU Monitoring Message is used to update the monitoring 543 station of any PDU sent from and received at the monitored device per 544 neighbor. Following the Common Header and the Per Peer Header is the 545 ISIS PDU. To tell whether it's a sent or received PDU, the 546 monitoring station can analyze the source and destination addresses 547 in the reported PDUs. 549 4.2.7. Termination Message 551 The Termination Message is sent when the NMP session is to be closed, 552 and is used to indicate the termination reason to the monitoring 553 station. The TCP session between the monitored router and the 554 monitoring station should be terminated upon receiving this message. 555 It consists of the Common Header and the Termination Info TLVs, 556 defined as follows. 558 0 1 2 3 559 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 560 +-------------------------------+-------------------------------+ 561 | Termination Info Type | Termination Info Length | 562 +-------------------------------+-------------------------------+ 563 + Termination Info Value (variable) + 564 ~ ~ 565 +---------------------------------------------------------------+ 567 o Termination Info Type (2 bytes): Provides the termination reason 568 type. Currently defined types are: 570 * Type = 0: Unknown. This reason type specifies that the NMP 571 session is closed for an unknown or unspecified reason. For 572 this data type, the length field is filled with all zeroes, and 573 the value field is set empty. 575 * Type = 1: Memory Low. This reason indicates that the monitored 576 router lacks resources for the NMP session. For this data 577 type, the length field is filled with all zeroes, and the value 578 field is set empty. 580 * Type = 2: Administratively Closed. This reason specifies that 581 the session is closed due to administrative reasons. The 582 corresponding Termination Info Value field may include more 583 details about the reason expressed in a free-form UTF-8 string 584 whose length is given by the Termination Info Length field. 586 * Type = 3: String. The corresponding Termination Info Value 587 field may include details about the reason expressed in a free- 588 form UTF-8 string whose length is given by the Termination Info 589 Length field. 591 Termination Info Length (2 bytes): indicates the length of the 592 Termination Info Reason Value field. 594 o Termination Info Value (variable): includes more detailed reason 595 for the session termination. 597 5. IANA 599 TBD 601 6. Contributors 603 TBD 605 7. Acknowledgments 607 TBD 609 8. References 611 [I-D.ietf-netconf-yang-push] 612 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 613 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 614 Subscription", draft-ietf-netconf-yang-push-17 (work in 615 progress), July 2018. 617 [I-D.openconfig-rtgwg-gnmi-spec] 618 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 619 C., and C. Morrow, "gRPC Network Management Interface 620 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 621 progress), March 2018. 623 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 624 "Simple Network Management Protocol (SNMP)", RFC 1157, 625 DOI 10.17487/RFC1157, May 1990, 626 . 628 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 629 DOI 10.17487/RFC1191, November 1990, 630 . 632 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 633 dual environments", RFC 1195, DOI 10.17487/RFC1195, 634 December 1990, . 636 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 637 for Network Management of TCP/IP-based internets: MIB-II", 638 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 639 . 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, 643 DOI 10.17487/RFC2119, March 1997, 644 . 646 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 647 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 648 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 649 . 651 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 652 Signalling Extensions for the Label Distribution 653 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 654 . 656 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 657 and A. Bierman, Ed., "Network Configuration Protocol 658 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 659 . 661 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 662 S. Ray, "North-Bound Distribution of Link-State and 663 Traffic Engineering (TE) Information Using BGP", RFC 7752, 664 DOI 10.17487/RFC7752, March 2016, 665 . 667 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 668 Monitoring Protocol (BMP)", RFC 7854, 669 DOI 10.17487/RFC7854, June 2016, 670 . 672 Authors' Addresses 674 Yunan Gu 675 Huawei 676 156 Beiqing Road 677 Beijing, 100095 678 P.R. China 680 Email: guyunan@huawei.com 682 Shunwan Zhuang 683 Huawei 684 156 Beiqing Road 685 Beijing, 100095 686 P.R. China 688 Email: zhuangshunwan@huawei.com 690 Zhenbin Li 691 Huawei 692 156 Beiqing Road 693 Beijing, 100095 694 P.R. China 696 Email: lizhenbin@huawei.com