idnits 2.17.1 draft-gu-opsawg-network-monitoring-igp-01.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 (February 19, 2021) is 1160 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.chen-npm-use-cases' is defined on line 599, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-push' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 645, 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') ** Downref: Normative reference to an Informational draft: draft-chen-npm-use-cases (ref. 'I-D.chen-npm-use-cases') ** 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 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 9 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. Chen 4 Intended status: Standards Track Huawei 5 Expires: August 23, 2021 Y. Qu 6 Futurewei 7 H. Chen 8 China Telecom 9 Z. Li 10 Huawei 11 February 19, 2021 13 Network Monitoring For IGP 14 draft-gu-opsawg-network-monitoring-igp-01 16 Abstract 18 To evolve towards automated network OAM (Operations, administration 19 and management), the monitoring of control plane protocols is a 20 fundamental necessity. This document proposes network monitoring for 21 IGP to facilitate troubleshooting by collecting the IGP monitoring 22 data and reporting it to the network monitoring server in real-time. 23 In this document, the operations of network monitoring for ISIS are 24 described, and the corresponding network monitoring message types and 25 message formats are defined. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 23, 2021. 50 Copyright Notice 52 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. IS-IS Route Flapping . . . . . . . . . . . . . . . . . . 5 73 3.2. IS-IS LSDB Synchronization Failure . . . . . . . . . . . 6 74 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Protocol Selection Options . . . . . . . . . . . . . . . 7 76 4.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 7 77 4.3. Message Format . . . . . . . . . . . . . . . . . . . . . 8 78 4.3.1. Common Header . . . . . . . . . . . . . . . . . . . . 8 79 4.3.2. Per Adjacency Header . . . . . . . . . . . . . . . . 8 80 4.3.3. Initiation Message . . . . . . . . . . . . . . . . . 9 81 4.3.4. Adjacency Status Change Notification . . . . . . . . 9 82 4.3.5. ISIS Statistic Report Message . . . . . . . . . . . . 11 83 4.3.6. IS-IS PDU Monitoring Message . . . . . . . . . . . . 12 84 4.3.7. Termination Message . . . . . . . . . . . . . . . . . 13 85 5. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 91 1. Introduction 93 1.1. Motivation 95 The requirement for better network OAM approaches has been greatly 96 driven by the network evolvement. The concept of network Telemetry 97 has been proposed to meet the current and future OAM demands w.r.t., 98 massive and real-time data storage, collection, process, export, and 99 analysis, and an architectural framework of existing Telemetry 100 approaches is introduced in [I-D.song-ntf]. Network Telemetry 101 provides visibility to the network health conditions, and is 102 beneficial for faster network troubleshooting, network OpEx 103 (operating expenditure) reduction, and network optimization. 104 Telemetry can be applied to the data plane, control plane and 105 management plane. There have been various methods proposed for each 106 plane: 108 o Management plane: For example, SNMP (Simple Network Management 109 Protocol) [RFC1157], NETCONF (Network Configuration Protocol) 110 [RFC6241] and gNMI (gRPC Network Management Interface) 111 [I-D.openconfig-rtgwg-gnmi-spec] are three typical widely adopted 112 management plane Telemetry approaches. Various YANG modules are 113 defined for network operational state retrieval and configuration 114 management. Subscription to specific YANG datastore can be 115 realized in combination with gRPC/NETCONF. 117 o Data plane: For example, In-situ OAM (iOAM) 118 [I-D.brockners-inband-oam-requirements] embeds an instruction 119 header to the user data packets, and collects the requested data 120 and adds it to the use packet at each network node along the 121 forwarding path. Applications such as path verification, SLA 122 (service-level agreement) assurance can be enabled with iOAM. 124 o Control Plane: BGP monitoring protocol (BMP) [RFC7854] is proposed 125 to monitor BGP sessions and intended to provide a convenient 126 interface for obtaining BGP route views. Date collected using BMP 127 can be further analyzed with big data platforms for network health 128 condition visualization, diagnose and prediction applications. 130 The general idea of most Telemetry approaches is to collect various 131 information from devices and export to the centralized server for 132 further analysis, and thus providing more network insight. It should 133 not be surprising that any future and even current Telemetry 134 applications may require the fusion of data acquired from more than 135 one single approach/one single plane. For example, for network 136 troubleshooting purposes, it requires the collection of comprehensive 137 information from devices, such system ID/router ID, interface status, 138 PDUs (protocol data units), device/protocol statistics and so on. 139 Information such as system ID/router ID can be reported by management 140 plane Telemetry approaches, while the protocol related data 141 (especially PDUs) are more fit to be monitored using the control 142 plane Telemetry. With rich information collected in real time at the 143 centralized server, network issues can be localized faster and more 144 accurately, and the root cause analysis can be also provided. 146 The conventional troubleshooting logic is to log in a faulty router, 147 physically or through Telnet, and by using CLI to display related 148 information/logs for fault source localization and further analysis. 149 There are several concerns with the conventional troubleshooting 150 methods: 152 1. It requires rich OAM experience for the OAM operator to know what 153 information to check on the device, and the operation is complex; 155 2. In a multi-vendor network, it requires the understanding and 156 familiarity of vendor specific operations and configurations; 158 3. Locating the fault source device could be non-trivial work, and 159 is often realized through network-wide device-by-device check, which 160 is both time-consuming and labor-consuming; and finally, 162 4. The acquisition of troubleshooting data can be difficult under 163 some cases, e.g., when auto recovery is used. 165 This document proposes the network monitoring for IGP to monitor the 166 running state of IGP, e.g., PDUs, protocol statistics and peer 167 status, which have not been systematically covered by any other 168 Telemetry approach, to facilitate network troubleshooting. 170 1.2. Overview 172 Like BMP, a networking monitoring session is established between each 173 monitored router (NM client) and the NM monitoring station (NM 174 server) through TCP connection. Information are collected directly 175 from each monitored router and reported to the NM server. The NM 176 message can be both periodic and event-triggered, depending on the 177 message type. 179 IS-IS [RFC1195], as one of the most commonly adopted network layer 180 protocols, builds the fundamental network connectivity of an 181 autonomous system (AS). The disfunction of IS-IS, e.g., IS-IS 182 neighbor down, route flapping, MTU mismatch, and so on, could lead to 183 network-wide instability and service interruption. Thus, it is 184 critical to keep track of the health condition of IS-IS, and the 185 availability of information, related to IS-IS running status, is the 186 fundamental requirement. In this document, typical network issues 187 are identified as the use cases of network monitoring. Then the 188 operations and the message formats of network monitoring for IS-IS 189 are defined. Network monitoring for OSPF will be included in the 190 future version. 192 2. Terminology 194 IGP: Interior Gateway Protocol 196 IS-IS: Intermediate System to Intermediate System 198 NM: Network Monitoring 200 IMP: Network Monitoring for IGP 202 BMP: BGP monitoring protocol 204 IIH: IS-IS Hello Packet 206 LSP: Link State Packet 208 CSNP: Complete Sequence Number Packet 210 NSNP: Partial Sequence Number Packet 212 3. Use Cases 214 We have identified two typical network issues due to IS-IS 215 disfunction that are currently difficult to detect or localize. 217 3.1. IS-IS Route Flapping 219 The IS-IS Route Flapping refers to the situation that one or more 220 routes appear and then disappear in the routing table repeatedly. 221 Route flapping usually comes with massive PDUs interactions (e.g., 222 LSP, LSP purge...), which consume excessive network bandwidth, and 223 excessive CPU processing. In addition, the impact is often network- 224 wide. The localizing of the flapping source and the identifying of 225 root causes haven't been easy work due to various reasons. 227 The flapping can be caused by system ID conflict, IS-IS neighborship 228 flapping, route source flapping (caused by import route policy 229 misconfiguration) , device clock dis-function with abnormal LSP purge 230 (e.g., 100 times faster) and so on. 232 o The system ID conflict check is a network-wide work. If such 233 information is collected centrally to a controller/server, the 234 issues can be identified in seconds, and more importantly, in 235 advance of the actual flapping event. 237 o The IS-IS neighborship flapping is typically caused by interface 238 flapping, BFD flapping, CPU high and so on. Conventionally, to 239 located the issue, operators typically identify the target 240 device(s), and then log in the devices to check related 241 statistics, parsed protocol PDU data and configurations. The 242 manual check often requires a combination of multiple CLIs (check 243 cost/next hop/exit interface/LSP age...) in a repeated manner, 244 which is time-consuming and requires rich OAM experience. If such 245 statistics and configuration data were collected at the server in 246 real-time, the server may analyze them automatically or semi- 247 automatically with troubleshooting algorithms implemented at the 248 server. 250 o In the case that route policies are misconfigured, which then 251 causes the route flapping, it's typically difficult to directly 252 identify the responsible policy in a short time. Thus, if the 253 route change history is recorded in correlation with the route 254 policy, then with such record collected at the server, the server 255 can directly identify the responsible policy with the one-to-one 256 mapping between policy processing and the route attribute change. 258 o In the case that flapping comes with abnormal LSP purges, it may 259 be due to continuous LSP corruptions with falsified shorter 260 Remaining Lifetime, or the clock running 100 times faster with 100 261 times more purge LSPs generated. In order to identify the purge 262 originator, RFC 6232 [RFC6232] proposes to carry the Purge 263 Orginator Identification (POI) TLV in IS-IS. However, to analyze 264 the root cause of such abnormal purges, the collection and 265 analysis of LSP PDUs are needed. 267 3.2. IS-IS LSDB Synchronization Failure 269 During the IS-IS flooding, sometimes the LSP synchronization failure 270 happens. The synchronization failure causes can be generally 271 classified into three cases: 273 o Case 1, the LSP is not correctly advertised. For example, an LSP 274 sent by Router A fails to be synchronized at Router B. It can be 275 due to incorrect route export policy, or too many prefixes being 276 advertised which exceeds the LSP/MTU threshold, and so on at 277 Router A. 279 o Case 2, LSP transmission error, which is typically caused by IS-IS 280 adjacency failure, .e.g., link down/BFD down/authentication 281 failure. 283 o Case 3, the LSP is received but not correctly processed. The 284 problem that happens at Router B can be faulty route import 285 policy, or Router B being in Overload mode, or the hardware/ 286 software bugs. 288 With sufficient ISIS PDU related statistics and parsed PDU 289 information recorded at the device, the neighborship failure in Case 290 2 can be typically diagnosed at Router A or Router B independently. 291 With such diagnosing information collected (e.g., in the format of 292 reason code) in real-time, the server can identify the root 293 synchronization issue with much less time and labor consumption 294 compared with conventional methods. In Case 1 & 3, the failure is 295 mostly caused by incorrect route policy and software/hardware issue. 296 By comparing the LSDB with the sent/received LSP, differences can be 297 recognized. Then the difference may further guide the localization 298 of the root cause. Thus, by collecting the LSDBs and sent/received 299 LSPs from the two affected neighbors, the server can have more 300 insights at the synchronization failure. 302 4. Message Format 304 4.1. Protocol Selection Options 306 Regarding the network monitoring data export, BMP has been a good 307 option. First of all, BMP serves similar purposes of network 308 monitoring for IGP that reports routes, route statistics and peer 309 status. In addition, BMP has already been implemented in major 310 vendor devices and utilized by operator. 312 4.2. Message Types 314 The variety of IS-IS troubleshooting use cases requires a systematic 315 information report of network monitoring, so that the NM server or 316 any third party analyzer could efficiently utilize the reported 317 messages to localize and recover various network issues. We define 318 NM messages for IS-IS uses the following types: 320 o Initiation Message: A message used for the monitored device to 321 inform the NM monitoring station of its capabilities, vendor, 322 software version and so on. For example, the link MTU can be 323 included within the message. The initiation message is sent once 324 the TCP connection between the monitoring station and monitored 325 router is set up. During the monitoring session, any change of 326 the initiation message could trigger an Initiation Message update. 328 o Adjacency Status Change Notification Message: A message used to 329 inform the NM monitoring station of the adjacency status change of 330 the monitored device, i.e., from up to down, from down/initiation 331 to up, with possible alarms/logs recorded in the device. This 332 message notifies the NM server of the ongoing IS-IS adjacency 333 change event and possible reasons. If no reason is provided or 334 the provided reason is not specific enough, the NM server can 335 further analyze the IS-IS PDU or the IS-IS statistics. 337 o Statistic Report Message: A message used to report the statistics 338 of the ongoing IS-IS process at the monitored device. For 339 example, abnormal LSP count of the monitored device can be a sign 340 of route flapping. This message can be sent periodically or event 341 triggered. If sent periodically, the frequency can be configured 342 by the operator depending on the monitoring requirement. If it's 343 event triggered, it could be triggered by a counter/timer 344 exceeding the threshold. 346 o IS-IS PDU Monitoring Message: A message used to update the NM 347 server of any PDU sent from and received at the monitored device. 348 For example, the IIHs collected from two neighbors can be used for 349 analyzing the adjacency set up failure issue. The LSPs collected 350 from two neighbors can be analyzed for the LSP synchronization 351 issue. 353 o Termination Message: A message for the monitored router to inform 354 the monitoring station of why it is closing the NM session. This 355 message is sent when the monitoring session is to be closed. 357 4.3. Message Format 359 4.3.1. Common Header 361 The common header is encapsulated in all messages of network 362 monitoring for IGP. It includes the Version, Message Length and 363 Message Type fields. The common header can reuse the common header 364 of BMP and new message types should defined for IGP monitoring. 366 o Type = TBD: Adjacency Status Change Notification 368 o Type = TBD: ISIS Statistic Report 370 o Type = TBD: IS-IS PDU Monitoring 372 4.3.2. Per Adjacency Header 374 Except the Initiation and Termination Message, all the rest messages 375 are per adjacency based. Thus, a per adjacency header is defined as 376 follows. 378 0 1 2 3 379 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 380 +---------------------------------------------------------------+ 381 | Reserved |CT| Neighbor System ID | 382 +---------------------------------------------------------------+ 383 | Neighbor System ID | 384 +-------------------------------+-------------------------------+ 385 | Neighbor Area ID | | 386 +-------------------------------+-------------------------------+ 387 | Timestamp (seconds) | 388 +---------------------------------------------------------------+ 389 | Timestamp (microseconds) | 390 +---------------------------------------------------------------+ 392 o Adjacency Flag (2 bytes): The Circuit Type (2 bits) flag specifies 393 if the router is an L1(01), L2(10), or L1/L2(11). If both bits 394 are zeroes (00), the Per Adjacency Header SHALL be ignored. This 395 configuration is used when the statistic is not per-adjacency 396 based, e.g., when reporting the number of adjacencies. 398 o Neighbor System ID (6 bytes): identifies the system ID of the 399 remote router. 401 o Neighbor Area ID (2 bytes): identifies the area ID of the remote 402 router. 404 o Timestamp (4 bytes): records the time when the message is sent/ 405 received, expressed in seconds and microseconds since midnight 406 (zero hour), January 1, 1970 (UTC). 408 4.3.3. Initiation Message 410 Three new types of Router Capability TLVs should be defined for IGP 411 monitoring: 413 o Type = TBD: Local System ID. The corresponding Router Capability 414 Value field SHALL indicate the router's System ID 416 o Type = TBD: Link MTU. The corresponding Router Capability Value 417 field SHALL indicate the router's link MTU. 419 4.3.4. Adjacency Status Change Notification 421 The Adjacency Status Change Notification Message indicates an IS-IS 422 adjacency status change: from up to down or from initiation/down to 423 up. It consists of the Common Header, Per Adjacency Header and the 424 Reason TLV. The Notification is triggered whenever the status 425 changes. The Reason TLV is optional, and is defined as follows. 426 More Reason types can be defined if necessary. 428 0 1 2 3 429 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 430 +-------------------------------+-------------------------------+ 431 | Reserved |S| Reason Type | Reason Length | 432 +-------------------------------+-------------------------------+ 433 + Reason Value (variable) + 434 ~ ~ 435 +---------------------------------------------------------------+ 437 o Reason Flags (1 byte): The S flag (1 bit) indicates if the 438 Adjacency status is from up to down (set to 0) or from down/ 439 initial to up (set to 1). The rest bits of the Flag field are 440 reserved. When the S flag is set to 1, the Reason Type SHALL be 441 set to all zeroes (i.e., Type 0), the Reason Length fields SHALL 442 be set to all zeroes, and the Reason Value field SHALL be set 443 empty. 445 o Reason Type (1 byte): indicates the possible reason that caused 446 the adjacency status change. Currently defined types are: 448 * Type = 0: Adjacency Up. This type indicates the establishment 449 of an adjacency. For this reason type, the S flag MUST be set 450 to 1, indicating it's a adjacency-up event. There's no further 451 reason to be provided. The reason Length field SHALL be set to 452 all zeroes, and the Reason Value field SHALL be set empty. 454 * Type = 1: Circuit Down. For this data type, the S flag MUST be 455 set to 0, indicating it's a adjacency-down event. The length 456 field is set to all zeroes, and the value field is set empty. 458 * Type = 2: Memory Low. For this data type, the S flag MUST be 459 set to 0, indicating it's a adjacency-down event. The length 460 field is set to all zeroes, and the value field is set empty. 462 * Type = 3: Hold timer expired. For this data type, the S flag 463 MUST be set to 0, indicating it's a adjacency-down event. The 464 length field is set to all zeroes, and the value field is set 465 empty. 467 * Type = 4: String. For this data type, the S flag MUST be set 468 to 0, indicating it's a adjacency-down event. The 469 corresponding Reason Value field indicates the reason specified 470 by the monitored router in a free-form UTF-8 string whose 471 length is given by the Reason Length field. 473 o Reason Length (2 bytes): indicates the length of the Reason Value 474 field. 476 o Reason Value (variable): includes the possible reason why the 477 Adjacency is down. 479 4.3.5. ISIS Statistic Report Message 481 The ISIS Statistic Report Message reports the statistics of the 482 parameters that are of interest to the operator. The message 483 consists of the Common Header, the Per Adjacency Header and the 484 Statistic TLV. The message include both per-adjacency based 485 statistics and non per- adjacency based statistics. For example, the 486 received/sent LSP counts are per-adjacency based statistics, and the 487 local LSP change times count and the number of established 488 adjacencies are non per- adjacency based statistics. For the non 489 per-adjacency based statistics, the CT Flag (2 bits) in the Per 490 Adjacency Header MUST be set to 00. Upon receiving any message with 491 CT flag set to 00, the Per Adjacency Header SHALL be ignored (the 492 total length of the Per Adjacency Header is 18 bytes as defined in 493 Section 3.2.2, and the message reading/analysis SHALL resume from the 494 Statistic TLV part. 496 The Statistic TLV is defined as follows. 498 0 1 2 3 499 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 500 +---------------------------------------------------------------+ 501 | Reserved |T| Statistic Type| Statistic Length | 502 +---------------------------------------------------------------+ 503 | Statistic Value | 504 +---------------------------------------------------------------+ 506 o Statistic Flags (1 byte): provides information for the reported 507 statistics. 509 * T flag (1 bit): indicates if the statistic is for the received- 510 from direction (set to 1) or sent-to direction the neighbor 511 (set to 0) 513 o Statistic Type (1 byte): specifies the statistic type of the 514 counter. Currently defined types are: 516 * Type = 0: IIH count. The T flag indicates if it's a sent or 517 received Hello PDU. It is a per-adjacency based statistic 518 type, and the CT flag in the Per Adjacency Header MUST NOT be 519 set to 00. 521 * Type = 1: Incorrect IIH received count. For this type, the T 522 flag MUST be set to 1. It is a per-adjacency based statistic 523 type, and the CT flag in the Per Adjacency Header MUST NOT be 524 set to 00. 526 * Type = 2: LSP count. The T flag indicates if it's a sent or 527 received LSP. It is a per-adjacency based statistic type, and 528 the CT flag in the Per Adjacency Header MUST NOT be set to 00. 530 * Type = 3: Incorrect LSP received count. For this type, the T 531 flag MUST be set to 1. It is a per-adjacency based statistic 532 type, and the CT flag in the Per Adjacency Header MUST NOT be 533 set to 00. 535 * Type = 4: Retransmitted LSP count. For this type, the T flag 536 MUST be set to 0. It is a per-adjacency based statistic type, 537 and the CT flag in the Per Adjacency Header MUST NOT be set to 538 00. 540 * Type = 5: CSNP count. The T flag indicates if it's a sent or 541 received CSNP. It is a per-adjacency based statistic type, and 542 the CT flag in the Per Adjacency Header MUST NOT be set to 00. 544 * Type = 6: PSNP count. The T flag indicates if it's a sent or 545 received PSNP. It is a per-adjacency based statistic type, and 546 the CT flag in the Per Adjacency Header MUST NOT be set to 00. 548 * Type = 7: Number of established adjacencies. It's a non per- 549 adjacency based statistic type, and thus for the monitoring 550 station to recognize this type, the CT flag in the Per 551 Adjacency Header MUST be set to 00. 553 * Type = 8: LSP change time count. It's a non per-adjacency 554 based statistic type, and thus for the monitoring station to 555 recognize this type, the CT flag in the Per Adjacency Header 556 MUST be set to 00. 558 o Statistic Length (2 bytes): indicates the length of the Statistic 559 Value field. 561 o Statistic Value (4 bytes): specifies the counter value, which is a 562 non-negative integer. 564 4.3.6. IS-IS PDU Monitoring Message 566 The IS-IS PDU Monitoring Message is used to update the monitoring 567 station of any PDU sent from and received at the monitored device per 568 neighbor. Following the Common Header and the Per Adjacency Header 569 is the IS-IS PDU. To tell whether it's a sent or received PDU, the 570 monitoring station can analyze the source and destination addresses 571 in the reported PDUs. 573 4.3.7. Termination Message 575 This document does not change the Termination Message defined by 576 RFC7854. 578 5. IANA 580 TBD 582 6. Contributors 584 TBD 586 7. Acknowledgments 588 TBD 590 8. References 592 [I-D.brockners-inband-oam-requirements] 593 Brockners, F., Bhandari, S., Dara, S., Pignataro, C., 594 Gredler, H., Leddy, J., Youell, S., Mozes, D., Mizrahi, 595 T., Lapukhov, P., and r. remy@barefootnetworks.com, 596 "Requirements for In-situ OAM", draft-brockners-inband- 597 oam-requirements-03 (work in progress), March 2017. 599 [I-D.chen-npm-use-cases] 600 Chen, H., Li, Z., Xu, F., Gu, Y., and Z. Li, "Network-wide 601 Protocol Monitoring (NPM): Use Cases", draft-chen-npm-use- 602 cases-00 (work in progress), March 2019. 604 [I-D.ietf-netconf-yang-push] 605 Clemm, A. and E. Voit, "Subscription to YANG Datastores", 606 draft-ietf-netconf-yang-push-25 (work in progress), May 607 2019. 609 [I-D.openconfig-rtgwg-gnmi-spec] 610 Shakir, R., Shaikh, A., Borman, P., Hines, M., Lebsack, 611 C., and C. Morrow, "gRPC Network Management Interface 612 (gNMI)", draft-openconfig-rtgwg-gnmi-spec-01 (work in 613 progress), March 2018. 615 [I-D.song-ntf] 616 Song, H., Zhou, T., Li, Z., Fioccola, G., Li, Z., 617 Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Toward a 618 Network Telemetry Framework", draft-song-ntf-02 (work in 619 progress), July 2018. 621 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 622 "Simple Network Management Protocol (SNMP)", RFC 1157, 623 DOI 10.17487/RFC1157, May 1990, 624 . 626 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 627 dual environments", RFC 1195, DOI 10.17487/RFC1195, 628 December 1990, . 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, 632 DOI 10.17487/RFC2119, March 1997, 633 . 635 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 636 Originator Identification TLV for IS-IS", RFC 6232, 637 DOI 10.17487/RFC6232, May 2011, 638 . 640 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 641 and A. Bierman, Ed., "Network Configuration Protocol 642 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 643 . 645 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 646 S. Ray, "North-Bound Distribution of Link-State and 647 Traffic Engineering (TE) Information Using BGP", RFC 7752, 648 DOI 10.17487/RFC7752, March 2016, 649 . 651 [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP 652 Monitoring Protocol (BMP)", RFC 7854, 653 DOI 10.17487/RFC7854, June 2016, 654 . 656 Authors' Addresses 657 Yunan Gu 658 Huawei 659 156 Beiqing Road 660 Beijing, 100095 661 China 663 Email: guyunan@huawei.com 665 Shuanglong Chen 666 Huawei 667 156 Beiqing Road 668 Beijing,100095 669 China 671 Email: chenshuanglong@huawei.com 673 Yingzhen Qu 674 Futurewei 675 United States 677 Email: yingzhen.qu@futurewei.com 679 Huanan Chen 680 China Telecom 681 109 West Zhongshan Ave 682 Guangzhou 683 China 685 Email: chenhuanan@189.com 687 Zhenbin Li 688 Huawei 689 156 Beiqing Road 690 Beijing, 100095 691 China 693 Email: lizhenbin@huawei.com