idnits 2.17.00 (12 Aug 2021) /tmp/idnits41792/draft-white-lsr-distoptflood-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 (2 March 2022) is 80 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 362, but no explicit reference was found in the text == Unused Reference: 'ISO10589' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC5301' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC5303' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'RFC5308' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC5309' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC5311' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC5316' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC7356' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC7981' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC3277' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC3719' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC5820' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC5837' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC6232' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'RFC7921' is defined on line 502, 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: 3 September 2022 Juniper Networks 6 2 March 2022 8 IS-IS Optimal Distributed Flooding for Dense Topologies 9 draft-white-lsr-distoptflood-01 11 Abstract 13 In dense topologies (such as data center fabrics based on the Clos 14 and butterfly, though not limited to these topologies), flooding 15 mechanisms designed for sparse topologies can flood excessively, or 16 carry too many copies of topology and reachability to fabric devices. 17 This results in slower convergence times and higher resource 18 utilization. The modifications to the flooding mechanism in the 19 Intermediate System to Intermediate System (IS-IS) link state 20 protocol described in this document reduce resource utilization to a 21 minimum, 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 dense 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 3 September 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 . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . 11 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 dense mesh topology. 84 The problem with such topologies is the connectivity density, which 85 causes too much information to be flooded (or too much repeated state 86 to be flooded). Analysis and experiment show, for instance, that in 87 a butterfly fabric of around 2500 intermediate systems, each 88 intermediate system will receive 40+ copies of any changed LSP 89 fragment. This not only wastes bandwidth and processor time, this 90 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 framgents 94 received by individual intermediate systems, potentially to one copy 95 per intermediate system. The mechanism described here chooses 96 different flooding intermediates using a hash across the system ID to 97 prevent single failures from having a large impact on flooding, and 98 to spread the processing load of flooding across many systems and 99 prevent bottlenecks. 101 The mechanisms described in this document are similar to those 102 implemented in OSPF to support mobile ad-hoc networks, as described 103 in [RFC5449], [RFC5614], and [RFC7182]. Mechanisms similar to these 104 have been widely implemented and deployed. 106 1.2. Contributors 108 The following people have contributed to this draft: Abhishek Kumar, 109 Nikos Triantafillis, Ivan Pepelnjak, Christian Franke, Hannes 110 Gredler, Les Ginsberg, Naiming Shen, Uma Chunduri, Nick Russo, and 111 Rodny Molina. 113 1.3. Experience 115 Lab testing shows modifications similar to these reduce flooding in a 116 large scale emulated butterfly network topology; without these 117 modifications, intermediate systems receive, on average, 40 copies of 118 any changed LSP fragment. With these modifications, intermediate 119 systems recieve, on average, two copies of any changed LSP fragment. 120 In many cases, each intermediate system receives one copy of each 121 changed LSP. In terms of performance, the modifications described 122 here reduce convergence times by around 50%. A network that converges 123 in about 30-40 seconds without these modifications converged in 15-20 124 seconds with these modifications. Processor load times were not 125 checked, as this was an emulated environment. 127 A mechanism similar to the one described in this document has been 128 implemented in the FR Routing open source routing stack as part of 129 fabricd. 131 1.4. Sample Network 133 The following spine and leaf fabric will be used to describe these 134 modifications. 136 +----+ +----+ +----+ +----+ +----+ +----+ 137 | 1A | | 1B | | 1C | | 1D | | 1E | | 1F | (T0) 138 +----+ +----+ +----+ +----+ +----+ +----+ 140 +----+ +----+ +----+ +----+ +----+ +----+ 141 | 2A | | 2B | | 2C | | 2D | | 2E | | 2F | (T1) 142 +----+ +----+ +----+ +----+ +----+ +----+ 144 +----+ +----+ +----+ +----+ +----+ +----+ 145 | 3A | | 3B | | 3C | | 3D | | 3E | | 3F | (T2) 146 +----+ +----+ +----+ +----+ +----+ +----+ 148 +----+ +----+ +----+ +----+ +----+ +----+ 149 | 4A | | 4B | | 4C | | 4D | | 4E | | 4F | (T1) 150 +----+ +----+ +----+ +----+ +----+ +----+ 152 +----+ +----+ +----+ +----+ +----+ +----+ 153 | 5A | | 5B | | 5C | | 5D | | 5E | | 5F | (T0) 154 +----+ +----+ +----+ +----+ +----+ +----+ 156 Figure 1 158 To reduce confusion (spine and leaf fabrics are difficult to draw in 159 plain text art), this diagram does not contain the connections 160 between devices. The reader should assume that each device in a 161 given layer is connected to every device in the layer above it. For 162 instance: 164 * 5A is connected to 4A, 4B, 4C, 4D, 4E, and 4F 166 * 5B is connected to 4A, 4B, 4C, 4D, 4E, and 4F 168 * 4A is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 169 5F 171 * 4B is connected to 3A, 3B, 3C, 3D, 3E, 3F, 5A, 5B, 5C, 5D, 5E, and 172 5F 174 * etc. 176 The tiers or stages of the fabric are also marked for easier 177 reference. T0 is assumed to be connected to application servers, or 178 rather they are Top of Rack (ToR) intermediate systems. The 179 remaining tiers, T1 and T2, are connected only to other devices in 180 the fabric itself. 182 2. Flooding Modifications 184 Flooding is perhaps the most challenging scaling issue for a link 185 state protocol running on a dense, large scale fabric. This section 186 describes modifications to the IS-IS flooding process to reduce 187 flooding load on a dense or mesh topology. 189 2.1. Optimizing Flooding 191 The simplest way to conceive of the solution presented here is in two 192 stages: 194 * Stage 1: Forward Optimization 196 - Find the group of intermediate systems that will all flood to 197 the same set of neighbors as the local IS 199 - Decide (deterministially) which of the intermediate systems 200 within this group should flood any received LSPs 202 * Stage 2: Reverse Optimization 204 - Find neighbors on the shortest path towards the origin of the 205 change 207 - Do not flood towards these neighbors 209 The first stage is best explained through an illustration. In the 210 network above, if 5A transmits a modified Link State Protocol Data 211 Unit (LSP) to 4A-4F, each of 4A-4F will, in turn, flood this modified 212 LSP to 3A (for instance). 3A will receive 6 copies of the modified 213 LSP, while only one copy is necessary for the intermediate systems 214 shown to converge on a single view of the topology. If 4A-4F could 215 determine they will all flood identical copies of the modified LSP to 216 3A, it is possible for all of them except one to decide not to flood 217 the changed LSP to 3A. 219 The technique used in this draft to determine the flooding group is 220 for each intermediate system to calculate a special SPT from the 221 point of view of the transmitting neighbor. By setting the metric of 222 all links to 1 and truncating the SPT to two hops, the local IS can 223 find the group of neighbors it will flood any changed LSP towards and 224 the set of intermediate systems (not necessarily neighbors) which 225 will also flood to this same set of neighbors. If every intermediate 226 system in the flooding set performs this same calculation, they will 227 all obtain the same flooding group. 229 Once this flooding group is determined, the members of the flooding 230 group will each (independently) choose which of the members should 231 flood. Each member of the flooding group calculates this 232 independently of all the other members, using a common hash across a 233 set of shared variables so each member of the group comes to the same 234 conclusion. The group member which is selected to flood the changed 235 LSP does so normally; the remaining group members do not flood the 236 LSP. 238 Note there is no signaling between the intermediate systems running 239 this flooding reduction mechanism. Each IS calculates a special, 240 truncated SPT separately, and determines which IS should flood any 241 changed LSPs independently. Because these calculations are performed 242 using a shared view of the network, however (based on the common link 243 state database) and a shared sorting hash, each member of the 244 flooding group will make the same decision. 246 The second stage is simpler, consisting of a single rule: do not 247 flood modified LSPs along the shortest path towards the origin of the 248 modified LSP. This rule relies on the observation that any IS 249 between the origin of the modified LSP and the local IS should 250 receive the modified LSP from some other IS closer to the source of 251 the modified LSP. 253 2.2. Optimization Process 255 Each intermediate system will determine whether it should reflood as 256 described below, when a modified LSP arrives from a Transmitting 257 Neighbor (TN), by: 259 Step 1: Build the Two-Hop List (THL) and Remote Neighbor's List (RNL) 260 by: 262 * Set all link metrics to 1 264 * Calculate an SPT truncated to 2 hops from the perspective of TN 266 * For each IS that is two hops (has a metric of two in the truncated 267 SPT) from TN: 269 - If the IS is on the shortest path towards the originator of the 270 modified LSP, skip 272 - If the IS is not on the shortest path towards the originator of 273 the modified LSP, add it to THL 275 * Add each IS that is one hop away from TN to the RNL 276 Step 2: Sort RNL by system IDs, from the least to the greatest. 278 Step 3: Calculate a number, N, by adding each byte in the LSP 279 originator's System-ID and then taking MOD on the number of 280 neighbors. N MUST be less than the number of members of RNL. 282 Step 4: Starting with the Nth member of RNL: 284 * If THL is empty, exit 286 * If this member of RNL is the local calculating IS, this IS MUST 287 reflood the modified LSP; exit 289 * Remove all members of THL connected to (adjacent to) this member 290 of RNL 292 * Move to the next member of RNL, wrapping to the beginning of RNL 293 if necessary 295 Note: This description is geared to clarity rather than optimal 296 performance. 298 2.3. Flooding Failures 300 It is possible in some failure modes for flooding to be incomplete 301 because of the flooding optimizations outlined. Specifically, if a 302 reflooder fails, or is somehow disconnected from all the links across 303 which it should be reflooding, it is possible an LSP is only 304 partially flooded through the fabric. To prevent faliures, an 305 intermediate system which does not reflood an LSP (or fragment) 306 should: 308 * Set a short timer; the default should be less than one second 310 * When the timer expires, send a Partial Sequence Number Packet 311 (PSNP) to all neighbors 313 * Process any Partial Sequence Number Packets (PSNPs) as required to 314 resynchronize 316 * Log/notify if a resynchronization is required 318 2.4. Flooding Example 320 Assume, in the network above, 5A floods some modified LSP towards 4A- 321 4F. To determine whether 4A should flood this LSP to 3A-3F: 323 * 5A is TN; 4A calculates a truncated SPT from 5A's perspective with 324 all link metrics set to 1 326 * 4A builds THL, which contains 3A, 3B, 3C, 3D, 3E, 3F, 5B, 5C, 5D, 327 5E and 5F 329 * 4A builds RNL, which contains 4A,4B,4C,4D,4E and 4F, sorting it by 330 the system ID 332 * 4A computes hash on the received LSP-ID to get N; assume N is 1 in 333 this case 335 * Since 4A is the Nth member of R-NL and there are members in N-NL, 336 4A must reflood; the loop exits 338 2.5. A Note on Performance 340 The calculations described here are complex, which might lead the 341 reader to conclude that the cost of calculation is so much higher 342 than the cost of flooding that this optimization is counter- 343 productive. The description provided here is designed for clarity 344 rather than optimal calculation, however. Many of the calculations 345 can be performed in advance and stored, rather than being performed 346 for each LSP and each neighbor. Optimized versions of the process 347 described here have been implemented, and do result in strong 348 convergence speed gains. 350 3. Security Considerations 352 This document outlines modifications to the IS-IS protocol for 353 operation on high density network topologies. Implementations SHOULD 354 implement IS-IS cryptographic authentication, as described in 355 [RFC5304], and should enable other security measures in accordance 356 with best common practices for the IS-IS protocol. 358 4. References 360 4.1. Normative References 362 [I-D.ietf-lsr-dynamic-flooding] 363 Li, T., Przygienda, T., Psenak, P., Ginsberg, L., Chen, 364 H., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra, 365 "Dynamic Flooding on Dense Graphs", Work in Progress, 366 Internet-Draft, draft-ietf-lsr-dynamic-flooding-10, 7 367 December 2021, . 370 [ISO10589] International Organization for Standardization, 371 "Intermediate system to Intermediate system intra-domain 372 routeing information exchange protocol for use in 373 conjunction with the protocol for providing the 374 connectionless-mode Network Service (ISO 8473)", ISO/ 375 IEC 10589:2002, Second Edition, November 2002. 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 383 DOI 10.17487/RFC2629, June 1999, 384 . 386 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 387 Topology (MT) Routing in Intermediate System to 388 Intermediate Systems (IS-ISs)", RFC 5120, 389 DOI 10.17487/RFC5120, February 2008, 390 . 392 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 393 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 394 October 2008, . 396 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 397 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, 398 DOI 10.17487/RFC5303, October 2008, 399 . 401 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 402 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 403 2008, . 405 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 406 DOI 10.17487/RFC5308, October 2008, 407 . 409 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 410 over LAN in Link State Routing Protocols", RFC 5309, 411 DOI 10.17487/RFC5309, October 2008, 412 . 414 [RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M. 415 Shand, "Simplified Extension of Link State PDU (LSP) Space 416 for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009, 417 . 419 [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 420 Support of Inter-Autonomous System (AS) MPLS and GMPLS 421 Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, 422 December 2008, . 424 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 425 Scope Link State PDUs (LSPs)", RFC 7356, 426 DOI 10.17487/RFC7356, September 2014, 427 . 429 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 430 for Advertising Router Information", RFC 7981, 431 DOI 10.17487/RFC7981, October 2016, 432 . 434 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 435 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 436 May 2017, . 438 4.2. Informative References 440 [I-D.ietf-isis-segment-routing-extensions] 441 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 442 Gredler, H., and B. Decraene, "IS-IS Extensions for 443 Segment Routing", Work in Progress, Internet-Draft, draft- 444 ietf-isis-segment-routing-extensions-25, 19 May 2019, 445 . 448 [RFC3277] McPherson, D., "Intermediate System to Intermediate System 449 (IS-IS) Transient Blackhole Avoidance", RFC 3277, 450 DOI 10.17487/RFC3277, April 2002, 451 . 453 [RFC3719] Parker, J., Ed., "Recommendations for Interoperable 454 Networks using Intermediate System to Intermediate System 455 (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, 456 . 458 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 459 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 460 DOI 10.17487/RFC4271, January 2006, 461 . 463 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 464 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 465 2008, . 467 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 468 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 469 DOI 10.17487/RFC5440, March 2009, 470 . 472 [RFC5449] Baccelli, E., Jacquet, P., Nguyen, D., and T. Clausen, 473 "OSPF Multipoint Relay (MPR) Extension for Ad Hoc 474 Networks", RFC 5449, DOI 10.17487/RFC5449, February 2009, 475 . 477 [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) 478 Extension of OSPF Using Connected Dominating Set (CDS) 479 Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, 480 . 482 [RFC5820] Roy, A., Ed. and M. Chandra, Ed., "Extensions to OSPF to 483 Support Mobile Ad Hoc Networking", RFC 5820, 484 DOI 10.17487/RFC5820, March 2010, 485 . 487 [RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, 488 N., and JR. Rivers, "Extending ICMP for Interface and 489 Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, 490 April 2010, . 492 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 493 Originator Identification TLV for IS-IS", RFC 6232, 494 DOI 10.17487/RFC6232, May 2011, 495 . 497 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 498 Check Value and Timestamp TLV Definitions for Mobile Ad 499 Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, 500 April 2014, . 502 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 503 Nadeau, "An Architecture for the Interface to the Routing 504 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 505 . 507 Authors' Addresses 509 Russ White 510 Juniper Networks 511 Email: russ@riw.us 512 Shraddha Hegde 513 Juniper Networks 514 Email: shraddha@juniper.net 516 Tony Przygienda 517 Juniper Networks 518 Email: prz@juniper.net