idnits 2.17.00 (12 Aug 2021) /tmp/idnits25458/draft-white-lsr-distoptflood-02.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 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (25 April 2022) is 19 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-lsr-dynamic-flooding' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'ISO10589' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC5301' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'RFC5303' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC5308' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC5309' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'RFC5311' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC5316' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC7981' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC3277' is defined on line 454, but no explicit reference was found in the text == Unused Reference: 'RFC3719' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC5820' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC5837' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC6232' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC7921' is defined on line 508, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 Summary: 2 errors (**), 0 flaws (~~), 26 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. White 3 Internet-Draft S. Hegde 4 Intended status: Informational T. Przygienda 5 Expires: 27 October 2022 Juniper Networks 6 25 April 2022 8 IS-IS Optimal Distributed Flooding for Dense Topologies 9 draft-white-lsr-distoptflood-02 11 Abstract 13 In dense topologies (such as data center fabrics based on the Clos 14 and butterfly topologies, though not limited to these), IGP flooding 15 mechanisms designed for sparse topologies can "overflood," or carry 16 too many copies of topology and reachability information to fabric 17 devices. This results in slower convergence times and higher 18 resource utilization. The modifications to the flooding mechanism in 19 the Intermediate System to Intermediate System (IS-IS) link state 20 protocol described in this document reduce resource utilization 21 significantly, while increasing convergence performance in dense 22 topologies. 24 Note that a Clos fabric is used as the primary example of a dense 25 flooding topology throughout this document. However, the flooding 26 optimizations described in this document apply to any topology. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 27 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.2. Contributors . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Experience . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.4. Sample Network . . . . . . . . . . . . . . . . . . . . . 3 66 2. Flooding Modifications . . . . . . . . . . . . . . . . . . . 5 67 2.1. Optimizing Flooding . . . . . . . . . . . . . . . . . . . 5 68 2.2. Optimization Process . . . . . . . . . . . . . . . . . . 6 69 2.3. Flooding Failures . . . . . . . . . . . . . . . . . . . . 7 70 2.4. Flooding Example . . . . . . . . . . . . . . . . . . . . 8 71 2.5. A Note on Performance . . . . . . . . . . . . . . . . . . 8 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 4.2. Informative References . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 1.1. Goals 82 The goal of this draft is to solve one specific set of problems 83 involved in operating a link state protocol in a densely meshed 84 topology. The problem with such topologies is the connectivity 85 density, which causes too many copies of identical information to be 86 flooded. Analysis and experiment show, for instance, that in a 87 butterfly fabric of around 2500 intermediate systems, each 88 intermediate system will receive more than 40 copies of any changed 89 LSP fragment. This not only wastes bandwidth and processor time, 90 this dramatically slows convergence speed. 92 This document describes a set of modifications to existing IS-IS 93 flooding mechanisms which minimize the number of LSP fragments 94 received by individual intermediate systems, in its extreme version 95 to one copy per intermediate system. The mechanisms described in 96 this document are similar to those implemented in OSPF to support 97 mobile ad-hoc networks, as described in [RFC5449], [RFC5614], and 98 [RFC7182]. These mechanisms have been widely implemented and 99 deployed. 101 1.2. Contributors 103 The following people have contributed to this draft: Abhishek Kumar, 104 Nikos Triantafillis, Ivan Pepelnjak, Christian Franke, Hannes 105 Gredler, Les Ginsberg, Naiming Shen, Uma Chunduri, Nick Russo, Shawn 106 Zandi, and Rodny Molina. 108 1.3. Experience 110 Laboratory tests show modifications similar to these reduce flooding 111 in a large scale emulated butterfly network topology; without these 112 modifications, intermediate systems receive, on average, 40 copies of 113 any changed LSP fragment. With the modifications described in this 114 document intermediate systems recieve, on average, two copies of any 115 changed LSP fragment. In many cases, each intermediate system 116 receives only a single copy of each changed LSP. In terms of 117 performance, the modifications described here cut convergence times 118 in half. Processor load times were not checked, as this was an 119 emulated environment. 121 A mechanism similar to the one described in this document has been 122 implemented in the FR Routing open source routing stack as part of 123 fabricd. 125 1.4. Sample Network 127 The following spine and leaf fabric will be used to describe these 128 modifications. 130 +----+ +----+ +----+ +----+ +----+ +----+ 131 | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) 132 +----+ +----+ +----+ +----+ +----+ +----+ 134 +----+ +----+ +----+ +----+ +----+ +----+ 135 | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) 136 +----+ +----+ +----+ +----+ +----+ +----+ 138 +----+ +----+ +----+ +----+ +----+ +----+ 139 | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) 140 +----+ +----+ +----+ +----+ +----+ +----+ 142 +----+ +----+ +----+ +----+ +----+ +----+ 143 | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) 144 +----+ +----+ +----+ +----+ +----+ +----+ 146 +----+ +----+ +----+ +----+ +----+ +----+ 147 | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) 148 +----+ +----+ +----+ +----+ +----+ +----+ 150 Figure 1 152 To reduce confusion (spine and leaf fabrics are difficult to draw in 153 plain text art), this diagram does not contain the connections 154 between devices. The reader should assume that each device in a 155 given layer is connected to every device in the layer above it. For 156 instance: 158 * 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F 160 * 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F 162 * 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 163 5F 165 * 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 166 5F 168 * etc. 170 The tiers or stages of the fabric are also marked for easier 171 reference. T0 is assumed to be connected to application servers, or 172 rather they are Top of Rack (ToR) intermediate systems. The 173 remaining tiers, T1 and T2, are connected only to other devices in 174 the fabric itself. A common alternate representation of this 175 topology is drawn "folded" with T2, the "top of fabric," shown on 176 top, while T1 is shown below, and T0 below T1. 178 2. Flooding Modifications 180 Flooding is perhaps the most challenging scaling issue for a link 181 state protocol running on a dense, large scale topology. This 182 section describes detailed modifications to the IS-IS flooding 183 process to reduce flooding load in a densely meshed topology. 185 2.1. Optimizing Flooding 187 The simplest way to conceive of the solution presented here is in two 188 stages: 190 * Stage 1: Forward Optimization 192 - Find the group of intermediate systems that will all flood to 193 the same set of neighbors as the local IS 195 - Decide (deterministically) which subset of the intermediate 196 systems within this group should re-flood any received LSPs 198 * Stage 2: Reverse Optimization 200 - Find neighbors on the shortest path towards the origin of the 201 change 203 - Do not flood towards these neighbors 205 The first stage is best explained through an illustration. In the 206 network above, if 5A transmits a modified Link State Protocol Data 207 Unit (LSP) to 4A-4F, each of 4A-4F will, in turn, flood this modified 208 LSP to 3A (for instance). 3A will receive 6 copies of the modified 209 LSP, while only one copy is necessary for the intermediate systems 210 shown to converge on a single view of the topology. If 4A-4F could 211 determine they will all flood identical copies of the modified LSP to 212 3A, it is possible for all of them except one to decide not to flood 213 the changed LSP to 3A. 215 The technique used in this draft to determine the flooding group is 216 for each intermediate system to calculate a special Shortest-path 217 Spanning Tree (SPT) from the point of view of the transmitting 218 neighbor. By setting the metric of all links to 1 and truncating the 219 SPT to two hops, the local IS can find the group of neighbors it will 220 flood any changed LSP towards and the set of intermediate systems 221 (not necessarily neighbors) which will also flood to this same set of 222 neighbors. If every intermediate system in the flooding set performs 223 this same calculation, they will all obtain the same flooding group. 225 Once this flooding group is determined, the members of the flooding 226 group will each (independently) choose which of the members should 227 re-flood the received information. Each member of the flooding group 228 calculates this independently of all the other members, but a common 229 hash MUST be used across a set of shared variables so each member of 230 the group comes to the same conclusion. The group member which is 231 selected to flood the changed LSP does so normally; the remaining 232 group members do not flood the LSP. 234 Note there is no signaling between the intermediate systems running 235 this flooding reduction mechanism. Each IS calculates the special, 236 truncated SPT separately, and determines which IS should flood any 237 changed LSPs independently based on a common hash function. Because 238 these calculations are performed using a shared view of the network, 239 however (based on the common link state database) and a shared hash 240 function, each member of the flooding group will make the same 241 decision. 243 The second stage is simpler, consisting of a single rule: do not 244 flood modified LSPs along the shortest path towards the origin of the 245 modified LSP. This rule relies on the observation that any IS 246 between the origin of the modified LSP and the local IS should 247 receive the modified LSP from some other IS closer to the source of 248 the modified LSP. 250 2.2. Optimization Process 252 Each intermediate system will determine whether it should re-flood 253 LSPs as described below. When a modified LSP arrives from a 254 Transmitting Neighbor (TN), the result of the following algorithm 255 obtains the necessary decision: 257 Step 1: Build the Two-Hop List (THL) and Remote Neighbor's List (RNL) 258 by: 260 * Set all link metrics to 1 262 * Calculate an SPT truncated to 2 hops from the perspective of TN 264 * For each IS that is two hops (has a metric of two in the truncated 265 SPT) from TN: 267 - If the IS is on the shortest path towards the originator of the 268 modified LSP, skip 270 - If the IS is not on the shortest path towards the originator of 271 the modified LSP, add it to THL 273 * Add each IS that is one hop away from TN to the RNL 275 Step 2: Sort RNL by system IDs, from the least to the greatest. 277 Step 3: Calculate a number, N, by adding each byte in LSP-ID (without 278 the fragment ID) and fragment ID MOD 2 (allowing for some balancing 279 of LSPs coming from same system ID without introducing excessive 280 amount of state in an implementation) and then taking MOD on the 281 number of neighbors. N MUST be less than the number of members of 282 RNL. 284 Step 4: Starting with the Nth member of RNL: 286 * If THL is empty, exit 288 * If this member of RNL is the local calculating IS, this IS MUST 289 reflood the modified LSP; exit 291 * Remove all members of THL connected to (adjacent to) this member 292 of RNL 294 * Move to the next member of RNL, wrapping to the beginning of RNL 295 if necessary 297 Note: This description is geared to clarity rather than optimal 298 performance. 300 2.3. Flooding Failures 302 It is possible in some failure modes for flooding to be incomplete 303 because of the flooding optimizations outlined. Specifically, if a 304 reflooder fails, or is somehow disconnected from all the links across 305 which it should be reflooding, it is possible an LSP is only 306 partially flooded through the fabric. To prevent such partition 307 failures, an intermediate system which does not reflood an LSP (or 308 fragment) should: 310 * Set a short timer; the default should be one second 312 * When the timer expires, send Partial Sequence Number Packet (PSNP) 313 of all LSPs that have not been reflooded during the timer runtime 314 to all neighbors unless an up-to-date PSNP or CSNP has been 315 already received from the neighbor 317 * Process any Partial Sequence Number Packets (PSNPs) received that 318 indicate that neighbors still have older versions of the LSP per 319 normal protocol procedures to resynchronize 321 * If resynchronization above a configurable threshold is required, 322 an implementation SHOULD notify the network operator 324 2.4. Flooding Example 326 Assume, in the network above, 5A floods some modified LSP towards 4A- 327 4F. To determine whether 4A should flood this LSP to 3A-3F: 329 * 5A is TN; 4A calculates a truncated SPT from 5A's perspective with 330 all link metrics set to 1 332 * 4A builds THL, which contains 3A, 3B, 3C, 3D, 3E, 3F, 5B, 5C, 5D, 333 5E and 5F 335 * 4A builds RNL, which contains 4A,4B,4C,4D,4E and 4F, sorting it by 336 the system ID 338 * 4A computes hash on the received LSP-ID to get N; assume N is 1 in 339 this case 341 * Since 4A is the Nth member of R-NL and there are members in N-NL, 342 4A must reflood; the loop exits 344 2.5. A Note on Performance 346 The calculations described here are complex, which might lead the 347 reader to conclude that the cost of calculation is so much higher 348 than the cost of flooding that this optimization is counter- 349 productive. The description provided here is designed for clarity 350 rather than optimal calculation, however. Many of the calculations 351 can be performed in advance and stored, rather than being performed 352 for each LSP and each neighbor. Optimized versions of the process 353 described here have been implemented, and do result in strong 354 convergence speed gains. 356 3. Security Considerations 358 This document outlines modifications to the IS-IS protocol for 359 operation on high density network topologies. Implementations SHOULD 360 implement IS-IS cryptographic authentication, as described in 361 [RFC5304], and should enable other security measures in accordance 362 with best common practices for the IS-IS protocol. 364 4. References 366 4.1. Normative References 368 [I-D.ietf-lsr-dynamic-flooding] 369 Li, T., Przygienda, T., Psenak, P., Ginsberg, L., Chen, 370 H., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra, 371 "Dynamic Flooding on Dense Graphs", Work in Progress, 372 Internet-Draft, draft-ietf-lsr-dynamic-flooding-10, 7 373 December 2021, . 376 [ISO10589] International Organization for Standardization, 377 "Intermediate system to Intermediate system intra-domain 378 routeing information exchange protocol for use in 379 conjunction with the protocol for providing the 380 connectionless-mode Network Service (ISO 8473)", ISO/ 381 IEC 10589:2002, Second Edition, November 2002. 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 389 DOI 10.17487/RFC2629, June 1999, 390 . 392 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 393 Topology (MT) Routing in Intermediate System to 394 Intermediate Systems (IS-ISs)", RFC 5120, 395 DOI 10.17487/RFC5120, February 2008, 396 . 398 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 399 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 400 October 2008, . 402 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 403 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 404 DOI 10.17487/RFC5303, October 2008, 405 . 407 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 408 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 409 2008, . 411 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 412 DOI 10.17487/RFC5308, October 2008, 413 . 415 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 416 over LAN in Link State Routing Protocols", RFC 5309, 417 DOI 10.17487/RFC5309, October 2008, 418 . 420 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 421 Shand, "Simplified Extension of Link State PDU (LSP) Space 422 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 423 . 425 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 426 Support of Inter-Autonomous System (AS) MPLS and GMPLS 427 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 428 December 2008, . 430 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 431 Scope Link State PDUs (LSPs)", RFC 7356, 432 DOI 10.17487/RFC7356, September 2014, 433 . 435 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 436 for Advertising Router Information", RFC 7981, 437 DOI 10.17487/RFC7981, October 2016, 438 . 440 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 441 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 442 May 2017, . 444 4.2. Informative References 446 [I-D.ietf-isis-segment-routing-extensions] 447 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 448 Gredler, H., and B. Decraene, "IS-IS Extensions for 449 Segment Routing", Work in Progress, Internet-Draft, draft- 450 ietf-isis-segment-routing-extensions-25, 19 May 2019, 451 . 454 [RFC3277] McPherson, D., "Intermediate System to Intermediate System 455 (IS-IS) Transient Blackhole Avoidance", RFC 3277, 456 DOI 10.17487/RFC3277, April 2002, 457 . 459 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 460 Networks using Intermediate System to Intermediate System 461 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 462 . 464 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 465 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 466 DOI 10.17487/RFC4271, January 2006, 467 . 469 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 470 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 471 2008, . 473 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 474 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 475 DOI 10.17487/RFC5440, March 2009, 476 . 478 [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, 479 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 480 Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, 481 . 483 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 484 Extension of OSPF Using Connected Dominating Set (CDS) 485 Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, 486 . 488 [RFC5820] Roy, A., Ed. and M. Chandra, Ed., "Extensions to OSPF to 489 Support Mobile Ad Hoc Networking", RFC 5820, 490 DOI 10.17487/RFC5820, March 2010, 491 . 493 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 494 N., and JR. Rivers, "Extending ICMP for Interface and 495 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 496 April 2010, . 498 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 499 Originator Identification TLV for IS-IS", RFC 6232, 500 DOI 10.17487/RFC6232, May 2011, 501 . 503 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 504 Check Value and Timestamp TLV Definitions for Mobile Ad 505 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 506 April 2014, . 508 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 509 Nadeau, "An Architecture for the Interface to the Routing 510 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 511 . 513 Authors' Addresses 515 Russ White 516 Juniper Networks 517 Email: russ@riw.us 519 Shraddha Hegde 520 Juniper Networks 521 Email: shraddha@juniper.net 523 Tony Przygienda 524 Juniper Networks 525 Email: prz@juniper.net