idnits 2.17.1 draft-ietf-l3vpn-ibgp-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character 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 (June 24, 2011) is 4662 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) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) == Outdated reference: A later version (-04) exists of draft-ietf-idr-optional-transitive-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Marques 3 Internet-Draft 4 Intended status: Standards Track R. Raszuk 5 Expires: December 26, 2011 K. Patel 6 Cisco Systems 7 K. Kumaki 8 T. Yamagata 9 KDDI Corporation 10 June 24, 2011 12 Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual 13 Private Networks (VPNs) 14 draft-ietf-l3vpn-ibgp-08 16 Abstract 18 This document defines protocol extensions and procedures for BGP 19 Provider/Customer edge router iteration in BGP/MPLS IP VPN networks. 20 These have the objective of making the usage of the BGP/MPLS IP VPN 21 transparent to the customer network, as far as routing information is 22 concerned. 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 December 26, 2011. 41 Copyright Notice 43 Copyright (c) 2011 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 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 60 3. IP VPN network as a Route Server . . . . . . . . . . . . . . . 5 61 4. Path attributes . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. BGP customer route attributes . . . . . . . . . . . . . . . . 8 63 6. Next-hop handling . . . . . . . . . . . . . . . . . . . . . . 10 64 7. Exchanging routes between different VPN customer networks . . 11 65 8. Deployment considerations . . . . . . . . . . . . . . . . . . 13 66 9. Security considerations . . . . . . . . . . . . . . . . . . . 15 67 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 68 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 71 12.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 74 1. Introduction 76 In current deployments, when BGP is used as the Provider/Customer 77 Edge routing protocol, these peering sessions are typically 78 configured as an external peering between the VPN provider 79 autonomous-system (AS) and the customer network autonomous-system. 80 At each External BGP boundary, BGP Path Attributes [RFC4271] are 81 modified as per standard BGP rules. This includes prepending the 82 AS_PATH attribute with the autonomous-system number of the 83 originating customer edge (CE) router and the autonomous-system 84 number(s) of the provider edge (PE) router(s). 86 In order for such routes not to be rejected by AS_PATH loop 87 detection, a PE router advertising a route received from a remote PE, 88 often remaps the customer network autonomous-system number to its 89 own. Otherwise the customer network can use different autonomous- 90 system numbers at different sites or configure their CE routers to 91 accept routes containing their own AS number. 93 While this technique works well in situations where there are no BGP 94 routing exchanges between the client network and other networks, it 95 does have drawbacks for customer networks that use BGP internally for 96 purposes other than interaction between CE and PE routers. 98 In order to make the usage of BGP/MPLS VPN services as transparent as 99 possible to any external interaction, it is desirable to define a 100 mechanism by which PE-CE routers can exchange BGP routes by means 101 other than external BGP. 103 One can consider a BGP/MPLS VPN as a provider-managed backbone 104 service interconnecting several customer-managed sites. While this 105 model is not universal it does constitute a good starting point. 107 Independently of the presence of VPN service, networks often use an 108 hierarchical design utilizing either BGP route reflection [RFC4456] 109 or confederations [RFC5065]. This document assumes that the IP VPN 110 service interacts with the customer network following a similar 111 model. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 3. IP VPN network as a Route Server 121 In a typical backbone/area hierarchical design, routers that attach 122 an area (or site) to the core, use BGP route reflection (or 123 confederations) to distribute routes between the top-level core iBGP 124 mesh and the local area iBGP cluster. 126 To provide equivalent functionality in a network using a provider 127 provisioned backbone, one can consider the VPN as the equivalent of 128 an Internal BGP Route Server which multiplexes information from _N_ 129 VPN attachment points. 131 A route learned by any of the PEs in the IP VPN network, is available 132 to all other PEs that import the Route Target used to identify the 133 customer network. This is conceptually equivalent to a centralized 134 route server. 136 In a PE router, PE received routes are not advertised back to other 137 PEs. It is this split horizon technique that prevents routing loops 138 in an IP VPN environment. This is also consistent with the behavior 139 of a top level mesh of RRs. 141 In order to complete the Route Server model, is necessary to be able 142 to transparently carry the Internal BGP PATH attributes of customer 143 network routes through the BGP/MPLS VPN core. This is achieved by 144 using a new BGP path attribute described below that allows the 145 customer network attributes to be saved and restored at the BGP/MPLS 146 VPN boundaries. 148 When a route is advertised from PE to CE, if it is advertised as an 149 iBGP route, the CE will not advertise it further unless it is itself 150 configured as a Route Reflector (or has an external BGP session). 151 This is a consequence of the default BGP behavior of not advertising 152 iBGP routes back to iBGP peers. This behavior is not modified. 154 On a BGP/MPLS VPN PE, a CE-received route MUST be advertised to other 155 VPN PEs that import the Route Targets which are associated with the 156 route. This is independent of whether the CE route has been received 157 as an external or internal route. However, a CE received route is 158 not readvertised back to other CEs unless Route Reflection (RR) is 159 explicitly configured. This is the equivalent of disabling client to 160 client reflection in BGP RR implementations. 162 When reflection is configured on the PE router, with local CE routers 163 as clients, there is no need to internally mesh multiple CEs that may 164 exist in the site. 166 This Route Server model can also be used to support a confederation 167 style abstraction to CE devices. We choose not to describe in detail 168 the procedures for that mode of operation, at this point. 169 Confederations are considered to be less common than route reflection 170 in enterprise environments. 172 4. Path attributes 174 --> push path attributes --> vrf-export --> BGP/MPLS IP VPN 175 VRF route PE-PE route 176 advertisement 177 <-- pop path attributes <-- vrf-import <-- 179 The diagram above shows the BGP path attribute stack processing in 180 relation to existing BGP/MPLS IP VPN [RFC4364] route processing 181 procedures. BGP path attributes received from a customer network are 182 pushed into the stack, before adding the Export Route Targets to the 183 BGP path attributes. Conversely, the stack is popped after the 184 Import Target processing step that identifies the VPN Routing and 185 Forwarding (VRF) table in which a PE received route is accepted. 187 When the advertising PE performs a "push" operation at the "vrf- 188 export" processing stage it SHOULD initialize the attributes of the 189 BGP IP VPN route advertisement as if for a locally originated route 190 from the respective VRF context. 192 When a PE received route is imported into a VRF, its IGP metric, as 193 far as BGP path selection is concerned, SHOULD be the metric to the 194 remote PE address, expressed in terms of the service provider metric 195 domain. 197 For the purposes of VRF route selection performed at the PE, between 198 routes received from local CEs and remote PEs, customer network IGP 199 metrics SHOULD always be considered higher (thus least preferred) 200 than local site metrics. 202 When backdoor links are present, this would tend to direct the 203 traffic between two sites through the backdoor link for BGP routes 204 originated by a remote site. However BGP already has policy 205 mechanisms to address this type of situations such as the LOCAL_PREF 206 attribute. 208 When a given CE is connected to more than one PE, it will not 209 advertise the route that it receives from a PE to another PE unless 210 configured as a route reflector, due to the standard BGP route 211 advertisement rules. 213 When a CE reflects a PE received route to another PE, the fact that 214 the original attributes of a route are preserved across the VPN 215 prevents the formation of routing loops due to mutual redistribution 216 between the two networks. 218 5. BGP customer route attributes 220 In order to transparently carry the BGP Path Attributes of customer 221 routes, this document defines a new BGP Path Attribute: 223 ATTR_SET (type code 128) 225 ATTR_SET is an optional transitive attribute that carries a set of 226 BGP path attributes. An attribute set (ATTR_SET) can include any 227 BGP attribute that can occur in a BGP UPDATE message, except the 228 MP_REACH and MP_UNREACH attributes. 230 The ATTR_SET attribute is encoded as follows: 232 +------------------------------+ 233 | Attr Flags (O|T) Code = 128 | 234 +------------------------------+ 235 | Attr. Length (1 or 2 octets) | 236 +------------------------------+ 237 | Origin AS (4 octets) | 238 +------------------------------+ 239 | Path attributes (variable) | 240 +------------------------------+ 242 The Attribute Flags are encoded according to RFC4271 [RFC4271]. The 243 Extended Length bit determines whether the Attribute Length is one or 244 two octets. 246 The attribute value consists on a 4 octet "Origin AS" value followed 247 by a variable length field which conforms to the BGP UPDATE message 248 path attribute encoding rules. The attribute length is 4 plus the 249 total length of the encoded attributes. 251 This attribute is used by a PE router to store the original set of 252 BGP attributes it receives from a CE. When a PE router advertises a 253 PE-received route to a CE, it will use the path attributes carried in 254 the ATTR_SET attribute. 256 In other words, the BGP Path Attributes are "pushed" into this stack 257 like attribute when the route is received by the VPN and "popped" 258 when the route is advertised in the PE to CE direction. 260 Using this mechanism isolates the customer network from the 261 attributes used in the customer network and vice versa. Attributes 262 as the route reflection cluster list attribute are segregated such 263 that customer network cluster identifiers won't be considered by the 264 customer network route reflectors and vice-versa. 266 The Origin autonomous-system number is designed to prevent a route 267 originating in a given autonomous system iBGP to be leaked into a 268 different autonomous system, without proper AS_PATH manipulation. It 269 SHOULD contain the autonomous-system number of the customer network 270 that originates the given set of attributes. The value is encoded as 271 a 32-bit unsigned integer in network byte order, regardless of 272 whether or not the originating PE supports Four-octet AS Numbers 273 [RFC4893]. 275 The AS_PATH and AGGREGATOR attributes contained within an ATTR_SET 276 attribute MUST be encoded using Four-octet AS Numbers [RFC4893], 277 regardless of the capabilities advertised by the BGP speaker to which 278 the ATTR_SET attribute is transmitted. BGP speakers that support the 279 extensions defined in this document MUST also support RFC4893 280 [RFC4893]. The reason for this requirement is to remove ambiguity 281 between two-octet and four-octet AS_PATH attribute encoding. 283 The NEXT_HOP attribute SHOULD NOT be included in an ATTR_SET. When 284 present it SHOULD be ignored by the receiving PE. Future 285 applications of the ATTR_SET attribute MAY define meaninful semantics 286 for an included NEXT_HOP attribute. 288 The ATTR_SET attribute SHALL be considered malformed if any of the 289 following applies: 291 o Its length is less than 4 octets. 293 o The original path attributes carried in the variable length 294 attribute data include the MP_REACH or MP_UNREACH attribute. 296 o The included attributes are malformed themselves. 298 An UPDATE message with a malformed ATTR_SET attribute SHALL be 299 handled as follows. If its Partial flag is set and its Neighbor- 300 Complete flag is clear, the UPDATE is treated as a route withdraw as 301 discussed in [I-D.ietf-idr-optional-transitive]. Otherwise (i.e. 302 Partial flag is clear or Neighbor-Complete is set), the procedures of 303 the BGP-4 base specification [RFC4271] MUST be followed with respect 304 to an Optional Attribute Error. 306 6. Next-hop handling 308 When BGP/MPLS VPNs are not in use, the NEXT_HOP attribute in iBGP 309 routes carries the address of the border router advertising the route 310 into the domain. The IGP distance to the NEXT_HOP of the route is an 311 important component of BGP route selection. 313 When a BGP/MPLS VPN service is used to provide interconnection 314 between different sites, since the customer network runs a different 315 IGP domain, metrics between the provider and customer networks are 316 not comparable. 318 However, the most important component of a metric is the inter-area 319 metric, which is known to the customer network. The intra-area 320 metric is typically negligible. 322 The use of route reflection, for instance, requires metrics to be 323 configured so that inter-cluster/area metrics are always greater than 324 intra-cluster metrics. 326 The approach taken by this document is to rewrite the NEXT_HOP 327 attribute at the VRF import/export boundary. PE routers take into 328 account the PE-PE IGP distance calculated by the customer network 329 IGP, when selecting between routes advertised from different PEs. 331 An advantage of the proposed method is that the customer network can 332 run independent IGPs at each site. 334 7. Exchanging routes between different VPN customer networks 336 In the traditional model, where External BGP sessions are used 337 between the BGP/MPLS VPN PE and CE, the PE router identifies itself 338 as belonging to the customer network autonomous-system. 340 In order to use Internal BGP sessions the PE router has to identify 341 itself as belonging to the Customer AS. More specifically, the VRF 342 that is used to interconnect to that customer site is assigned to the 343 Customer AS rather than the VPN provider AS. 345 The Origin AS element in the ATTR_SET path attribute conveys the AS 346 number of the originating VRF. This AS number is used in a receiving 347 PE in order to identify route exchanges between VRFs in different 348 ASes. 350 In scenarios such as what is commonly referred to an "extranet" VPN, 351 routes MAY be advertised to both internal and external VPN 352 attachments, belonging to different autonomous systems. 354 +-----+ +-----+ 355 | PE1 |-----------------| PE2 | 356 +-----+ +-----+ 357 / \ | 358 +-----+ +-----+ +-----+ 359 | CE1 | | CE2 | | CE3 | 360 +-----+ +-----+ +-----+ 361 AS 1 AS 2 AS 1 363 Consider the example given above where (PE1, CE1) and (PE2, CE3) 364 sessions are iBGP. In BGP/MPLS VPNs, a route received from CE1 above 365 may be distributed to the VRFs corresponding to the attachment points 366 for CEs 2 and 3. 368 The desired result, in such a scenario is to present the internal 369 peer (CE3) with a BGP advertisement that contains the same BGP Path 370 Attributes received from CE1 and to the external peer (CE 2) a BGP 371 advertisement that would correspond to a situation where AS 1 and 2 372 have an external BGP session between them. 374 It order to achieve this goal the following set of rules apply: 376 When importing a VPN route that contains the ATTR_SET attribute 377 into a destination VRF, a PE router MUST check that the "Origin 378 AS" number contained in the ATTR_SET attribute matches the 379 autonomous-system associated with the VRF. 381 In case the autonomous-system numbers do match, the route is 382 imported into the VRF with the attributes contained in the 383 ATTR_SET attribute. Otherwise, in the case of an autonomous- 384 system number mismatch, the set of attributes to be associated 385 with the route SHALL be constructed as follows: 387 1. The path attributes are set to the attributes contained in the 388 ATTR_SET attribute. 390 2. Internal BGP specific attributes are discarded (LOCAL_PREF, 391 ORIGINATOR, CLUSTER_LIST, etc). 393 3. The "Origin AS" number contained in the ATTR_SET attribute is 394 prepended to the AS_PATH following the rules that would apply 395 to an external BGP peering between the source and destination 396 ASes. 398 4. If the autonomous-system associated with the VRF is the same 399 as the VPN provider autonomous-system and the AS_PATH 400 attribute of the VPN route is not empty, it SHALL be prepended 401 to the AS_PATH attribute of the VRF route. 403 When advertising the VRF route to an Exterior BGP peer, a PE 404 router SHALL apply steps 1 to 4 defined above and subsequently 405 prepend its own autonomous-system number to the AS_PATH attribute. 406 For example, if the route originated in a VRF that supports 407 Internal BGP peering and the ATTR_SET attribute and is advertised 408 to a CE that is configured in the traditional Exterior BGP mode 409 then both the originator AS, the VPN AS_PATH segment and the 410 customer network AS are prepended to the AS_PATH. 412 When importing a route without the ATTR_SET attribute to a VRF 413 that is configured in a different autonomous-system, a PE router 414 MUST prepend the VPN provider AS number to the AS_PATH. 416 In all cases where a route containing the ATTR_SET attribute is 417 imported, attributes present on the VPN route other than the NEXT_HOP 418 attribute are ignored, both from the point of view of route selection 419 in the VRF Adj-RIB-in and route advertisement to a CE router. In 420 other words, the information contained in ATTR_SET attribute 421 overrides the VPN route attributes on "vrf-import". 423 8. Deployment considerations 425 It is RECOMMENDED that different VRFs of the same VPN (i.e. in 426 different PE routers) which are configured with iBGP PE-CE peering 427 sessions use different Route Distinguisher (RD) values. Otherwise 428 (in the case where the same RD is used) the BGP IP VPN infrastructure 429 may select a single BGP customer path for a given IP Network Layer 430 Reachability Information (NLRI); without access to the detailed path 431 information that is contained in the ATTR_SET attribute. 433 As mentioned previously, the model for this service is a "Route 434 Server" where the IP VPN provides the customer network with all the 435 BGP paths known by the CEs. This effectively implies the use of 436 unique RDs per VRF. 438 The stated goal of this extension is to isolate the customer network 439 from the BGP path attribute operations performed by the IP VPN and 440 conversely isolate the service provider network from any attributes 441 injected by the customer. For instance, BGP communities can be used 442 to influence the behavior of the IP VPN infrastructure. Using this 443 extension, the service provider network can transparently carry these 444 attributes without interference with its operations. 446 Another example of unwanted interaction between customer and IP VPN 447 BGP attributes is a scenario where the same Service Provider 448 autonomous-system number is used both to provide Internet service as 449 well as the IP VPN service. In this case, it is not uncommon to have 450 a VPN customer route contain the AS Number of the Service Provider. 451 The IP VPN network should work transparently in this case as in all 452 others. 454 This protocol extension is designed to behave such that each PE VRF 455 operates as a router in the configured AS. Previously VRFs operate 456 in the provider network AS only. The VPN backbone provides 457 interconnection between VRFs of the same AS, as well as 458 interconnection between different ASes (subject to the appropriate 459 policies). When interconnecting VRFs in the same AS, the VPN 460 backbone operates as a top level Route Reflection mesh. When 461 interconnecting VRFs in different ASes, the provider network provides 462 an implicit peering relationship between the ASes that originate and 463 import a specific route. 465 This extension is also applicable to scenarios where the VPN backbone 466 spans multiple ASes. When the VPN backbone Inter-AS operation 467 follows option b) or c) as defined in Section 10 of [RFC4364], the 468 Provider networks are able to influence the route attributes and 469 route selection of the VPN routes while providing a transparent 470 service to the customer AS. Both internal BGP connectivity or 471 extranets can be provided to the customer AS. 473 When VPN Provider networks interconnect via option a), there is no 474 possibility of providing a fully transparent service. By definition 475 option a) implies that each autonomous-system border router (ASBR) 476 has a VRF associated with the customer VPN that is configured to 477 operate in the respective Provider AS. These ASBR VRFs then 478 communicate via eBGP with their peer Provider ASes. 480 In this case it is still possible to have all the customer VRFs with 481 one Provider network to be configured in the same customer AS. This 482 customer AS will then peer with the Provider AS implicitly at the 483 ABSR. Which will in turn peer explicitly with a second Provider AS. 484 This is not however a scenario in which transparency to the customer 485 AS is possible. 487 9. Security considerations 489 It is worthwhile to consider the security implications of this 490 proposal from two independent perspectives: the IP VPN provider and 491 the IP VPN customer. 493 From an IP VPN provider perspective, this mechanism will assure 494 separation between the BGP path attributes advertised by the customer 495 CE router and the BGP attributes used within the provider network, 496 thus potentially improving security. 498 Although this behavior is largely implementation dependent, currently 499 it is possible for a CE device to inject BGP attributes (extended 500 communities, for example) that have semantics on the IP VPN provider 501 network, unless explicitly disabled by configuration in the PE. 503 With the rules specified for the ATTR_SET path attribute, any 504 attribute that has been received from a CE is pushed into the stack 505 before the route is advertised out to other PEs. 507 As with any other field based on values received from an external 508 system, an implementation must consider the issues of input 509 validation and resource management. 511 From the perspective of the VPN customer network, it is our opinion 512 that there is no change to the security profile of PE-CE interaction. 513 While having an iBGP session allows the PE to specify additional 514 attributes not allowed on an eBGP session (e.g. local-pref), this 515 does not significantly change the fact that the VPN customer must 516 trust its service provider to provide it correct routing information. 518 10. IANA considerations 520 This document defines a new BGP path attribute which is part of a 521 registry space managed by IANA. We request that IANA update its BGP 522 Path Attributes registry with the value specified above (128) for the 523 ATTR_SET path attribute. 525 11. Acknowledgments 527 The authors would like to thank Stephane Litkowski and Bruno Decraene 528 for their comments. 530 12. References 532 12.1. Normative References 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, March 1997. 537 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 538 Protocol 4 (BGP-4)", RFC 4271, January 2006. 540 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 541 Networks (VPNs)", RFC 4364, February 2006. 543 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 544 Number Space", RFC 4893, May 2007. 546 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 547 Reflection: An Alternative to Full Mesh Internal BGP 548 (IBGP)", RFC 4456, April 2006. 550 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 551 System Confederations for BGP", RFC 5065, August 2007. 553 12.2. Informative References 555 [I-D.ietf-idr-optional-transitive] 556 Scudder, J. and E. Chen, "Error Handling for Optional 557 Transitive BGP Attributes", 558 draft-ietf-idr-optional-transitive-03 (work in progress), 559 September 2010. 561 Authors' Addresses 563 Pedro Marques 565 Email: pedro.r.marques@gmail.com 567 Robert Raszuk 568 Cisco Systems 569 170 W. Tasman Dr. 570 San Jose, CA 95134 571 US 573 Email: raszuk@cisco.com 575 Keyur Patel 576 Cisco Systems 577 170 W. Tasman Dr. 578 San Jose, CA 95134 579 US 581 Email: keyupate@cisco.com 583 Kenji Kumaki 584 KDDI Corporation 585 Garden Air Tower 586 Iidabashi 587 Chiyoda-ku, Tokyo 102-8460 588 Japan 590 Email: ke-kumaki@kddi.com 592 Tomohiro Yamagata 593 KDDI Corporation 594 Garden Air Tower 595 Iidabashi 596 Chiyoda-ku, Tokyo 102-8460 597 Japan 599 Email: to-yamagata@kddi.com