idnits 2.17.1 draft-gu-network-monitoring-protocol-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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2018) is 2109 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 696, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 752, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-brockners-inband-oam-requirements (ref. 'I-D.brockners-inband-oam-requirements') == 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 Informational draft: draft-song-ntf (ref. 'I-D.song-ntf') ** 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: 10 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 18, 2019 Huawei 6 July 17, 2018 8 Network Monitoring Protocol (NMP) 9 draft-gu-network-monitoring-protocol-00 11 Abstract 13 To evolve towards automated network OAM (Operations, administration 14 and management), the monitoring of control plane protocols is a 15 fundamental necessity. In this document, a network monitoring 16 protocol (NMP) is proposed to provision the running status 17 information of control plane protocols, e.g., IGP (Interior Gateway 18 Protocol) and other protocols. By collecting the protocol monitoring 19 data and reporting it to the NMP monitoring server in real-time, NMP 20 can facilitate network troubleshooting. In this document, NMP for 21 IGP troubleshooting are illustrated to showcase the necessity of NMP. 22 IS-IS is used as the demonstration protocol, and the case of OSPF 23 (Open Shortest Path First) and other control protocols will be 24 elaborated in the future versions. The operations of NMP are 25 described, and the NMP message types and message formats are defined 26 in the document. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 3, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. IS-IS Adjacency Issues . . . . . . . . . . . . . . . . . 5 73 3.2. Forwarding Path Disconnection . . . . . . . . . . . . . . 6 74 3.3. IS-IS LSP Synchronization Failure . . . . . . . . . . . . 6 75 4. NMP Message Format . . . . . . . . . . . . . . . . . . . . . 7 76 4.1. Protocol Selection Options . . . . . . . . . . . . . . . 7 77 4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 7 78 4.3. Message Format . . . . . . . . . . . . . . . . . . . . . 8 79 4.3.1. Common Header . . . . . . . . . . . . . . . . . . . . 8 80 4.3.2. Per Adjacency Header . . . . . . . . . . . . . . . . 9 81 4.3.3. Initiation Message . . . . . . . . . . . . . . . . . 10 82 4.3.4. Adjacency Status Change Notification . . . . . . . . 11 83 4.3.5. Statistic Report Message . . . . . . . . . . . . . . 12 84 4.3.6. IS-IS PDU Monitoring Message . . . . . . . . . . . . 14 85 4.3.7. Termination Message . . . . . . . . . . . . . . . . . 14 86 5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 1.1. Motivation 96 The requirement for better network OAM approaches has been greatly 97 driven by the network evolvement. The concept of network Telemetry 98 has been proposed to meet the current and future OAM demands w.r.t., 99 massive and real-time data storage, collection, process, exportion, 100 and analysis, and an architectural framework of existing Telemetry 101 approaches is introduced in [I-D.song-ntf]. Network Telemetry 102 provides visibility to the network health conditions, and is 103 beneficial for faster network troubleshooting, network OpEx 104 (operating expenditure) reduction, and network optimization. 105 Telemetry can be applied to the data plane, control plane and 106 management plane. There have been various methods proposed for each 107 plane: 109 o Management plane: For example, SNMP (Simple Network Management 110 Protocol) [RFC1157], NETCONF (Network Configuration Protocol) 111 [RFC6241] and gNMI (gRPC Network Management Interface) 112 [I-D.openconfig-rtgwg-gnmi-spec] are three typical widely adopted 113 management plane Telemetry approaches. Various YANG modules are 114 defined for network operational state retrieval and configuration 115 management. Subscription to specific YANG datastore can be 116 realized in combination with gRPC/NETCONF. 118 o Data plane: For example, In-situ OAM (iOAM) 119 [I-D.brockners-inband-oam-requirements] embeds an instruction 120 header to the user data packets, and collects the requested data 121 and adds it to the use packet at each network node along the 122 forwarding path. Applications such as path verification, SLA 123 (service-level agreement) assurance can be enabled with iOAM. 125 o Control Plane: BGP monitoring protocol (BMP) [RFC7854] is proposed 126 to monitor BGP sessions and intended to provide a convenient 127 interface for obtaining BGP route views. Date collected using BMP 128 can be further analyzed with big data platforms for network health 129 condition visualization, diagnose and prediction applications. 131 The general idea of most Telemetry approaches is to collect various 132 information from devices and export to the centralized server for 133 further analysis, and thus providing more network insight. It should 134 not be surprising that any future and even current Telemetry 135 applications may require the fusion of data acquired from more than 136 one single approach/one single plane. For example, for network 137 troubleshooting purposes, it requires the collection of comprehensive 138 information from devices, such system ID/router ID, interface status, 139 PDUs (protocol data units), device/protocol statistics and so on. 141 Information such as system ID/router ID can be reported by management 142 plane Telemetry approaches, while the protocol related data 143 (especially PDUs) are more fit to be monitored using the control 144 plane Telemetry. With rich information collected in real time at the 145 centralized server, network issues can be localized faster and more 146 accurately, and the root cause analysis can be also provided. 148 The conventional troubleshooting logic is to log in a faulty router, 149 physically or through Telnet, and by using CLI to display related 150 information/logs for fault source localization and further analysis. 151 There are several concerns with the conventional troubleshooting 152 methods: 154 1. It requires rich OAM experience for the OAM operator to know what 155 information to check on the device, and the operation is complex; 157 2. In a multi-vendor network, it requires the understanding and 158 familiarity of vendor specific operations and configurations; 160 3. Locating the fault source device could be non-trivial work, and 161 is often realized through network-wide device-by-device check, which 162 is both time-consuming and labor-consuming; and finally, 164 4. The acquisition of troubleshooting data can be difficult under 165 some cases, e.g., when auto recovery is used. 167 This document proposes the Network Monitoring Protocols (NMP) to 168 monitor the running status of control protocols, e.g., PDUs, protocol 169 statistics and peer status, which have not been systematically 170 covered by any other Telemetry approach, to facilitate network 171 troubleshooting. 173 1.2. Overview 175 Like BMP, an NMP session is established between each monitored router 176 (NMP client) and the NMP monitoring station (NMP server) through TCP 177 connection. Information are collected directly from each monitored 178 router and reported to the NMP server. The NMP message can be both 179 periodic and event-triggered, depending on the message type. 181 IS-IS [RFC1195], as one of the most commonly adopted network layer 182 protocols, builds the fundamental network connectivity of an 183 autonomous system (AS). The disfunction of IS-IS, e.g., IS-IS 184 neighbor down, route flapping, MTU mismatch, and so on, could lead to 185 network-wide instability and service interruption. Thus, it is 186 critical to keep track of the health condition of IS-IS, and the 187 availability of information, related to IS-IS running status, is the 188 fundamental requirement. In this document, typical network issues 189 are illustrated as the use cases of NMP for IS-IS to showcase the 190 necessity of NMP. Then the operations and the message formats of NMP 191 for IS-IS are defined. In this document IS-IS is used as the 192 illustration protocol, and the case of OSPF and other control 193 protocols will be included in the future version. 195 2. Terminology 197 IGP: Interior Gateway Protocol 199 IS-IS: Intermediate System to Intermediate System 201 NMP: Network Monitoring Protocol 203 IMP: Network Monitoring Protocol for IGP 205 BMP: BGP monitoring protocol 207 IIH: IS-IS Hello Packet 209 LSP: Link State Packet 211 CSNP: Complete Sequence Number Packet 213 NSNP: Partial Sequence Number Packet 215 3. Use Cases 217 We have identified several typical network issues due to IS-IS 218 disfunction that are currently difficult to detect or localize. The 219 usage of NMP is not limited to the solve the following listed issues. 221 3.1. IS-IS Adjacency Issues 223 IS-IS adjacency issues are identified as top network issues and may 224 take hours to localize. The adjacency issues can be classified into 225 two situations: 227 1. An existing established adjacency goes down; 229 2. An adjacency fails to be established. 231 In Case 1, the adjacency down can be caused by factors such as 232 circuit down, hold timer expiration, device memory low, user 233 configuration change, and so on. Case 2 can be caused by mismatch 234 link MTU, mismatch authentication, mismatch area ID, system ID 235 conflict, and so on. Typically, such adjacency failure events are 236 logged/recorded in the device, but currently there is no real-time 237 report/alarm of such issue. The conventional troubleshooting process 238 for adjacency issue is to find the faulty devices and then log in to 239 check the logs or the IIH statistics for further analysis. 241 Using NMP, the IS-IS adjacency status: up, down and initial, is 242 reported to the NMP server in real time, together with the possible 243 recorded reasons. Then the NMP server can solve such issue in about 244 minutes. For example, for an adjacency set up failure due to 245 different authentications, the NMP server can recognize the 246 difference by comparing the IIHs collected from both devices. 248 3.2. Forwarding Path Disconnection 250 The PING test can be used to test the reachability of a destination 251 address. However, there are cases of disconnection that cannot be 252 detected by PING. The PING result may return a connected path, but 253 the forwarding of certain-sized packets always fails. This could be 254 caused by factors, such as mismatched MTU values for devices along 255 the path. It can be quite common since vendors have different 256 understanding and configurations of MTU. There are methods proposed 257 to discover the path MTU. For example, router's link MTU is conveyed 258 in the MPLS LDP/RSVP-TE path set up signaling, and the path MTU is 259 decided at the ingress or egress node[RFC3988] [RFC3209]. For IPv4 260 packets, by setting the DF flag bit of the outgoing packet, any 261 device along the path with smaller MTU will drop the packet, and send 262 back an ICMP Fragmentation Needed message containing its MTU, 263 allowing the source to reduce the MTU. The process is repeated until 264 the MTU is small enough to traverse the entire path without 265 fragmentation[RFC1191]. Apparently, such method is too time- 266 consuming. 268 Using NMP, each device can report its link MTU to the monitoring 269 station directly. The mismatch can be recognized at the NMP server 270 in seconds. 272 3.3. IS-IS LSP Synchronization Failure 274 It happens that two IS-IS neighbors fail to learn the LSPs sent from 275 each other in the following two cases: in Case 1, the LSP fails to be 276 received, and in Case 2, the LSP is received but the LSP information 277 shown in the receiver's LSDB is not the same as the one sent from the 278 transmitter (e.g., one or more prefixes missing, the LSP sequence 279 number modified). Case 1 can be caused by link failure, similar to 280 the adjacency down issue. In Case 2, the received LSP can be 281 processed incorrectly due to hardware/software bugs. In fact, the 282 LSDB synchronization issue is usually hard to localize once happens. 284 Using NMP, the NMP server can detect the failure by comparing the 285 sent/received LSP statistics from the two neighbors. In the case 286 that the received LSPs are improperly processed within the device, 287 the NMP monitoring station can recognize the LSP synchronization 288 failure by comparing the LSPs sent out from the two neighbors. 290 4. NMP Message Format 292 4.1. Protocol Selection Options 294 Regarding the NMP/IMP monitoring data exportion, BMP has been a good 295 option. First of all, BMP serves similar purposes of NMP that 296 reports routes, route statistics and peer status. In addition, BMP 297 has already been implemented in major vendor devices and utilized by 298 operator. Thus, we propose the following two options for the NMP 299 data exportion. 301 o Option 1: Extending BMP with new message types to carry NMP/IMP 302 data: Reusing the BMP framework saves certain implementation cost 303 for both vendors and operators. Besides, the monitoring data 304 exportion of different routing protocols (e.g., BGP, ISIS, OSPF) 305 can be unified. 307 o Option 2: Defining NMP to carry NMP/IMP data: This option defines 308 a brand new framework to carry protocol monitoring data, similar 309 to BMP. Defining a new framework provides advantages such as more 310 flexible and customized features for IGP and other protocols, 311 since the monitoring data and troubleshooting of different 312 protocols vary from one another. 314 In this document, we take Option 2 as the illustration example to 315 define the NMP message types and message formats. The decision of 316 the protocol selection may be further clarified in futures versions. 318 4.2. Message Types 320 The variety of IS-IS troubleshooting use cases requires a systematic 321 information report of NMP, so that the NMP server or any third party 322 analyzer could efficiently utilize the reported messages to localize 323 and recover various network issues. We define NMP messages for IS-IS 324 uses the following types: 326 o Initiation Message: A message used for the monitored device to 327 inform the NMP monitoring station of its capabilities, vendor, 328 software version and so on. For example, the link MTU can be 329 included within the message. The initiation message is sent once 330 the TCP connection between the monitoring station and monitored 331 router is set up. During the monitoring session, any change of 332 the initiation message could trigger an Initiation Message update. 334 o Adjacency Status Change Notification Message: A message used to 335 inform the monitoring station of the adjacency status change of 336 the monitored device, i.e., from up to down, from down/initiation 337 to up, with possible alarms/logs recorded in the device. This 338 message notifies the NMP server of the ongoing IS-IS adjacency 339 change event and possible reasons. If no reason is provided or 340 the provided reason is not specific enough, the NMP server can 341 further analyze the IS-IS PDU or the IS-IS statistics. 343 o Statistic Report Message: A message used to report the statistics 344 of the ongoing IS-IS process at the monitored device. For 345 example, abnormal LSP count of the monitored device can be a sign 346 of route flapping. This message can be sent periodically or event 347 triggered. If sent periodically, the frequency can be configured 348 by the operator depending on the monitoring requirement. If it's 349 event triggered, it could be triggered by a counter/timer 350 exceeding the threshold. 352 o IS-IS PDU Monitoring Message: A message used to update the NMP 353 server of any PDU sent from and received at the monitored device. 354 For example, the IIHs collected from two neighbors can be used for 355 analyzing the adjacency set up failure issue. The LSPs collected 356 from two neighbors can be analyzed for the LSP synchronization 357 issue. 359 o Termination Message: A message for the monitored router to inform 360 the monitoring station of why it is closing the NMP session. This 361 message is sent when the monitoring session is to be closed. 363 4.3. Message Format 365 4.3.1. Common Header 367 The common header is encapsulated in all NMP messages. It includes 368 the Version, Message Length and Message Type fields. 370 o Version (1 byte): Indicates the NMP version and is set to '1' for 371 all messages. 373 o Message Length (4 bytes): Length of the message in bytes 374 (including headers, data, and encapsulated messages, if any). 376 o Message Type (1 byte): This indicates the type of the NMP message, 377 which are listed as follows. 379 * Type = 0: Initiation 381 * Type = 1: Adjacency Status Change Notification 383 * Type = 2: Statistic Report 385 * Type = 3: IS-IS PDU Monitoring 387 * Type = 4: Termination Message 389 0 1 2 3 390 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 391 +---------------+ 392 | Version | 393 +---------------------------------------------------------------+ 394 | Message Length | 395 +---------------------------------------------------------------+ 396 | Msg. Type | 397 +---------------+ 399 4.3.2. Per Adjacency Header 401 Except the Initiation and Termination Message, all the rest messages 402 are per adjacency based. Thus, a per adjacency header is defined as 403 follows. 405 0 1 2 3 406 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 407 +---------------------------------------------------------------+ 408 | Reserved |CT| Neighbor System ID | 409 +---------------------------------------------------------------+ 410 | Neighbor System ID | 411 +-------------------------------+-------------------------------+ 412 | Neighbor Area ID | | 413 +-------------------------------+-------------------------------+ 414 | Timestamp (seconds) | 415 +---------------------------------------------------------------+ 416 | Timestamp (microseconds) | 417 +---------------------------------------------------------------+ 419 o Adjacency Flag (2 bytes): The Circuit Type (2 bits) flag specifies 420 if the router is an L1(01), L2(10), or L1/L2(11). If both bits 421 are zeroes (00), the Per Adjacency Header SHALL be ignored. This 422 configuration is used when the statistic is not per-adjacency 423 based, e.g., when reporting the number of adjacencies. 425 o Neighbor System ID (6 bytes): identifies the system ID of the 426 remote router. 428 o Neighbor Area ID (2 bytes): identifies the area ID of the remote 429 router. 431 o Timestamp (4 bytes): records the time when the message is sent/ 432 received, expressed in seconds and microseconds since midnight 433 (zero hour), January 1, 1970 (UTC). 435 4.3.3. Initiation Message 437 The Initiation Message indicates the monitored router's capabilities, 438 vendor, software version and so on. It consists of the Common Header 439 and the Router Capability TLV. The Common Header can be followed by 440 multiple Router Capability TLVs. 442 The Router Capability TLV is defined as follows. 444 0 1 2 3 445 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 446 +-------------------------------+-------------------------------+ 447 | Router Cap.Type | Router Cap. Length | 448 +-------------------------------+-------------------------------+ 449 + Router Cap. Value (variable) + 450 ~ ~ 451 +---------------------------------------------------------------+ 453 o Router Capability Type: provides the type of the router capability 454 information. Currently defined types are: 456 * Type = 0: sysDescr. The corresponding Router Capability Value 457 field should contain an ASCII string whose value MUST be set to 458 be equal to the value of the sysDescr MIB-II [RFC1213] object. 460 * Type = 1: sysName. The corresponding Router Capability Value 461 field should contain an ASCII string whose value MUST be set to 462 be equal to the value of the sysName MIB-II [RFC1213] object. 464 * Type = 2: Local System ID. The corresponding Router Capability 465 Value field SHALL indicate the router's System ID 467 * Type = 3: Link MTU. The corresponding Router Capability Value 468 field SHALL indicate the router's link MTU. 470 * Type = 4: String. The corresponding Router Capability Value 471 field contains a free-form UTF-8 string whose length is given 472 by the Information Length field. 474 4.3.4. Adjacency Status Change Notification 476 The Adjacency Status Change Notification Message indicates an IS-IS 477 adjacency status change: from up to down or from initiation/down to 478 up. It consists of the Common Header, Per Adjacency Header and the 479 Reason TLV. The Notification is triggered whenever the status 480 changes. The Reason TLV is optional, and is defined as follows. 481 More Reason types can be defined if necessary. 483 0 1 2 3 484 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 485 +-------------------------------+-------------------------------+ 486 | Reserved |S| Reason Type | Reason Length | 487 +-------------------------------+-------------------------------+ 488 + Reason Value (variable) + 489 ~ ~ 490 +---------------------------------------------------------------+ 492 o Reason Flags (1 byte): The S flag (1 bit) indicates if the 493 Adjacency status is from up to down (set to 0) or from down/ 494 initial to up (set to 1). The rest bits of the Flag field are 495 reserved. When the S flag is set to 1, the Reason Type SHALL be 496 set to all zeroes (i.e., Type 0), the Reason Length fields SHALL 497 be set to all zeroes, and the Reason Value field SHALL be set 498 empty. 500 o Reason Type (1 byte): indicates the possible reason that caused 501 the adjacency status change. Currently defined types are: 503 * Type = 0: Adjacency Up. This type indicates the establishment 504 of an adjacency. For this reason type, the S flag MUST be set 505 to 1, indicating it's a adjacency-up event. There's no further 506 reason to be provided. The reason Length field SHALL be set to 507 all zeroes, and the Reason Value field SHALL be set empty. 509 * Type = 1: Circuit Down. For this data type, the S flag MUST be 510 set to 0, indicating it's a adjacency-down event. The length 511 field is set to all zeroes, and the value field is set empty. 513 * Type = 2: Memory Low. For this data type, the S flag MUST be 514 set to 0, indicating it's a adjacency-down event. The length 515 field is set to all zeroes, and the value field is set empty. 517 * Type = 3: Hold timer expired. For this data type, the S flag 518 MUST be set to 0, indicating it's a adjacency-down event. The 519 length field is set to all zeroes, and the value field is set 520 empty. 522 * Type = 4: String. For this data type, the S flag MUST be set 523 to 0, indicating it's a adjacency-down event. The 524 corresponding Reason Value field indicates the reason specified 525 by the monitored router in a free-form UTF-8 string whose 526 length is given by the Reason Length field. 528 o Reason Length (2 bytes): indicates the length of the Reason Value 529 field. 531 o Reason Value (variable): includes the possible reason why the 532 Adjacency is down. 534 4.3.5. Statistic Report Message 536 The Statistic Report Message reports the statistics of the parameters 537 that are of interest to the operator. The message consists of the 538 NMP Common Header, the Per Adjacency Header and the Statistic TLV. 539 The message include both per-adjacency based statistics and non per- 540 adjacency based statistics. For example, the received/sent LSP 541 counts are per-adjacency based statistics, and the local LSP change 542 times count and the number of established adjacencies are non per- 543 adjacency based statistics. For the non per-adjacency based 544 statistics, the CT Flag (2 bits) in the Per Adjacency Header MUST be 545 set to 00. Upon receiving any message with CT flag set to 00, the 546 Per Adjacency Header SHALL be ignored (the total length of the Per 547 Adjacency Header is 18 bytes as defined in Section 3.2.2, and the 548 message reading/analysis SHALL resume from the Statistic TLV part. 550 The Statistic TLV is defined as follows. 552 0 1 2 3 553 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 554 +---------------------------------------------------------------+ 555 | Reserved |T| Statistic Type| Statistic Length | 556 +---------------------------------------------------------------+ 557 | Statistic Value | 558 +---------------------------------------------------------------+ 560 o Statistic Flags (1 byte): provides information for the reported 561 statistics. 563 * T flag (1 bit): indicates if the statistic is for the received- 564 from direction (set to 1) or sent-to direction the neighbor 565 (set to 0) 567 o Statistic Type (1 byte): specifies the statistic type of the 568 counter. Currently defined types are: 570 * Type = 0: IIH count. The T flag indicates if it's a sent or 571 received Hello PDU. It is a per-adjacency based statistic 572 type, and the CT flag in the Per Adjacency Header MUST NOT be 573 set to 00. 575 * Type = 1: Incorrect IIH received count. For this type, the T 576 flag MUST be set to 1. It is a per-adjacency based statistic 577 type, and the CT flag in the Per Adjacency Header MUST NOT be 578 set to 00. 580 * Type = 2: LSP count. The T flag indicates if it's a sent or 581 received LSP. It is a per-adjacency based statistic type, and 582 the CT flag in the Per Adjacency Header MUST NOT be set to 00. 584 * Type = 3: Incorrect LSP received count. For this type, the T 585 flag MUST be set to 1. It is a per-adjacency based statistic 586 type, and the CT flag in the Per Adjacency Header MUST NOT be 587 set to 00. 589 * Type = 4: Retransmitted LSP count. For this type, the T flag 590 MUST be set to 0. It is a per-adjacency based statistic type, 591 and the CT flag in the Per Adjacency Header MUST NOT be set to 592 00. 594 * Type = 5: CSNP count. The T flag indicates if it's a sent or 595 received CSNP. It is a per-adjacency based statistic type, and 596 the CT flag in the Per Adjacency Header MUST NOT be set to 00. 598 * Type = 6: PSNP count. The T flag indicates if it's a sent or 599 received PSNP. It is a per-adjacency based statistic type, and 600 the CT flag in the Per Adjacency Header MUST NOT be set to 00. 602 * Type = 7: Number of established adjacencies. It's a non per- 603 adjacency based statistic type, and thus for the monitoring 604 station to recognize this type, the CT flag in the Per 605 Adjacency Header MUST be set to 00. 607 * Type = 8: LSP change time count. It's a non per-adjacency 608 based statistic type, and thus for the monitoring station to 609 recognize this type, the CT flag in the Per Adjacency Header 610 MUST be set to 00. 612 o Statistic Length (2 bytes): indicates the length of the Statistic 613 Value field. 615 o Statistic Value (4 bytes): specifies the counter value, which is a 616 non-negative integer. 618 4.3.6. IS-IS PDU Monitoring Message 620 The IS-IS PDU Monitoring Message is used to update the monitoring 621 station of any PDU sent from and received at the monitored device per 622 neighbor. Following the Common Header and the Per Adjacency Header 623 is the IS-IS PDU. To tell whether it's a sent or received PDU, the 624 monitoring station can analyze the source and destination addresses 625 in the reported PDUs. 627 4.3.7. Termination Message 629 The Termination Message is sent when the NMP session is to be closed, 630 and is used to indicate the termination reason to the monitoring 631 station. The TCP session between the monitored router and the 632 monitoring station SHALL be terminated upon receiving this message. 633 It consists of the Common Header and the Termination Info TLVs, 634 defined as follows. 636 0 1 2 3 637 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 638 +-------------------------------+-------------------------------+ 639 | Termination Info Type | Termination Info Length | 640 +-------------------------------+-------------------------------+ 641 + Termination Info Value (variable) + 642 ~ ~ 643 +---------------------------------------------------------------+ 645 o Termination Info Type (2 bytes): Provides the termination reason 646 type. Currently defined types are: 648 * Type = 0: Unknown. This reason type specifies that the NMP 649 session is closed for an unknown or unspecified reason. For 650 this data type, the length field is filled with all zeroes, and 651 the value field is set empty. 653 * Type = 1: Memory Low. This reason indicates that the monitored 654 router lacks resources for the NMP session. For this data 655 type, the length field is filled with all zeroes, and the value 656 field is set empty. 658 * Type = 2: Administratively Closed. This reason specifies that 659 the session is closed due to administrative reasons. The 660 corresponding Termination Info Value field may include more 661 details about the reason expressed in a free-form UTF-8 string 662 whose length is given by the Termination Info Length field. 664 * Type = 3: String. The corresponding Termination Info Value 665 field may include details about the reason expressed in a free- 666 form UTF-8 string whose length is given by the Termination Info 667 Length field. 669 Termination Info Length (2 bytes): indicates the length of the 670 Termination Info Reason Value field. 672 o Termination Info Value (variable): includes more detailed reason 673 for the session termination. 675 5. IANA 677 TBD 679 6. Contributors 681 TBD 683 7. Acknowledgments 685 TBD 687 8. References 689 [I-D.brockners-inband-oam-requirements] 690 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 691 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 692 T., <>, P., and r. remy@barefootnetworks.com, 693 "Requirements for In-situ OAM", draft-brockners-inband- 694 oam-requirements-03 (work in progress), March 2017. 696 [I-D.ietf-netconf-yang-push] 697 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 698 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 699 Subscription", draft-ietf-netconf-yang-push-17 (work in 700 progress), July 2018. 702 [I-D.openconfig-rtgwg-gnmi-spec] 703 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 704 C., and C. Morrow, "gRPC Network Management Interface 705 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 706 progress), March 2018. 708 [I-D.song-ntf] 709 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 710 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 711 Network Telemetry Framework", draft-song-ntf-02 (work in 712 progress), July 2018. 714 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 715 "Simple Network Management Protocol (SNMP)", RFC 1157, 716 DOI 10.17487/RFC1157, May 1990, 717 . 719 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 720 DOI 10.17487/RFC1191, November 1990, 721 . 723 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 724 dual environments", RFC 1195, DOI 10.17487/RFC1195, 725 December 1990, . 727 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 728 for Network Management of TCP/IP-based internets: MIB-II", 729 STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991, 730 . 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, 734 DOI 10.17487/RFC2119, March 1997, 735 . 737 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 738 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 739 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 740 . 742 [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit 743 Signalling Extensions for the Label Distribution 744 Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, 745 . 747 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 748 and A. Bierman, Ed., "Network Configuration Protocol 749 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 750 . 752 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 753 S. Ray, "North-Bound Distribution of Link-State and 754 Traffic Engineering (TE) Information Using BGP", RFC 7752, 755 DOI 10.17487/RFC7752, March 2016, 756 . 758 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 759 Monitoring Protocol (BMP)", RFC 7854, 760 DOI 10.17487/RFC7854, June 2016, 761 . 763 Authors' Addresses 765 Yunan Gu 766 Huawei 767 156 Beiqing Road 768 Beijing, 100095 769 P.R. China 771 Email: guyunan@huawei.com 773 Shunwan Zhuang 774 Huawei 775 156 Beiqing Road 776 Beijing, 100095 777 P.R. China 779 Email: zhuangshunwan@huawei.com 781 Zhenbin Li 782 Huawei 783 156 Beiqing Road 784 Beijing, 100095 785 P.R. China 787 Email: lizhenbin@huawei.com