idnits 2.17.00 (12 Aug 2021) /tmp/idnits6716/draft-yang-rtgwg-oma-impl-report-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 abstract seems to contain references ([I-D.zxd-rtgwg-ordered-metric-adjustment]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (November 25, 2015) is 2369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 305 -- Looks like a reference, but probably isn't: '100' on line 305 -- Looks like a reference, but probably isn't: '156' on line 295 -- Looks like a reference, but probably isn't: '9953' on line 295 -- Looks like a reference, but probably isn't: '222' on line 297 -- Looks like a reference, but probably isn't: '5' on line 307 -- Looks like a reference, but probably isn't: '101' on line 307 -- Looks like a reference, but probably isn't: '8' on line 309 -- Looks like a reference, but probably isn't: '99' on line 309 == Unused Reference: 'RFC1195' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC2328' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC5715' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC6976' is defined on line 528, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Yang 3 Internet-Draft H. Yu 4 Intended status: Informational UESTC 5 Expires: May 28, 2016 X. Zhang 6 N. Wu 7 Huawei 8 November 25, 2015 10 Ordered Metric Adjustment Implementation Report 11 draft-yang-rtgwg-oma-impl-report-00 13 Abstract 15 Ordered Metric Adjustment (OMA) as specified in 16 [I-D.zxd-rtgwg-ordered-metric-adjustment] has provided a mechanism 17 whereby global transient forwarding loops can be avoided through 18 graceful link metric adjustment. This document provides an 19 implementation report for OMA algorithm and mechanism on different 20 network topologies. What's more, it gives an analysis on efficiency 21 and performance of OMA, comparing with other well-known loop- 22 preventing algorithm. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 28, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Overview of Algorithm . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Calculating the adjustment range of link metric for each 68 node . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Merge different Seq(Yj) into a global sequence . . . . . 5 70 4. Innovation point of algorithm . . . . . . . . . . . . . . . . 5 71 5. Simulation of Algorithm . . . . . . . . . . . . . . . . . . . 6 72 5.1. Environment Setup . . . . . . . . . . . . . . . . . . . . 6 73 5.2. Measurement and Methods . . . . . . . . . . . . . . . . . 7 74 5.3. Simulation results . . . . . . . . . . . . . . . . . . . 8 75 5.3.1. Micro-loop risk . . . . . . . . . . . . . . . . . . . 8 76 5.3.2. Sequence length and computing time . . . . . . . . . 8 77 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 10.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This document provides an implementation report for OMA algorithm and 89 mechanism on different network topologies. What's more, it gives an 90 analysis on efficiency and performance of OMA, comparing with other 91 well-known loop-preventing algorithm. 93 2. Terminology 95 o Reverse Shortest Path First Tree (RSPF Tree): A directed acyclic 96 graph containing all the shortest path from the node of the 97 network toward the root. 99 o Link L: An edge in the network connecting node a to b will shut 100 down and its metric value is K when link L is up. 102 o X set: A node set contains the node impacted by the removal of a 103 link L such that each node in X set must change its forwarding 104 paths to avoid link L. 106 o Y set: A node set contains all destination nodes in that may be 107 concerned by the down event of the link L. 109 o D(Yj,Xi): The shortest distacnce from node Xi to Yj when link L is 110 up. 112 o D'(Yj,Xi): The shortest distacnce from node Xi to Yj when link L 113 is down. 115 o COST(Yj,Xi,max): If node Xi switches its optimal path to Yj, the 116 reasonable upper metric of link L can be adjusted is 117 COST(Yj,Xi,max),COST(Yj,Xi,max) = MIN(COST(Yj,Xk,min)),where Xk is 118 the father of node Xi in case of link L being up. 120 o COST(Yj,Xi,min): If node Xi switches its optimal path to Yj, the 121 reasonable lower metric of link L can be adjusted is 122 COST(Yj,Xi,min), COST(Yj,Xi,min) = D'(Yj,Xi)- D(Yj,Xi) + K. 124 o R = (R_min,R_max): Here R_min equals COST(Yj,Xi,min) and R_max = 125 COST(Yj,Xi,min). When the link L!_s metric is set in the range of 126 (R_min, R_max), node Xi can be switched to its optimal path to Yj 127 without forwarding loop. 129 o Seq(Yj): A metric range sequence for Yj contains all metric ranges 130 of source nodes Xi affected by the removal of a link L.When link 131 L' s metric set to a value in each metric range of sequence 132 Seq(Yj) in order, each node Xi will to its optimal path to Yj 133 without forwarding loop. 135 3. Overview of Algorithm 137 The Internet is the most popular network, which is a distributed 138 system. Depend on its configuration, each network device 139 communicates with its neighbor, calculate routes and generate the FIB 140 individually, finally, the packet will be forwarded hop by hop. But 141 due to the difference of each device hardware capabilities and 142 internal/external environments, the route calculation cannot be 143 scheduled at same time, then micro-loop occur. 145 In draft [I-D.zxd-rtgwg-ordered-metric-adjustment] we introduces a 146 method to prevent forwarding loop by adjusting link metric gradually 147 for several times. In this section we will give an overview of 148 algorithm and here we just talk about link down event and results 149 computed in down event are also appropriate to link up event. We 150 suppose link L connecting node A to B referenced in the following 151 sections will shut down. 153 First of all, we have some definitions. Set X consist of Xi which on 154 sub-tree below A in RSPF tree with root B such that each node in X 155 must change its forwarding paths to Yj to avoid link L. And the 156 notation Y that gives the set of "affected destinations". This set 157 contains all destination nodes that may be concerned by the change of 158 the link L and set Y consist of Yj which on sub- tree below B in RSPF 159 tree with root A. In Figure 1, we have X = {A, C, F, G, H} and Y= 160 {B, D, E} 162 10 163 /A----------B\ 164 / \ 165 10/ \10 166 / \ 167 / \ 168 C D 169 /\ /\ 170 / \ / \ 171 / \10 80/ \50 172 10/ \ / \ 173 / \ 10 / 50 \ 174 G \F-----------H----------E 176 Figure 1 Topology 178 3.1. Calculating the adjustment range of link metric for each node 180 This part is used to calculate a reasonable adjustment metric range 181 for each node Xi to switch its optimal path to a destination Yj 182 without forwarding loop. Each metric range of Xi related to Yj make 183 up of a metric range sequence for Yj. 185 For destination Yj, we calculate the RSPF tree with root Yj when link 186 L is up and down to determine the values of two variables R_min = 187 COST(Yj,Xi,min) and R_max = COST(Yj,Xi,max). When the link L's 188 metric is set in the range of (R_min,R_max), node Xi can switch to 189 its optimal path to the root node Yj without forwarding loop. 191 Then metric ranges of Xi computed above make up of a metric range 192 sequence for Yj recorded as Seq(Yj). Then the metric of link L can 193 be set to a value in each range of sequence in order .For example, in 194 figure 1, we have seq(B) ={[100,120],[80,100],[60,80]} and if we set 195 the metric of link L to 60, 81 and 101, each node Xi will switch to 196 its optimal path to the B without forwarding loop. 198 3.2. Merge different Seq(Yj) into a global sequence 200 According to section 1.1, we have different metric range sequence 201 corresponding to each destination Yj. However, nodes need to react 202 to the change of a link weight for all affected destinations. This 203 part will show how to merge different sequences of each destination 204 into a minimal sequence effectively, then multiple nodes in set X 205 simultaneously switch optimal path to each root node without 206 forwarding loop. 208 Compare the metric range of each Seq(Yj) and choose range R = 209 (R_min,R_max) with largest lower bound in these metric ranges. Then 210 remove the metric range with upper bound larger than the lower bound 211 R_min of R in all sequence. Repeat operation above when the sequence 212 of all destination is empty, then algorithm terminates. 214 When the algorithm finishes, remaining metric ranges 215 (R_1min,R_1max),(R_2min,R_2max),... (R_nmin,R_nmax) are what we want. 216 In case of link L going to up, the adjustment process of metric of 217 link L can be set to R_1min+1,R_2min+1,... ,R_nmin, and configuration 218 value K. In case of link L going to down, the adjustment process of 219 metric of link L can be set to configuration value K, 220 R_nmin+1,R_((n-1)min)+1,... , and R_1min. 222 In figure 1, In case of link L going to down, the adjustment process 223 of metric of link L can be set to {10,41,61,81,101}, in proper order, 224 then there is no forwarding loop during this adjustment. 226 4. Innovation point of algorithm 228 There are several different algorithms solving forwarding loops by 229 adjusting link metric gradually. Compared with other solution, we 230 put forward two innovation points in each part of our algorithm. 232 First innovation point of our algorithm is to check whether 233 destination Yj is affected actually due to the down link. In part 1 234 of algorithm, if the size of set Y is |Y|, we need to compute 2|Y| 235 times RSPF tree and its complexity is in |N|log|N|+|E| per times in 236 the best case. We just compute an RSPF tree when link L is up 237 firstly. According to the Dynamic Dijsktra Algorithm, we know that 238 nodes only on sub- tree below A in RSPF tree with root Yj will change 239 its optimal paths to destination if link L change. Obviously, if it 240 is empty on sub- tree below A in RSPF tree with root Yj, only node A 241 will change its optimal path to root so that no forwarding loop for 242 destination Yj can occur when link L down. We call it "Unaffected 243 destination" and in this case we can delete destination Yj from the 244 set Y. If there are |m| destinations are unaffected, we just need | 245 2|Y|-|m|| times computation. 247 The second innovation of our algorithm is that using metric range 248 express the reasonable adjustment metric range for each node to 249 change their optimal path to the root node and using a common range 250 instead of several overlapping ranges to reduce the operation. In 251 part 2 of algorithm, we merge different range sequences into a global 252 sequence, however, many ranges overlap with each other so if merge 253 overlapping ranges into a common range, adjusting link metric several 254 times can be instead of one time. Like this we can reduce a large 255 number of metric ranges in a reasonably short time and the final 256 global sequence will include a few ranges. 258 Through these two points, we have a minimal metric sequence length 259 with the fastest computing time among the similar algorithms. 261 5. Simulation of Algorithm 263 This section aims at evaluating the performance of our algorithm from 264 two aspects: sequence length and the time required to compute them on 265 real IP networks. Firstly, we present the topologies we used in our 266 algorithms. Then present the results of our simulation, analyzing 267 the reasonable length, as well as the efficiency of our optimizations 268 on computing times. 270 5.1. Environment Setup 272 Table I summarizes the main characteristics of our simulation 273 topologies. |N| and |E| respectively represent the number of nodes 274 and links in the graph. d_m is the maximum degree, and ω gives 275 the weight distribution. Networks 1-6 of Table I are Rocketfuel 276 inferred topologies obtained with traceroute campaigns 277 [inferring-link-weight-e2e]. Networks 7-10 are generated obey power- 278 law distribution. Networks 9 and 10 are topologies with special 279 shape. Network 9 is a star topology and network 10 is a circle 280 consists of several small circles. Networks 4 and 5 come with 281 inferred IGP weights and other topologies come with random weights in 282 [1,100]. 284 +----+---------+-----+-----+----+------------+ 285 | ID | Network | |N| | |E| | dm | w | 286 +----+---------+-----+-----+----+------------+ 287 | 1 | Abovenet| 17 | 74 | 8 | [1,100] | 288 +----+---------+-----+-----+----+------------+ 289 | 2 | Exodus | 21 | 72 | 7 | [1,100] | 290 +----+---------+-----+-----+----+------------+ 291 | 3 | Tiscali | 27 | 128 | 18 | [1,100] | 292 +----+---------+-----+-----+----+------------+ 293 | 4 | Sprint | 30 | 138 | 11 | [1,100] | 294 +----+---------+-----+-----+----+------------+ 295 | 5 | Geant | 23 | 74 | 6 | [156,9953] | 296 +----+---------+-----+-----+----+------------+ 297 | 6 | AT&T | 154 | 376 | 29 | [1,222] | 298 +----+---------+-----+-----+----+------------+ 299 | 7 | Pow-1 | 50 | 200 | 7 | [1,100] | 300 +----+---------+-----+-----+----+------------+ 301 | 8 | Pow-2 | 100 | 400 | 7 | [1,100] | 302 +----+---------+-----+-----+----+------------+ 303 | 9 | Pow-3 | 200 | 800 | 7 | [1,100] | 304 +----+---------+-----+-----+----+------------+ 305 | 10 | Pow-4 | 500 | 2000| 7 | [1,100] | 306 +----+---------+-----+-----+----+------------+ 307 | 11 | star | 13 | 44 | 6 | [5,101] | 308 +----+---------+-----+-----+----+------------+ 309 | 12 | circle | 41 | 90 | 3 | [8,99] | 310 +----+---------+-----+-----+----+------------+ 311 Table 1 Main graph properties of simulation network 313 5.2. Measurement and Methods 315 In the results of simulation we focus on the length of metric 316 sequence and computing time. The shortest sequence length, the less 317 operation will we do. Thus we expect to get a minimal sequence and 318 computing time is as short as possible. 320 Firstly we have a loop-risk test on all simulation networks. We 321 carry on 1000 times tests on each network making a link fail 322 randomly, recording the total number that we need to use our 323 algorithm to reconfigure fail link. This test will show that in most 324 topologies the risk of loop will occur frequently when a link fail. 325 So it is very important to search an efficient algorithm to prevent 326 micro-loop. 328 Then we carry on |E| times tests in each network mentioned above 329 ensuring that every link in topology will fail once, recording the 330 sequence length and computing time each time and analysis it. 332 5.3. Simulation results 334 5.3.1. Micro-loop risk 336 Table 2 shows that possibility of micro-loop occurrence is more 50% 337 in most topology. So it is very important to search an efficient 338 algorithm to prevent forwarding loop. 340 +-----------+-------+-------+-------+-------+-------+-------+ 341 | Topo-ID | 1 | 2 | 3 | 4 | 5 | 6 | 342 +-----------+-------+-------+-------+-------+-------+-------+ 343 | Loop risk | 52.1% | 66.8% | 66.8% | 64.1% | 73.0% | 29.1% | 344 +-----------+-------+-------+-------+-------+-------+-------+ 346 +-----------+-------+-------+-------+-------+-------+-------+ 347 | Topo-ID | 7 | 8 | 9 | 10 | 11 | 12 | 348 +-----------+-------+-------+-------+-------+-------+-------+ 349 | Loop risk | 77.6% | 89.1% | 91.6% | 96.1% | 56.3% | 100.0%| 350 +-----------+-------+-------+-------+-------+-------+-------+ 351 Table 2 Micro-loop risk percentage 353 5.3.2. Sequence length and computing time 355 Tables 2 and 3 respectively give an overview of metric sequence 356 length and computing time observed on our set of simulation networks. 358 Minimal Metric Sequence Length: The length of the sequence we 359 obtained in most cases are relatively short. The actual network 360 topology of 1-4,6 and 11, for more than half of the cases, no 361 intermediate metric is needed, as the size of the sequence is equal 362 to 0 and more than 90% of the cases, less than two intermediate 363 metrics are needed to ensure a loop-free convergence in case of a 364 link removal. For all networks, in most case approximately less than 365 ten intermediate metrics can solve micro-loop during the convergence. 367 For all networks, there are several factors which influence the 368 length of the metric sequence: 1) network size: Apparently when the 369 size becomes larger, the number of source and destination nodes 370 significantly increased, so more intermediate state are needed. In 371 our simulation, network 10 is the biggest which has 500 nodes and 372 2000 links and we can notice that it need more intermediate state 373 than others. 2) network shape: a ring network is easy to form a deep 374 , so there can be many nodes on the ring forward its packets along 375 the same direction to destination. When an upstream link is closed, 376 if all these nodes go backward to avoid a failed link, it will 377 produce a number of cycles, as the length of the sequence is longer 378 than others certainly. Results of network 12 prove it. 3) weight 379 distribution: When a network with a large weight range, there may be 380 less overlap range. So the common range remained will be more thus 381 we get a longer sequence such as network 5. 383 Although in a few cases the length of metric sequence is a little 384 long, but most of our sequence have a very reasonable size. 386 Computing Time: We will show that compared with others, our algorithm 387 has the shortest computing time. Here we focus on a similar 388 algorithm [lightweight-algorithm-minimal-operation-impact] (We call 389 it to "Graceful" for short in the following content) and give a 390 contrast between them. Table III gives computing time percentiles 391 including worst-cases results. 393 According to the statistical, for all networks except network 10, the 394 maximum computation time for calculating a sequence is below a few 395 hundred milliseconds. Compared with the Graceful algorithm, there is 396 no significant difference when network size is small. However, with 397 network size increasing our algorithm performs better significantly 398 which can be completed in a shorter time. That is because two 399 innovative points in our algorithm. It can reduce the computation 400 time effectively. 402 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 403 | | Length distribution (%) | MAX | 404 | NID +------------------------------------------------------+ | 405 | ||MMS|=0| <=1 | <=2 | <=5 | <=8 | <=10 | <=15 ||MMS|| 406 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 407 |1 |69.64% |89.29%|98.21% |100.00%|100.00%|100.00%|100.00%| 3 | 408 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 409 |2 |50.00% |80.65%|90.32% |100.00%|100.00%|100.00%|100.00%| 5 | 410 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 411 |3 |55.41% |83.78%|91.89% |100.00%|100.00%|100.00%|100.00%| 4 | 412 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 413 |4 |54.72% |83.02%|96.23% |100.00%|100.00%|100.00%|100.00%| 4 | 414 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 415 |5 |21.88% |29.69%|59.38% |82.81% |93.75% |87.50% |100.00%| 15 | 416 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 417 |6 |77.69% |96.15%|98.46% |100.00%|100.00%|100.00%|100.00%| 4 | 418 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 419 |7 |32.76% |60.92%|79.31% |94.25% |97.70% |95.98% |100.00%| 14 | 420 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 421 |8 |25.26% |49.21%|63.16% |84.74% |91.58% |87.63% |98.68% | 21 | 422 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 423 |9 |11.15% |23.23%|38.32% |68.50% |84.65% |75.72% |98.56% | 34 | 424 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 425 |10 |4.38% |10.56%|18.28% |44.85% |65.35% |73.79% |89.39% | 87 | 426 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 427 |11 |53.33% |93.33%|100.00%|100.00%|100.00%|100.00%|100.00%| 2 | 428 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 429 |12 |0.00% |0.00% |1.11% |57.78% |84.44% |62.22% |94.44% | 22 | 430 +-----+-------+------+-------+-------+-------+-------+-------+-----+ 431 Table 3 Length Distribution 433 +-----+---------------------------------------------------------+ 434 | | Computing Time Distribution (ms) | 435 | +------------+-------------+-------------+----------------+ 436 | NID | 50th | 80th | 100th | Mean | 437 | +------------+----+--------+----+--------+-------+--------+ 438 | |OMA|Graceful|OMA |Graceful|OMA |Graceful|OMA |Graceful| 439 +-----+---+--------+----+--------+----+--------+-------+--------+ 440 |1 |1 |1 |1 |1 |2 |5 |0.64 |0.96 | 441 +-----+---+--------+----+--------+----+--------+-------+--------+ 442 |2 |1 |1 |4 |3 |4 |8 |1.56 |1.82 | 443 +-----+---+--------+----+--------+----+--------+-------+--------+ 444 |3 |1 |1 |1 |4 |7 |8 |1.22 |2.23 | 445 +-----+---+--------+----+--------+----+--------+-------+--------+ 446 |4 |1 |1 |3 |4 |7 |10 |1.79 |2.33 | 447 +-----+---+--------+----+--------+----+--------+-------+--------+ 448 |5 |2 |3 |3 |6 |20 |15 |2.44 |3.41 | 449 +-----+---+--------+----+--------+----+--------+-------+--------+ 450 |6 |6 |13 |49 |175 |189 |294 |35.68 |69.11 | 451 +-----+---+--------+----+--------+----+--------+-------+--------+ 452 |7 |3 |4 |8 |18 |24 |52 |4.76 |9.32 | 453 +-----+---+--------+----+--------+----+--------+-------+--------+ 454 |8 |12 |21 |37 |86 |113 |351 |20.95 |49.50 | 455 +-----+---+--------+----+--------+----+--------+-------+--------+ 456 |9 |71 |172 |192 |650 |589 |2541 |111.55 |346.83 | 457 +-----+---+--------+----+--------+----+--------+-------+--------+ 458 |10 |907|2467 |2656|6886 |7365|24206 |1445.28|3689.79 | 459 +-----+---+--------+----+--------+----+--------+-------+--------+ 460 |11 |1 |0 |1 |1 |2 |2 |0.80 |0.47 | 461 +-----+---+--------+----+--------+----+--------+-------+--------+ 462 |12 |6 |18 |9 |31 |14 |131 |6.17 |26.27 | 463 +-----+---+--------+----+--------+----+--------+-------+--------+ 464 Table 4 Computing Time Distribution 466 6. Conclusion 468 In document [I-D.zxd-rtgwg-ordered-metric-adjustment] we introduces a 469 method to prevent forwarding loop by adjusting link metric gradually 470 for several times. In this document we mainly give the simulation 471 data. We have a simple review firstly then focus on the innovation 472 in our algorithm. Then give the simulation results such that our 473 algorithm have the best performance among the current mainstream 474 algorithms to prevent forwarding loop. 476 7. IANA Considerations 478 This document includes no request to IANA. 480 8. Security Considerations 482 This document is not currently believed to introduce new security 483 concerns. 485 9. Acknowledgments 487 TBD. 489 10. References 491 10.1. Normative References 493 [I-D.zxd-rtgwg-ordered-metric-adjustment] 494 Zhang, X. and G. Yan, "Algorithm for Ordered Metric 495 Adjustment", draft-zxd-rtgwg-ordered-metric-adjustment-00 496 (work in progress), October 2013. 498 [inferring-link-weight-e2e] 499 Mahajan, R., Spring, N., Wetherall, D., and T. Anderson, 500 "Inferring link weights using end-to-end measurements", 501 November 2002. 503 [lightweight-algorithm-minimal-operation-impact] 504 Clad, F., Merindol, P., Pansiot, J., Francois, P., and O. 505 Bonaventure, "Graceful Convergence in Link-State IP 506 Networks: A Lightweight Algorithm Ensuring Minimal 507 Operational Impact, IEEE 1063-6692", February 2014. 509 10.2. Informative References 511 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 512 dual environments", RFC 1195, DOI 10.17487/RFC1195, 513 December 1990, . 515 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 516 Requirement Levels", BCP 14, RFC 2119, 517 DOI 10.17487/RFC2119, March 1997, 518 . 520 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 521 DOI 10.17487/RFC2328, April 1998, 522 . 524 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free 525 Convergence", RFC 5715, DOI 10.17487/RFC5715, January 526 2010, . 528 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 529 Francois, P., and O. Bonaventure, "Framework for Loop-Free 530 Convergence Using the Ordered Forwarding Information Base 531 (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 532 2013, . 534 Authors' Addresses 536 Shiqi Yang 537 UESTC 538 No.2006, Xi Yuan Ave., Westn High-Tech Zone 539 Chengdu 611731 540 China 542 Email: yangsq90309@163.com 544 Hongfang Yu 545 UESTC 546 No.2006, Xi Yuan Ave., Westn High-Tech Zone 547 Chengdu 611731 548 China 550 Email: yuhf.uestc@139.com 552 Xudong Zhang 553 Huawei 554 Huawei Bld., No.156 Beiqing Rd. 555 Beijing 100095 556 China 558 Email: zhangxudong@huawei.com 560 Nan Wu 561 Huawei 562 Huawei Bld., No.156 Beiqing Rd. 563 Beijing 100095 564 China 566 Email: eric.wu@huawei.com