idnits 2.17.1 draft-mohanty-l2vpn-evpn-df-election-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 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 (March 7, 2015) is 3331 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-l2vpn-evpn' is defined on line 427, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999' == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Working Group S. Mohanty 3 Internet-Draft K. Patel 4 Intended status: Standards Track A. Sajassi 5 Expires: September 8, 2015 Cisco Systems, Inc. 6 J. Drake 7 Juniper Networks, Inc. 8 March 7, 2015 10 A new Designated Forwarder Election for the EVPN 11 draft-mohanty-l2vpn-evpn-df-election-01 13 Abstract 15 This document describes an improved EVPN Designated Forwarder 16 Election (DF) algorithm which can be used to enhance operational 17 experience in terms of convergence speed and robustness over a WAN 18 deploying EVPN 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 8, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. The modulus based DF Election Algorithm . . . . . . . . . . . 4 57 3. Problems with the modulus based DF Election Algorithm . . . . 4 58 4. Highest Random Weight . . . . . . . . . . . . . . . . . . . . 6 59 5. HRW and Consistent Hashing . . . . . . . . . . . . . . . . . 7 60 6. HRW Algorithm for EVPN DF Election . . . . . . . . . . . . . 7 61 7. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8 62 8. Operational Considerations . . . . . . . . . . . . . . . . . 9 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 11.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 Ethernet MPLS VPN (EVPN) [RFC7432]is an emerging technology that is 73 gaining prominence in Internet Service Provider IP/MPLS networks. In 74 EVPN, mac addresses are disseminated as routes across the 75 geographical area via the Border Gateway Protocol, BGP [RFC4271] 76 using the familiar L3VPN model [RFC4364]. An EVPN instance that 77 spans across PEs is defined as an EVI. Constrained Route 78 Distribution [RFC4684] can be used in conjunction to selectively 79 advertise the routes to where they are needed. One of the major 80 advantages of EVPN over VPLS [RFC4761],[RFC6624] is that it provides 81 a solution for minimizing flooding of unknown traffic and also 82 provides all Active mode of operation so that the traffic can truly 83 be multi-homed. In technologies such as EVPN or VPLS, managing 84 Broadcast, Unknown Unicast and multicast traffic (BUM) is a key 85 requirement. In the case where the customer edge (CE) router is 86 multi-homed to one or more Provider Edge (PE) Routers, it is 87 necessary that one and only one of the PE routers should forward BUM 88 traffic into the core or towards the CE as and when appropriate. 90 Specifically, quoting Section 8.5, [RFC7432], Consider a CE that is a 91 host or a router that is multi-homed directly to more than one PE in 92 an EVPN instance on a given Ethernet segment. One or more Ethernet 93 Tags may be configured on the Ethernet segment. In this scenario 94 only one of the PEs, referred to as the Designated Forwarder (DF), is 95 responsible for certain actions: 97 a. Sending multicast and broadcast traffic, on a given Ethernet Tag 98 on a particular Ethernet segment, to the CE. 100 b. Flooding unknown unicast traffic (i.e. traffic for which an PE 101 does not know the destination MAC address), on a given Ethernet 102 Tag on a particular Ethernet segment to the CE, if the 103 environment requires flooding of unknown unicast traffic. 105 +---------------+ 106 | IP/MPLS | 107 | CORE | 108 +----+ ES1 +----+ +----+ 109 | CE1|-----| |-----------| |____ES2 110 +----+ | PE1| | PE2| \ 111 | |-------- +----+ \+----+ 112 +----+ | | | CE2| 113 | | +----+ /+----+ 114 | |__| |____/ | 115 | | PE3| ES2 / 116 | +----+ / 117 | | / 118 +-------------+----+ / 119 | PE4|____/ES2 120 | | 121 +----+ 123 Figure 1 Multi-homing Network of E-VPN 125 Figure 1 127 Figure 1 illustrates a case where there are two Ethernet Segments, 128 ES1 and ES2. PE1 is attached to CE1 via Ethernet Segment ES1 whereas 129 PE2, PE3 and PE4 are attached to CE2 via ES2 i.e. PE2, PE3 and PE4 130 form a redundancy group. Since CE2 is multi-homed to different PEs 131 on the same Ethernet Segment, it is necessary for PE2, PE3 and PE4 to 132 agree on a DF to satisfy the above mentioned requirements. 134 Layer2 devices are particularly susceptible to forwarding loops 135 because of the broadcast nature of the Ethernet traffic. Therefore 136 it is very important that in case of multi-homing, only one of the 137 links be used to direct traffic to/from the core. 139 One of the pre-requisites for this support is that participating PEs 140 must agree amongst themselves as to who would act as the Designated 141 Forwarder. This needs to be achieved through a distributed algorithm 142 in which each participating PE independently and unambiguously 143 selects one of the participating PEs as the DF, and the result should 144 be unanimously in agreement. 146 The DF election algorithm as described in the base EVPN draft has 147 some undesirable properties and in some cases can be somewhat 148 disruptive and unfair. This document describes those issues and 149 proposes a mechanism for dealing with those issues. These mechanisms 150 do involve changes to the DF Election algorithm , but do not require 151 any protocol changes to the EVPN Route exchange and have minimal 152 changes to their content per se. 154 1.1. Requirements Language 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 2. The modulus based DF Election Algorithm 162 The default procedure for DF election at the granularity of (ESI,EVI) 163 is referred to as "service carving". With service carving, it is 164 possible to elect multiple DFs per Ethernet Segment (one per EVI) in 165 order to perform load-balancing of multi-destination traffic destined 166 to a given Segment. The objective is that the load-balancing 167 procedures should carve up the EVI space among the redundant PE nodes 168 evenly, in such a way that every PE is the DF for a disjoint set of 169 EVIs. 171 The existing DF algorithm as described in the EVPN RFC(Section 8.5 172 [RFC7432]) is based on a modulus operation. The PEs to which the ES 173 (for which DF election is to be carried out per vlan) is multi-homed 174 form an ordered (ordinal) list in ascending order of the PE ip 175 address values. Say, there are N PEs, P0, P1, ... PN-1 ranked as per 176 increasing IP addresses in the ordinal list; then for each vlan with 177 ethernet tag v, configured on the ethernet segment ES1, PEx is the DF 178 for vlan v on ES ES1 when x equals (v mod N). In the case when the 179 vlan density is high meaning there are significant number of vlans 180 and the vlan-id or ethernet-tag is uniformly distributed, the 181 thinking is that the DF election will be spread across the PEs 182 hosting that ethernet segment and good service carving can be 183 achieved. 185 3. Problems with the modulus based DF Election Algorithm 187 There are three fundamental problems with the current DF Election. 189 First, the algorithm will not perform well when the ethernet tag 190 follows a non-uniform distribution, for instance when the ethernet 191 tags are all even or all odd. In such a case let us assume that 192 the ES is multi-homed to two PEs; all the vlans will only pick one 193 of the PEs as the DF. This is very sub-optimal. It defeats the 194 purpose of service carving as the DFs are not really evenly spread 195 across. In this particular case, in fact one of the PEs does not 196 get elected all as the DF, so it does not participate in the DF 197 responsibilities at all. Consider another example where referring 198 to Figure 1, lets assume that PE2, PE3, PE4 are in ascending order 199 of the IP address; and each vlan configured on ES2 is associated 200 with an Ethernet Tag of of the form (3x+1), where x is an integer. 201 This will result in PE3 always be selected as the DF. 203 Even in the case when the ethernet tag distribution is uniform the 204 instance of a PE being up or down results in re-computation ((v 205 mod N-1) or (v mod N+1) as is the case); The resulting modulus 206 value need not be uniformly distributed but subject to the 207 primality of N-1 or N+1 as may be the case. 209 The third problem is one of disruption. Consider a case when the 210 same Ethernet Segment is multi homed to a set of PEs. When the ES 211 is down in one of the PEs, say PE1, or PE1 itself reboots, or the 212 BGP process goes down or the connectivity between PE1 and an RR 213 goes down, the effective number of PEs in the system now becomes 214 N-1 and DFs are computed for all the vlans that are configured on 215 that ethernet segment. In general, if the DF for a vlan v happens 216 not to be PE1, but some other PE, say PE2, it is likely that some 217 other PE will become the new DF. This is not desirable. 218 Similarly when a new PE hosts the same Ethernet segment, the 219 mapping again changes because of the mod operation. This results 220 in needless churn. Again referring to Figure 1, say v1, v2 and v3 221 are vlans configured on ES2 with associated ethernet tags of value 222 999, 1000 and 10001 respectively. So PE1, PE2 and PE3 are also 223 the DFs for v1, v2 and v3 respectively. Now when PE3 goes down, 224 PE2 will become the DF for v1 and PE1 will become the DF for v2. 226 One point to note is that the current DF election algorithm assumes 227 that all the PEs who are multi-homed to the same Ethernet Segment and 228 interested in the DF Election by exchanging EVPN routes have a V4 229 peering with each other or via a Route Reflector. This need not be 230 the case as there can be a v6 peering and supporting the EVPN 231 address-family. 233 Mathematically, a conventional hash function maps a key k to a number 234 i representing one of m hash buckets through a function h(k) i.e. 235 i=h(k). In the EVPN case, h is simply a modulo-m hash function viz. 236 h(v) = v mod N, where N is the number of PEs that are multi-homed to 237 the Ethernet Segment in discussion. It is well-known that for good 238 hash distribution using the modulus operation, the modulus N should 239 be a prime-number not too close to a power of 2 [CLRS2009]. When the 240 effective number of PEs changes from N to N-1 (or vice versa); all 241 the objects (vlan v) will be remapped except those for which v mod N 242 and v mod (N-1) refer to the same PE in the previous and subsequent 243 ordinal rankings respectively. 245 From a forwarding perspective, this is a churn, as it results in 246 programming the CE and PE side ports as blocking or non-blocking at 247 potentially all PEs when the DF changes either because (i) a new PE 248 is added or (ii) another one goes down or loses connectivity or else 249 cannot take part in the DF election process for whatever reason. 250 This draft addresses this problem and furnishes a solution to this 251 undesirable behavior. 253 4. Highest Random Weight 255 Highest Random Weight (HRW) as defined in [HRW1999] is originally 256 proposed in the context of Internet Caching and proxy Server load 257 balancing. Given an object name and a set of servers, HRW maps a 258 request to a server using the object-name (object-id) and server-name 259 (server-id) rather than the state of the server states. HRW forms a 260 hash out of the server-id and the object-id and forms an ordered list 261 of the servers for the particular object-id. The server for which 262 the hash value is highest, serves as the primary responsible for that 263 particular object, and the server with the next highest value in that 264 hash serves as the backup server. HRW always maps a given object 265 object name to the same server within a given cluster; consequently 266 it can be used at client sites to achieve global consensus on object- 267 server mappings. When that server goes down, the backup server 268 becomes the responsible designate. 270 Choosing an appropriate hash function that is statistically oblivious 271 to the key distribution and imparts a good uniform distribution of 272 the hash output is an important aspect of the algorithm,. Fortunately 273 many such hash functions exist. [HRW1999] provides pseudorandom 274 functions based on Unix utilities rand and srand and easily 275 constructed XOR functions that perform considerably well. This 276 imparts very good properties in the load balancing context. Also 277 each server independently and unambiguously arrives at the primary 278 server selection. HRW already finds use in multicast and ECMP 279 [RFC2991],[RFC2992]. 281 In the existing DF algorithm Section 2, whenever a new PE comes up or 282 an existing PE goes down, there is a significant interval before the 283 change is noticed by all peer PEs as it has to be conveyed by the BGP 284 update message involving the type-4 route. There is a timer to batch 285 all the messages before triggering the service carving procedures. 286 When the timer expires, each PE will build the ordered list and 287 follow the procedures for DF Election. In the proposed method which 288 we will describe shortly this "jittered" behavior is retained. 290 5. HRW and Consistent Hashing 292 HRW is not the only algorithm that addresses the object to server 293 mapping problem with goals of fair load distribution, redundancy and 294 fast access. There is another family of algorithms that also 295 addresses this problem; these fall under the umbrella of the 296 Consistent Hashing Algorithms [CHASH]. These will not be considered 297 here. 299 6. HRW Algorithm for EVPN DF Election 301 The applicability of HRW to DF Election can be described here. Let 302 DF(v) denote the Designated Forwarder and BDF(v) the Backup 303 Designated forwarder for the ethernet tag V, where v is the vlan, Si 304 is the IP address of server i and weight is a pseudorandom function 305 of v and Si 307 1. DF(v) = Si: Weight(v, Si) >= Weight(V, Sj) , for all j. In case 308 of a tie, choose the PE whose IP address is numerically the 309 least. 311 2. BDF(v) = Sk: Weight(v, Si) >= Weight(V, Sk) and Weight(v, Sk) >= 312 Weight(v, Sj). in case of tie choose the PE whose IP address is 313 numerically the least. 315 Since the Weight is a Pseudorandom function with domain as a 316 concatenation of (v, S), it is an efficient deterministic algorithm 317 which is independent of the Ethernet Tag V sample space distribution. 318 Choosing a good hash function for the pseudorandom function is an 319 important consideration for this algorithm to perform provably better 320 than the existing algorithm. As mentioned previously, such functions 321 are described in the HRW paper. We take as candidate hash functions 322 two of the ones that are preferred in [HRW1999]. 324 1. Wrand(v, Si) = (1103515245((1103515245.Si+12345)XOR 325 D(v))+12345)(mod 2^31) and 327 2. Wrand2(v, Si) = (1103515245((1103515245.D(v)+12345)XOR 328 Si)+12345)(mod 2^31) 330 Here D(v) is the 31-bit digest of the ethernet-tag v and Si is 331 address of the ith server. The server's IP address length does not 332 matter as only the low-order 31 bits are modulo significant. 334 A point to note is that the the domain of the Weight function is a 335 concatenation of the ethernet-tag and the PE IP-address, and the 336 actual length of the server IP address (whether V4 or V6) is not 337 really relevant, so long as the actual hash algorithm takes into 338 consideration the concatenated string. The existing algorithm in 339 [RFC7432] as is cannot employ both V4 and V6 neighbor peering 340 address. 342 HRW solves the disadvantage pointed out in Section 3 and ensures (i) 343 with very high probability that the task of DF election for 344 respective vlans is more or less equally distributed among the PEs 345 even for the 2 PE case (ii)If a PE, hosting some vlans on given ES, 346 but is neither the DF nor the BDF for that vlan, goes down or its 347 connection to the ES goes down, it does not result in a DF and BDF 348 reassignment the other PEs. This saves computation, especially in 349 the case when the connection flaps. (iii)More importantly it avoids 350 the needless disruption case (c) that are inherent in the existing 351 modulus based algorithm (iv)In addition to the DF, the algorithm also 352 furnishes the BDF, which would be the DF if the current DF fails. 354 7. Protocol Considerations 356 Note that for the DF election procedures to be globally convergent 357 and unanimous, it is necessary that all the participating PEs agree 358 on the DF Election algorithm to be used. It is not possible that 359 some PEs continue to use the existing modulus based DF election and 360 some newer PEs use the HRW. For brownfield deployments and for 361 interoperability with legacy boxes, its is important that all PEs 362 need to have the capability to fall back on the modulus algorithm. A 363 PE (one with a newer version of the software) can indicate its 364 willingness to support HRW by signaling a new extended community 365 along with the Ethernet-Segment Route (Type-4). This extended 366 community is explained in the next paragraph. When a PE receives the 367 Ethernet-Segment Routes from all the other PEs for the ethernet 368 segment in question, it checks to see if all the advertisements have 369 the extended community attached; in the case that they do, this 370 particular PE, and by induction all the other PEs proceed to do DF 371 Election as per the HRW Algorithm. Otherwise if even a single 372 advertisement for the type-4 route is not received with the extended 373 community, the default modulus algorithm is used as before. Also, 374 the HRW algorithm needs to be executed after the "jittered" time. 376 A new BGP extended community attribute [RFC4360] needs to be defined 377 to identify the DF election procedure to be used for the Ethernet 378 Segment. We propose to name this extended community as the DF 379 Election Extended Community. It is a new transitive extended 380 community where the Type field is 0x06, and the Sub-Type is to be 381 defined. It may be advertised along with Ethernet Segment routes. 383 Each DF Election Extended Community is encoded as a 8-octet value as 384 follows: 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type=0x06 | Sub-Type(TBD) | DF Type(One Octet) |Reserved=0 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Reserved = 0 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 2 395 The DF Type state is encoded as one octet. A value of 0 means that 396 the default (the mod based) DF election procedures are used and a 397 value of 1 means that the HRW algorithm will be employed. A request 398 needs to registered with the IETF authority for the subtype 399 [I-D.ietf-idr-extcomm-iana] 401 8. Operational Considerations 403 TBD. 405 9. Security Considerations 407 This document raises no new security issues for EVPN. 409 10. Acknowledgements 411 The authors would like to thank Tamas Mondal and Sami Boutros for 412 their feedback and useful discussions 414 11. References 416 11.1. Normative References 418 [HRW1999] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings 419 to Increase Hit Rates", IEEE/ACM Transactions in 420 networking Volume 6 Issue 1, February 1998. 422 [I-D.ietf-idr-extcomm-iana] 423 Rosen, E. and Y. Rekhter, "IANA Registries for BGP 424 Extended Communities", draft-ietf-idr-extcomm-iana-02 425 (work in progress), December 2013. 427 [I-D.ietf-l2vpn-evpn] 428 Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. 429 Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- 430 evpn-07 (work in progress), May 2014. 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 436 Protocol 4 (BGP-4)", RFC 4271, January 2006. 438 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 439 Communities Attribute", RFC 4360, February 2006. 441 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 442 (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 443 4761, January 2007. 445 [RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, 446 J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 447 VPN", RFC 7432, February 2015. 449 11.2. Informative References 451 [CHASH] Karger, D., Lehman, E., Leighton, T., Panigrahy, R., 452 Levine, M., and D. Lewin, "Consistent Hashing and Random 453 Trees: Distributed Caching Protocols for Relieving Hot 454 Spots on the World Wide Web", ACM Symposium on Theory of 455 Computing ACM Press New York, May 1997. 457 [CLRS2009] 458 Cormen, T., Leiserson, C., Rivest, R., and C. Stein, 459 "Introduction to Algorithms (3rd ed.)", MIT Press and 460 McGraw-Hill ISBN 0-262-03384-4., February 2009. 462 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 463 Multicast Next-Hop Selection", RFC 2991, November 2000. 465 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 466 Algorithm", RFC 2992, November 2000. 468 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 469 Networks (VPNs)", RFC 4364, February 2006. 471 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 472 R., Patel, K., and J. Guichard, "Constrained Route 473 Distribution for Border Gateway Protocol/MultiProtocol 474 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 475 Private Networks (VPNs)", RFC 4684, November 2006. 477 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 478 Virtual Private Networks Using BGP for Auto-Discovery and 479 Signaling", RFC 6624, May 2012. 481 Authors' Addresses 483 Satya Ranjan Mohanty 484 Cisco Systems, Inc. 485 225 West Tasman Drive 486 San Jose, CA 95134 487 USA 489 Email: satyamoh@cisco.com 491 Keyur Patel 492 Cisco Systems, Inc. 493 225 West Tasman Drive 494 San Jose, CA 95134 495 USA 497 Email: keyupate@cisco.com 499 Ali Sajassi 500 Cisco Systems, Inc. 501 225 West Tasman Drive 502 San Jose, CA 95134 503 USA 505 Email: sajassi@cisco.com 507 John Drake 508 Juniper Networks, Inc. 509 1194 N. Mathilda Drive 510 Sunnyvale, CA 95134 511 USA 513 Email: jdrake@juniper.com