idnits 2.17.1 draft-ietf-l3vpn-bgpvpn-auto-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([VPN-VR], [RFC2547-bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 127 has weird spacing: '... prefix which...' == 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 2004) is 7309 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 235, but not defined == Unused Reference: 'BGP-MP' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC-3107' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'L2VPN-VKOMP-LASS' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 480, but no explicit reference was found in the text == Unused Reference: 'TLS-TISSA' is defined on line 483, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-COMM' ** 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 2547 (Obsoleted by RFC 4364) ** 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) -- No information found for draft-tsenevir-bgpl2vpn - is the name correct? -- Duplicate reference: RFC2547, mentioned in 'IPSEC-2547', was also mentioned in 'RFC2547-bis'. -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN WG Hamid Ould-Brahim 3 Internet Draft Nortel Networks 4 Expiration Date: October 2004 5 Eric C. Rosen 6 Cisco Systems 8 Yakov Rekhter 9 Juniper Networks 11 (Editors) 13 April 2004 15 Using BGP as an Auto-Discovery 16 Mechanism for Layer-3 and Layer-2 VPNs 18 draft-ietf-l3vpn-bgpvpn-auto-02.txt 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026 [RFC-2026]. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet- Drafts as 33 reference material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider 43 Edge (PE) devices attached to a common VPN must exchange certain 44 information as a prerequisite to establish VPN-specific 45 connectivity. The purpose of this draft is to define a BGP based 46 auto-discovery mechanism for both layer-2 VPN architectures and 47 layer-3 VPNs ([VPN-VR]). This mechanism is based on the approach 48 used by [RFC2547-bis] for distributing VPN routing information 49 within the service provider(s). Each VPN scheme uses the mechanism 50 to automatically discover the information needed by that particular 51 scheme. 53 1. Introduction 55 In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider 56 Edge (PE) devices attached to a common VPN must exchange certain 57 information as a prerequisite to establish VPN-specific 58 connectivity. The purpose of this draft is to define a BGP based 59 auto-discovery mechanism for both layer-2 VPN architectures (i.e., 60 [L2VPN-KOMP], [L2VPN-ROSEN]) and layer-3 VPNs ([VPN-VR]). This 61 mechanism is based on the approach used by [RFC2547-bis] 62 for distributing VPN routing information within the service 63 provider(s). Each VPN scheme uses the mechanism to automatically 64 discover the information needed by that particular scheme. 66 In [RFC2547-bis] based layer-3 VPNs, VPN-specific routes are 67 exchanged, along with the information needed to enable a PE to 68 determine which routes belong to which VRFs. In [VPN-VR], virtual 69 router (VR) addresses must be exchanged, along with the information 70 needed to enable the PEs to determine which VRs are in the same VPN 71 ("membership"), and which of those VRs are to have VPN connectivity 72 ("topology"). Once the VRs are reachable through the tunnels, routes 73 ("reachability") are then exchanged by running existing routing 74 protocols per VPN basis. 76 The BGP-4 multiprotocol extensions are used to carry various 77 information about VPNs for both layer-2 and layer-3 VPN 78 architectures. VPN-specific information associated with the NLRI is 79 encoded either as attributes of the NLRI, or as part of the NLRI 80 itself, or both. 82 2. Provider-Provisioned VPN Reference Model 84 Both the layer-2 and layer-3 vpns architectures are using a network 85 reference model as illustrated in figure 1. 87 PE PE 88 +--------------+ +--------------+ 89 +--------+ | +----------+ | | +----------+ | +--------+ 90 | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | 91 | Sites |--| |Database /| | BGP route | | Database/| |-| sites | 92 +--------+ | |Processing| |<----------->| |Processing| | +--------+ 93 | +----------+ | Distribution| +----------+ | 94 | | | | 95 +--------+ | +----------+ | | +----------+ | +--------+ 96 | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | 97 | Sites |--| |Database /| |-(Backbones)-| | Database/| |-| sites | 98 +--------+ | |Processing| | -------- | |Processing| | +--------+ 99 | +----------+ | | +----------+ | 100 | | | | 101 +--------+ | +----------+ | | +----------+ | +--------+ 102 | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | 103 | Sites |--| |Database /| | | | Database/| |-| sites | 104 +--------+ | |Processing| | | |Processing| | +--------+ 105 | +----------+ | | +----------+ | 106 +--------------+ +--------------+ 108 Figure 1: Network based VPN Reference Model 110 It is assumed that the PEs can use BGP to distribute information to 111 each other. This may be via direct IBGP peering, via direct EBGP 112 peering, via multihop BGP peering, through intermediaries such as 113 Route Reflectors, through a chain of intermediate BGP connections, 114 etc. It is assumed also that the PE knows what architecture it is 115 supporting. 117 3. Carrying VPN information in BGP Multi-Protocol (BGP-MP) Attributes 119 The BGP-4 multiprotocol extensions are used to carry various 120 information about VPNs for both layer-2 and layer-3 VPN 121 architectures. VPN-specific information associated with the NLRI is 122 encoded either as attributes of the NLRI, or as part of the NLRI 123 itself, or both. The addressing information in the NLRI field is 124 ALWAYS within the VPN address space, and therefore MUST be unique 125 within the VPN. The address specified in the BGP next hop attribute, 126 on the other hand, is in the service provider addressing space. In 127 L3VPNs, the NLRI contains an address prefix which is within the 128 VPN address space, and therefore must be unique within the VPN. 130 3.1 Carrying Layer-3 VPN Information in BGP-MP 132 This is done as follows. The NLRI is a VPN-IP address or a labeled 133 VPN-IP address. 135 In the case of the virtual router, the NLRI address prefix is an 136 address of one of the virtual routers configured on the PE. Thus 137 this mechanism allows the virtual routers to discover each other, to 138 set up adjacencies and tunnels to each other, etc. In the case of 139 [RFC2547-bis], the NLRI prefix represents a route to an arbitrary 140 system or set of systems within the VPN. 142 3.2 Carrying Layer-2 VPN Information in BGP-MP 144 The NLRI carries VPN layer-2 addressing information called VPN-L2 145 address. A VPN-L2 address is composed of a quantity beginning with 146 an 8 bytes Route Distinguisher (RD) field and a variable length 147 quantity encoded according to the layer-2 VPN architecture used. 149 Different layer-2 VPN solutions use the same common AFI, but 150 different SAFI. The AFI indicates that the NLRI is carrying a VPN-l2 151 address, while the SAFI indicates solution-specific semantics and 152 syntax of the VPN-l2 address that goes after the RD. The RD must be 153 chosen so as it ensures that each NLRI is globally unique (i.e., the 154 same NLRI does not appear in two VPNs). 156 BGP Route target extended community is used to constrain route 157 distribution between PEs. The BGP Next hop carries the service 158 provider tunnel endpoint address. 160 This draft doesn't preclude the use of additional extended 161 communities for encoding specific l2vpn parameters. 163 4. Interpretation of VPN Information in Layer-3 VPNs 165 4.1 Interpretation of VPN Information in the [RFC2547-bis] Model 167 For details see [RFC2547-bis]. 169 4.2 Interpretation of VPN Information in the [VPN-VR] Model 171 4.2.1 Membership Discovery 173 The VPN-ID format as defined in [RFC-2685] is used to identify a 174 VPN. All virtual routers that are members of a specific VPN share 175 the same VPN-ID. A VPN-ID is carried in the NLRI to make addresses 176 of VRs globally unique. Making these addresses globally unique is 177 necessary if one uses BGP for VRs' auto-discovery. 179 4.2.1.1 Encoding of the VPN-ID in the NLRI 181 For the virtual router model, the VPN-ID is carried within the route 182 distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the 183 first byte of RD type field is used to indicate the existence of the 184 VPN-ID format. A value of 0x80 in the first byte of RD's type field 185 indicates that the RD field is carrying the VPN-ID format. In this 186 case, the type field range 0x8000-0x80ff will be reserved for the 187 virtual router case. 189 4.2.1.2 VPN-ID Extended Community 191 A new extended community is used to carry the VPN-ID format. This 192 attribute is transitive across the Autonomous system boundary. The 193 type field of the VPN-ID extended community is of regular type to be 194 assigned by IANA [BGP-COMM]. The remaining 7 bytes hold the VPN-ID 195 value field as per [RFC-2685]. The BGP UPDATE message will carry 196 information for a single VPN. It is the VPN-ID Extended Community, 197 or more precisely route filtering based on the Extended Community 198 that allows one VR to find out about other VRs in the same VPN. 200 4.2.2 VPN Topology Information 202 A new extended community is used to indicate different VPN topology 203 values. This attribute is transitive across the Autonomous system 204 boundary. The value of the type field for extended type is assigned 205 by IANA. The first two bytes of the value field (of the remaining 6 206 bytes) are reserved. The actual topology values are carried within 207 the remaining four bytes. The following topology values are defined: 209 Value Topology Type 211 1 "Hub" 212 2 "Spoke" 213 3 "Mesh" 215 Arbitrary values can also be used to allow specific topologies to be 216 constructed. VPN connectivity between two VRs within the same VPN is 217 achieved if and only if at least one of them is a hub (the other is 218 a hub or a spoke), or if both VRs are part of a full mesh VPN 219 topology. 221 5. Interpretation of VPN Information in Layer-2 VPNs 223 The interpretation of the VPN information carried in the VPN-L2 224 address is to be specified as part of each L2VPN solution 225 standardized by L2VPN working group. 227 6. Tunnel Discovery 229 Layer-3 VPNs and Layer-2 VPNs must be implemented through some form 230 of tunneling mechanism, where the packet formats and/or the 231 addressing used within the VPN can be unrelated to that used to 232 route the tunneled packets across the backbone. There are numerous 233 tunneling mechanisms that can be used by a network based VPN (e.g., 234 IP/IP [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC-2401], and MPLS 235 tunnels [RFC-3031]). Each of these tunnels allows for opaque 236 transport of frames as packet payload across the backbone, with 237 forwarding disjoint from the address fields of the encapsulated 238 packets. A provider edge router may terminate multiple type of 239 tunnels and forward packets between these tunnels and other network 240 interfaces in different ways. 242 BGP can be used to carry tunnel endpoint addresses between edge 243 routers. For scalability purposes, this draft recommends the use of 244 tunneling mechanisms with demultiplexing capabilities such as IPSec, 245 MPLS, and GRE (with respect to using GRE -the key field, it is no 246 different than just MPLS over GRE, however there is no specification 247 on how to exchange the key field, while there is a specification and 248 implementations on how to exchange the label). Note that IP in IP 249 doesn't have demultiplexing capabilities. 251 The BGP next hop will carry the service provider tunnel endpoint 252 address. As an example, if IPSec is used as tunneling mechanism, the 253 IPSec tunnel remote address will be discovered through BGP, and the 254 actual tunnel establishment is achieved through IPSec signaling 255 protocol. 257 When MPLS tunneling is used, the label carried in the NLRI field is 258 associated with an address of a VR, where the address is carried in 259 the NLRI and is encoded as a VPN-IP address. 261 7. Auto-Discovery and VR-[RFC2547-bis] Interworking Scenarios 263 Two interwoking scenarios are considered when the network is using 264 both virtual routers and [RFC2547-bis]. The first scenario is a CE- 265 PE relationship between a PE (implementing [RFC2547-bis]), and a VR 266 appearing as a CE to the PE. The connection between the VR, and the 267 PE can be either direct connectivity, or through a tunnel (e.g., 268 IPSec). 270 The second scenario is when a PE is implementing both architectures. 271 In this particular case, a single BGP session configured on the 272 service provider network can be used to advertise either [RFC2547- 273 bis] VPN information or the virtual router related VPN information. 274 From the VR and the [RFC2547-bis] point of view there is complete 275 separation from data path and addressing schemes. However the PE's 276 interfaces are shared between both architectures. 278 A PE implementing only [RFC2547-bis] will not import routes from a 279 BGP UPDATE message containing the VPN-ID extended community. On the 280 other hand, a PE implementing the virtual router architecture will 281 not import routes from a BGP UPDATE message containing the route 282 target extended community attribute. 284 The granularity at which the information is either [RFC2547-bis] 285 related or VR-related is per BGP UPDATE message. Different SAFI 286 numbers are used to indicate that the message carried in BGP 287 multiprotocol extension attributes is to be handled by the VR or 288 [RFC2547-bis] architectures. SAFI number of 128 is used for [RFC2547- 289 bis] related format. A value of 129 for the SAFI number is for the 290 virtual router (where the NLRI are carrying a labeled prefixes), and 291 a SAFI value of 140 is for non labeled addresses. 293 8. Scalability Considerations 295 In this section, we briefly summarize the main characteristics of 296 our model with respect to scalability. 298 Recall that the Service Provider network consists of (a) PE routers, 299 (b) BGP Route Reflectors, (c) P routers (which are neither PE 300 routers nor Route Reflectors), and, in the case of multi-provider 301 VPNs, and (d) ASBRs. 303 A PE router, unless it is a Route Reflector should not retain 304 VPN-related information unless it has at least one VPN with an 305 Import Target identical to one of the VPN-related information Route 306 Target attributes. Inbound filtering should be used to cause such 307 information to be discarded. If a new Import Target is later added 308 to one of the PE's VPNs (a "VPN Join" operation), it must then 309 acquire the VPN-related information it may previously have 310 discarded. 312 This can be done using the refresh mechanism described in [BGP- 313 RFSH]. The outbound route filtering mechanism of [BGP-ORF] can also be 314 used to advantage to make the filtering more dynamic. 316 Similarly, if a particular Import Target is no longer present in 317 any of a PE's VPNs (as a result of one or more "VPN Prune" 318 operations), the PE may discard all VPN-related information which, 319 as a result, no longer have any of the PE's VPN's Import Targets as 320 one of their Route Target Attributes. 322 Note that VPN Join and Prune operations are non-disruptive, and do 323 not require any BGP connections to be brought down, as long as the 324 refresh mechanism of [BGP-RFSH] is used. 326 As a result of these distribution rules, no one PE ever needs to 327 maintain all routes for all VPNs; this is an important scalability 328 consideration. 330 Route reflectors can be partitioned among VPNs so that each 331 partition carries routes for only a subset of the VPNs supported by 332 the Service Provider. Thus no single route reflector is required to 333 maintain VPN-related information for all VPNs. 335 For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs 336 need not maintain and distribute VPN-related information at all. 338 P routers do not maintain any VPN-related information. In order 339 to properly forward VPN traffic, the P routers need only maintain 340 routes to the PE routers and the ASBRs. 342 As a result, no single component within the Service Provider network 343 has to maintain all the VPN-related information for all the VPNs. 344 So the total capacity of the network to support increasing numbers 345 of VPNs is not limited by the capacity of any individual component. 347 An important consideration to remember is that one may have any 348 number of INDEPENDENT BGP systems carrying VPN-related information. 349 This is unlike the case of the Internet, where the Internet BGP 350 system must carry all the Internet routes. Thus one significant 351 (but perhaps subtle) distinction between the use of BGP for the 352 Internet routing and the use of BGP for distributing VPN-related 353 information, as described in this document is that the former is not 354 amenable to partition, while the latter is. 356 9. Security Considerations 358 This document describes a BGP-based auto-discovery mechanism which 359 enables a PE router that attaches to a particular VPN to discover 360 the set of other PE routers that attach to the same VPN. Each PE 361 router that is attached to a given VPN uses BGP to advertise that 362 fact. Other PE routers which attach to the same VPN receive these 363 BGP advertisements. This allows that set of PE routers to discover 364 each other. Note that a PE will not always receive these 365 advertisements directly from the remote PEs; the advertisements may 366 be received from "intermediate" BGP speakers. 368 It is of critical importance that a particular PE should not be 369 "discovered" to be attached to a particular VPN unless that PE 370 really is attached to that VPN, and indeed is properly authorized to 371 be attached to that VPN. If any arbitrary node on the Internet 372 could start sending these BGP advertisements, and if those 373 advertisements were able to reach the PE routers, and if the PE 374 routers accepted those advertisements, then anyone could add any 375 site to any VPN. Thus the auto-discovery procedures described here 376 presuppose that a particular PE trusts its BGP peers to be who they 377 appear to be, and further that it can trusts those peers to be 378 properly securing their local attachments. (That is, a PE must 379 trust that its peers are attached to, and are authorized to be 380 attached to, the VPNs to which they claim to be attached.). 382 If a particular remote PE is a BGP peer of the local PE, then the 383 BGP authentication procedures of RFC 2385 can be used to ensure that 384 the remote PE is who it claims to be, i.e., that it is a PE that is 385 trusted. 387 If a particular remote PE is not a BGP peer of the local PE, then 388 the information it is advertising is being distributed to the local 389 PE through a chain of BGP speakers. The local PE must trust that 390 its peers only accept information from peers that they trust in 391 turn, and this trust relation must be transitive. BGP does not 392 provide a way to determine that any particular piece of received 393 information originated from a BGP speaker that was authorized to 394 advertise that particular piece of information. Hence the 395 procedures of this document should be used only in environments 396 where adequate trust relationships exist among the BGP speakers. 398 Some of the VPN schemes which may use the procedures of this 399 document can be made robust to failures of these trust 400 relationships. That is, it may be possible to keep the VPNs secure 401 even if the auto-discovery procedures are not secure. For example, 402 a VPN based on the VR model can use IPsec tunnels for transmitting 403 data and routing control packets between PE routers. An 404 illegitimate PE router which is discovered via BGP will not have the 405 shared secret which makes it possible to set up the IPsec tunnel, 406 and so will not be able to join the VPN. Similarly, [IPSEC-2547] 407 describes procedures for using IPsec tunnels to secure VPNs based on 408 the [RFC2547-bis] model. The details for using IPsec to secure a 409 particular sort of VPN depend on that sort of VPN and so are out of 410 scope of the current document. 412 10. IANA Considerations 414 New AFI value to be assigned by IANA to indicate that the NLRI is 415 carrying VPN-L2 Address as described in section 3.2 to be used by 416 all L2VPN solutions. 418 SAFI number of "128" is used for [RFC2547-bis]. 419 SAFI number "129" for indicating that the NLRI is carrying 420 information for VR-based solution. 421 SAFI number "140" for indicating that the NLRI is carrying 422 information for VR for non labeled prefixes. 423 New Extended Community to be assigned by IANA and used for Topology 424 values for VR-based L3VPN solution see section 4.2.2. 425 New Extended Community to be assigned by IANA for carrying VPN-ID 426 format based on RFC2685 format (see section 4.2.1.2) 428 11. Use of BGP Capability Advertisement 430 A BGP speaker that uses VPN information as described in this 431 document with multiprotocol extensions should use the Capability 432 Advertisement procedures [RFC-3392] to determine whether the speaker 433 could use Multiprotocol Extensions with a particular peer. 435 12. Normative References 437 [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities 438 Attribute", June 2001, work in progress 440 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 441 Extensions for BGP4", February 1998, RFC 2283 443 [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in 444 BGP4", January 2000, RFC3107 446 [RFC2547-bis] Rosen E., et al, "BGP/MPLS VPNs", Work in Progress. 448 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 449 2685, September 1999. 451 [RFC-3392] Chandra, R., et al., "Capabilities Advertisement with 452 BGP-4", RFC3392, May 2002. 454 [VPN-VR] Knight, P., Ould-Brahim H., Gleeson, B., "Network based IP 455 VPN Architecture using Virtual Routers", Work in Progress. 457 13. Informative References 459 [L2VPN-ROSEN] Rosen, E., Radoaca, V., "Provisioning Models and 460 Endpoint Identifiers in L2VPN Signaling", Work in Progress. 462 [L2VPN-KOMP] Kompella, K., et al., "Virtual Private LAN Service", 463 Work in Progress. 465 [L2VPN-VKOMP-LASS] Kompella, V., Lasserre, M., et al., "Transparent 466 VLAN Services over MPLS", Work in Progress. 468 [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 469 Routing Encapsulation (GRE)", RFC 1701, October 1994. 471 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC2003, 472 October 1996. 474 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 475 3", RFC2026, October 1996. 477 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 478 Internet Protocol", RFC2401, November 1998. 480 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", RFC 2119, March 1997. 483 [TLS-TISSA] "BGP/MPLS Layer-2 VPN", draft-tsenevir-bgpl2vpn-01.txt, 484 work in progress, July 2001. 486 [IPSEC-2547] Rosen, E., et al., "Use of PE-PE IPsec in RFC2547 487 VPNs", Work in Progress. 489 [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC2918, 490 September 2000. 492 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 493 Capability for BGP-4", Work in Progress. 495 14. Intellectual Property Rights Notices 497 The IETF takes no position regarding the validity or scope of any 498 intellectual property or other rights that might be claimed to 499 pertain to the implementation or use of the technology described in 500 this document or the extent to which any license under such rights 501 might or might not be available; neither does it represent that it 502 has made any effort to identify any such rights. Information on the 503 IETF's procedures with respect to rights in standards-track and 504 standards-related documentation can be found in BCP-11. Copies of 505 claims of rights made available for publication and any assurances 506 of licenses to be made available, or the result of an attempt made 507 to obtain a general license or permission for the use of such 508 proprietary rights by implementors or users of this specification 509 can be obtained from the IETF Secretariat. 511 15. Contributors 513 Bryan Gleeson 514 Tahoe Networks 515 3052 Orchard Drive 516 San Jose, CA 95134 USA 517 Email: bryan@tahoenetworks.com 519 Peter Ashwood-Smith 520 Nortel Networks 521 P.O. Box 3511 Station C, 522 Ottawa, ON K1Y 4H7, Canada 523 Phone: +1 613 763 4534 524 Email: petera@nortelnetworks.com 526 Luyuan Fang 527 AT&T 528 200 Laurel Avenue 529 Middletown, NJ 07748 530 Email: Luyuanfang@att.com 531 Phone: +1 (732) 420 1920 533 Jeremy De Clercq 534 Alcatel 535 Francis Wellesplein 1 536 B-2018 Antwerpen, Belgium 537 Phone: +32 3 240 47 52 538 Email: jeremy.de_clercq@alcatel.be 540 Riad Hartani 541 Caspian Networks 542 170 Baytech Drive 543 San Jose, CA 95143 544 Phone: 408 382 5216 545 Email: riad@caspiannetworks.com 547 Tissa Senevirathne 548 Force10 Networks 549 1440 McCarthy Blvd, 550 Milpitas, CA 95035. 552 Phone: 408-965-5103 553 Email: tsenevir@hotmail.com 555 16. Authors Information 557 Hamid Ould-Brahim 558 Nortel Networks 559 P O Box 3511 Station C 560 Ottawa, ON K1Y 4H7, Canada 561 Email: hbrahim@nortelnetworks.com 563 Eric C. Rosen 564 Cisco Systems, Inc. 565 1414 Massachusetts Avenue 566 Boxborough, MA 01719 567 E-mail: erosen@cisco.com 569 Yakov Rekhter 570 Juniper Networks 571 1194 N. Mathilda Avenue 572 Sunnyvale, CA 94089 573 Email: yakov@juniper.net 575 Full Copyright Statement 577 Copyright (C) The Internet Society (2004). All Rights Reserved. This 578 document and translations of it may be copied and furnished to 579 others, and derivative works that comment on or otherwise explain it 580 or assist in its implementation may be prepared, copied, published 581 and distributed, in whole or in part, without restriction of any 582 kind, provided that the above copyright notice and this paragraph 583 are included on all such copies and derivative works. However, this 584 document itself may not be modified in any way, such as by removing 585 the copyright notice or references to the Internet Society or other 586 Internet organizations, except as needed for the purpose of 587 developing Internet standards in which case the procedures for 588 copyrights defined in the Internet Standards process must be 589 followed, or as required to translate it into languages other than 590 English. 592 The limited permissions granted above are perpetual and will not be 593 revoked by the Internet Society or its successors or assigns.