idnits 2.17.1 draft-ietf-softwire-v4nlri-v6nh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 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 (January 28, 2009) is 5538 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 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-09 == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire F. Le Faucheur 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track E. Rosen 5 Expires: August 1, 2009 Cisco Systems, Inc. 6 January 28, 2009 8 Advertising IPv4 Network Layer Reachability Information with an IPv6 9 Next Hop 10 draft-ietf-softwire-v4nlri-v6nh-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 1, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer 50 protocols to which the address carried in the Next Hop field may 51 belong is determined by the Address Family Identifier (AFI) and the 52 Subsequent Address Family Identifier (SAFI). The current AFI/SAFI 53 definitions for the IPv4 address family only have provisions for 54 advertising a Next Hop address that belongs to the IPv4 protocol when 55 advertising an IPv4 Network Layer Reachability Information (NLRI) or 56 a VPN-IPv4 NLRI. This document specifies the extensions necessary to 57 allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop 58 address that belongs to the IPv6 protocol. This comprises an 59 extension of the AFI/SAFI definitions to allow the address of the 60 Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 61 protocol, the encoding of the Next Hop in order to determine which of 62 the protocols the address actually belongs to, and a new BGP 63 Capability allowing MP-BGP Peers to dynamically discover whether they 64 can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 70 3. Extension of AFI/SAFI Definitions for IPv4 Address Family . . 5 71 4. Use of BGP Capability Advertisement . . . . . . . . . . . . . 6 72 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. IPv4 over IPv6 Core . . . . . . . . . . . . . . . . . . . 9 75 6.2. IPv4 VPN over IPv6 Core . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Multi Protocol-BGP (MP-BGP) [RFC4760] specifies that the set of 87 Network Layer protocols to which the address carried in the Next Hop 88 field may belong is determined by the Address Family Identifier (AFI) 89 and the Subsequent Address Family Identifier (SAFI). A number of 90 existing AFI/SAFIs allow the Next Hop address to belong to a 91 different address family than the Network Layer Reachability 92 Information (NLRI). For example, the AFI/SAFI <25/65> used as per 93 [I-D.ietf-l2vpn-signaling] in order to perform L2VPN Autodiscovery 94 allows advertising an NLRI containing the identifier of a VPLS 95 instance, or identifying a particular pool of attachment circuits at 96 a given Provider Edge (PE), while the Next Hop field contains the 97 loopback address of a PE. Similarly, the AFI/SAFI <1/132> defined in 98 [RFC4684] in order to advertise Route Target (RT) membership 99 information, allows advertising an NLRI containing such RT membership 100 information while the Next Hop field contains the address of the 101 advertising router. 103 Furthermore, a number of these existing AFI/SAFIs allow the Next Hop 104 to belong to either the IPv4 Network Layer Protocol or the IPv6 105 Network Layer Protocol, and specify the encoding of the Next Hop 106 information in order to determine which of the protocols the address 107 actually belongs to. For example, [RFC4684] allows the Next Hop 108 address to be either IPv4 or IPv6 and states that the Next Hop field 109 address shall be interpreted as an IPv4 address, whenever the length 110 of Next Hop address is 4 octets, and as a IPv6 address, whenever the 111 length of the Next Hop address is 16 octets. 113 There are situations such as those described in [RFC4925] and in 114 [I-D.ietf-softwire-mesh-framework] where carriers (or large 115 enterprise networks acting as carrier for their internal resources) 116 may be required to establish connectivity between 'islands' of 117 networks of one address family type across a transit core of a 118 differing address family type. This includes both the case of IPv6 119 islands across an IPv4 core and the case of IPv4 islands across an 120 IPv6 core. Where Multi-Protocol BGP (MP-BGP) is used to advertise 121 the corresponding reachability information, this translates into the 122 requirement for a BGP speaker to advertise Network Layer Reachability 123 Information (NLRI) of a given address family via a Next Hop of a 124 different address family (i.e. IPv6 NLRI with IPv4 Next Hop and IPv4 125 NLRI with IPv6 Next Hop). 127 The current AFI/SAFI definitions for the IPv6 address family assume 128 that the Next Hop address belongs to the IPv6 address family type. 129 Specifically, as per [RFC2545] and [RFC3107], when the is 130 <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 131 type. As per [RFC4659], when the is <2/128>, the Next Hop 132 address is assumed to be of IPv6-VPN type. 134 However, [RFC4798] and [RFC4659] specify how an IPv4 address can be 135 encoded inside the Next Hop IPv6 address field when an IPv6 NLRI 136 needs to be advertised with an IPv4 Next Hop. [RFC4798] defines how 137 the IPv4-mapped IPv6 address format specified in the IPv6 addressing 138 architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- 140 mapped IPv6 address format as well as a null Route Distinguisher can 141 be used for that purpose when the is <2/128>. Thus, there 142 are existing solutions for the advertisement of IPv6 NLRI with an 143 IPv4 next hop. 145 Similarly, the current AFI/SAFI definitions for advertisement of IPv4 146 NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the 147 IPv4 address family type. Specifically, as per [RFC4760] and 148 [RFC3107], when the is <1/1>, <1/2>, or <1/4>, the Next 149 Hop address is assumed to be of IPv4 type. As per [RFC4364], when 150 the is <1/128>, the Next Hop address is assumed to be of 151 VPN-IPv4 type. There is clearly no generally applicable method for 152 encoding an IPv6 address inside the IPv4 address field of the Next 153 Hop. Hence, there is currently no specified solution for advertising 154 IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop. 156 This document specifies the extensions necessary to do so. This 157 comprises an extension of the AFI/SAFI definitions to allow the 158 address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to belong 159 to either the IPv4 or the IPv6 protocol, the encoding of the Next Hop 160 information in order to determine which of the protocols the address 161 actually belongs to, and a new BGP Capability allowing MP-BGP Peers 162 to dynamically discover whether they can exchange IPv4 NLRI and VPV- 163 IPv4 NLRI with an IPv6 Next Hop. The new BGP capability allows 164 gradual deployment of the new functionality of advertising IPv4 165 reachability via an IPv6 next hop, without any flag day nor any risk 166 of traffic black-holing. 168 2. Requirements Language 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 3. Extension of AFI/SAFI Definitions for IPv4 Address Family 176 As mentioned earlier, MP-BGP specifies that the set of Network Layer 177 protocols to which the address carried in the Next Hop field may 178 belong is determined by the Address Family Identifier (AFI) and the 179 Subsequent Address Family Identifier (SAFI). The following current 180 AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, 181 <1/2>, <1/4> and <1/128>) only have provisions for advertising a Next 182 Hop address that belongs to the IPv4 protocol. This document extends 183 the definition of the AFI/SAFI for advertisement of IPv4 NLRI and 184 VPN-IPv4 NLRI to extend the set of network layer protocols to which 185 the Next Hop address can belong, to include IPv6 in addition to IPv4. 187 Specifically, this document allows advertising with [RFC4760] of an 188 MP_REACH_NLRI with: 190 o AFI=1 192 o SAFI = 1, 2, 4 or 128 194 o Length of Next Hop Address = 16 or 32 196 o Next Hop Address = IPv6 address of next hop (potentially followed 197 by the link-local IPv6 address of the next hop). This field is to 198 be constructed as per section 3 of [RFC2545]. 200 o NLRI= NLRI as per current AFI/SAFI definition 202 This is in addition to the current mode of operation allowing 203 advertisement of an NLRI for of <1,1>, <1,2> and <1,4> 204 with a next hop address of IPv4 type and advertisement of an NLRI for 205 of <1,128> with a next hop address of VPN-IPv4 type. 207 The BGP speaker receiving the advertisement MUST use the Length of 208 Next Hop Address field to determine which network layer protocol the 209 next hop address belongs to. When the Length of Next Hop Address 210 field is equal to 16 or 32, the next hop address is of type IPv6. 211 Note that this method of using the Length of the Next Hop Address 212 field to determine which network layer protocol the next hop address 213 belongs to (out of the set of protocols allowed by the AFI/SAFI 214 definition) is the same as used in [RFC4684] and 215 [I-D.ietf-l2vpn-signaling]. 217 4. Use of BGP Capability Advertisement 219 [RFC3392] defines a mechanism to allow two BGP speakers to discover 220 if a particular capability is supported by their BGP peer and thus 221 whether it can be used with that peer. This document defines a new 222 capability which can be advertised using [RFC3392] and which is 223 referred to as the Extended Next Hop Encoding capability. This 224 capability allows BGP speakers to discover whether, for a given NLRI 225 , a peer supports advertisement with a next hop whose 226 network protocol is determined by the value of the Length of Next Hop 227 Address field, as specified in section 2. 229 A BGP speaker that wishes to advertise to a BGP peer an IPv6 next hop 230 for an IPv4 NLRI or for a VPN-IPv4 NLRI as per this specification 231 MUST use the Capability Advertisement procedures defined in [RFC3392] 232 with the Extended Next Hop Encoding Capability to establish whether 233 its peer supports this for the NLRI AFI/SAFI pair(s) of interest. 234 The fields in the Capabilities Optional Parameter MUST be set as 235 follows: 237 o The Capability Code field MUST be set to [To be allocated by IANA] 238 (which indicates the Extended Next Hop Encoding capability). 240 o The Capability Length field is set to a variable value which is 241 the length of the Capability Value field (which follows). 243 o The Capability Value field has the following format: 245 +-----------------------------------------------------+ 246 | NLRI AFI - 1 (2 octets) | 247 +-----------------------------------------------------+ 248 | NLRI SAFI - 1 (2 octets) | 249 +-----------------------------------------------------+ 250 | Nexthop AFI - 1 (2 octets) | 251 +-----------------------------------------------------+ 252 | ..... | 253 +-----------------------------------------------------+ 254 | NLRI AFI - N (2 octets) | 255 +-----------------------------------------------------+ 256 | NLRI SAFI - N (2 octet) | 257 +-----------------------------------------------------+ 258 | Nexthop AFI - N (2 octets) | 259 +-----------------------------------------------------+ 261 where: 263 * each triple indicates that 264 an NLRI of NLRI AFI, NLRI SAFI may be advertised with a Next 265 Hop address belonging to the Network Layer protocol of Nexthop 266 AFI. 268 * the AFI and SAFI values are defined in the Address Family 269 Identifier and Subsequent Address Family Identifier registries 270 maintained by IANA. 272 Since this document only concerns itself with the advertisement of 273 IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification 274 only allows the following values in the Capability Value field of the 275 Extended Next Hop Encoding capability: 277 o NLRI AFI=1 (IPv4) 279 o NLRI SAFI = 1, 2, 4 or 128 281 o Nexthop AFI=2 (IPv6) 283 This specification does not propose that the Extended Next Hop 284 Encoding capability be used with any other combinations of NLRI AFI, 285 NLRI SAFI, Nexthop AFI. In particular, this specification does not 286 propose that the Extended Next Hop Encoding capability be used for 287 NLRI AFI/SAFIs whose definition already allows use of both IPv4 and 288 IPv6 next hops (e.g. AFI/SAFI=1/132 as defined in [RFC4684]). 289 Similarly, it does not propose that the Extended Next Hop Encoding 290 capability be used for NLRI AFI/SAFIs for which there is already a 291 solution for advertising a next hop of a different address family 292 (e.g AFI/SAFI=2/1, 2/2 or 2/4 with IPv4 next hop as per [RFC4798] and 293 AFI/SAFI=2/128 with IPv4 next hop as per [RFC4659]). 295 It is expected that if new AFI/SAFIs are defined in the future, their 296 definition will (where appropriate) have provisions for both IPv4 and 297 IPv6 next hops from the onset, with determination based on Length of 298 Next Hop Address field. Thus, new AFI/SAFIs are not expected to make 299 use of the Extended Next Hop Encoding capability. 301 A BGP speaker MUST only advertise to a BGP peer an IPv4 or VPN-IPv4 302 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained 303 via BGP Capability Advertisement that the BGP peer supports the 304 Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. 306 The Extended Next Hop Encoding capability provides information about 307 next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is 308 allowed. It does not influence whether that AFI/SAFI is indeed 309 allowed. Whether a AFI/SAFI can be used between the BGP peers is 310 purely determined through the Multiprotocol Extensions capability 311 defined in [RFC4760]. 313 The Extended Next Hop Encoding capability MAY be dynamically updated 314 through the use of the Dynamic Capability capability and associated 315 mechanisms defined in [I-D.ietf-idr-dynamic-cap]. 317 5. Operations 319 By default, if a particular BGP session is running over IPvx (where 320 IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is 321 putting its own address in as the next hop, then the next hop address 322 SHOULD be specified as an IPvx address, using the encoding rules 323 specified in the AFI/SAFI definition of the NLRI being updated. This 324 default behavior may be overridden by policy. 326 When a next hop address needs to be passed along unchanged (as, e.g., 327 a Route Reflector (RR) would do), its encoding MUST NOT be changed. 328 If a particular RR client cannot handle that encoding (as determined 329 by the BGP capability advertisement), then the NLRI in question 330 cannot be distributed to that client. For sound routing in certain 331 scenarios, this will require that all the RR clients be able to 332 handle whatever encodings any of them may generate. 334 6. Usage Examples 336 6.1. IPv4 over IPv6 Core 338 The extensions defined in this document may be used as discussed in 339 [I-D.ietf-softwire-mesh-framework] for the interconnection of IPV4 340 islands over an IPv6 backbone. In this application, Address Family 341 Border Routers (AFBR) (as defined in [RFC4925]) advertise IPv4 NLRI 342 information in the MP_REACH_NLRI along with an IPv6 next hop. 344 The MP_REACH_NLRI is encoded with: 346 o AFI=1 348 o SAFI=1 350 o Length of Next Hop Network Address = 16 (or 32) 352 o Network Address of Next Hop= IPv6 address of Next Hop 354 o NLRI= IPv4 routes 356 During BGP Capability Advertisement, the PE routers would include the 357 following fields in the Capabilities Optional Parameter: 359 o Capability Code set to "Extended Next Hop Encoding" 361 o Capability Value containing 364 6.2. IPv4 VPN over IPv6 Core 366 The extensions defined in this document may be used for support of 367 IPV4 VPNs over an IPv6 backbone. In this application, PE Routers 368 would advertise VPN-IPv4 NLRI information in the MP_REACH_NLRI along 369 with an IPv6 next hop. 371 The MP_REACH_NLRI is encoded with: 373 o AFI=1 375 o SAFI=128 377 o Length of Next Hop Network Address = 16 (or 32) 379 o Network Address of Next Hop= IPv6 address of Next Hop 381 o NLRI= IPv4-VPN routes 383 During BGP Capability Advertisement, the PE routers would include the 384 following fields in the Capabilities Optional Parameter : 386 o Capability Code set to "Extended Next Hop Encoding" 388 o Capability Value containing 391 7. IANA Considerations 393 This document defines, in section 3, a new Capability Code to 394 indicate the Extended Next Hop Encoding capability in the [RFC3392] 395 Capabilities Optional Parameter. The value for this new Capability 396 Code is to be allocated from the range 1 through 63 set aside for 397 allocation using the "IETF Review" policy defined in [RFC5226]. 399 8. Security Considerations 401 This document does not raise any additional security issues beyond 402 those of BGP-4 and the MultiProtocol extensions for BGP-4. The same 403 security mechanisms are applicable. 405 Although not expected to be the typical case, the IPv6 address used 406 as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as 407 defined in [RFC4291]). Configuration of the security mechanisms 408 potentially deployed by the network operator (such as security checks 409 on next hop address) need to keep this case in mind also. 411 9. Acknowledgments 413 The authors would like to thank Yakov Rekhter, Pranav Metha and John 414 Scudder for their contributions in the approach defined in this 415 document. 417 10. References 419 10.1. Normative References 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 425 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 426 March 1999. 428 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 429 BGP-4", RFC 3107, May 2001. 431 [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement 432 with BGP-4", RFC 3392, November 2002. 434 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 435 Architecture", RFC 4291, February 2006. 437 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 438 Networks (VPNs)", RFC 4364, February 2006. 440 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 441 "Multiprotocol Extensions for BGP-4", RFC 4760, 442 January 2007. 444 10.2. Informative References 446 [I-D.ietf-idr-dynamic-cap] 447 Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", 448 draft-ietf-idr-dynamic-cap-09 (work in progress), 449 November 2006. 451 [I-D.ietf-l2vpn-signaling] 452 Rosen, E., "Provisioning, Autodiscovery, and Signaling in 453 L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress), 454 May 2006. 456 [I-D.ietf-softwire-mesh-framework] 457 Wu, J., Cui, Y., Li, X., Metz, C., Rosen, E., Barber, S., 458 Mohapatra, P., and J. Scudder, "Softwire Mesh Framework", 459 draft-ietf-softwire-mesh-framework-05 (work in progress), 460 September 2008. 462 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 463 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 464 IPv6 VPN", RFC 4659, September 2006. 466 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 467 R., Patel, K., and J. Guichard, "Constrained Route 468 Distribution for Border Gateway Protocol/MultiProtocol 469 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 470 Private Networks (VPNs)", RFC 4684, November 2006. 472 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 473 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 474 Provider Edge Routers (6PE)", RFC 4798, February 2007. 476 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 477 Problem Statement", RFC 4925, July 2007. 479 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 480 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 481 May 2008. 483 Authors' Addresses 485 Francois Le Faucheur 486 Cisco Systems 487 Greenside, 400 Avenue de Roumanille 488 Sophia Antipolis 06410 489 France 491 Email: flefauch@cisco.com 493 Eric Rosen 494 Cisco Systems, Inc. 495 1414 Massachusetts Avenue 496 Boxborough, MA 01719 497 USA 499 Email: erosen@cisco.com