idnits 2.17.00 (12 Aug 2021) /tmp/idnits59976/draft-keyupate-idr-bgp-spf-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2016) is 2143 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) == Missing Reference: 'RFC2328' is mentioned on line 428, but not defined == Missing Reference: 'RFC5286' is mentioned on line 452, but not defined == Missing Reference: 'RFC4456' is mentioned on line 432, but not defined == Missing Reference: 'RFC4915' is mentioned on line 447, but not defined == Missing Reference: 'RFC4750' is mentioned on line 442, but not defined == Missing Reference: 'RFC5549' is mentioned on line 457, but not defined ** Obsolete undefined reference: RFC 5549 (Obsoleted by RFC 8950) == Missing Reference: 'RFC4724' is mentioned on line 437, but not defined == Outdated reference: draft-ietf-idr-bgpls-segment-routing-epe has been published as RFC 9086 == Outdated reference: draft-ietf-rtgwg-bgp-routing-large-dc has been published as RFC 7938 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-bgp-routing-large-dc (ref. 'I-D.ietf-rtgwg-bgp-routing-large-dc') Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft A. Lindem 4 Intended status: Standards Track A. Roy 5 Expires: January 9, 2017 D. Yeung 6 V. Venugopal 7 Cisco Systems 8 July 8, 2016 10 Shortest Path Routing Extensions for BGP Protocol 11 draft-keyupate-idr-bgp-spf-00.txt 13 Abstract 15 Many Massively Scaled Data Centers (MSDCs) have converged on 16 simplified layer 3 routing. Furthermore, requirements for 17 operational simplicity have lead many of these MSDCs to converge on 18 BGP as their single routing protocol for both their fabric routing 19 and their Data Center Interconnect (DCI) routing. This document 20 describes a solution which leverages BGP Link-State distribution and 21 the Shortest Path First algorithm similar to Internal Gateway 22 Protocols (IGPs) such as OSPF. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 72 2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. BGP Single-Hop Peering on Network Node Connections . . . 4 74 2.2. BGP Peering Between Directly Connected Network Nodes . . 4 75 2.3. BGP Peering in Route-Reflector or Controller Topology . . 4 76 3. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Node NLRI Usage and Modifications . . . . . . . . . . . . 5 78 3.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 6 79 3.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 6 80 4. Shortest Path Routing (SPF) Capability . . . . . . . . . . . 6 81 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 6 82 5.1. Impact on BGP Tie-breaking attributes . . . . . . . . . . 7 83 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 7 84 5.3. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 7 85 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 8 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 88 7.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 9 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 91 8.2. Information References . . . . . . . . . . . . . . . . . 10 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 94 1. Introduction 96 Many Massively Scaled Data Centers (MSDCs) have converged on 97 simplified layer 3 routing. Furthermore, requirements for 98 operational simplicity have lead many of these MSDCs to converge on 99 BGP [RFC4271] as their single routing protocol for both their fabric 100 routing and their Data Center Interconnect (DCI) routing. 101 Requirements and procedures for using BGP are described in 102 [I-D.ietf-rtgwg-bgp-routing-large-dc]. This document describes an 103 alternative solution which leverages BGP-LS [RFC7752] and the 104 Shortest Path First algorithm similar to Internal Gateway Protocols 105 (IGPs) such as OSPF [RFC2328]. 107 [RFC4271] defines the Decision Process that is used to select routes 108 for subsequent advertisement by applying the policies in the local 109 Policy Information Base (PIB) to the routes stored in its Adj-RIBs- 110 In. The output of the Decision Process is the set of routes that are 111 announced by a BGP speaker to its peers. These selected routes are 112 stored by a BGP speaker in the speaker's Adj-RIBs-Out according to 113 policy. 115 [RFC7752] describes a mechanism by which link-state and TE 116 information can be collected from networks and shared with external 117 components using BGP. This is achieved by defining a NLRI carried 118 within BGP-LS AFIs and BGP-LS SAFIs. The BGP-LS extensions defined 119 in [RFC7752] makes use of the Decision Process defined in [RFC4271]. 121 This draft modifies [RFC7752] by replacing its use of the existing 122 Decision Process; in particular the Phase 1 and 2 decision functions 123 of the Decision Process are replaced with the Shortest Path Algorithm 124 (SPF) also known as the Dijkstra Algorithm. The Phase 3 decision 125 function is also simplified since it is no longer dependent on the 126 previous phases. This solution avails the benefits of both BGP and 127 SPF-based IGPs. These include TCP based flow-control, no periodic 128 link-state refresh, and completely incremental NLRI advertisement. 129 These advantages can reduce the overhead in MSDCs where there is a 130 high degree of Equal Cost Multi-Path (ECMPs) and the topology is very 131 stable. Additionally, using a SPF-based computation can support fast 132 convergence and the computation of Loop-Free Alternatives (LFAs) 133 [RFC5286] in the event of link failures. Furthermore, a BGP based 134 solution lends itself to multiple peering models including those 135 incorporating route-reflectors [RFC4456] or controllers. 137 Support for Multiple Topology Routing (MTR) as described in [RFC4915] 138 is an area for further study dependent on deployment requirements. 140 1.1. Requirements Language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 2. BGP Peering Models 148 Depending on the requirements, scaling, and capabilities of the BGP 149 speakers, various peering models are supported. The only requirement 150 is that all BGP speakers in the BGP SPF routing domain receive link- 151 state NLRI on a timely basis, run an SPF calculation, and update 152 their data plane appropriately. The content of the Link NLRI is 153 described in Section 3.2. 155 2.1. BGP Single-Hop Peering on Network Node Connections 157 The simplest peering model is the one described in section 5.2.1 of 158 [I-D.ietf-rtgwg-bgp-routing-large-dc]. In this model, EBGP single- 159 hop sessions are established over direct point-to-point links 160 interconnecting the network nodes. For the purposes of BGP SPF, Link 161 NLRI is only advertised if a single-hop BGP session has been 162 established, the Link-State address family capability has been 163 exchanged, and the SPF capability has been exchanged on the 164 corresponding session. If the session goes down, the NLRI will be 165 withdrawn. 167 2.2. BGP Peering Between Directly Connected Network Nodes 169 In this model, BGP speakers peer with all directly connected network 170 nodes but the sessions may be multi-hop and the direct connection 171 discovery and liveliness detection for those connections are 172 independent of the BGP protocol. How this is accomplished is outside 173 the scope of this document. Consequently, there will be a single 174 session even if there are multiple direct connections between BGP 175 speakers. For the purposes of BGP SPF, Link NLRI is advertised as 176 long as a BGP session has been established, the Link-State address 177 family capability has been exchanged, the SPF capability has been 178 exchanged, and the corresponding link is up and considered 179 operational. 181 2.3. BGP Peering in Route-Reflector or Controller Topology 183 In this model, BGP speakers peer solely with one or more Route 184 Reflectors [RFC4456] or controllers. As in the previous model, 185 direct connection discovery and liveliness detection for those 186 connections are done outside the BGP protocol. For the purposes of 187 BGP SPF, Link NLRI is advertised as long as the corresponding link is 188 up and considered operational. 190 3. Extensions to BGP-LS 192 [RFC7752] describes a mechanism by which link-state and TE 193 information can be collected from networks and shared with external 194 components using BGP protocol. It contains two parts: definition of 195 a new BGP NLRI that describes links, nodes, and prefixes comprising 196 IGP link-state information and definition of a new BGP path attribute 197 (BGP-LS attribute) that carries link, node, and prefix properties and 198 attributes, such as the link and prefix metric or auxiliary Router- 199 IDs of nodes, etc. 201 The BGP protocol will be used in the Protocol-ID field specified in 202 table 1 of [I-D.ietf-idr-bgpls-segment-routing-epe]. The local and 203 remote node descriptors for all NLRI will be the BGP Router-ID (TLV 204 516) and either the AS Number (TLV 512) [RFC7752] or the BGP 205 Confederation Member (TLV 517) 206 [I-D.ietf-idr-bgpls-segment-routing-epe]. However, if the BGP 207 Router-ID is known to be unique within the BGP Routing domain, it can 208 be used as the sole descriptor. 210 3.1. Node NLRI Usage and Modifications 212 The SPF capability is a new Node Attribute TLV that will be added to 213 those defined in table 7 of [RFC7752]. The new attribute TLV will 214 only be applicable when BGP is specified in the Node NLRI Protocol ID 215 field. The TBD TLV type will be defined by IANA. The new Node 216 Attribute TLV will contain a single octet SPF algorithm field: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Type | Length | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | SPF Algorithm | 224 +-+-+-+-+-+-+-+-+ 226 The SPF Algorithm may take the following values: 228 1 - Normal SPF 229 2 - Strict SPF 231 When computing the SPF for a given BGP routing domain, only BGP nodes 232 advertising the SPF capability attribute will be included the 233 Shortest Path Tree (SPT). 235 3.2. Link NLRI Usage 237 The criteria for advertisement of Link NLRI are discussed in 238 Section 2. 240 Link NLRI is advertised with local and remote node descriptors as 241 described above and unique link identifiers dependent on the 242 addressing. For IPv4 links, the links local IPv4 (TLV 259) and 243 remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the 244 local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be 245 used. For unnumbered links, the link local/remote identifiers (TLV 246 258) will be used. For links supporting having both IPv4 and IPv6 247 addresses, both sets of descriptors may be included in the same Link 248 NLRI. The link identifiers are described in table 5 of [RFC7752]. 250 The link IGP metric attribute TLV (TLV 1095) as well as any others 251 required for non-SPF purposes SHOULD be advertised. Algorithms such 252 as setting the metric inversely to the link speed as done in the OSPF 253 MIB [RFC4750] may be supported. However, this is beyond the scope of 254 this document. 256 3.3. Prefix NLRI Usage 258 Prefix NLRI is advertised with a local descriptor as described above 259 and the prefix and length used as the descriptors (TLV 265) as 260 described in [RFC7752]. The prefix metric attribute TLV (TLV 1155) 261 as well as any others required for non-SPF purposes SHOULD be 262 advertised. For loopback prefixes, the metric should be 0. For non- 263 loopback, the setting of the metric is beyond the scope of this 264 document. 266 4. Shortest Path Routing (SPF) Capability 268 In order to replace the Phase 1 and 2 decision functions of the 269 existing Decision Process with an SPF-based Decision Process, this 270 draft introduces a new capability to signal the support of an SPF 271 Decision Process. The SPF Capability is a new BGP Capability 272 [RFC5492]. The Capability Code for this capability is allocated by 273 IANA as specified in the Section 6. The Capability Length field of 274 this capability has a value of 0. 276 5. Decision Process with SPF Algorithm 278 The Decision Process described in [RFC4271] takes place in three 279 distinct phases. The Phase 1 decision function of the Decision 280 Process is responsible for calculating the degree of preference for 281 each route received from a Speaker's peer. The Phase 2 decision 282 function is invoked on completion of the Phase 1 decision function 283 and is responsible for choosing the best route out of all those 284 available for each distinct destination, and for installing each 285 chosen route into the Loc-RIB. The combination of the Phase 1 and 2 286 decision functions is also known as a Path vector algorithm. 288 The SPF based Decision process starts with selecting only those Node 289 NLRI whose SPF capability TLV matches with the local BGP speaker's 290 SPF capability TLV value. These selected Node NLRI and their Link/ 291 Prefix NLRI are use to build a directed graph during the SPF 292 computation. The best paths for BGP prefixes are installed as a 293 result of the SPF process. The Phase 3 decision function of the 294 Decision Process [RFC4271] is also simplified since it is no longer 295 based on the output of the previous phases. Since Link-State NLRI 296 always contains the local descriptor [RFC7752], it will only be 297 originated by a single BGP speaker in the BGP routing domain. Hence, 298 for each valid NLRI, the Phase 3 decision function will simply need 299 to advertise a valid NLRI instance dependent on policy. 301 5.1. Impact on BGP Tie-breaking attributes 303 The modified Decision Process with SPF algorithm uses the metric from 304 Link and Prefix NLRI Attribute TLVs [RFC7752]. As a result, any 305 attributes that would influence the Decision process defined in 306 [RFC4271] like ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are 307 ignored by the SPF algorithm. Furthermore, the NEXT_HOP attribute 308 value is preserved and validated but otherwise ignored in any 309 received BGP Update messages. 311 5.2. Dual Stack Support 313 The SPF based decision process operates on Node, Link, and Prefix 314 NLRIs that support both IPv4 and IPv6 addresses. Whether to run a 315 single SPF instance or multiple SPF instances for separate AFs is a 316 matter of a local implementation. Normally, IPv4 next-hops are 317 calculated for IPv4 prefixes and IPv6 next-hops are calculated for 318 IPv6 prefixes. However, an interesting use-case is deployment of 319 [RFC5549] where IPv6 link-local next-hops are calculated for both 320 IPv4 and IPv6 prefixes. As stated in Section 1, support for Multiple 321 Topology Routing (MTR) is an area for future study. 323 5.3. NEXT_HOP Manipulation 325 A BGP speaker that supports SPF extensions MAY interact with peers 326 that don't support SPF extensions. If the BGP Link-State address 327 family is advertised to a peer not supporting the SPF extensions 328 described herein, then the BGP speaker MUST conform to the NEXT_HOP 329 rules mentioned in [RFC4271] when announcing the Link-State address 330 family routes to those peers. 332 All BGP peers that support SPF extensions would locally compute the 333 NEXT_HOP values as result of the SPF process. As a result, the 334 NEXT_HOP attribute is always ignored on receipt. However BGP 335 speakers should set the NEXT_HOP address according to the NEXT_HOP 336 attribute rules mentioned in [RFC4271]. 338 5.4. Error Handling 340 When a BGP speaker receives a BGP Update containing a malformed SPF 341 Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it MUST 342 ignore the received TLV and the Node NLRI and not pass it to other 343 BGP peers as specified in [RFC7606]. When discarding a Node NLRI 344 with malformed TLV, a BGP speaker SHOULD log an error for further 345 analysis. 347 6. IANA Considerations 349 This document defines a new capability for BGP known as a SPF 350 Capability. We request IANA to assign a BGP capability number from 351 BGP Capability Codes Registry. 353 This document also defines a new attribute TLV for BGP LS Node NLRI. 354 We request IANA to assign a new TLV for the SPF capability from the 355 "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and 356 Attribute TLVs" Registry. Additionally, IANA is requested to create 357 a new registry for "BGP-LS SPF Capability Algorithms" for the value 358 of the algorithm both in the BGP-LS Node Attribute TLV and the BGP 359 SPF Capability. The initial assignments are: 361 +-------------+-----------------------------------+ 362 | Value(s) | Assignment Policy | 363 +-------------+-----------------------------------+ 364 | 0 | Reserved (not to be assigned) | 365 | | | 366 | 1 | SPF | 367 | | | 368 | 2 | Strict SPF | 369 | | | 370 | 3-254 | Unassigned (IETF Review) | 371 | | | 372 | 255 | Reserved (not to be assigned) | 373 +-------------+-----------------------------------+ 375 BGP-LS SPF Capability Algorithms 377 7. Security Considerations 379 This extension to BGP does not change the underlying security issues 380 inherent in the existing [RFC4724] and [RFC4271]. 382 7.1. Acknowledgements 384 The authors would like to thank .... for the review and comments. 386 8. References 388 8.1. Normative References 390 [I-D.ietf-idr-bgpls-segment-routing-epe] 391 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 392 and M. Chen, "Segment Routing BGP Egress Peer Engineering 393 BGP-LS Extensions", draft-ietf-idr-bgpls-segment-routing- 394 epe-05 (work in progress), May 2016. 396 [I-D.ietf-rtgwg-bgp-routing-large-dc] 397 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 398 routing in large-scale data centers", draft-ietf-rtgwg- 399 bgp-routing-large-dc-11 (work in progress), June 2016. 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 407 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 408 DOI 10.17487/RFC4271, January 2006, 409 . 411 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 412 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 413 2009, . 415 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 416 Patel, "Revised Error Handling for BGP UPDATE Messages", 417 RFC 7606, DOI 10.17487/RFC7606, August 2015, 418 . 420 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 421 S. Ray, "North-Bound Distribution of Link-State and 422 Traffic Engineering (TE) Information Using BGP", RFC 7752, 423 DOI 10.17487/RFC7752, March 2016, 424 . 426 8.2. Information References 428 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 429 DOI 10.17487/RFC2328, April 1998, 430 . 432 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 433 Reflection: An Alternative to Full Mesh Internal BGP 434 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 435 . 437 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 438 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 439 DOI 10.17487/RFC4724, January 2007, 440 . 442 [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., 443 Coltun, R., and F. Baker, "OSPF Version 2 Management 444 Information Base", RFC 4750, DOI 10.17487/RFC4750, 445 December 2006, . 447 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 448 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 449 RFC 4915, DOI 10.17487/RFC4915, June 2007, 450 . 452 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 453 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 454 DOI 10.17487/RFC5286, September 2008, 455 . 457 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 458 Layer Reachability Information with an IPv6 Next Hop", 459 RFC 5549, DOI 10.17487/RFC5549, May 2009, 460 . 462 Authors' Addresses 464 Keyur Patel 465 Cisco Systems 466 170 W. Tasman Drive 467 San Jose, CA 95134 468 USA 470 Email: keyupate@cisco.com 471 Acee Lindem 472 Cisco Systems 473 170 W. Tasman Drive 474 San Jose, CA 95134 475 USA 477 Email: acee@cisco.com 479 Abhay Roy 480 Cisco Systems 481 170 W. Tasman Drive 482 San Jose, CA 95134 483 USA 485 Email: akr@cisco.com 487 Derek Yeung 488 Cisco Systems 489 170 W. Tasman Drive 490 San Jose, CA 95134 491 USA 493 Email: myeung@cisco.com 495 Venu Venugopal 496 Cisco Systems 497 170 W. Tasman Drive 498 San Jose, CA 95134 499 USA 501 Email: venuv@cisco.com