idnits 2.17.1 draft-ietf-l3vpn-bgpvpn-auto-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 579. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 2007) is 6214 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: 'RFC-3031' is mentioned on line 215, but not defined == Unused Reference: 'BGP-MP' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC-3107' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 430, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') (Obsoleted by RFC 2858) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-VR' -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-gre-ip-2547-03 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-11 == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-rt-constrain-01 Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN WG Hamid Ould-Brahim 3 draft-ietf-l3vpn-bgpvpn-auto-09.txt Nortel Networks 4 INFORMATIONAL 5 Expiration Date: November 2007 6 Eric C. Rosen 7 Cisco Systems 9 Yakov Rekhter 10 Juniper Networks 12 (Editors) 14 April 2007 16 Using BGP as an Auto-Discovery Mechanism for 17 VR-based Layer-3 VPNs 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents 22 that any applicable patent or other IPR claims of which he 23 or she is aware have been or will be disclosed, and any of which he 24 or she becomes aware will be disclosed, in accordance with Section 6 25 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet- Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 In any provider-based VPN scheme, the Provider Edge (PE) devices 45 attached to a common VPN must exchange certain information as a 46 prerequisite to establish VPN-specific connectivity. The main 47 purpose of an auto-discovery mechanism is to enable a PE to 48 dynamically discover the set of remote PEs having VPN members in 49 common. The auto-discovery mechanism proceeds by having a PE 50 advertises to other PEs, at a minimum, its own IP address and the 51 list of VPN members configured on that PE. Once that information is 52 received the remote PEs will then identify the list of VPN sites 53 members of the same VPN, and use the information 54 carried within the discovery mechanism to establish VPN 55 connectivity. This draft defines a BGP based auto-discovery 56 mechanism for Virtual Router-based layer-3 VPNs. This mechanism is 57 based on the approach used by BGP/MPLS-IP-VPN for distributing VPN 58 routing information within the service provider(s). 60 Changes from 07 version (DELETE THIS WHEN IT BECOMES RFC) 62 - Updated the IANA section to reflect the review from IANA 63 - Nits from Harald's feedback. 65 1. Introduction 67 In any provider-based VPN scheme, the Provider Edge (PE) devices 68 attached to a common VPN must exchange certain information as a 69 prerequisite to establish VPN-specific connectivity. An auto- 70 discovery mechanism allows a PE to dynamically discover the set of 71 remote PEs having VPN members in common. The auto-discovery 72 mechanism proceeds by having a PE advertises to other PEs, at a 73 minimum, its own IP address and the list of VPN sites configured 74 on that PE. Once that information is received the remote PEs will 75 then identify the list of VPN sites member of the same VPN with the 76 advertising PE, and use the information carried within the discovery 77 mechanism to establish VPN connectivity. 79 The purpose of this draft is to define a BGP based auto-discovery 80 mechanism for VR-based VPNs [VPN-VR] solution. This mechanism is 81 based on the approach used by [BGP/MPLS-IP-VPN] for distributing VPN 82 routing information within the service provider(s). 84 Virtual router (VR) addresses must be exchanged, along with the 85 information needed to enable the PEs to determine which VRs are in 86 the same VPN ("membership"), and which of those VRs are to have VPN 87 connectivity ("topology"). Once the VRs are reachable through the 88 tunnels, routes ("reachability") are then exchanged by running 89 existing routing protocols per VPN basis. 91 The BGP-4 multiprotocol extensions are used to carry various 92 information about VR-based VPNs. VPN-specific information associated 93 with the NLRI is encoded either as attributes of the NLRI, or as 94 part of the NLRI itself, or both. 96 2. Provider-Provisioned VPN Reference Model 98 When using BGP as an auto-discovery mechanism, VR-based l3vpns are 99 using a network reference model as illustrated in figure 1. 101 PE PE 102 +--------------+ +--------------+ 103 +--------+ | +----------+ | | +----------+ | +--------+ 104 | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | 105 | Sites |--| |Database /| | BGP route | | Database/| |-| sites | 106 +--------+ | |Processing| |<----------->| |Processing| | +--------+ 107 | +----------+ | Distribution| +----------+ | 108 | | | | 109 +--------+ | +----------+ | | +----------+ | +--------+ 110 | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | 111 | Sites |--| |Database /| |-(Backbones)-| | Database/| |-| sites | 112 +--------+ | |Processing| | -------- | |Processing| | +--------+ 113 | +----------+ | | +----------+ | 114 | | | | 115 +--------+ | +----------+ | | +----------+ | +--------+ 116 | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | 117 | Sites |--| |Database /| | | | Database/| |-| sites | 118 +--------+ | |Processing| | | |Processing| | +--------+ 119 | +----------+ | | +----------+ | 120 +--------------+ +--------------+ 122 Figure 1: Network based VPN Reference Model 124 It is assumed that the PEs can use BGP to distribute information to 125 each other. This may be via direct IBGP peering, via direct EBGP 126 peering, via multihop BGP peering, through intermediaries such as 127 Route Reflectors, through a chain of intermediate BGP connections, 128 etc. 130 3. Carrying VR-based VPN information in BGP 132 The BGP-4 multiprotocol extensions are used to carry various 133 information about VPNs. VPN-specific information associated with the 134 NLRI is encoded either as attributes of the NLRI, or as part of the 135 NLRI itself, or both. The addressing information in the NLRI field 136 is ALWAYS within the VPN address space, and therefore MUST be unique 137 within the VPN. The address specified in the BGP next hop attribute, 138 on the other hand, is in the service provider addressing space. 140 The NLRI is a VPN-IP address or a labeled VPN-IP address. The NLRI 141 address prefix is an address of one of the virtual routers 142 configured on the PE. That address is used by the VRs to establish 143 routing adjacencies and tunnel to each other [VPN-VR]. 145 4. Interpretation of VPN Information in the VR Model 147 4.1 Membership Discovery 149 The VPN-ID format as defined in [RFC-2685] is used to identify a 150 VPN. All virtual routers that are members of a specific VPN share 151 the same VPN-ID. A VPN-ID is carried in the NLRI to make addresses 152 of VRs globally unique. Making these addresses globally unique is 153 necessary if one uses BGP for VRs' auto-discovery. 155 4.2 Encoding of the VPN-ID in the NLRI 157 For the virtual router model, the VPN-ID is carried within the route 158 distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the 159 first byte of RD type field is used to indicate the existence of the 160 VPN-ID format. A value of 0x80 in the first byte of RD's type field 161 indicates that the RD field is carrying the VPN-ID format. In this 162 case, the type field range 0x8000-0x80ff will be reserved for the 163 virtual router case. 165 4.3 VPN-ID Extended Community 167 A new extended community is used to carry the VPN-ID format. This 168 attribute is transitive across the Autonomous system boundary. The 169 type field of the VPN-ID extended community is of regular type to be 170 assigned by IANA [BGP-COMM]. The remaining 7 bytes hold the VPN-ID 171 value field as per [RFC-2685]. The BGP UPDATE message will carry 172 information for a single VPN. It is the VPN-ID Extended Community, 173 or more precisely route filtering based on the Extended Community 174 that allows one VR to find out about other VRs in the same VPN. 176 4.4 VPN Topology Information 178 A new extended community is used to indicate different VPN topology 179 values. This attribute is transitive across the Autonomous system 180 boundary. The value of the type field for extended type is assigned 181 by IANA. The first two bytes of the value field (of the remaining 6 182 bytes) are reserved. The actual topology values are carried within 183 the remaining four bytes. The following topology values are defined: 185 Value Topology Type 187 1 "Hub" 188 2 "Spoke" 189 3 "Mesh" 191 Arbitrary values can also be used to allow specific topologies to be 192 constructed. 194 In a hub and spoke topology, spoke VRs (i.e., PE having VRs as 195 spokes within the VPN) will advertise their BGP information with VPN 196 topology extended community with value of "2". Spoke VRs will only 197 be allowed to connect to hub VRs and therefore spoke VR-based PEs 198 will just import VPN information from BGP that is set of "1". Hub 199 sites can connect to both hub and spoke sites (i.e., Hub VRs can 200 import VPN topology of both values "1", "2", or "3". In a mesh 201 topology, mesh sites connect to each other, each VR will advertise 202 VPN topology information of "3". 204 Furthermore, in the presence of both hub and spoke and mesh 205 topologies within the same VPN, mesh sites can as well connect to 206 hub sites and vice versa. 208 5. Tunnel Discovery 210 Layer-3 VPNs must be implemented through some form of tunneling 211 mechanism, where the packet formats and/or the addressing used 212 within the VPN can be unrelated to that used to route the tunneled 213 packets across the backbone. There are numerous tunneling mechanisms 214 that can be used by a network based VPN (e.g., IP/IP [RFC-2003], GRE 215 tunnels [RFC-1701], IPSec [RFC-2401], and MPLS tunnels [RFC-3031]). 216 Each of these tunnels allows for opaque transport of frames as 217 packet payload across the backbone, with forwarding disjoint from 218 the address fields of the encapsulated packets. A provider edge 219 router may terminate multiple types of tunnels and forward packets 220 between these tunnels and other network interfaces in different 221 ways. BGP can be used to carry tunnel endpoint addresses between 222 edge routers. 224 The BGP next hop will carry the service provider tunnel endpoint 225 address. As an example, if IPSec is used as tunneling mechanism, the 226 IPSec tunnel remote address will be discovered through BGP, and the 227 actual tunnel establishment is achieved through IPSec signaling 228 protocol. 230 When MPLS tunneling is used, the label carried in the NLRI field is 231 associated with an address of a VR, where the address is carried in 232 the NLRI and is encoded as a VPN-IP address. 234 The auto-discovery mechanism should convey minimum information for 235 the tunnels to be setup. The means of distributing multiplexors must 236 be defined either via some sort of tunnel-protocol-specific signaling 237 mechanism, or via additional information carried by the 238 auto-discovery protocol. That information may or may not be 239 used directly within the specific signaling protocol. On one end of 240 the spectrum, the combination of IP address (such as BGP next hop and 241 IP address carried within the NLRI) and the label and/or VPN-ID 242 provides sufficient information for a PE to setup per VPN tunnels or 243 shared tunnels per set of VPNs. On another end of the spectrum 244 additional specific tunnel related information can be carried within 245 the discovery process if needed. 247 6. Scalability Considerations 249 In this section, we briefly summarize the main characteristics of 250 our model with respect to scalability. 252 Recall that the Service Provider network consists of (a) PE routers, 253 (b) BGP Route Reflectors, (c) P routers (which are neither PE 254 routers nor Route Reflectors), and, in the case of multi-provider 255 VPNs, (d) ASBRs. 257 A PE router, unless it is a Route Reflector should not retain 258 VPN-related information unless it has at least one VPN with an 259 Import Target identical to one of the VPN-related information Route 260 Target attributes. Inbound filtering should be used to cause such 261 information to be discarded. If a new Import Target is later added 262 to one of the PE's VPNs (a "VPN Join" operation), it must then 263 acquire the VPN-related information it may previously have 264 discarded. 266 This can be done using the refresh mechanism described in [BGP- 267 RFSH]. 269 The outbound route filtering mechanism of [BGP-ORF], [BGP-CONS] can 270 also be used to advantage to make the filtering more dynamic. 272 Similarly, if a particular Import Target is no longer present in 273 any of a PE's VPNs (as a result of one or more "VPN Prune" 274 operations), the PE may discard all VPN-related information which, 275 as a result, no longer have any of the PE's VPN's Import Targets as 276 one of their Route Target Attributes. 278 Note that VPN Join and Prune operations are non-disruptive, and do 279 not require any BGP connections to be brought down, as long as the 280 refresh mechanism of [BGP-RFSH] is used. 282 As a result of these distribution rules, no one PE ever needs to 283 maintain all routes for all VPNs; this is an important scalability 284 consideration. 286 Route reflectors can be partitioned among VPNs so that each 287 partition carries routes for only a subset of the VPNs supported by 288 the Service Provider. Thus no single route reflector is required to 289 maintain VPN-related information for all VPNs. 291 For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs 292 need not maintain and distribute VPN-related information at all. 294 P routers do not maintain any VPN-related information. In order 295 to properly forward VPN traffic, the P routers need only maintain 296 routes to the PE routers and the ASBRs. 298 As a result, no single component within the Service Provider network 299 has to maintain all the VPN-related information for all the VPNs. 300 So the total capacity of the network to support increasing numbers 301 of VPNs is not limited by the capacity of any individual component. 303 An important consideration to remember is that one may have any 304 number of INDEPENDENT BGP systems carrying VPN-related information. 305 This is unlike the case of the Internet, where the Internet BGP 306 system must carry all the Internet routes. Thus one significant 307 (but perhaps subtle) distinction between the use of BGP for the 308 Internet routing and the use of BGP for distributing VPN-related 309 information, as described in this document is that the former is not 310 amenable to partition, while the latter is. 312 7. Security Considerations 314 This document describes a BGP-based auto-discovery mechanism which 315 enables a PE router that attaches to a particular VPN to discover 316 the set of other PE routers that attach to the same VPN. Each PE 317 router that is attached to a given VPN uses BGP to advertise that 318 fact. Other PE routers which attach to the same VPN receive these 319 BGP advertisements. This allows that set of PE routers to discover 320 each other. Note that a PE will not always receive these 321 advertisements directly from the remote PEs; the advertisements may 322 be received from "intermediate" BGP speakers. 324 It is of critical importance that a particular PE should not be 325 "discovered" to be attached to a particular VPN unless that PE 326 really is attached to that VPN, and indeed is properly authorized to 327 be attached to that VPN. If any arbitrary node on the Internet 328 could start sending these BGP advertisements, and if those 329 advertisements were able to reach the PE routers, and if the PE 330 routers accepted those advertisements, then anyone could add any 331 site to any VPN. Thus the auto-discovery procedures described here 332 presuppose that a particular PE trusts its BGP peers to be who they 333 appear to be, and further that it can trusts those peers to be 334 properly securing their local attachments. (That is, a PE must 335 trust that its peers are attached to, and are authorized to be 336 attached to, the VPNs to which they claim to be attached.). 338 If a particular remote PE is a BGP peer of the local PE, then the 339 BGP authentication procedures of RFC 2385 can be used to ensure that 340 the remote PE is who it claims to be, i.e., that it is a PE that is 341 trusted. 343 If a particular remote PE is not a BGP peer of the local PE, then 344 the information it is advertising is being distributed to the local 345 PE through a chain of BGP speakers. The local PE must trust that 346 its peers only accept information from peers that they trust in 347 turn, and this trust relation must be transitive. BGP does not 348 provide a way to determine that any particular piece of received 349 information originated from a BGP speaker that was authorized to 350 advertise that particular piece of information. Hence the 351 procedures of this document should be used only in environments 352 where adequate trust relationships exist among the BGP speakers. 354 Some of the VPN schemes which may use the procedures of this 355 document can be made robust to failures of these trust 356 relationships. That is, it may be possible to keep the VPNs secure 357 even if the auto-discovery procedures are not secure. For example, 358 a VPN based on the VR model can use IPsec tunnels for transmitting 359 data and routing control packets between PE routers. An 360 illegitimate PE router which is discovered via BGP will not have the 361 shared secret which makes it possible to set up the IPsec tunnel, 362 and so will not be able to join the VPN. Similarly, [IP-GRE] 363 describes procedures for using IPsec tunnels to secure VPNs based on 364 the [BGP/MPLS-IP-VPN] model. The details for using IPsec to secure 365 a particular sort of VPN depend on that sort of VPN and so are out 366 of scope of the current document. 368 8. IANA Considerations 370 IANA has assigned new extended community for Topology 371 values for VR-based L3VPN solution. 373 IANA has assigned new extended community for 374 carrying VPN-ID format based on RFC2685 format. 376 IANA has assigned new SAFI number for indicating that 377 the NLRI is carrying information for VR for labeled prefixes. 379 SAFI number "140" for indicating that the NLRI is carrying 380 information for VR for non-labeled prefixes. 382 9. Use of BGP Capability Advertisement 384 A BGP speaker that uses VPN information as described in this 385 document with multiprotocol extensions should use the Capability 386 Advertisement procedures [RFC-3392] to determine whether the speaker 387 could use Multiprotocol Extensions with a particular peer. 389 10. Acknowledgement 391 The authors would like to acknowledge Benson Schliesser, and Thomas 392 Narten for the constructive and fruitful comments. 394 11. Normative References 396 [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities 397 Attribute", RFC4360. 399 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 400 Extensions for BGP4", February 1998, RFC 2283. 402 [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in 403 BGP4", January 2000, RFC3107. 405 [BGP/MPLS-IP-VPN] Rosen E., et al, "BGP/MPLS VPNs", RFC4364. 407 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", 408 RFC 2685, September 1999. 410 [RFC-3392] Chandra, R., et al., "Capabilities Advertisement with 411 BGP-4", RFC3392, May 2002. 413 [VPN-VR] Knight, P., Ould-Brahim H., Gleeson, B., "Network based IP 414 VPN Architecture using Virtual Routers", Work in progress. 416 12. Informative References 418 [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 419 Routing Encapsulation (GRE)", RFC 1701, October 1994. 421 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 422 October 1996. 424 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 425 3", RFC 2026, October 1996. 427 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 428 Internet Protocol", RFC 2401, November 1998. 430 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", RFC 2119, March 1997. 433 [IP-GRE] Rosen, E., et al., "Use of PE-PE GRE or IP in BGP/MPLS IP 434 Virtual Private Networks", draft-ietf-l3vpn-gre-ip-2547-03.txt, 435 October 2004, Work in Progress. 437 [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC 2918, 438 September 2000. 440 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 441 Capability for BGP-4", draft-ietf-idr-route-filter-11.txt, 442 December 2004, Work in Progress. 444 [BGP-CONS] Marques, P., et al., "Constrained VPN route distribution" 445 draft-ietf-l3vpn-rt-constrain-01.txt, September 2004, work in 446 progress 448 13. Annex: Auto-Discovery in VR and MPLS-IP-VPN Interworking Scenarios 450 Two interwoking scenarios are considered when the network is using 451 both virtual routers and BGP/MPLS-IP-VPN. The first scenario is a 452 CE-PE relationship between a PE (implementing BGP/MPLS-IP-VPN), and 453 a VR appearing as a CE to the PE. The connection between the VR, and 454 the PE can be either direct connectivity, or through a tunnel (e.g., 455 IPSec). 457 The second scenario is when a PE is implementing both architectures. 458 In this particular case, a single BGP session configured on the 459 service provider network can be used to advertise either BGP/MPLS- 460 IP-VPN VPN information or the virtual router related VPN 461 information. From the VR and the BGP/MPLS-IP-VPN point of view there 462 is complete separation from data path and addressing schemes. 463 However the PE's interfaces are shared between both architectures. 465 A PE implementing only BGP/MPLS-IP-VPN will not import routes from a 466 BGP UPDATE message containing the VPN-ID extended community. On the 467 other hand, a PE implementing the virtual router architecture will 468 not import routes from a BGP UPDATE message containing the route 469 target extended community attribute. 471 The granularity at which the information is either BGP/MPLS-IP-VPN 472 related or VR-related is per BGP UPDATE message. Different SAFI 473 numbers are used to indicate that the message carried in BGP 474 multiprotocol extension attributes is to be handled by the VR or 475 BGP/MPLS-IP-VPN architectures. 477 14. Contributors 479 Bryan Gleeson 480 Nokia 481 313 Fairchild Drive 482 Mountain View CA 94043 USA 483 bryan.gleeson/at/nokia.com 485 Peter Ashwood-Smith 486 Nortel Networks 487 P.O. Box 3511 Station C, 488 Ottawa, ON K1Y 4H7, Canada 489 Phone: +1 613 763 4534 490 Email: petera@nortelnetworks.com 491 Luyuan Fang 492 AT&T 493 200 Laurel Avenue 494 Middletown, NJ 07748 495 Email: Luyuanfang@att.com 496 Phone: +1 (732) 420 1920 498 Jeremy De Clercq 499 Alcatel 500 Francis Wellesplein 1 501 B-2018 Antwerpen, Belgium 502 Phone: +32 3 240 47 52 503 Email: jeremy.de_clercq@alcatel.be 505 Riad Hartani 506 Caspian Networks 507 170 Baytech Drive 508 San Jose, CA 95143 509 Phone: 408 382 5216 510 Email: riad@caspiannetworks.com 512 Tissa Senevirathne 513 Force10 Networks 514 1440 McCarthy Blvd, 515 Milpitas, CA 95035. 516 Phone: 408-965-5103 517 Email: tsenevir@hotmail.com 519 15. Author' Addresses 521 Hamid Ould-Brahim 522 Nortel Networks 523 P O Box 3511 Station C 524 Ottawa, ON K1Y 4H7, Canada 525 Email: hbrahim@nortelnetworks.com 527 Eric C. Rosen 528 Cisco Systems, Inc. 529 1414 Massachusetts Avenue 530 Boxborough, MA 01719 531 E-mail: erosen@cisco.com 533 Yakov Rekhter 534 Juniper Networks 535 1194 N. Mathilda Avenue 536 Sunnyvale, CA 94089 537 Email: yakov@juniper.net 539 Intellectual Property Statement 541 The IETF takes no position regarding the validity or scope 542 of and Intellectual Property Rights or other rights that 543 might be claimed to pertain to the implementation or use of 544 the technology described in this document or the extent to 545 which any license under such rights might or might not be 546 available; nor does it represent that it has made any 547 independent effort to identify any such rights. Information 548 on the procedures with respect to rights in RFC documents 549 can be found in BCP 78 and BCP 79. 551 Copies of IPR disclosures made to the IETF Secretariat and 552 any assurances of licenses to be made available, or the 553 result of an attempt made to obtain a general license or 554 permission for the use of such proprietary rights by 555 implementers or users of this specification can be obtained 556 from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its 560 attention any copyrights, patents or patent applications, or 561 other proprietary rights that may cover technology that may 562 be required to implement this standard. Please address the 563 information to the IETF at ietf-ipr@ietf.org. 565 Copyright Statement 567 Copyright (C) The IETF Trust (2007). 569 This document is subject to the rights, licenses and restrictions 570 contained in BCP 78, and except as set forth therein, the authors 571 retain all their rights. 573 This document and the information contained herein are provided on an 574 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 575 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 576 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 577 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 578 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 579 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.