idnits 2.17.1 draft-ietf-l3vpn-rt-constrain-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 84. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 97. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 4 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 202: '... versa. It SHOULD however prune less...' RFC 2119 keyword, line 338: '... A BGP speaker MAY participate in th...' RFC 2119 keyword, line 361: '... implementations SHOULD generate an En...' RFC 2119 keyword, line 413: '.... Implementations SHOULD also provide...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 7163 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: 'BGP-CAP' is defined on line 435, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-20 ** Obsolete normative reference: RFC 2796 (ref. 'BGP-RR') (Obsoleted by RFC 4456) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) == Outdated reference: A later version (-13) exists of draft-ietf-idr-restart-10 -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-09 == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-05 == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-02 == Outdated reference: A later version (-02) exists of draft-kompella-ppvpn-vpls-01 Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Pedro Marques (Ed.) 2 Internet Draft Juniper Networks 3 Expiration Date: March 2005 4 Robert Raszuk 5 Luyuan Fang Luca Martini 6 AT&T Keyur Patel 7 Jim Guichard 8 Ronald Bonica Cisco Systems Inc. 9 MCI 11 September 2004 13 Constrained VPN route distribution 15 draft-ietf-l3vpn-rt-constrain-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, we certify that any applicable 20 patent or other IPR claims of which we are aware have been disclosed, 21 or will be disclosed, and any of which we become aware will be 22 disclosed, in accordance with RFC 3668. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that other 29 groups may also distribute working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document defines MP-BGP procedures that allow BGP speakers to 45 exchange Route Target reachability information. This information can 46 be used to build a route distribution graph in order to limit the 47 propagation of VPN NLRI (such as VPN-IPv4, VPN-IPv6 or L2-VPN NLRI) 48 between different autonomous systems or distinct clusters of the same 49 autonomous system. 51 Table of Contents 53 1 Specification of Requirements ............................. 2 54 2 Intellectual Property Statement ........................... 3 55 3 Introduction .............................................. 3 56 4 NLRI DIstribution ......................................... 4 57 4.1 Inter-AS VPN route distribution. .......................... 4 58 4.2 Intra-AS VPN route distribution ........................... 6 59 5 Route Target membership NLRI advertisements ............... 7 60 6 Capability Advertisement .................................. 8 61 7 Operation ................................................. 8 62 8 Deployment considerations ................................. 9 63 9 Security considerations ................................... 10 64 10 Acknowledgments ........................................... 10 65 11 Normative References ...................................... 10 66 12 Informative References .................................... 11 67 13 Author Information ........................................ 11 69 1. Specification of Requirements 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 75 2. Intellectual Property Statement 77 The IETF takes no position regarding the validity or scope of any 78 Intellectual Property Rights or other rights that might be claimed to 79 pertain to the implementation or use of the technology described in 80 this document or the extent to which any license under such rights 81 might or might not be available; nor does it represent that it has 82 made any independent effort to identify any such rights. Information 83 on the procedures with respect to rights in RFC documents can be 84 found in BCP 78 and BCP 79. 86 Copies of IPR disclosures made to the IETF Secretariat and any assur- 87 ances of licenses to be made available, or the result of an attempt 88 made to obtain a general license or permission for the use of such 89 proprietary rights by implementers or users of this specification can 90 be obtained from the IETF on-line IPR repository at 91 http://www.ietf.org/ipr. 93 The IETF invites any interested party to bring to its attention any 94 copyrights, patents or patent applications, or other proprietary 95 rights that may cover technology that may be required to implement 96 this standard. Please address the information to the IETF at ietf- 97 ipr@ietf.org. 99 3. Introduction 101 In BGP/MPLS IP VPNs, PE routers use Route Target (RT) extended commu- 102 nities to control the distribution of routes into VRFs. Within a 103 given iBGP mesh, PE routers need only to hold routes marked with 104 Route Targets pertaining to VRFs that have local CE attachments. 106 It is common, however, for an autonomous system use route reflection 107 [BGP-RR] in order to simplify the process of bringing up a new PE 108 router in the network and to limit the size of the iBGP peering mesh. 110 In such a scenario, as well as when VPNs may have members in more 111 than one autonomous system, the number of routes carried by the 112 inter-cluster or inter-as distribution routers is an important con- 113 sideration. 115 In order to limit the VPN routing information that is maintained at a 116 given RR, RFC2547bis [RFC2547bis] suggests, in section 4.3.3., the 117 usage of "Cooperative Route Filtering" [ORF] between route reflec- 118 tors. This proposal extends [RFC2547bis] ORF work to include support 119 for multiple autonomous systems, and asymetric VPN topologies such as 120 hub-and-spoke. While it 121 would be possible to extend the encoding currently defined for 122 extended-community ORF in order to achieve this purpose, BGP itself 123 already has all the necessary machinery for dissemination of arbi- 124 trary information in a loop free fashion, both within a single 125 autonomous system, as well as across multiple autonomous systems. 127 This document builds on the model described in [RFC2547bis] and on 128 concept of cooperative route filtering by adding the ability to prop- 129 agate Route Target membership information between iBGP meshes. 131 By using MP-BGP UPDATE messages to propagate Route Target membership 132 information it is possible to reuse all this machinery including 133 route reflection, confederations and inter-as information loop detec- 134 tion. 136 Received Route Target membership information can then be used to 137 restrict advertisement of VPN NLRI to peers that have advertised 138 their respective Route Targets, effectively building a route distri- 139 bution graph. In this model, VPN NLRI routing information flows in 140 the inverse direction of Route Target membership information. 142 This mechanism is applicable to any BGP NLRI that controls the dis- 143 tribution of routing information based on Route Targets, such as BGP 144 L2VPNs [L2VPN] and VPLS [VPLS]. 146 Throughout this document, the term NLRI, which originally expands to 147 "Network Layer Reachability Information" is used to describe routing 148 information carried via MP-BGP updates without any assumption of 149 semantics. 151 An NLRI consisting of will be referred to as RT 152 membership information for the purpose of the explanation in this 153 document. 155 4. NLRI DIstribution 157 4.1. Inter-AS VPN route distribution. 159 In order to better understand the problem at hand, it is helpful to 160 divide it in its inter-AS and intra-AS components. Figure 1 repre- 161 sents an arbitrary graph of autonomous systems (a through j) inter- 162 connected in an ad-hoc fashion. The following discussion ignores the 163 complexity of intra-AS route distribution. 165 +----------------------------------+ 166 | +---+ +---+ +---+ | 167 | | a | -- | b | -- | c | | 168 | +---+ +---+ +---+ | 169 | | | | 170 | | | | 171 | +---+ +---+ +---+ +---+ | 172 | | d | -- | e | -- | f | -- | j | | 173 | +---+ +---+ +---+ +---+ | 174 | / | | 175 | / | | 176 | +---+ +---+ +---+ | 177 | | g | -- | h | -- | i | | 178 | +---+ +---+ +---+ | 179 +----------------------------------+ 180 Figure 1. Topology of autonomous systems. 182 Lets consider the simple case of a VPN with CE attachments in ASes a 183 and i using a single Route Target to control VPN route distribution. 184 Ideally we would like to build a flooding graph for the respective 185 VPN routes that would not include nodes (c, g, h, j). 187 In order to achieve this we will rely on ASa and ASi generating a 188 NLRI consisting of ( RT membership information ). 189 Receipt of such an advertisement by one of the ASes in the network 190 will signal the need to distribute VPN routes containing this Route 191 Target community to the peer that advertised this route. 193 Using RT membership information that includes both route-target and 194 originator AS number, allows BGP speakers to use standard path selec- 195 tion rules concerning as-path length (and other policy mechanisms) to 196 prune duplicate paths in the RT membership information flooding 197 graph, while maintaining the information required to reach all 198 autonomous systems advertising the Route Target. 200 In the example above, AS e needs to maintain a path to AS a in order 201 to flood VPN routing information originating from AS i and vice- 202 versa. It SHOULD however prune less preferred paths such as the 203 longer path to ASi with as-path (g h i). 205 Extending the example above to include AS j as a member of the VPN 206 distribution graph would cause AS f to advertise 2 RT Membership NLRI 207 to AS e, one containing origin AS i and one containing origin AS j. 208 While advertising a single path, lets assume (f j) is selected, would 209 be sufficient to guarantee that VPN information flows to all VPN mem- 210 ber ASes, the information concerning the path (f i) is necessary to 211 prune the arc (e g h i) from the route distribution graph. 213 As with other approaches for building distribution graphs, the bene- 214 fits of this mechanism are directly proportional to how "sparse" the 215 VPN membership is. Standard RFC2547 inter-AS behavior can be seen as 216 a dense-mode approach, to make the analogy with multicast routing 217 protocols. 219 4.2. Intra-AS VPN route distribution 221 As indicated above, the inter-AS VPN route distribution graph, for a 222 given route-target, is constructed by creating a directed arc on the 223 inverse direction of received Route Target membership UPDATEs con- 224 taining an NLRI of the form . 226 Inside the BGP topology of a given autonomous-system, as far as 227 external RT membership information is concerned (route-targets where 228 the as# is not the local as), it is easy to see that standard BGP 229 route selection and advertisement rules [BGP-BASE] will allow a tran- 230 sit AS to create the necessary flooding state. 232 Consider a IPv4 NLRI prefix, sourced by a single AS, which dis- 233 tributed via BGP within a given transit AS. BGP protocol rules guar- 234 antee that a BGP speaker has a valid route that can be used for for- 235 warding of data packets for that destination prefix, in the inverse 236 path of received routing updates. 238 By the same token, and given that a key provides 239 uniqueness between several ASes that may be sourcing this route-tar- 240 get, BGP route selection and advertisement procedures guarantee that 241 a valid VPN route distribution path exists to the origin of the Route 242 Target membership information advertisement. 244 Route Target membership information that are originated within the 245 autonomous-system however require more careful examination. Several 246 PE routers within a given autonomous-system may source the the same 247 NLRI , thus default route advertisement rules are 248 no longer sufficient to guarantee that within the given AS each node 249 in the distribution graph has selected a feasible path to each of the 250 PEs that import the given route-target. 252 When processing RT membership NLRIs received from internal iBGP 253 peers, it is necessary to consider all availiable iBGP paths for a 254 given RT prefix, when building the outbound route filter, and not 255 just the best path. 257 In addition, when advertising Route Target membership information 258 sourced by the local autonomous system to an iBGP peer, a BGP speaker 259 shall modify its procedure to calculate the BGP attributes such that: 261 -i. When advertising RT membership NLRI to a route-reflector 262 client, the Originator attribute shall be set to the router- 263 id of the advertiser and the Next-hop attribute shall be set 264 of the local address for that session. 266 -ii. When advertising a RT membership NLRI to a non client peer, 267 if the best path as selected by path selection procedure 268 described in section 9.1 of [BGP-BASE], is a route received 269 from a non-client peer, and there is an alternative path to 270 the same destination from a client, the attributes of the 271 client path are advertised to the peer. 273 The first of these route advertisement rules is designed such that 274 the originator of RT membership NLRI does not drop a RT membership 275 NLRI which is reflected back to it, thus allowing the route reflector 276 to use this RT membership NLRI in order to signal the client that it 277 should distribute VPN routes with the specific target torwards the 278 reflector. 280 The second rule makes is such that any BGP speaker present in an iBGP 281 mesh can signal the interest of its route reflection clients in 282 receiving VPN routes for that target. 284 These procedures assume that the autonomous-system route reflection 285 topology is configured such that IPv4 unicast routing would work cor- 286 rectly. For instance, route reflection clusters must be contiguous 288 An alternative solution to the procedure given above would have been 289 to source different routes per PE, such as NLRI of the form , and aggregate them at the edge of the network. 291 The solution adopted is considered to be advantageous over the former 292 given that it requires less routing-information within a given AS. 294 5. Route Target membership NLRI advertisements 296 Route Target membership NLRI is advertised in BGP UPDATE messages 297 using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [BGP-MP]. The 298 value pair used to identify this NLRI is (AFI=1, 299 SAFI=132). 301 The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as 302 an IPv4 address, whenever the lenght of NextHop address is 4 octects, 303 and as a IPv6 address, whenever the lenght of the NextHop address is 304 16 octets. 306 The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix 307 of 0 to 96 bits encoded as defined in section 4 of [BGP-MP]. 309 This prefix is structured as follows: 311 +-------------------------------+ 312 | origin as (4 octects) | 313 +-------------------------------+ 314 | route target (8 octects) | 315 + + 316 | | 317 +-------------------------------+ 319 Except for the default route target, which is encoded as a 0 length 320 prefix, the minimum prefix length is 32 bits. As the origin-as field 321 cannot be interpreted as a prefix. 323 Route targets can then be expressed as prefixes, where for instance, 324 a prefix would encompass all route target extended communities 325 assigned by a given Global Administrator [BGP-EXTCOMM]. 327 The default route target can be used to indicate to a peer the will- 328 ingness to receive all VPN route advertisements such as, for 329 instance, the case of route reflector speaking to one of its PE 330 router clients. 332 6. Capability Advertisement 334 A BGP speaker that wishes to exchange Route Target membership infor- 335 mation must use the the Multiprotocol Extensions Capability Code as 336 defined in [BGP-MP], to advertise the corresponding (AFI, SAFI) pair. 338 A BGP speaker MAY participate in the distribution of Route Target 339 information while not using the learned information for purposes of 340 VPN NLRI output route filtering, although the latter is discouraged. 342 7. Operation 344 A VPN NLRI route should be advertised to a peer that participates in 345 the exchange of Route Target membership information if that peer has 346 advertised either the default Route Target membership NLRI or a Route 347 Target membership NLRI containing any of the targets contained in the 348 extended communities attribute of the VPN route in question. 350 When a BGP speaker receives a BGP UPDATE that advertises or withdraws 351 a given Route Target membership NLRI, it should examine the RIB-OUTs 352 of VPN NLRIs and reevaluate the advertisement status of routes that 353 match the Route Target in question. 355 A BGP speaker should generate the minimum set of BGP VPN route 356 updates necessary to transition between the previous and current 357 state of the route distribution graph that is derived from Route Tar- 358 get membership information. 360 In order to avoid VPN route churn when a BGP session is established, 361 implementations SHOULD generate an End-of-RIB marker, as defined in 362 [BGP-GR], for the Route Target membership (afi, safi). Regardless of 363 whether graceful-restart is enabled on the BGP session. This allows 364 the receiver to know when it has received the full contents of the 365 peers membership information. The exchange of VPN NLRI should follow 366 the receipt of the End-of-RIB markers. 368 8. Deployment considerations 370 This mecanism reduces the scaling requirements that are imposed on 371 route reflectors by limiting the number of VPN routes and events that 372 a reflector has to process to the VPN routes used by its direct 373 clients. By default, a reflector must scale in terms of the total 374 number of VPN routes present on the network. 376 This also means that its is now possible to reduce the load impossed 377 on a given reflector by dividing the PE routers present on its clus- 378 ter into a new set of clusters. This is a localized configuration 379 change that need not affect any system outside this cluster. 381 The effectiveness of RT-based filtering depends on how sparse the VPN 382 membership is. 384 For instance, in the inter-as case, it is likely that a given VPN is 385 connected to only a subset of all participating ASes. The only cur- 386 rent mechanism to limit the scope of VPN route flooding is through 387 manual filtering on the EBGP border routers. With the current pro- 388 posal such filtering can be performed based on the dynamic Route Tar- 389 get membership information. 391 In some inter-as deployments not all RTs used for a given VPN have 392 external significance. For example, a VPN can use an hub RT and a 393 spoke RT internally to an autonomous-system. The spoke RT does not 394 have meaning outside this AS and so it may be stripped at an external 395 border router. The same policy rules that result in extended commu- 396 nity filtering can be applied to RT membership information in order 397 to avoid advertising an RT membership NLRI for the spoke-RT in the 398 example above. 400 Throughout this document, we assume that autonomous-systems agree on 401 an RT assignment convention. RT translation at the external border 402 router boundary, is considered to be a local implementation decision, 403 as it should not affect inter-operability. 405 9. Security considerations 407 This document does not alter the security properties of BGP-based 408 VPNs. However it should be taken into consideration that output 409 route filters built from RT membership information NLRI are not 410 intended for security purposes. When exchanging routing information 411 between separate administrative domains, it is a good practice to 412 filter all incoming and outgoing NLRIs by some other mean in addition 413 to RT membership information. Implementations SHOULD also provide 414 means to filter RT membership information. 416 10. Acknowledgments 418 This proposal is based on the extended community route filtering 419 mechanism defined in [ORF]. 421 Ahmed Guetari was instrumental in defining requirements for this pro- 422 posal. 424 The authors would also like to thank Yakov Rekhter, Dan Tappan, Dave 425 Ward, John Scudder, and Jerry Ash for their comments and suggestions. 427 11. Normative References 429 [BGP-BASE] Y. Rekhter, T. Li, S. Hares, "A Border Gateway Protocol 4 430 (BGP-4)", draft-ietf-idr-bgp4-20.txt, 03/03 432 [BGP-RR] Bates, Chandra, and Chen, "BGP Route Reflection: An 433 alternative to full mesh IBGP", RFC 2796. 435 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with BGP-4", 436 RFC2842. 438 [BGP-MP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 439 Extensions for BGP-4", RFC2858. 441 [BGP-GR] S. Sangli, Y. Rekhter, R. Fernando, J. Scudder, E. Chen, 442 "Graceful Restart Mechanism for BGP", draft-ietf-idr-restart-10.txt, 06/04. 444 12. Informative References 446 [RFC2547bis] "BGP/MPLS VPNs", Rosen et. al., 447 draft-ietf-ppvpn-rfc2547bis-03.txt, 10/02. 449 [ORF] E. Chen, Y. Rekhter, "Cooperative Route Filtering Capability for 450 BGP-4", draft-ietf-idr-route-filter-09.txt, 08/03. 452 [BGP-EXTCOMM] S. Sangli, D. Tappan, Y. Rekhter, "BGP Extended Communities 453 Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, 05/02. 455 [L2VPN] K. Kompella et al., "Layer 2 VPNs Over Tunnels", 456 draft-kompella-ppvpn-l2vpn-02.txt, 11/01. 458 [VPLS] K Kompella (Ed.), "Virtual Private LAN Service", 459 draft-kompella-ppvpn-vpls-01.txt, 11/02 461 13. Author Information 463 Ronald P. Bonica 464 MCI 465 22001 Loudoun County Pkwy 466 Ashburn, Virginia, 20147 467 Phone: 703 886 1681 468 Email: ronald.p.bonica@mci.com 470 Luyuan Fang 471 AT&T 472 200 Laurel Avenue, Room C2-3B35 473 Middletown, NJ 07748 474 Phone: 732-420-1921 475 Email: luyuanfang@att.com 477 Luca Martini 478 Cisco Systems, Inc. 479 9155 East Nichols Avenue, Suite 400 480 Englewood, CO, 80112 481 e-mail: lmartini@cisco.com 482 Pedro Marques 483 Juniper Networks 484 1194 N. Mathilda Ave. 485 Sunnyvale, CA 94089 486 Email: roque@juniper.net 488 Robert Raszuk 489 Cisco Systems, Inc. 490 170 West Tasman Dr 491 San Jose, CA 95134 492 Email: rraszuk@cisco.com 494 Keyur Patel 495 Cisco Systems, Inc. 496 170 West Tasman Dr 497 San Jose, CA 95134 498 Email: keyupate@cisco.com 500 Jim Guichard 501 Cisco Systems, Inc. 502 300 Beaver Brook Road 503 Boxborough, MA, 01719 504 Email: jguichar@cisco.com