idnits 2.17.1 draft-ietf-rtgwg-spf-uloop-pb-statement-07.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 (May 23, 2018) is 2158 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Routing Area Working Group S. Litkowski 3 Internet-Draft Orange Business Service 4 Intended status: Informational B. Decraene 5 Expires: November 24, 2018 Orange 6 M. Horneffer 7 Deutsche Telekom 8 May 23, 2018 10 Link State protocols SPF trigger and delay algorithm impact on IGP 11 micro-loops 12 draft-ietf-rtgwg-spf-uloop-pb-statement-07 14 Abstract 16 A micro-loop is a packet forwarding loop that may occur transiently 17 among two or more routers in a hop-by-hop packet forwarding paradigm. 19 In this document, we are trying to analyze the impact of using 20 different Link State IGP implementations in a single network, with 21 respect to micro-loops. The analysis is focused on the SPF delay 22 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 [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 https://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 November 24, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 (https://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. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 66 3. SPF trigger strategies . . . . . . . . . . . . . . . . . . . 5 67 4. SPF delay strategies . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Two steps SPF delay . . . . . . . . . . . . . . . . . . . 6 69 4.2. Exponential backoff . . . . . . . . . . . . . . . . . . . 6 70 5. Mixing strategies . . . . . . . . . . . . . . . . . . . . . . 7 71 6. Benefits of standardized SPF delay behavior . . . . . . . . . 11 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 10.2. Informative References . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 Link State IGP protocols are based on a topology database on which 83 the SPF (Shortest Path First) algorithm is run to find a consistent 84 set of non-looping routing paths. 86 Specifications like IS-IS ([RFC1195]) propose some optimizations of 87 the route computation (See Appendix C.1) but not all the 88 implementations follow those non-mandatory optimizations. 90 We will call "SPF triggers", the events that would lead to a new SPF 91 computation based on the topology. 93 Link State IGP protocols, like OSPF ([RFC2328]) and IS-IS 94 ([RFC1195]), are using multiple timers to control the router behavior 95 in case of churn: SPF delay, PRC delay, LSP generation delay, LSP 96 flooding delay, LSP retransmission interval... 98 Some of those timers (values and behavior) are standardized in 99 protocol specifications, while some are not. The SPF computation 100 related timers have generally remained unspecified. 102 For non standardized timers, implementations are free to implement it 103 in any way. For some standardized timer, we can also see that rather 104 than using static configurable values for such timer, implementations 105 may offer dynamically adjusted timers to help controlling the churn. 107 We will call "SPF delay", the timer that exists in most 108 implementations that specifies the required delay before running SPF 109 computation after a SPF trigger is received. 111 A micro-loop is a packet forwarding loop that may occur transiently 112 among two or more routers in a hop-by-hop packet forwarding paradigm. 113 We can observe that these micro-loops are formed when two routers do 114 not update their Forwarding Information Base (FIB) for a certain 115 prefix at the same time. The micro-loop phenomenon is described in 116 [I-D.ietf-rtgwg-microloop-analysis]. 118 Two micro-loop mitigation techniques have been defined by IETF. 119 [RFC6976] has not been widely implemented, presumably due to the 120 complexity of the technique. [I-D.ietf-rtgwg-uloop-delay]) has been 121 implemented. However, it does not prevent all micro-loops that can 122 occur for a given topology and failure scenario. 124 In multi-vendor networks, using different implementations of a link 125 state protocol may favor micro-loops creation during the convergence 126 process due to discrepancies of timers. Service Providers are 127 already aware to use similar timers (values and behavior) for all the 128 network as a best practice, but sometimes it is not possible due to 129 limitations of implementations. 131 This document will present why it sounds important for service 132 providers to have consistent implementations of Link State protocols 133 across vendors. We are particularly analyzing the impact of using 134 different Link State IGP implementations in a single network in 135 regards of micro-loops. The analysis is focused on the SPF delay 136 algorithm. 138 [I-D.ietf-rtgwg-backoff-algo] defines a solution that satisfies this 139 problem statement and this document captures the reasoning of the 140 provided solution. 142 2. Problem statement 144 S ---- E 145 | | 146 10 | | 10 147 | | 148 D ---- A 149 | 2 150 Px 152 Figure 1 - Network topology suffering from micro-loops 154 In Figure 1, S uses primarily the SD link to reach the prefixes 155 behind D (Px). When the SD link fails, the IGP convergence occurs. 156 If S converges before E, S will forward the traffic to Px through E, 157 but as E has not converged yet, E will loop back traffic to S, 158 leading to a micro-loop. 160 The micro-loop appears due to the asynchronous convergence of nodes 161 in a network when an event occurs. 163 Multiple factors (or a combination of these factors) may increase the 164 probability for a micro-loop to appear: 166 o the delay of failure notification: the more E is advised of the 167 failure later than S, the more a micro-loop may have a chance to 168 appear. 170 o the SPF delay: most implementations support a delay for the SPF 171 computation to try to catch as many events as possible. If S uses 172 an SPF delay timer of x msec and E uses an SPF delay timer of y 173 msec and x < y, E would start converging after S leading to a 174 potential micro-loop. 176 o the SPF computation time: mostly a matter of CPU power and 177 optimizations like incremental SPF. If S computes its SPF faster 178 than E, there is a chance for a micro-loop to appear. CPUs are 179 today fast enough to consider SPF computation time as negligible 180 (on the order of milliseconds in a large network). 182 o the SPF computation order: an SPF trigger can be common to 183 multiple IGP areas or levels (e.g., IS-IS Level1/Level2) or for 184 multiple address families with multi-topologies. There is no 185 specified order for SPF computation today and it is implementation 186 dependent. In such scenarios, if the order of SPF computation 187 done in S and E for each area/level/topology/SPF-algorithm is 188 different, there is a possibility for a micro-loop to appear. 190 o the RIB and FIB prefix insertion speed or ordering. This is 191 highly dependent on the implementation. 193 This document will focus on analysis of the SPF delay behavior and 194 associated triggers. 196 3. SPF trigger strategies 198 Depending on the change advertised in LSPDU or LSA, the topology may 199 be affected or not. An implementation may avoid running the SPF 200 computation (and may only run IP reachability computation instead) if 201 the advertised change does not affect the topology. 203 Different strategies exists to trigger the SPF computation: 205 1. An implementation may always run a full SPF for any type of 206 change. 208 2. An implementation may run a full SPF only when required. For 209 example, if a link fails, a local node will run an SPF for its 210 local LSP update. If the LSP from the neighbor (describing the 211 same failure) is received after SPF has started, the local node 212 can decide that a new full SPF is not required as the topology 213 has not change. 215 3. If the topology does not change, an implementation may only 216 recompute the IP reachability. 218 As noted in Section 1, SPF optimizations are not mandatory in 219 specifications. This has led to the implementation of different 220 strategies. 222 4. SPF delay strategies 224 Implementations of link state routing protocols use different 225 strategies to delay the SPF computation. The two most common SPF 226 delay behaviors are the following: 228 1. Two phase SPF delay. 230 2. Exponential backoff delay. 232 Those behavior will be explained in the next sections. 234 4.1. Two steps SPF delay 236 The SPF delay is managed by four parameters: 238 o Rapid delay: amount of time to wait before running SPF, after the 239 initial SPF trigger event. 241 o Rapid runs: the number of consecutive SPF runs that can use the 242 rapid delay. When the number is exceeded, the delay moves to the 243 slow delay value. 245 o Slow delay: amount of time to wait before running SPF. 247 o Wait time: amount of time to wait without receiving SPF trigger 248 events before going back to the rapid delay. 250 Example: Rapid delay = 50msec, Rapid runs = 3, Slow delay = 1sec, 251 Wait time = 2sec 253 SPF delay time 254 ^ 255 | 256 | 257 SD- | x xx x 258 | 259 | 260 | 261 RD- | x x x x 262 | 263 +---------------------------------> Events 264 | | | | || | | 265 < wait time > 267 Figure 2 - Two phase delay algorithm 269 4.2. Exponential backoff 271 The algorithm has two modes: the fast mode and the backoff mode. In 272 the fast mode, the SPF delay is usually delayed by a very small 273 amount of time (fast reaction). When an SPF computation has run in 274 the fast mode, the algorithm automatically moves to the backoff mode 275 (a single SPF run is authorized in the fast mode). In the backoff 276 mode, the SPF delay is increasing exponentially at each run. When 277 the network becomes stable, the algorithm moves back to the fast 278 mode. The SPF delay is managed by four parameters: 280 o First delay: amount of time to wait before running SPF. This 281 delay is used only when SPF is in fast mode. 283 o Incremental delay: amount of time to wait before running SPF. 284 This delay is used only when SPF is in backoff mode and increments 285 exponentially at each SPF run. 287 o Maximum delay: maximum amount of time to wait before running SPF. 289 o Wait time: amount of time to wait without events before going back 290 to the fast mode. 292 Example: First delay = 50msec, Incremental delay = 50msec, Maximum 293 delay = 1sec, Wait time = 2sec 295 SPF delay time 296 ^ 297 MD- | xx x 298 | 299 | 300 | 301 | 302 | 303 | x 304 | 305 | 306 | 307 | x 308 | 309 FD- | x x x 310 ID | 311 +---------------------------------> Events 312 | | | | || | | 313 < wait time > 314 FM->BM -------------------->FM 316 Figure 3 - Exponential delay algorithm 318 5. Mixing strategies 320 In Figure 1, we consider a flow of packet from S to D. We consider 321 that S is using optimized SPF triggering (Full SPF is triggered only 322 when necessary), and two steps SPF delay (rapid=150ms,rapid-runs=3, 323 slow=1s). As implementation of S is optimized, Partial Reachability 324 Computation (PRC) is available. We consider the same timers as SPF 325 for delaying PRC. We consider that E is using a SPF trigger strategy 326 that always compute a Full SPF for any change, and uses the 327 exponential backoff strategy for SPF delay (start=150ms, inc=150ms, 328 max=1s) 330 We also consider the following sequence of events: 332 o t0=0 ms: a prefix is declared down in the network. We consider 333 this event to happen at time=0. 335 o 200ms: the prefix is declared as up. 337 o 400ms: a prefix is declared down in the network. 339 o 1000ms: S-D link fails. 341 +--------+--------------------+------------------+------------------+ 342 | Time | Network Event | Router S events | Router E events | 343 +--------+--------------------+------------------+------------------+ 344 | t0=0 | Prefix DOWN | | | 345 | 10ms | | Schedule PRC (in | Schedule SPF (in | 346 | | | 150ms) | 150ms) | 347 | | | | | 348 | | | | | 349 | 160ms | | PRC starts | SPF starts | 350 | 161ms | | PRC ends | | 351 | 162ms | | RIB/FIB starts | | 352 | 163ms | | | SPF ends | 353 | 164ms | | | RIB/FIB starts | 354 | 175ms | | RIB/FIB ends | | 355 | 178ms | | | RIB/FIB ends | 356 | | | | | 357 | 200ms | Prefix UP | | | 358 | 212ms | | Schedule PRC (in | | 359 | | | 150ms) | | 360 | 214ms | | | Schedule SPF (in | 361 | | | | 150ms) | 362 | | | | | 363 | | | | | 364 | 370ms | | PRC starts | | 365 | 372ms | | PRC ends | | 366 | 373ms | | | SPF starts | 367 | 373ms | | RIB/FIB starts | | 368 | 375ms | | | SPF ends | 369 | 376ms | | | RIB/FIB starts | 370 | 383ms | | RIB/FIB ends | | 371 | 385ms | | | RIB/FIB ends | 372 | | | | | 373 | 400ms | Prefix DOWN | | | 374 | 410ms | | Schedule PRC (in | Schedule SPF (in | 375 | | | 300ms) | 300ms) | 376 | | | | | 377 | | | | | 378 | | | | | 379 | | | | | 380 | 710ms | | PRC starts | SPF starts | 381 | 711ms | | PRC ends | | 382 | 712ms | | RIB/FIB starts | | 383 | 713ms | | | SPF ends | 384 | 714ms | | | RIB/FIB starts | 385 | 716ms | | RIB/FIB ends | RIB/FIB ends | 386 | | | | | 387 | 1000ms | S-D link DOWN | | | 388 | 1010ms | | Schedule SPF (in | Schedule SPF (in | 389 | | | 150ms) | 600ms) | 390 | | | | | 391 | | | | | 392 | 1160ms | | SPF starts | | 393 | 1161ms | | SPF ends | | 394 | 1162ms | Micro-loop may | RIB/FIB starts | | 395 | | start from here | | | 396 | 1175ms | | RIB/FIB ends | | 397 | | | | | 398 | | | | | 399 | | | | | 400 | | | | | 401 | 1612ms | | | SPF starts | 402 | 1615ms | | | SPF ends | 403 | 1616ms | | | RIB/FIB starts | 404 | 1626ms | Micro-loop ends | | RIB/FIB ends | 405 +--------+--------------------+------------------+------------------+ 407 Table 1 - Route computation when S and E use the different behaviors 408 and multiple events appear 410 In the Table 1, we can see that due to discrepancies in the SPF 411 management, after multiple events of a different type, the values of 412 the SPF delay are completely misaligned between node S and node E, 413 leading to the creation of micro-loops. 415 The same issue can also appear with only a single type of event as 416 shown below: 418 +--------+--------------------+------------------+------------------+ 419 | Time | Network Event | Router S events | Router E events | 420 +--------+--------------------+------------------+------------------+ 421 | t0=0 | Link DOWN | | | 422 | 10ms | | Schedule SPF (in | Schedule SPF (in | 423 | | | 150ms) | 150ms) | 424 | | | | | 425 | | | | | 426 | 160ms | | SPF starts | SPF starts | 427 | 161ms | | SPF ends | | 428 | 162ms | | RIB/FIB starts | | 429 | 163ms | | | SPF ends | 430 | 164ms | | | RIB/FIB starts | 431 | 175ms | | RIB/FIB ends | | 432 | 178ms | | | RIB/FIB ends | 433 | | | | | 434 | 200ms | Link DOWN | | | 435 | 212ms | | Schedule SPF (in | | 436 | | | 150ms) | | 437 | 214ms | | | Schedule SPF (in | 438 | | | | 150ms) | 439 | | | | | 440 | | | | | 441 | 370ms | | SPF starts | | 442 | 372ms | | SPF ends | | 443 | 373ms | | | SPF starts | 444 | 373ms | | RIB/FIB starts | | 445 | 375ms | | | SPF ends | 446 | 376ms | | | RIB/FIB starts | 447 | 383ms | | RIB/FIB ends | | 448 | 385ms | | | RIB/FIB ends | 449 | | | | | 450 | 400ms | Link DOWN | | | 451 | 410ms | | Schedule SPF (in | Schedule SPF (in | 452 | | | 150ms) | 300ms) | 453 | | | | | 454 | | | | | 455 | 560ms | | SPF starts | | 456 | 561ms | | SPF ends | | 457 | 562ms | Micro-loop may | RIB/FIB starts | | 458 | | start from here | | | 459 | 568ms | | RIB/FIB ends | | 460 | | | | | 461 | | | | | 462 | 710ms | | | SPF starts | 463 | 713ms | | | SPF ends | 464 | 714ms | | | RIB/FIB starts | 465 | 716ms | Micro-loop ends | | RIB/FIB ends | 466 | | | | | 467 | 1000ms | Link DOWN | | | 468 | 1010ms | | Schedule SPF (in | Schedule SPF (in | 469 | | | 1s) | 600ms) | 470 | | | | | 471 | | | | | 472 | | | | | 473 | | | | | 474 | 1612ms | | | SPF starts | 475 | 1615ms | | | SPF ends | 476 | 1616ms | Micro-loop may | | RIB/FIB starts | 477 | | start from here | | | 478 | 1626ms | | | RIB/FIB ends | 479 | | | | | 480 | | | | | 481 | | | | | 482 | | | | | 483 | 2012ms | | SPF starts | | 484 | 2014ms | | SPF ends | | 485 | 2015ms | | RIB/FIB starts | | 486 | 2025ms | Micro-loop ends | RIB/FIB ends | | 487 | | | | | 488 | | | | | 489 +--------+--------------------+------------------+------------------+ 491 Table 2 - Route computation upon multiple link down events when S and 492 E use the different behaviors 494 6. Benefits of standardized SPF delay behavior 496 Using the same event sequence as in Table 1, we may expect fewer and/ 497 or shorter micro-loops using a standardized SPF delay. 499 +--------+--------------------+------------------+------------------+ 500 | Time | Network Event | Router S events | Router E events | 501 +--------+--------------------+------------------+------------------+ 502 | t0=0 | Prefix DOWN | | | 503 | 10ms | | Schedule PRC (in | Schedule PRC (in | 504 | | | 150ms) | 150ms) | 505 | | | | | 506 | | | | | 507 | 160ms | | PRC starts | PRC starts | 508 | 161ms | | PRC ends | | 509 | 162ms | | RIB/FIB starts | PRC ends | 510 | 163ms | | | RIB/FIB starts | 511 | 175ms | | RIB/FIB ends | | 512 | 176ms | | | RIB/FIB ends | 513 | | | | | 514 | 200ms | Prefix UP | | | 515 | 212ms | | Schedule PRC (in | | 516 | | | 150ms) | | 517 | 213ms | | | Schedule PRC (in | 518 | | | | 150ms) | 519 | | | | | 520 | | | | | 521 | 370ms | | PRC starts | PRC starts | 522 | 372ms | | PRC ends | | 523 | 373ms | | RIB/FIB starts | PRC ends | 524 | 374ms | | | RIB/FIB starts | 525 | 383ms | | RIB/FIB ends | | 526 | 384ms | | | RIB/FIB ends | 527 | | | | | 528 | 400ms | Prefix DOWN | | | 529 | 410ms | | Schedule PRC (in | Schedule PRC (in | 530 | | | 300ms) | 300ms) | 531 | | | | | 532 | | | | | 533 | | | | | 534 | | | | | 535 | 710ms | | PRC starts | PRC starts | 536 | 711ms | | PRC ends | PRC ends | 537 | 712ms | | RIB/FIB starts | | 538 | 713ms | | | RIB/FIB starts | 539 | 716ms | | RIB/FIB ends | RIB/FIB ends | 540 | | | | | 541 | 1000ms | S-D link DOWN | | | 542 | 1010ms | | Schedule SPF (in | Schedule SPF (in | 543 | | | 150ms) | 150ms) | 544 | | | | | 545 | | | | | 546 | 1160ms | | SPF starts | | 547 | 1161ms | | SPF ends | SPF starts | 548 | 1162ms | Micro-loop may | RIB/FIB starts | SPF ends | 549 | | start from here | | | 550 | 1163ms | | | RIB/FIB starts | 551 | 1175ms | | RIB/FIB ends | | 552 | 1177ms | Micro-loop ends | | RIB/FIB ends | 553 +--------+--------------------+------------------+------------------+ 555 Table 3 - Route computation when S and E use the same standardized 556 behavior 558 As displayed above, there could be some other parameters like router 559 computation power, flooding timers that may also influence micro- 560 loops. In all the examples in this document comparing the SPF timer 561 behavior of router S and router E, we have made router E a bit slower 562 than router S. This can lead to micro-loops even when both S and E 563 use a common standardized SPF behavior. However, we expect that by 564 aligning implementations of the SPF delay, service providers may 565 reduce the number and the duration of micro-loops. 567 7. Security Considerations 569 This document does not introduce any security consideration. 571 8. Acknowledgements 573 Authors would like to thank Mike Shand and Chris Bowers for their 574 useful comments. 576 9. IANA Considerations 578 This document has no action for IANA. 580 10. References 582 10.1. Normative References 584 [I-D.ietf-rtgwg-backoff-algo] 585 Decraene, B., Litkowski, S., Gredler, H., Lindem, A., 586 Francois, P., and C. Bowers, "SPF Back-off Delay algorithm 587 for link state IGPs", draft-ietf-rtgwg-backoff-algo-10 588 (work in progress), March 2018. 590 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 591 dual environments", RFC 1195, DOI 10.17487/RFC1195, 592 December 1990, . 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 600 DOI 10.17487/RFC2328, April 1998, 601 . 603 10.2. Informative References 605 [I-D.ietf-rtgwg-microloop-analysis] 606 Zinin, A., "Analysis and Minimization of Microloops in 607 Link-state Routing Protocols", draft-ietf-rtgwg-microloop- 608 analysis-01 (work in progress), October 2005. 610 [I-D.ietf-rtgwg-uloop-delay] 611 Litkowski, S., Decraene, B., Filsfils, C., and P. 612 Francois, "Micro-loop prevention by introducing a local 613 convergence delay", draft-ietf-rtgwg-uloop-delay-09 (work 614 in progress), November 2017. 616 [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., 617 Francois, P., and O. Bonaventure, "Framework for Loop-Free 618 Convergence Using the Ordered Forwarding Information Base 619 (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July 620 2013, . 622 Authors' Addresses 624 Stephane Litkowski 625 Orange Business Service 627 Email: stephane.litkowski@orange.com 629 Bruno Decraene 630 Orange 632 Email: bruno.decraene@orange.com 634 Martin Horneffer 635 Deutsche Telekom 637 Email: martin.horneffer@telekom.de