idnits 2.17.1 draft-ietf-ospf-af-alt-08.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-08) exists of draft-ietf-ospf-lls-05 -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'PIM') (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Lindem (Editor) 3 Internet-Draft Redback Networks 4 Intended status: Standards Track S. Mirtorabi 5 Expires: January 2, 2010 A. Roy 6 M. Barnes 7 Cisco Systems 8 R. Aggarwal 9 Juniper Networks 10 Jul 11 2009 12 Support of address families in OSPFv3 13 draft-ietf-ospf-af-alt-08.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 2, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes a mechanism for supporting multiple address 52 families in OSPFv3 using multiple instances. It maps an address 53 family (AF) to an OSPFv3 instance using the Instance ID field in the 54 OSPFv3 packet header. This approach is fairly simple and minimizes 55 extensions to OSPFv3 for supporting multiple AFs. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Design Considerations . . . . . . . . . . . . . . . . . . 3 61 1.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 62 2. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. Instance ID values for new AFs . . . . . . . . . . . . . . 4 64 2.2. OSPFv3 Options Changes . . . . . . . . . . . . . . . . . . 4 65 2.3. Advertising Prefixes in new AFs . . . . . . . . . . . . . 5 66 2.4. Changes to the Hello processing . . . . . . . . . . . . . 5 67 2.5. Next hop for IPv4 unicast and multicast AFs . . . . . . . 5 68 2.6. AS External LSA Forwarding Address for IPv4 Unicast 69 and IPv4 Multicast AFs . . . . . . . . . . . . . . . . . . 6 70 2.7. Database Description Maximum Transmissoin Unit (MTU) 71 Specification for Non-IPv6 AFs . . . . . . . . . . . . . . 6 72 2.8. Operation over Virtual Links . . . . . . . . . . . . . . . 9 73 3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 79 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 OSPFv3 [OSPFV3] has been defined to support the base IPv6 unicast 85 Address Family (AF). There are requirements to advertise other AFs 86 in OSPFv3 including multicast IPv6, unicast IPv4, and multicast IPv4. 87 This document supports these other AFs in OSPFv3 by mapping each AF 88 to a separate Instance ID and OSPFv3 instance. 90 1.1. Design Considerations 92 This section describes the rationale for using the multiple instance 93 ID approach to support multiple address families in OSPFv3. As 94 described earlier, OSPFv3 is designed to support multiple instances. 95 Hence mapping an instance to an address family doesn't introduce any 96 new mechanisms to the protocol. It minimizes the protocol extensions 97 required and it simplifies the implementation. The presence of a 98 separate link state database per address family is also easier to 99 debug and operate. Additionally, it doesn't change the existing 100 instance, area, and interface based configuration model in most 101 OSPFv3 implementations. 103 1.2. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC-KEYWORDS]. 109 2. Protocol Details 111 Currently the entire Instance ID number space is used for IPv6 112 unicast. This specification assigns different Instance ID ranges to 113 different AFs in order to support other AFs in OSPFv3. Each Instance 114 ID implies a separate OSPFv3 instance with its own neighbor 115 adjacencies, link state database, protocol data structures, and 116 shortest path first (SPF) computation. 118 Additionally, the current LSAs that are defined to advertise IPv6 119 unicast prefixes can be used without any modifications to advertise 120 prefixes from other AFs. 122 It should be noted that OSPFv3 is running on top of IPv6 and uses 123 IPv6 link local addresses for OSPFv3 control packets. Therefore, it 124 is required that IPv6 be enabled on a link, although the link may not 125 be participating in any IPv6 AF. 127 2.1. Instance ID values for new AFs 129 Instance ID zero is already defined by default for the IPv6 unicast 130 AF. We define the following ranges for different AFs. The first 131 value of each range is considered as the default value for the 132 corresponding AF. 134 Instance ID # 0 - # 31 IPv6 unicast AF 135 Instance ID # 32 - # 63 IPv6 multicast AF 136 Instance ID # 64 - # 95 IPv4 unicast AF 137 Instance ID # 96 - # 127 IPv4 multicast AF 138 Instance ID # 128 - # 255 Unassigned 140 OSPFv3 Instance IDs 142 2.2. OSPFv3 Options Changes 144 A new AF-bit is added to the OSPFv3 options field. V6-bit and MC-bit 145 are only applicable to the IPv6 unicast AF. 147 1 2 148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 150 | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x | E|V6| 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+ 153 The Options field 155 OSPFv3 Options 157 V6-bit 158 The V6 bit is used in OSPFv3 to exclude a node from IPv6 unicast 159 route calculation but allow it in the SPF calculation for other 160 address families. Since Instance ID now denotes the AF 161 explicitly, this bit is ignored in AFs other than IPv6 unicast. 163 AF-bit 164 When a router supports AF, it MUST set this new bit in the OSPFv3 165 Options field of Hello Packets, DD packets, and LSAs. 167 2.3. Advertising Prefixes in new AFs 169 Each Prefix defined in OSPFv3 has a prefix length field. This 170 facilitate advertising prefixes of different lengths in different 171 AFs. The existing LSAs defined in OSPFv3 are used for this purpose 172 and there is no need to define new LSAs. 174 Prefixes which don't match the AF of the OSPFv3 instance, MUST be 175 discarded in any route computation. 177 2.4. Changes to the Hello processing 179 When a router does not support an AF but it is configured with the 180 corresponding Instance ID packets could be black holed. This could 181 happen due to misconfiguration or a router software downgrade. Black 182 holing is possible because the router which doesn't support the AF 183 can still be included in the SPF calculated path as long as it 184 establishes adjacencies using the Instance ID corresponding to the 185 AF. Note that router and network LSAs are AF independent. 187 In order to avoid the above situation, hello processing is changed in 188 order to only establish adjacencies with routers that have the AF-bit 189 set in their Options field. 191 Receiving Hello Packets is specified in section 3.2.2.1 of [OSPFV3]. 192 The following check is added to Hello reception: 194 o When a router participates in an AF (sets the AF-bit in Options 195 field) it MUST discard Hello packets having the AF-bit clear in 196 the Options field. The only exception is the Base IPv6 unicast 197 AF, where this check MUST NOT be done (for backward 198 compatibility). 200 2.5. Next hop for IPv4 unicast and multicast AFs 202 OSPFv3 runs on top of IPv6 and uses IPv6 link local addresses for 203 OSPFv3 control packets and next hop calculations. Although IPV6 link 204 local addresses could be used as next hops for IPv4 address families, 205 it is desirable to have IPv4 next hop addresses. For example, in 206 IPv4 multicast having the next hop address the same as the Protocol 207 Independent Multicast (PIM) [PIM] neighbor address (IPv4 address) 208 makes it easier to determine which upstream neighbor to send a PIM 209 join when doing a Reverse Path Forwarding (RPF) lookup. It is also 210 easier for troubleshooting to have a next hop with the same AF. 212 In order to achieve this, the link's IPv4 address will be advertised 213 in the "link local address" field of the IPv4 instance's Link-LSA. 214 This address is placed in the first 32 bit of "link local address" 215 field and used for IPv4 next hop calculations. The remaining bits 216 MUST be set to zero. 218 We call the direct interface address (DIA) the address that is 219 reachable directly via the link provided that a layer 3 to layer 2 220 mapping is available. Note that there is no explicit need for the 221 IPv4 link addresses to be on the same subnet. An implementation 222 SHOULD resolve layer 3 to layer 2 mappings via Address Resolution 223 Protocol (ARP) [ARP] or Neighbor Discovery (ND) [ND] for a DIA even 224 if the IPv4 address is not on the same subnet as the router's 225 interface IP address. 227 2.6. AS External LSA Forwarding Address for IPv4 Unicast and IPv4 228 Multicast AFs 230 For OSPFv3, this address is an IPv6 host address (128 bits). If 231 included, data traffic for the advertised destination will be 232 forwarded to this address. For IPv4 unicast and IPv4 multicast AFs, 233 the Forwarding Address in AS-external-LSAs MUST encode an IPv4 234 address. To achieve this, the IPv4 Forwarding Address is advertised 235 by placing it in the first 32 bits of the Forwarding Address field in 236 the AS-external-LSAs. The remaining bits MUST be set to zero. 238 2.7. Database Description Maximum Transmissoin Unit (MTU) 239 Specification for Non-IPv6 AFs 241 For address families other than IPv6, both the MTU for the address 242 family of the instance and IPv6 MTU used for OSPFv3 maximum packet 243 determination MUST be considered. The MTU in the Database 244 Description packet MUST always contain the MTU corresponding to the 245 advertised address family. For example, if the instance corresponds 246 to an IPv4 address family, the IPv4 MTU for the interface MUST be 247 specified in the interface MTU field. As specified section 10.6 of 248 [OSPFV2], the Database Description packet will be rejected if the MTU 249 is greater than the receiving interface's MTU for the address family 250 corresponding to the instance. This behavior will assure an 251 adjacency is not formed and address family specific routes are not 252 installed over a path with conflicting MTUs. 254 The value used for OSPFv3 maximum packet size determination MUST also 255 be compatible for an adjacency to be established. Since only a 256 single MTU field is specified, the M6-bit is defined by this 257 specification. If the M6-bit is clear, the specified MTU SHOULD also 258 be checked against the IPv6 MTU and the Database Description packet 259 SHOULD be rejected if the MTU is larger than the receiving 260 interface's IPv6 MTU. An OSPFv3 router SHOULD NOT set the M6-bit if 261 its IPv6 MTU and address family specific MTU are the same. 263 If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 264 address families. If the M6-bit is set, the IPv6 MTU is decided by 265 the presence or absense of IPv6 MTU TLV in the LLS [LLS] block. If 266 this TLV is present, it carries the IPv6 MTU which SHOULD be compared 267 with local IPv6 MTU. If this TLV is absent, the minimum IPv6 MTU of 268 1280 octets SHOULD be used for the comparison (refer to [IPV6]). 270 If the M6-bit is set in a received Database Description packet for a 271 non-IPv6 address family, the receiving router MUST NOT check the 272 Interface MTU in the Database Exchange packet against the receiving 273 interface's IPv6 MTU. 275 The figure below graphically depicts the OSPFv3 Database Description 276 Packet: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 281 | 3 | 2 | Packet Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 283 | Router ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 285 | Area ID | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 287 | Checksum | Instance ID | 0 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 289 | 0 | Options | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 291 | Interface MTU | 0 |0|0|0|M6|0|I|M|MS| 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 293 | DD sequence number | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 295 | | 296 +- -+ 297 | | 298 +- An LSA Header -+ 299 | | 300 +- -+ 301 | | 302 +- -+ 303 | | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+ 305 | ... | 307 The OSPFv3 Database Description Packet 309 The changed fields in the Database Description packet are described 310 below. The remaining fields are unchanged from [OSPFV3]. 312 Interface MTU 313 The size in octets of the largest address-family specific datagram 314 that can be sent out the associated interface without 315 fragmentation. The MTUs of common Internet link types can be 316 found in Table 7-1 of [MTUDISC]. Interface MTU SHOULD be set to 0 317 in Database Description packets sent over virtual links. 319 M6-bit 320 The IPv6 MTU bit - this bit indicates the sender is using a 321 different IPv6 MTU than the MTU for the address family. 323 IPv6 MTU TLV can be optionally carried in LLS block as described 324 above. This TLV carries the IPv6 MTU on the interface. The length 325 field of of TLV is set to 4 bytes. 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | 6 (TBD) | 4 | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | IPv6 MTU | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Format of IPv6 MTU TLV 337 The IPv6 MTU TLV may appear in the LLS block only once. 339 2.8. Operation over Virtual Links 341 OSPFv3 control packets sent over a virtual link are IPv6 packets and 342 may traverse multiples hops. Therefore, there MUST be a global IPv6 343 address associated with the virtual link so that the control packet 344 is forwarded correctly by the intermediate hops between virtual link 345 endpoints. Although this requirement can be satisfied in IPv6 346 unicast AFs, it will not function in other AFs as there will not be a 347 routable global IPv6 address or forwarding path. Therefore, virtual 348 links are not supported in AFs other than IPv6 Unicast. 350 3. Backward Compatibility 352 In this section, we will define a non-capable OSPFv3 router as one 353 not supporting this specification. Each new AF will have a 354 corresponding Instance ID and can interoperate with the existing non- 355 capable OSPFv3 routers in an IPv6 unicast topology. Furthermore, 356 when a non-capable OSPFv3 router uses an Instance ID which is 357 reserved for a given AF, no adjacency will be formed with this router 358 since the AF-bit in the Options field will not be set in Hello 359 packets. Therefore, there are no backward compatibility issues. AFs 360 can be gradually deployed without disturbing networks with non- 361 capable OSPFv3 routers. 363 4. Security Considerations 365 IPsec [IPsec]. can be used for OSPFv3 authentication and 366 confidentiality as described in [OSPFV3-AUTH]. When multiple OSPFv3 367 instances use the same interface, they all MUST use the same Security 368 Association (SA), since the SA selectors do not provide selection 369 based on OSPFv3 header fields such as the instance ID. This 370 restriction is documented in section 8 of [OSPFV3-AUTH]. 372 Security considerations for the OSPFv3 are covered in [OSPFV3]. 374 5. IANA Considerations 376 The following IANA assignments are to be made from existing 377 registries: 379 The AF-bit is assigned from OSPFv3 Options field as defined in 380 Section 2.2. 382 IANA is requested to create a new registry, "OSPFv3 Instance ID 383 Address Family Values". for assignment of address families. Note 384 that the Instance ID MAY be used for applications other than the 385 support of multiple address families. However, if it is being used 386 for address families the assignments herein SHOULD be honored. 388 +-------------+----------------------+--------------------+ 389 | Value/Range | Designation | Assignment Policy | 390 +-------------+----------------------+--------------------+ 391 | 0 | Base IPv6 Unicast AF | Already assigned | 392 | | | | 393 | 1-31 | IPv6 Unicast AFs | Already assigned | 394 | | dependent on local | | 395 | | policy | | 396 | | | | 397 | 32 | Base IPv6 Multicast | Already assigned | 398 | | | | 399 | 33-63 | IPv6 Multicast AFs | Already assigned | 400 | | dependent on local | | 401 | | policy | | 402 | | | | 403 | 64 | Base IPv4 Unicast AF | Already assigned | 404 | | | | 405 | 65-95 | IPv4 Unicast AFs | Already assigned | 406 | | dependent on local | | 407 | | policy | | 408 | | | | 409 | 96 | Base IPv4 Multicast | Already assigned | 410 | | | | 411 | 97-127 | IPv4 Multicast AFs | Already assigned | 412 | | dependent on local | | 413 | | policy | | 414 | | | | 415 | 128-255 | Unassigned | Standards Action | 416 +-------------+----------------------+--------------------+ 418 OSPFv3 Address Family Use of Instance IDs 420 o Instance IDs 0-127 are assigned by this specification. 422 o Instance IDs in the range 128-255 are not assigned at this time. 423 Before any assignments can be made in this range, there MUST be a 424 Standards Track RFC including IANA Considerations explicitly 425 specifying the AF Instance IDs being assigned. 427 M6-Bit is assigned as defined in Section 2.7. 429 A TLV type for IPv6 MTU TLV is assigned from OSPF LLS TLVs registry. 431 6. References 433 6.1. Normative References 435 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 436 (IPv6) Specification", RFC 2460, December 1998. 438 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 439 Internet Protocol", RFC 4301, December 2005. 441 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 443 [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 444 for IPv6", RFC 5340, July 2008. 446 [OSPFV3-AUTH] 447 Gupta, M. and S. Melam, "Authentication/Confidentiality 448 for OSPFv3", RFC 4552, June 2006. 450 [RFC-KEYWORDS] 451 Bradner, S., "Key words for use in RFC's to Indicate 452 Requirement Levels", RFC 2119, March 1997. 454 6.2. Informative References 456 [ARP] Plummer, D., "An Ethernet Address Resolution Protocol", 457 RFC 826, November 1982. 459 [LLS] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. 460 Young, "OSPF Link-local Signaling", 461 draft-ietf-ospf-lls-05.txt, Work in progress. 463 [MTUDISC] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 464 November 1990. 466 [ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 467 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, 468 September 2007. 470 [PIM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 471 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 472 Protocol Specification (Revised)", RFC 4601, August 2006. 474 Appendix A. Acknowledgments 476 The RFC text was produced using Marshall Rose's xml2rfc tool. 478 Thanks to Tom Henderson and the folks at Boeing for implementing in 479 quagga. 481 Thanks to Nischal Sheth for review and comments. 483 Authors' Addresses 485 Acee Lindem 486 Redback Networks 487 102 Carric Bend Court 488 Cary, NC 27519 489 USA 491 Email: acee@redback.com 493 Sina Mirtorabi 494 Cisco Systems 495 3 West Plumeria Drive 496 San Jose, CA 95134 497 USA 499 Email: smirtora@cisco.com 501 Abhay Roy 502 Cisco Systems 503 225 West Tasman Drive 504 San Jose, CA 95134 505 USA 507 Email: akr@cisco.com 509 Michael Barnes 510 Cisco Systems 511 225 West Tasman Drive 512 San Jose, CA 95134 513 USA 515 Email: mjbarnes@cisco.com 517 Rahul Aggarwal 518 Juniper Networks 519 1194 N. Mathilda Ave. 520 Sunnyvale, CA 94089 521 USA 523 Email: rahul@juniper.net