idnits 2.17.1 draft-tian-bupt-inwt-mechanism-policy-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2020) is 1272 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1157' is defined on line 595, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BUPT T. Pan 3 Internet-Draft M. Gao 4 Intended status: Informational E. Song 5 Expires: April 28, 2021 Z. Bian 6 X. Lin 7 Beijing University of Posts and Telecommunications 8 October 25, 2020 10 In-band Network-Wide Telemetry 11 draft-tian-bupt-inwt-mechanism-policy-01 13 Abstract 15 This document describes INT-path, a cost-effective network-wide 16 telemetry framework based on INT (In-band Network Telemetry), by 17 decoupling the network monitoring system into a routing mechanism and 18 a routing path generation policy. INT-path embeds SR (Source 19 Routing) into INT probes to allow specifying the route that the probe 20 packet takes through the network. Above this probing path control 21 mechanism, an Euler trail-based path planning policy is developed to 22 generate non-overlapped INT paths that cover the entire network with 23 a minimum path number, reducing the overall telemetry overhead. INT- 24 path is very suitable for deployment in data center networks thanks 25 to their symmetric topologies. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119][RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 28, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Source Routing-based Path Monitoring (Mechanism) . . . . . . 4 71 3.1. Packet Header Format . . . . . . . . . . . . . . . . . . 5 72 3.2. Forwarding Behaviors . . . . . . . . . . . . . . . . . . 6 73 4. DFS-based path planning algorithm . . . . . . . . . . . . . . 8 74 4.1. Algorithm Outline . . . . . . . . . . . . . . . . . . . . 8 75 4.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Euler trail-based path planning algorithm . . . . . . . . . . 10 77 5.1. Algorithm Outline . . . . . . . . . . . . . . . . . . . . 10 78 5.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 At present, conducting fine-grained, network-wide traffic monitoring 89 plays an increasingly significant role in maintaining large-scale 90 computer networks. It enables fine-grained network-wide visibility 91 to ease the fast detection and localization of network gray 92 failures[Jia]. It also improves the network traffic load balancing 93 with the prior knowledge of link congestion. The network-wide 94 traffic monitoring can be well applied to all types of networks, 95 especially data center networks, where traffic is highly dynamic and 96 network failures occur silently, while user perception of network 97 latency is expected to be bounded. 99 In traditional network monitoring, management protocols, such as SNMP 100 (Simple Network Management Protocol)[RFC1157]are coarse-grained and 101 involve a large device query latency due to the constant interaction 102 between the control plane and the data plane. To ameliorate the 103 performance issue, INT is proposed to achieve fine-grained network 104 monitoring. INT allows packets to query device-internal states such 105 as queue depth, queuing latency when they pass through the data plane 106 pipeline, without requiring additional intervention from the control 107 plane CPU. At the last hop of the path, the packet containing the 108 end-to-end monitoring data can be sent to a remote central controller 109 for data analysis. INT can print device-internal states to either 110 specified flows of traffic or additionally introduced probe packets. 111 In this document, our proposal relies on INT's probe packet mode. 113 INT is essentially an underlying primitive that need the support of 114 special hardware for device-internal state exposure. To achieve 115 network-wide traffic monitoring, INT further requires a high-level 116 orchestration built upon it. In our proposal, multiple controllable 117 probing paths are generated to monitor the entire network. To reduce 118 the telemetry overhead of additional probe packets for the original 119 network, such orchestration should be better follow the following 120 design principles: 122 o It should use non-overlapped probing paths to completely cover all 123 network edges to reduce unnecessary bandwidth occupation. 125 o It should keep the path number as small as possible to lessen the 126 processing overhead of the telemetry workload sent to the 127 controller. 129 This document addresses the problem of "In-band Network-wide 130 Telemetry", and proposes INT-path, a telemetry framework to achieve 131 lightweight network-wide traffic monitoring. Specifically, we embed 132 SR into INT probes to allow specifying the route the probe packet 133 takes through the network. Based on the routing mechanism, we design 134 two path planning policies to generate multiple non-overlapped INT 135 paths that cover the entire network. The first is based on DFS 136 (Depth-First Search) which is straightforward but computationally- 137 efficient. The second is an Euler trail-based algorithm that can 138 optimally generate non-overlapped INT paths with a minimum path 139 number. 141 2. Problem Statement 143 This document proposes INT-path to solve the following technical 144 challenges of building a network-wide telemetry system based on INT: 146 o Uncontrollable probing path. As an underlying primitive, INT only 147 defines how to extract device-internal states using probe packets. 148 However, the probe packet itself cannot proactively decide which 149 path to monitor since it does not have any path-related prior 150 knowledge. If the INT header is embedded in an IP packet, the 151 probing path will be passively decided by its destination IP 152 address together with the routing table in each network device, 153 leaving probing path totally uncontrollable by the INT packet 154 sender. Given the uncontrollable probing path, it is not easy to 155 work out purposive strategies to optimally generate multiple 156 probing paths for achieving cost-effective network-wide telemetry. 158 o Telemetry overhead. During traffic monitoring, we need 159 periodically perform the INT operation at all devices and notify 160 the controller about the underlying traffic status. However, 161 straightforwardly conducting INT at each device or device chain 162 incurs significant performance overhead: (1) INT will inject 163 probes into the network, which will occupy a fraction of link 164 bandwidth (the finer INT sampling granularity, the more bandwidth 165 will be consumed). (2) INT agents must be deployed for probe 166 generation and collection as the extra cost (the higher number of 167 separated INT paths, the more INT agents need to be deployed). 168 (3) Besides, as the INT agent number grows, the controller will 169 suffer from a performance penalty for handling increased telemetry 170 workload sent from those INT agents. 172 To tackle these problems, this document proposes INT-path, a 173 framework for network-wide telemetry, by decoupling the system into a 174 routing mechanism and a route generation policy. The underlying 175 mechanism allows network operators or INT agents to specify a 176 particular path for monitoring, addressing the uncontrollable path 177 issue (see section3 for details). The policy built upon the 178 mechanism generates multiple INT paths to cover the entire network 179 and a good policy is expected to minimize the telemetry overhead with 180 the least path overlapping as well as the minimized total path number 181 (see section4 and section5 for details). 183 3. Source Routing-based Path Monitoring (Mechanism) 185 This document addresses the uncontrollable path issue via the 186 technique of SR. Figure 1 shows the SR-based telemetry architecture 187 as well as the probe packet format. Although SR is not a new 188 technique, we innovate to couple it with the INT probe using the P4 189 language [P4] to implement user-specified or on demand path 190 monitoring. 192 |<-- Variable length -->| 193 | 22B | 194 +------+------+------+------+ 195 | INTn | .... | INT2 | INT1 | 196 +------+------+------+------+ 197 \ / 198 \ / 199 \ / 200 \ / 201 +-------+------+------+-------+-------+ 202 | ETH | IP | SR | INT | UDP | 203 +-------+------+------+-------+-------+ 204 / \ 205 / \ 206 / \ 207 / \ 208 +-------+------+-------+-------+ 209 | Portn | .... | Port2 | Port1 | 210 +-------+------+-------+-------+ 211 | 4b | 212 |<---------- 512b --------->| 214 Figure 1. Probe packet format 216 3.1. Packet Header Format 218 Theoretically, the SR label stack and the INT label stack can be 219 placed above either the IP header or the UDP header. If placed above 220 the UDP header, they need to occupy an extra port number, which is 221 likely to conflict with the port number chosen by the end hosts for a 222 certain application. While, if placed above the IP header, they only 223 occupy an IP protocol number, and then we can choose an unused 224 protocol number according to existing RFC specifications. Therefore, 225 the program chosen by this document is to place the SR label stack 226 and the INT label stack above the IP header as shown in Figure1. One 227 thing to declare is that although we design a customized header 228 format as follows for the probe packets, the network devices can 229 still correctly forward these packets provided that protocol- 230 independent forwarding is supported. 232 o DP: DP means Destination Port which is set to "SR_INT_PORT" to 233 inform the packet parser that it is an SR-INT probe (i.e., INT 234 probe packet with an SR label stack). 236 o DIP: DIP means destination IP address of the probe packet which is 237 set using controller's IP to guarantee that the probe packet will 238 finally be forwarded to the controller for further analysis. 240 o SR: A 512-bit space is reserved for the SR label stack above the 241 IP header. A 4-bit space is allocated for each SR label to denote 242 the router output port ID thus can maximally support 16 output 243 ports for each router. 245 o INT: Above the fixed-length SR label stack, a variable-length INT 246 label stack is allocated. Each INT label occupies 22B containing 247 the information such as device ID, ingress/egress port, egress 248 queue depth. Since P4 currently does not well support parsing 249 double variable length stacks in the packet header, the SR label 250 stack with a fixed length is statically allocated and the right 251 shift operation is used to perform the "stack pop" behavior. 253 3.2. Forwarding Behaviors 255 In the SR-based telemetry architecture, three types of logic routers 256 are proposed with different functionalities: the INT generator, the 257 INT forwarder and the INT collector (as shown in Figure 2). 259 +--------+ +--------+ 260 |End Host| |End Host| 261 +--------+ +--------+ 262 | | 263 | | 264 +---------+ +---------+ 265 | INT | | INT | 266 |generator| |collector| 267 +---------+ +---------+ 268 | | +---------+ | | 269 | | | INT | | | 270 | | |forwarder| | | 271 | | +---------+ | | 272 | | / \ | | 273 | | / \ | | 274 | +---------+ +---------+ | 275 | | INT | | INT | | 276 | |forwarder| |forwarder| | 277 | +---------+ +---------+ | 278 | \ / | 279 | \ / | 280 | +---------+ | 281 | | INT | | 282 | |forwarder| | 283 | +---------+ | 284 | | 285 +-------------------------------------------+ 286 | Controller | 287 +-------------------------------------------+ 289 Figure 2. Source routing-based path monitoring 291 o INT generator: The INT generator is responsible for spawning the 292 SR-INT probe packets at the first hop of the monitoring path. 293 Since packet generation directly from the data plane is currently 294 undefined in P4, we consider a workaround to periodically generate 295 "empty" probes from the outside by either the router/switch CPU or 296 a host attached to the network device. When the probe arrives at 297 the data plane, the INT generator will rewrite its packet header 298 to allocate the SR label stack and add its local INT information 299 using header.setValid() in P4 before forwarding the packet. 300 Specifically, the INT generator will push the output port IDs into 301 the SR label stack in the packet header. The sequence of the 302 output port IDs (i.e., how to forward the packet across the 303 network) is predetermined at the controller via centralized route 304 calculation. 306 o INT forwarder: The INT forwarder performs packet forwarding of 307 either the SR-INT probes or the background traffic, according to 308 the DP number of the incoming traffic. If the DP is 309 "SR_INT_PORT", the INT forwarder will perform label switching and 310 forward the packet only according to the output port ID popped 311 from the SR label stack. The SR label is popped once at a router 312 by right shifting the SR header by 4 bits at each hop. Besides, 313 the INT forwarder will also push its local INT information into 314 the INT label stack before forwarding the probe. 316 o INT collector: At the last hop of the monitoring path, since the 317 DIP is filled with controller's IP address, the INT collector will 318 finally forward the probe packet to the controller for further 319 analysis. 321 4. DFS-based path planning algorithm 323 4.1. Algorithm Outline 325 In this section, we propose a simple algorithm based on DFS. 327 When traversing a tree or a graph, DFS starts at the root and 328 explores as far as possible along each branch before backtracking. 329 The basic idea of the DFS-based path planning algorithm is to 330 consecutively add the visited vertices into the current path before 331 backtracking; if we have nowhere to go and have to backtrack, we just 332 create a new path and add the fork vertex (the first vertex along the 333 backtracking path that has unvisited edges) as the first node of the 334 new path. After all the edges are visited in the DFS order, we can 335 extract multiple non-overlapped paths covering the entire graph. 337 A recursive version of the DFS-based path planning algorithm is as 338 follows: 340 o Step1: Choose v0 as the first vertex of the depth-first traversal 341 and start the algorithm. 343 o Step2: Select one of v0's adjacency vertices v1 and mark the edge 344 between v0 and v1 as visited, add v0 and v1 into the current INT 345 path; continue to search for v1's adjacency vertex v2 and mark the 346 edge between v1 and v2 as visited, add v2 into the current INT 347 path; continue to search for v2's adjacency vertex v3 and mark the 348 edge between v2 and v3 as visited, add v3 into the current INT 349 path; and continue until a vertex vi has no adjacency vertices 350 that has unvisited edges, then mark the vertex vi as visited, and 351 store the current INT path into set INT path. 353 o Step3: Backtrack at the visited vertex vi until a previous vertex 354 that has unvisited edges is found, and find an adjacency vertex of 355 the previous vertex and mark the edge between them as visited, 356 then add the previous vertex and the adjacency vertex into a new 357 current INT path, that is, continue as step2. If all the 358 adjacency vertices of the previous vertex have been accessed, then 359 mark the previous vertex as visited. Step3 continues until all of 360 the vertices that are reachable by backtracking from vi are 361 visited. 363 o Step4: If there are any unvisited vertices, this algorithm selects 364 one of them as a new source and repeats step2 and step3 from that 365 vertex. Step4 continues until every edge and every vertex has 366 been visited. Then the set INT path is the multiple non- 367 overlapped paths covering the entire graph. 369 4.2. Example 371 We show an algorithm example on a network graph of five devices as 372 shown in Figure 3. 374 +----+ +----+ +----+ 375 | v0 |-----| v1 |-----| v2 | 376 +----+ +-+--+ +--+-+ 377 | / | 378 | / | 379 | / | 380 | / | 381 | / | 382 +-+--+ +--+-+ 383 | v3 |-----| v4 | 384 +----+ +----+ 386 Figure 3. Depth-first graph traversal 388 At the beginning, v0 is pushed into the call stack, path1 = {v0, v1} 389 and the edge between v0 and v1 is marked as visited. The path1 390 expands as more and more vertices are visited in the DFS order. When 391 path1 expands to {v0, v1, v2, v3, v1}, we have nowhere to go and have 392 to find the fork vertex. At this time, we pop v1 from the stack and 393 return to v3, which has an unvisited edge to v4 (notice that the call 394 stack push/pop operations are implicitly performed during recursion). 395 Then, we identify v3 as the fork vertex because it is the first 396 vertex along the backtracking path that has unvisited edges. Based 397 on v3, we create a new path as path2 = {v3, v4}. When path2 expands 398 to {v3, v4, v2}, we have again nowhere to go and have to backtrack. 399 But at this time, although we check all the vertices popped from the 400 call stack, we still cannot find any fork vertex. The recursion 401 halts when the call stack finally becomes empty. At last, we extract 402 two non-overlapped INT probing paths (i.e., path1 and path2). 404 5. Euler trail-based path planning algorithm 406 5.1. Algorithm Outline 408 Although the DFS-based path planning algorithm is computationally- 409 efficient, it has no guarantee to minimize the number of generated 410 paths, which will potentially increase the telemetry overhead, 411 especially the telemetry workload at the centralized. Here, we 412 propose an optimal path planning algorithm taking advantage of the 413 mathematical properties of the Euler trail/circuit. 415 In fact, the mathematical properties of the Euler trail/circuit 416 already indicated the theoretical value of the minimum non-overlapped 417 path number for covering a given graph. To achieve the theoretical 418 minimum, each extracted path from a graph should start from one odd 419 vertex and end at another odd vertex. In other words, removing one 420 such path from a graph will eliminate a pair of odd vertices from 421 that graph. According to the above observation, we devise an Euler 422 trail-based algorithm to iteratively extract a path between a pair of 423 odd vertices until all the vertices/edges are extracted from the 424 original graph. 426 Although the algorithm sounds rather straightforward as an iterative 427 path extraction process, the devil lies in the detail of dealing with 428 several boundary cases. To be more specific, the devil lies in the 429 possibility that an extracted path can split one connected graph into 430 multiple subgraphs, which definitely complicates the iterative path 431 extraction process. 433 Next we explain the optimal algorithm in detail. We use G to 434 represent the network graph, which is initialized to be one connected 435 graph and may also become multiple disconnected subgraphs caused by 436 path extraction during algorithm iteration. We use Q to represent 437 the path set which is initialized as an empty set and will finally 438 contain the generated non-overlapped INT paths. We use G-p to 439 represent extracting a path p from the graph G which will possibly 440 further split the graph(s) G into more subgraphs. 442 Actually, without considering the complexity of graph split, for a 443 given connected graph, there are mainly three different cases for 444 path extraction. We propose solutions in each of these three cases 445 as follows: 447 o The first case is: The graph does not contain any odd vertex. We 448 can extract an Euler circuit from the graph, which will traverse 449 every vertex of the graph. The Euler circuit can be found with 450 the Hierholzer's algorithm [Hierholzer] and inserted into Q. The 451 Hierholzer's algorithm is an efficient algorithm for finding Euler 452 trails and Euler circuits. 454 o The second case is: The graph contains two odd vertices. We just 455 find an Euler trail between the two odd vertices as the path to be 456 extracted. Under this circumstance, an Euler trail can also be 457 found with the Hierholzer's algorithm and inserted into Q. 459 o The last case is: The graph contains more than two odd vertices. 460 We should extract an Euler trail between any pair of odd vertices. 461 In this case, the specific algorithm is as follows: 463 Step1: If G is not empty, perform the following steps. Otherwise 464 the algorithm terminates. 466 Step2: Choose two odd vertices randomly and find a path p to 467 connect the pair of odd vertices with the Dijkstra's algorithm or 468 any other algorithms. Then delete the edges along path p from G, 469 and add path p into Q. After this, if the graph(s) in G have been 470 broken into multiple disconnected subgraphs, then go to step3. If 471 the graph in G has not been broken into multiple disconnected 472 subgraphs, then go to step1. 474 Step3: Use S to store the disconnected subgraphs split from G. 475 Then, select graphs with no odd vertex from S and store them into 476 T. If neither set T nor set Q is an empty set, then go to step4. 477 If set T is not empty and set Q is empty, each subgraph in the set 478 T is processed in the same way as in the first case, that is, 479 using Hierholzer's algorithm to extract an Euler circuit from the 480 subgraph, then delete the edges along the Euler circuit from G and 481 add the Euler circuit into Q. For each subgraph in set S, if it 482 has two odd vertices, the subgraph is processed in the same way as 483 in the second case, that is, using Hierholzer's algorithm to find 484 an Euler trail between the two odd vertices as the path to be 485 extracted, then delete the edges along the Euler trail from G and 486 add the Euler trail into Q. For each subgraph in set S, if it has 487 more than two odd vertices, then go to step2. 489 Step4: For each graph in set T, generate an Euler circuit 490 T_circuit for its full edge coverage. Then search the current Q 491 to find a path T_path having at least a same vertex with 492 T_circuit. Then, connect T_circuit with T_path to create a longer 493 new path, and replace the original T_path with the new path in Q, 494 and delete the edges along path T_circuit from G. 496 5.2. Example 498 Figure 4 shows a path extraction process of the Euler trail-based 499 algorithm. At the start, there is only one connected graph G1 500 {1,2,3,4,5,6,7} with 4 odd vertices. Since the number of the odd 501 vertices is larger than 2, we randomly choose two odd vertices (1 and 502 3), extract a path 1-4-3 from G1 and insert the path into Q. The 503 above path extraction behavior will split the original G1 into two 504 subgraphs G1 {1,2,3} and G2 {4,5,6,7}. Since G1 has no odd vertex 505 and set Q is not empty, we paste the path 1-4-3 in Q with the Euler 506 circuit 1-2-3-1 generated from G1 to create a new path 1-2-3-1-4-3. 507 The new path will replace the original path 1-4-3 in Q. After the 508 path paste, there is only one graph G1 {4,5,6,7} with 2 odd vertices. 509 We use the Hierholzer's algorithm to find its Euler trail 5-4-6-5-7-6 510 as the second INT path in Q. The algorithm halts after all the paths 511 are extracted. 513 +----+3+----+ +----+6+----+ 514 / + \ / + \ 515 + | + | + 516 2 | 4 | 7 517 + | + | + 518 \ + / \ + / 519 +----+1+----+ +----+5+----+ 520 (a) 521 G1={1,2,3,4,5,6,7}; 522 S={G1}, T=Empty; 523 odd_num=4>2; 524 Q={1-4-3}; 526 +----+3 +----+6+----+ 527 / + / + \ 528 + | + | + 529 2 | 4 | 7 530 + | + | + 531 \ + \ + / 532 +----+1 +----+5+----+ 533 (b) 534 G1={1,2,3},G2={4,5,6,7}; 535 S={G1,G2}, T={G1}; 536 T_path=1-4-3,T_circuit=1-2-3-1; 537 path=1-2-3-1-4-3; 538 Q={1-2-3-1-4-3}; 540 +----+6+----+ 541 / + \ 542 + | + 543 4 | 7 544 + | + 545 \ + / 546 +----+5+----+ 547 (c) 548 G1={4,5,6,7}; 549 S={G2}, T=Empty; 550 odd_num=2; 551 Q={1-2-3-1-4-3,5-4-6-5-7-6}; 553 Figure 4. Path extraction process of the Euler trail-based algorithm 555 6. IANA Considerations 557 This document introduces no new security issues. 559 7. Security Considerations 561 This document makes no request of IANA. 563 8. References 565 8.1. Normative References 567 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 568 Requirement Levels", BCP 14, RFC 2119, 569 DOI 10.17487/RFC2119, March 1997, 570 . 572 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 573 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 574 May 2017, . 576 8.2. Informative References 578 [Hierholzer] 579 Hierholzer, H. and W. Wiener, "Ueber die Moeglichkeit, 580 einen Linienzug ohne Wiederholung und ohne Unterbrechung 581 zu umfahren", March 1873, 582 . 584 [Jia] Jia, CH., Pan, T., Bian, ZZ., Lin, XC., Song, EG., Xu, C., 585 Huang, T., and YJ. Liu, "Rapid Detection and Localization 586 of Gray Failures in Data Centers via In-band Network 587 Telemetry", April 2020, 588 . 590 [P4] Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N., 591 Rexford, J., Schlesinger, C., and D. Talayco, "P4: 592 programming protocol-independent packet processors", July 593 2014, . 595 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 596 "Simple Network Management Protocol (SNMP)", RFC 1157, 597 DOI 10.17487/RFC1157, May 1990, 598 . 600 Authors' Addresses 601 Tian Pan 602 Beijing University of Posts and Telecommunications 603 Beijing 604 China 606 Email: pan@bupt.edu.cn 608 Minglan Gao 609 Beijing University of Posts and Telecommunications 610 China 612 Email: gml@bupt.edu.cn 614 Enge Song 615 Beijing University of Posts and Telecommunications 616 China 618 Email: songenge@bupt.edu.cn 620 Zizheng Bian 621 Beijing University of Posts and Telecommunications 622 China 624 Email: zizheng_bian@bupt.edu.cn 626 Xingchen Lin 627 Beijing University of Posts and Telecommunications 628 China 630 Email: linxchen3907@163.com