idnits 2.17.1 draft-ietf-idr-flowspec-interfaceset-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 document seems to lack an Introduction section. ** There are 6 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2016) is 2871 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-idr-rtc-no-rt' is defined on line 537, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-idr-rtc-no-rt-05 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-05) exists of draft-uttaro-idr-bgp-persistence-03 Summary: 3 errors (**), 0 flaws (~~), 4 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 4 Intended status: Standards Track A. Simpson 5 Expires: November 19, 2016 Alcatel Lucent 6 K. Patel 7 Cisco 8 J. Haas 9 Juniper Networks 10 May 18, 2016 12 Applying BGP flowspec rules on a specific interface set 13 draft-ietf-idr-flowspec-interfaceset-00 15 Abstract 17 BGP Flow-spec is an extension to BGP that allows for the 18 dissemination of traffic flow specification rules. The primary 19 application of this extension is DDoS mitigation where the flowspec 20 rules are applied in most cases to all peering routers of the 21 network. 23 This document will present another use case of BGP Flow-spec where 24 flow specifications are used to maintain some access control lists at 25 network boundary. BGP Flowspec is a very efficient distributing 26 machinery that can help in saving OPEX while deploying/updating ACLs. 27 This new application requires flow specification rules to be applied 28 only on a specific subset of interfaces and in a specific direction. 30 The current specification of BGP Flow-spec does not detail where the 31 flow specification rules need to be applied. 33 This document presents a new interface-set flowspec action that will 34 be used in complement of other actions (marking, rate-limiting ...). 35 The purpose of this extension is to inform remote routers on where to 36 apply the flow specification. 38 This extension can also be used in a DDoS mitigation context where a 39 provider wants to apply the filtering only on specific peers. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [RFC2119]. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on November 19, 2016. 64 Copyright Notice 66 Copyright (c) 2016 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 82 1.1. Specific filtering for DDoS . . . . . . . . . . . . . . . 3 83 1.2. ACL maintenance . . . . . . . . . . . . . . . . . . . . . 4 84 2. Collaborative filtering and managing filter direction . . . . 5 85 3. Interface specific filtering using BGP flowspec . . . . . . . 6 86 4. Interface-set extended community . . . . . . . . . . . . . . 7 87 5. Interaction with permanent traffic actions . . . . . . . . . 8 88 5.1. Interaction with interface ACLs . . . . . . . . . . . . . 9 89 5.2. Interaction with flow collection . . . . . . . . . . . . 10 90 6. Scaling of per interface rules . . . . . . . . . . . . . . . 10 91 7. Deployment considerations . . . . . . . . . . . . . . . . . . 11 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 11.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Use case 102 1.1. Specific filtering for DDoS 104 ----------------- --- (ebgp) - Peer3 (BW 10G) 105 / \/ 106 | /| 107 | PE --- (ebgp) - Transit1(BW 4x10G) 108 Cust1 --- (ebgp) --- PE | 109 | PE ---- (ebgp) - Peer2 (BW 4*10G) 110 | \| 111 Cust2 --- (ebgp) --- PE |----- (ebgp) - Customer3 112 /| | 113 Peer1(BW10G)-(ebgp) | PE --- (ebgp) - Transit2(BW 4x10G) 114 | | 115 \ / 116 ------------------ 118 Figure 1 120 The figure 1 above displays a typical service provider Internet 121 network owing Customers, Peers and Transit. To protect pro actively 122 against some attacks (e.g. DNS, NTP ...), the service provider may 123 want to deploy some rate-limiting of some flows on peers and transit 124 links. But depending on link bandwidth, the provider may want to 125 apply different rate-limiting values. 127 For 4*10G links peer/transit, it may want to apply a rate-limiting of 128 DNS flows of 1G, while on 10G links, the rate-limiting would be set 129 to 250Mbps. Customer interfaces must not be rate-limited. 131 BGP Flow-spec infrastructure may already be present on the network, 132 and all PEs may have a BGP session running flowspec address family. 133 The Flowspec infrastructure may be reused by the service provider to 134 implement such rate-limiting in a very quick manner and being able to 135 adjust values in future quickly without having to configure each node 136 one by one. Using the current BGP flowspec specification, it would 137 not be possible to implement different rate limiter on different 138 interfaces of a same router. The flowspec rule is applied to all 139 interfaces in all directions or on some interfaces where flowspec is 140 activated but flowspec rule set would be the same among all 141 interfaces. 143 Section Section 3 will detail a solution to address this use case 144 using BGP Flowspec. 146 1.2. ACL maintenance 148 --------------- --- (ebgp) - Cust4_VPN 149 / \/ 150 Cust1_INT -- (ebgp) --- PE /| 151 | PE ------ (ebgp) - Transit1 152 Cust3_VPN -- (ebgp) --- PE | 153 | PE ------ (ebgp) - Peer2 154 | \| 155 Cust2_INT -- (ebgp) --- PE |----- (ebgp) - Cust4_INT 156 /| | 157 Peer1 ------ (ebgp) -- | PE ------ (ebgp) - Transit2 158 | | 159 \ / 160 ---------------- 162 Figure 2 164 The figure 1 above displays a typical service provider multiservice 165 network owing Customers, Peers and Transit for Internet, as well as 166 VPN services. The service provider requires to ensure security of 167 its infrastructure by applying ACLs at network boundary. Maintaining 168 and deploying ACLs on hundreds/thousands of routers is really painful 169 and time consuming and a service provider would be interested to 170 deploy/updates ACLs using BGP Flowspec. In this scenario, depending 171 on the interface type (Internet customer, VPN customer, Peer, Transit 172 ...) the content of the ACL may be different. 174 We foresee two main cases : 176 o Maintaining complete ACLs using flowspec : in this case all the 177 ingress ACL are maintained and deployed using BGPFlowspec. See 178 section Section 8 for more details on security aspects. 180 o Requirement of a quick deployment of a new filtering term due to a 181 security alert : new security alerts often requires a fast 182 deployment of new ACL terms. Using traditional CLI and hop by hop 183 provisioning, such deployment takes time and network is 184 unprotected during this time window. Using BGP flowspec to deploy 185 such rule, a service provider can protect its network in few 186 seconds. Then the SP can decide to keep the rule permanently in 187 BGP Flowspec or update its ACL or remove the entry (in case 188 equipments are not vulnerable anymore). 190 Section Section 3 will detail a solution to address this use case 191 using BGP Flowspec. 193 2. Collaborative filtering and managing filter direction 195 [RFC5575] states in Section 5. : "This mechanism is primarily 196 designed to allow an upstream autonomous system to perform inbound 197 filtering in their ingress routers of traffic that a given downstream 198 AS wishes to drop.". 200 In case of networks collaborating in filtering, there is a use case 201 for performing outbound filtering. Outbound filtering allows to 202 apply traffic action one step before and so may allow to prevent 203 impact like congestions. 205 ---------------------- 206 / \ 207 | Upstream provider | 208 \ / 209 ----------------------- 210 | | 211 |P2 |P1 212 ---------------------- 213 / \ 214 | MyAS | 215 \ / 216 ----------------------- 218 Figure 3 220 In the figure above, MyAS is connected to an upstream provider. If a 221 malicious traffic comes in from the upstream provider, it may 222 congestion P1 or P2 links. If MyAS apply inbound filtering on P1/P2 223 using BGP Flowspec, the congestion issue will not be solved. 225 Using collaborative filtering, the upstream provider may propose to 226 MyAS to filter malicious traffic sent to it. We propose to enhance 227 [RFC5575] to make myAS able to send BGP FlowSpec updates (on eBGP 228 sessions) to the upstream provider to request outbound filtering on 229 peering interfaces towards MyAS. When the upstream provider will 230 receive the BGP Flowspec update from MyAS, the BGP flowspec update 231 will contain request for outbound filtering on a specific set of 232 interfaces. The upstream provider will apply automatically the 233 requested filter and congestion will be prevented. 235 3. Interface specific filtering using BGP flowspec 237 The use case detailed above requires application of different BGP 238 Flowspec rules on different set of interfaces. The basic 239 specification detailed in [RFC5575] does not address this and does 240 not give any detail on where the FlowSpec filter need to be applied. 242 We propose to introduce, within BGP Flowspec, an identification of 243 interfaces where a particular filter should apply on. Identification 244 of interfaces within BGP Flowspec will be done through group 245 identifiers. A group identifier marks a set of interfaces sharing a 246 common administrative property. Like a BGP community, the group 247 identifier itself does not have any significance. It is up to the 248 network administrator to associate a particular meaning to a group 249 identifier value (e.g. group ID#1 associated to Internet customer 250 interfaces). The group identifier is a local interface property. 251 Any interface may be associated with one or more group identifiers 252 using manual configuration. 254 When a filtering rule advertised through BGP Flowspec must be applied 255 only to particular sets of interfaces, the BGP Flowspec BGP update 256 will contain the identifiers associated with the relevant sets of 257 interfaces. In addition to the group identifiers, it will also 258 contain the direction the filtering rule must be applied in (see 259 Section 4). 261 Configuration of group identifiers associated to interfaces may 262 change over time. An implementation MUST ensure that the filtering 263 rules (learned from BGP Flowspec) applied to a particular interface 264 are always updated when the group identifier mapping is changing. 266 Considering figure 2, we can imagine the following design : 268 o Internet customer interfaces are associated with group-identifier 269 1. 271 o VPN customer interfaces are associated with group-identifier 2. 273 o All customer interfaces are associated with group-identifier 3. 275 o Peer interfaces are associated with group-identifier 4. 277 o Transit interfaces are associated with group-identifier 5. 279 o All external provider interfaces are associated with group- 280 identifier 6. 282 o All interfaces are associated with group-identifier 7. 284 If the service provider wants to deploy a specific inbound filtering 285 on external provider interfaces only, the provider can send the BGP 286 flow specification using group-identifier 6 and including inbound 287 direction. 289 There are some cases where nodes are dedicated to specific functions 290 (Internet peering, Internet Edge, VPN Edge, Service Edge ...), in 291 this kind of scenario, there is an interest for a constrained 292 distribution of filtering rules that are using the interface specific 293 filtering. Without the constrained route distribution, all nodes 294 will received all the filters even if they are not interested in 295 those filters. Constrained route distribution of flowspec filters 296 would allow for a more optimized distribution. 298 4. Interface-set extended community 300 This document proposes a new BGP Route Target extended community 301 called "flowspec interface-set". This document so expands the 302 definition of the Route Target extended community to allow a new 303 value of high order octet (Type field) to be TBD (in addition to the 304 values specified in [RFC4360]). 306 In order to ease intra-AS and inter-AS use cases, this document 307 proposes to have a transitive as well as a non transitive version of 308 this extended community. 310 This new BGP Route Target extended community is encoded as follows : 312 0 1 2 3 313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type (TBD) | 0x02 | Autonomous System Number : 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 : AS Number (cont.) |O|I| Group Identifier | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 The flags are : 322 o O : if set, the flow specification rule MUST be applied in 323 outbound direction to the interface set referenced by the 324 following group-identifier. 326 o I : if set, the flow specification rule MUST be applied in input 327 direction to the interface set referenced by the following group- 328 identifier. 330 Both flags can be set at the same time in the interface-set extended 331 community leading to flow rule to be applied in both directions. An 332 interface-set extended community with both flags set to zero MUST be 333 treated as an error and as consequence, the FlowSpec update MUST be 334 discarded. 336 The Group Identifier is coded as a 14-bit number (values goes from 0 337 to 16383). 339 Multiple instances of the interface-set community may be present in a 340 BGP update. This may appear if the flow rule need to be applied to 341 multiple set of interfaces. 343 Multiple instances of the community in a BGP update MUST be 344 interpreted as a "OR" operation : if a BGP update contains two 345 interface-set communities with group ID 1 and group ID 2, the filter 346 would need to be installed on interfaces belonging to Group ID 1 or 347 Group ID 2. 349 As using a Route Target, route distribution of flowspec NLRI with 350 interface-set may be subject to constrained distribution as defined 351 in [RFC4684]. Constrained route distribution for flowspec routes 352 using interface-set requires discussion and will be addressed in a 353 future revision of the document. 355 5. Interaction with permanent traffic actions 357 [RFC5575] states that BGP Flowspec is primarily designed to allow 358 upstream AS to perform inbound filtering in their ingress routers. 359 This specification does not precise where this ingress filtering 360 should happen in the packet processing pipe. 362 This proposal enhances [RFC5575] in order to add action on traffic 363 coming from or going to specific interfaces. Based on this 364 enhancement, some new requirements come to implementations. 366 An implementation SHOULD apply input actions (I bit set) within the 367 input packet processing pipe. An implementation SHOULD apply output 368 actions (O bit set) within the output packet processing pipe. 370 As input and output processing pipes may also involve already present 371 static/permanent features that will manipulate the packet, the next 372 sections will try to clarify how the static behaviors should interact 373 will BGP flowspec actions. 375 5.1. Interaction with interface ACLs 377 Deploying interface specific filters using BGP FlowSpec (dynamic 378 entries) may interfere with existing permanent interface ACL (static 379 entries). The content of the existing permanent ACL MUST NOT be 380 altered by dynamic entries coming from BGP FlowSpec. Permanent ACLs 381 are using a specific ordering which is not compatible with the 382 ordering of FS rules and misordering of ACL may lead to undesirable 383 behaviour. In order, to keep a deterministic and well known 384 behaviour, an implementation SHOULD process the BGP FlowSpec ACL as 385 follows : 387 o In inbound direction, the permanent ACL action is applied first 388 followed by FlowSpec action. This gives the primary action to the 389 permanent ACL as it is done today. 391 o In outbound direction, FlowSpec action action is applied first 392 followed by permanent ACL. This gives the final action to the 393 permanent ACL as it is done today. 395 Inbound filters Outbound filters 396 --------- ------- ---------- ------- --------- 397 |Permanent| -> |Dynamic| -> |Forwarding| -> |Dynamic| -> |Permanent| 399 In order for a flow to be accepted, the flow must be accepted by the 400 two ACLs and a flow is rejected when one of the ACL rejects it as 401 described in the table below : 403 +-------------------------+--------------------------+--------------+ 404 | Permanent ACL entry | FlowSpec ACL entry | Result | 405 | action | action | action | 406 +-------------------------+--------------------------+--------------+ 407 | Drop | Drop | Drop | 408 | Drop | Accept | Drop | 409 | Accept | Drop | Drop | 410 | Accept | Accept | Accept | 411 +-------------------------+--------------------------+--------------+ 413 Example : 415 o ACL permanent IN : 417 * Entry 1 : permit udp from 10/8 to 11/8 port 53 419 * Entry 2 : permit tcp from 10/8 to 11/8 port 22 420 * Entry 3 : deny ip from 10/8 to 11/8 422 o ACL dynamic FlowSpec IN : 424 * Entry 1 : deny udp from 10.0.0.1/32 to 11/8 port 53 426 * Entry 2 : permit tcp from 10/8 to 11/8 port 80 428 In the example above : 430 o a UDP flow from 10.0.0.1 to 11.0.0.2 on port 53 will be rejected 431 because the dynamic ACL rejects it. 433 o a UDP flow from 10.0.0.2 to 11.0.0.2 on port 53 will be accepted 434 because both ACLs accept it. 436 o a TCP flow from 10.0.0.2 to 11.0.0.2 on port 80 will be rejected 437 because permanent ACL rejects it. 439 5.2. Interaction with flow collection 441 A router may activate flow collection features (used in collaboration 442 with Netflow export). Flow collection can be done at input side or 443 output side. As for ACL, an implementation SHOULD process : 445 o BGP FS rules after the inbound flow collection : in case of DDoS 446 protection, it is important to keep monitoring of attack flows and 447 so performing action, after collection. 449 o BGP FS rules before the outbound flow collection : purpose of 450 outbound flow collection is really to track flows that are exiting 451 the interface. BGP FS rules should not interfere in this. 453 Inbound Outbound 454 Flow BGP BGP Flow 455 collection FS FS collection 456 --------- ------- ---------- ------- --------- 457 |Permanent| -> |Dynamic| -> |Forwarding| -> |Dynamic| -> |Permanent| 459 6. Scaling of per interface rules 461 Creating rules that are applied on specific interfaces may create 462 forwarding rules that may be harder to share. 464 An implementation SHOULD take care about trying to keep sharing 465 forwarding structures as much as possible in order to limit the 466 scaling impact. How the implementation would do so is out of scope 467 of the document. 469 7. Deployment considerations 471 There are some cases where a particular BGP Flowspec NLRI may be 472 advertised to different interface groups with a different action. 473 For example, a service provider may want to discard all ICMP traffic 474 from customer interfaces to infrastructure addresses and want to 475 rate-limit the same traffic when it comes from some internal 476 platforms. These particular cases require ADD-PATH to be deployed in 477 order to ensure that all paths (NLRI+interface group+actions) are 478 propagated within the BGP control plane. Without ADD-PATH, only a 479 single "NLRI+interface group+actions" will be propagated, so some 480 filtering rules will never be applied. 482 8. Security Considerations 484 Managing permanent Access Control List by using BGP Flowspec as 485 described in Section 1.2 helps in saving roll out time of such ACL. 486 However some ACL especially at network boundary are critical for the 487 network security and loosing the ACL configuration may lead to 488 network open for attackers. 490 By design, BGP flowspec rules are ephemeral : the flow rule exists in 491 the router while the BGP session is UP and the BGP path for the rule 492 is valid. We can imagine a scenario where a Service Provider is 493 managing the network boundary ACLs by using only FlowSpec. In this 494 scenario, if , for example, an attacker succeed to make the internal 495 BGP session of a router to be down , it can open all boundary ACLs on 496 the node, as flowspec rules will disappear due to the BGP session 497 down. 499 In reality, the chance for such attack to occur is low, as boundary 500 ACLs should protect the BGP session from being attacked. 502 In order to complement the BGP flowspec solution is such deployment 503 scenario and provides security against such attack, a service 504 provider may activate Long lived Graceful Restart 505 [I-D.uttaro-idr-bgp-persistence] on the BGP session owning Flowspec 506 address family. So in case of BGP session to be down, the BGP paths 507 of Flowspec rules would be retained and the flowspec action will be 508 retained. 510 9. Acknowledgements 512 Authors would like to thanks Wim Hendrickx for his valuable comments. 514 10. IANA Considerations 516 This document requests a new type from the "BGP Transitive Extended 517 Community Types" extended community registry. This type name shall 518 be 'FlowSpec'. 520 This document requests a new type from the "BGP Non-Transitive 521 Extended Community Types" extended community registry. This type 522 name shall be 'FlowSpec'. 524 This document requests creation of a new registry called "FlowSpec 525 Extended Community Sub-Types". This registry contains values of the 526 second octet (the "Sub-Type" field) of an extended community when the 527 value of the first octet (the "Type" field) is to one of those 528 allocated in this document. 530 Within this new registry, this document requests a new subtype 531 (suggested value 0x02), this sub-type shall be named "interface-set". 533 11. References 535 11.1. Normative References 537 [I-D.ietf-idr-rtc-no-rt] 538 Rosen, E., Patel, K., Haas, J., and R. Raszuk, "Route 539 Target Constrained Distribution of Routes with no Route 540 Targets", draft-ietf-idr-rtc-no-rt-05 (work in progress), 541 May 2016. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 549 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 550 February 2006, . 552 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 553 R., Patel, K., and J. Guichard, "Constrained Route 554 Distribution for Border Gateway Protocol/MultiProtocol 555 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 556 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 557 November 2006, . 559 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 560 and D. McPherson, "Dissemination of Flow Specification 561 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 562 . 564 11.2. Informative References 566 [I-D.uttaro-idr-bgp-persistence] 567 Uttaro, J., Chen, E., Decraene, B., and J. Scudder, 568 "Support for Long-lived BGP Graceful Restart", draft- 569 uttaro-idr-bgp-persistence-03 (work in progress), November 570 2013. 572 Authors' Addresses 574 Stephane Litkowski 575 Orange 577 Email: stephane.litkowski@orange.com 579 Adam Simpson 580 Alcatel Lucent 582 Email: adam.simpson@alcatel-lucent.com 584 Keyur Patel 585 Cisco 587 Email: keyupate@cisco.com 589 Jeff Haas 590 Juniper Networks 592 Email: jhaas@juniper.net