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