idnits 2.17.1 draft-ouldbrahim-bgpgmpls-ovpn-01.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 14) being 114 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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.) -- 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) == Missing Reference: 'TBD' is mentioned on line 555, but not defined == Missing Reference: 'RFC2858' is mentioned on line 450, but not defined ** Obsolete undefined reference: RFC 2858 (Obsoleted by RFC 4760) == Unused Reference: 'Framework' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'OVPN-REQ' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'RFC-2858' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'VPN-BGP' is defined on line 585, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-COMM' -- Possible downref: Non-RFC (?) normative reference: ref. 'Framework' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'LINK-BUNDLING' -- Possible downref: Non-RFC (?) normative reference: ref. 'OVPN-REQ' ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP' Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Provider Provisioned VPN WG Hamid Ould-Brahim 3 Internet Draft Nortel Networks 4 Expiration Date: January 2002 5 Yakov Rekhter 6 Juniper Networks 8 - Editors 10 Don Fedyk 11 Peter Ashwood-Smith 12 Nortel Networks 14 Eric C. Rosen 15 Cisco Systems 17 Eric Mannie 18 Ebone 20 Luyuan Fang 21 AT&T 23 John Drake 24 Calient Networks 26 Yong Xue 27 UUNET/WorldCom 29 Riad Hartani 30 Caspian Networks 32 July 2001 34 BGP/GMPLS Optical VPNs 36 draft-ouldbrahim-bgpgmpls-ovpn-01.txt 38 Status of this Memo 40 This document is an Internet-Draft and is in full conformance 41 with all provisions of Section 10 of RFC2026 [RFC-2026], except 42 that the right to produce derivative works is not granted. 44 Internet-Drafts are working documents of the Internet 45 Engineering Task Force (IETF), its areas, and its working 46 groups. Note that other groups may also distribute working 47 documents as Internet-Drafts. 49 Ould-Brahim, et. al 1 50 draft-ouldbrahim-bgpgmpls-ovpn-01.txt July 2001 52 Internet-Drafts are draft documents valid for a maximum of six 53 months and may be updated, replaced, or obsoleted by other 54 documents at any time. It is inappropriate to use Internet- 55 Drafts as reference material or to cite them other than as 56 "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt 60 The list of Internet-Draft Shadow Directories can be accessed 61 at http://www.ietf.org/shadow.html. 63 Abstract 65 Consider a service provider network that offers Optical Virtual 66 Private Network (OVPN) service. An important goal in the OVPN 67 service is the ability to support what is known as "single end 68 provisioning", where addition of a new port to a given OVPN 69 would involve configuration/provisioning changes only on the 70 devices connected to that port. Another important goal in the 71 OVPN service is the ability to establish/terminate an optical 72 connection between a pair of (existing) ports within an OVPN 73 without involving configuration/provisioning changes in any of 74 the provider devices. 76 In this document we describe a set of mechanisms that 77 accomplishes these goals. 79 Obsoletes draft-fedyk-bgpvpon-auto-00.txt 81 1. Sub-IP Summary ID 83 This ID targets the PPVPN working group as it deals with a VPN 84 solution similar to port-based VPNs. It describes an approach 85 to allow service providers to offer optical VPN service. A pair 86 of client devices (a router, a SONET/SDH cross-connect, or an 87 Ethernet switch) could be connected through the service 88 provider network via an optical connection. It is this optical 89 connection that forms the basic unit of service that the 90 service provider network offers. 92 RELATED DOCUMENTS 94 draft-ouldbrahim-ovpn-requirements-00.txt. Others can be found 95 in the "references" section. 97 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 99 Fits the PPVPN box. 101 WHY IS IT TARGETED AT THIS WG 102 This WG is looking at port based VPN over an IP/MPLS 103 infrastructure. This work is exactly a port-based optical VPN 104 using IP related building blocks. 106 JUSTIFICATION 108 The current PPVPN chairs have already discussed this work and 109 are considering expanding the PPVPN charter to include OVPN as 110 part of PPVPN mandate. 112 2. Optical VPN Reference Model 114 Consider a service provider network that consists of devices 115 such as Optical Network Element (ONE) which may be Optical 116 Cross Connects (OXCs). We partition these devices into P 117 (provider) ONEs and PE (provider edge) ONEs. The P ONEs are 118 connected only to the ONEs within the provider's network. The 119 PE ONEs are connected to the ONEs within the provider network, 120 as well as to the devices outside of the provider network. 121 We'll refer to such other devices as Client Edge Devices (CEs). 122 An example of a CE would be a router, or a SONET/SDH cross- 123 connect, or an Ethernet switch. 125 +---+ +---+ 126 | P |....| P | 127 +---+ +---+ 128 PE / \ PE 129 +-----+ +-----+ +--+ 130 | | | |----| | 131 +--+ | | | | |CE| 132 |CE|----+-----+ | |----| | 133 +--+\ | | | +--+ 134 \ +-----+ | | 135 \ | | | | +--+ 136 \| | | |----|CE| 137 +-----+ +-----+ +--+ 138 \ / 139 +---+ +---+ 140 | P |....| P | 141 +---+ +---+ 143 Figure 1 Optical VPN Reference Model 145 A CE is connected to a PE ONE via one or more links, where each 146 link may consists of one or more channels or sub-channels 147 (e.g., wavelength or wavelength and timeslot respectively). 148 For purpose of this discussion we assume that all the channels 149 within a given link have shared similar characteristics (e.g., 150 bandwidth, encoding, etc_), and can be interchanged from the 151 CEs point of view. Channels on different links of a CE need not 152 have the same characteristics. 154 There may be more than one link between a given CE PE ONE pair. 155 A CE may be connected to more than one PE ONE (with at least 156 one port per each PE ONE). And, of course, a PE ONE may have 157 more than one CE connected to it. 159 If a CE is connected to a PE ONE via multiple links and all 160 these links belong to the same VPN, then for the purpose of 161 OVPN these links could be treated as a single link using the 162 link bundling constructs [LINK-BUNDLING]. 164 In general a link may have only data bearing channels, or only 165 control bearing channels, or both. For the purpose of this 166 discussion we assume that for a given CE - PE ONE pair at least 167 one of the links between them has at least one control bearing 168 channel and at least one data bearing channel. 170 A link has two end-points - one on CE and one on PE ONE. In the 171 context of this document we'll refer to the former as "CE 172 port", and to the latter as "PE ONE port". From the above it 173 follows that a CE is connected to a PE ONE via one or more 174 ports, where each port may consists of one or more channels or 175 sub-channels (e.g., wavelength or wavelength and timeslot 176 respectively), and all the channels within a given port have 177 shared similar characteristics (e.g., bandwidth, encoding, 178 etc_), and can be interchanged from the CEs point of view. 179 Channels on different ports of a CE need not have the same 180 characteristics. 182 Note that in the context of this document both ports and links 183 are logical constructs, and are used to represent grouping of 184 physical resources per OVPN basis that are used to connect a CE 185 to a PE ONE. At any given point in time, a given port on a PE 186 ONE is associated with at most one OVPN. This association is 187 established and maintained by the service provider provisioning 188 system. 190 A pair of CEs could be connected through the service provider 191 network via an optical connection. It is precisely this optical 192 connection that forms the basic unit of service that the 193 service provider network offers. If a port by which a CE is 194 connected to a PE ONE consists of multiple channels (e.g., 195 multiple wavelengths), the CE could establish optical 196 connection to multiple other CEs over this single port. 198 An important goal in the OVPN service is the ability to support 199 what is known as "single end provisioning", where addition of a 200 new port to a given OVPN would involve 201 configuration/provisioning changes only on the PE ONE that has 202 this port and on the CE that is connected to the PE ONE via 203 this port. Another important goal in the OVPN service is the 204 ability to establish/terminate an optical connection between a 205 pair of (existing) ports within an OVPN without involving 206 configuration/provisioning changes in any of the provider's 207 ONEs. The mechanisms outlined in this document aim at achieving 208 these goals. Specifically, as part of the Optical VPN service 209 offering, these mechanisms (1) enable the service provider to 210 restrict the set of ports that a given port could be connected 211 to, (2) enable the service provider to provide a CE with the 212 information about the ports that the CE could be connected, (3) 213 enable a CE to establish the actual connections to a subset of 214 ports provided by (2). Finally, the mechanisms allow different 215 OVPN topologies to be supported ranging from hub-and-spoke to 216 complete mesh. 218 The service provider does not initiate the creation of an 219 optical circuit between a pair of PE ONE ports. This is done 220 rather by the CEs, which attach to the ports. However, the SP, 221 by using the mechanisms outlined in this document, restricts 222 the set of other PE ONE ports which may be the remote endpoints 223 of optical circuits that have the given port as the local 224 endpoint. Subject to these restrictions, the CE-to-CE 225 connectivity is under the control of the CEs themselves. In 226 other words, SP allows an OVPN to have a certain set of 227 topologies, and CE-initiated signaling is used to choose a 228 particular topology from that set. 230 Since this model involves minimal provisioning changes when 231 changing the connectivity among the ports within a OVPN on the 232 providers network and the OVPNs themselves are controlled by 233 the CEs, the tariff structure may be on a port basis or 234 alternatively tariffs could be triggered on the basis of 235 signaling mechanisms. 237 Finally, it is assumed that CE-to-CE optical connectivity is 238 based on GMPLS [GMPLS]. 240 3. Overview of operations 242 This document assumes that within a given OVPN each port on a 243 CE that connects the CE to a PE ONE has an identifier that is 244 unique within that OVPN (but need not be unique across several 245 OVPNs). One way to accomplish this is to assign each port an IP 246 address that is unique within a given OVPN, and use this 247 address as a port identifier. Another way to accomplish this is 248 to assigned each port an interface index that is unique within 249 a given CE, assign each CE an IP address that is unique within 250 a given OVPN, and then use a tuple as a port identifier. 253 This document assumes that within a service provider network, 254 each port on a PE ONE has an identifier that is unique within 255 that network. One way to accomplish this would be to assign 256 each port on a PE ONE an interface index, assign each PE ONE an 257 IP address that is unique within the service provider network 258 (in the case of multi-provider operations, the address has to 259 be unique across all the providers involved), and then use a 260 tuple as a port identifier 261 within the provider network. 263 PE ONE PE ONE 264 +---------+ +--------------+ 265 +--------+ | +------+| | +----------+ | +--------+ 266 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 267 | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | 268 +--------+ | | ||<----------->| | | | +--------+ 269 | +------+| Distribution| +----------+ | 270 | | | | 271 +--------+ | +------+| -------- | +----------+ | +--------+ 272 | VPN-B | | |VPN-B || ( Optical ) | | VPN-B | | | VPN-B | 273 | CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 | 274 +--------+ | | || (Backbone ) | | | | +--------+ 275 | +------+| --------- | +----------+ | 276 | | | | 277 +--------+ | +-----+ | | +----------+ | +--------+ 278 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 279 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 280 +--------+ | | | | | | | | +--------+ 281 | +-----+ | | +----------+ | 282 +---------+ +--------------+ 284 Figure 2 OVPN Components 286 As a result each link connecting the CE to the PE ONE is 287 associated with a CE port that has a unique identifier within a 288 given OVPN, and with a PE port that has a unique identifier 289 within the service provider network. We'll refer to the former 290 as the customer port identifier (CPI), and to the latter as the 291 provider port identifier (PPI). 293 This document assumes that in addition to PPI, each port on PE 294 ONE has also an identifier that is unique within the OVPN of 295 the CE connected to that port. One way to accomplish this is 296 to assign each port an IP address that is unique within a given 297 OVPN, and use this address as a port identifier. Another way to 298 accomplish this is to assigned each port an interface index 299 that is unique within a given PE ONE, assign each PE ONE an IP 300 address that is unique within a given OVPN (but need not be 301 unique within the service provider network), and then use a 302 tuple acts as a port 303 identifier. We'll refer to such port identifier as VPN-PPI. 304 Note that PE ONE IP address used for VPN-PPI need not be the 305 same as PE ONE IP address used for PPI, and moreover, a given 306 PE ONE may have multiple PE ONE addresses used for VPN-PPI, one 307 per OVPN. Subject to the constraints outlined in the next 308 paragraph, PPI could be used as VPN-PPI. 310 For a given link connecting a CE to a PE ONE, if CPI is an IP 311 address, then VPN-PPI has to be an IP address as well. And if 312 CPI is an , then VPN-PPI has 313 to be an . However, for a 314 given port on PE ONE, whether VPN-PPI of that port is an IP 315 address or an is 316 independent of whether PPI of that port is an IP address or an 317 . 319 Each PE ONE maintains a Port Information Table (PIT) for each 320 OVPN that has at least one port on that PE ONE. A PIT contains 321 a list of tuples for all the ports within its OVPN. 323 A PIT on a given PE ONE is populated from two sources: the 324 information related to the CEs (optionally received from the 325 CEs) attached to the ports on that PE ONEs, and the information 326 received from other PE ONEs. We'll refer to the former as the 327 "local" information, and to the latter as the "remote" 328 information. 330 The local information is propagated to other PE ONEs by using 331 BGP with multi-protocol extensions. To restrict the flow of 332 this information to only the PITs within a given OVPN, we use 333 BGP route filtering based on the Route Target Extended 334 Community [BGP-COMM], as follows. 336 Each PIT on a PE ONE is configured with one or more Route 337 Target Communities, called "export Route Targets", that are 338 used for tagging the local information when it is exported into 339 provider's BGP. The granularity of such tagging could be as 340 fine as a single pair. In addition, each PIT on a PE 341 ONE is configured with one or more Route Target Communities, 342 called "import Route Targets", that restrict the set of routes 343 that could be imported from provider's BGP into the PIT to only 344 the routes that have at least of these Communities. 346 When a service provider adds a new OVPN port to a particular PE 347 ONE, this port is associated at provisioning time with a PIT on 348 that PE ONE, and this PIT is associated (again at provisioning 349 time) with that OVPN. 351 Once a port is configured on the PE ONE, the CE that is 352 attached via this port to the PE ONE MAY pass to the PE ONE the 353 CPI information of that port. This document assumes that this 354 is accomplished by using BGP (however, the document doesn't 355 preclude the use of other mechanisms). 357 This information, combined with the PPI information available 358 to the PE ONE, enables the PE ONE to create a tuple 359 for such port, and then use this tuple to populate the PIT of 360 the OVPN associated with that port. 362 In order to establish an optical connection, a CE needs to 363 identify all other CEs in the CE's OVPN it wants to connect to. 364 A CE may already have obtained the CE list through 365 configuration or through some other schemes (such schemes are 366 outside the scope of this draft). 368 It is also desirable, that the service provider, as a value 369 added service, may provide a CE with a list of all other CEs in 370 the CE's OVPN. This is accomplished by passing the information 371 stored in the PE ONE PITs to the attached CE. This document 372 assumes that this is accomplished by using BGP Multi-protocol 373 extensions (however this draft doesn't preclude other 374 mechanisms to be used). Although optional, this draft 375 recommends the PE to signal to the attached CEs the remote CPIs 376 it learnt from the remote CEs part of the same OVPN. A CE may 377 decide to initiate an optical connection request to a remote CE 378 only when it learn the CPI of the remote CE from the PE. This 379 has the benefit to avoid rejecting connection request while the 380 PE is populating the PITs. 382 Once a CE obtains the information about the CPIs of other ports 383 within the same OVPN, which we'll refer to as "target ports", 384 the CE uses a (subset of) GMPLS signaling to request the 385 provider network to establish an optical connection to a target 386 port. Note that this draft assumes that GMPLS is only used to 387 establish optical connections between client devices. 389 The request originated by the CE contains the CPI of the port 390 on the CE that CE wants to use for the optical connection, and 391 the CPI of the target port. When the PE ONE attached to the CE 392 that originated the request receives the request, the PE ONE 393 identifies the appropriate PIT, and then uses the information 394 in that PIT to find out the PPI associated with the CPI of the 395 target port carried in the request. The PPI should be 396 sufficient for the PE ONE to establish an optical connection. 397 Ultimately the request reaches the CE associated with the 398 target CPI (note that the request still carries the CPI of the 399 CE that originated the request). If the CE associated with the 400 target CPI accepts the request, the optical connection is 401 established. 403 Note that a CE need not establish an optical connection to 404 every target port that CE knows about - it is a local to the CE 405 matter to select a subset of target ports to which the CE will 406 try to establish optical connections. 408 A port, in addition to its CPI and PPI may also have other 409 information associated with it that describes characteristics 410 of the channels within that port, such as encoding supported by 411 the channels, bandwidth of a channel, total unreserved 412 bandwidth within the port, etc. This information could be 413 further augmented with the information about certain 414 capabilities of the Service Provider network (e.g., support 415 RSOH DCC transparency, arbitrary concatenation, etc_). This 416 information is used to ensure that ports at each end of an 417 optical connection have compatible characteristics, and that 418 there are sufficient unallocated resources to establish an 419 optical connection. Distribution of this information (including 420 the mechanisms for distributing this information) is identical 421 to the distribution of the information. Distributing 422 changes to this information due to establishing/terminating of 423 optical connections is identical to the distribution of the 424 information, except that thresholds should be used 425 to contain the volume of control traffic caused by such 426 distribution. 428 It may happen that for a given pair of ports within an OVPN, 429 each of the CEs connected to these ports would concurrently try 430 to establish an optical connection to the other CE. If having a 431 pair of optical connections between a pair of ports is viewed 432 as undesirable, the a way to resolve this is have CE with the 433 lower value of CPI is required to terminate the optical 434 connection originated by the CE. This option could be 435 controlled by configuration on the CE devices. 437 4. Encoding 439 This section specifies encoding of various information defined 440 in this document. 442 4.1 Encoding of CPI and channel characteristics in GMPLS Signaling 444 [TBD] 446 4.2 Encoding of CPI, PPI, and channel characteristics in BGP 448 4.2.1 Encoding of CPI and PPI information in BGP 449 The mapping is carried using the Multiprotocol 450 Extensions BGP [RFC2858]. [RFC2858] defines the format of two 451 BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be 452 used to announce and withdraw the announcement of reachability 453 information. We introduce a new address family identifier (AFI) 454 for OVPN (to be assigned by the IANA), a new subsequent address 455 family identifier (to be assigned by the IANA), and also a new 456 NLRI format for carrying the CPI and PPI information. 458 One or more tuples could be carried in the above 459 mentioned BGP attributes. 461 The format of encoding a single tuple is shown in 462 Figure 3 below: 464 +---------------------------------------+ 465 | Length (1 octet) | 466 +---------------------------------------+ 467 | PPI AFI (2 octets) | 468 +---------------------------------------+ 469 | PPI Length (1 octet) | 470 +---------------------------------------+ 471 | PPI (variable) | 472 +---------------------------------------+ 473 | CPI AFI (2 octets) | 474 +---------------------------------------+ 475 | CPI (length) | 476 +---------------------------------------+ 477 | CPI (variable) | 478 +---------------------------------------+ 480 Figure 3: NLRI BGP encoding 482 The use and meaning of these fields are as follows: 484 Length: 486 A one octet field whose value indicates the length of 487 the 488 Information tuple in octets. 490 PPI AFI: 492 A two octets field whose value indicates address 493 family identifier of PPI 495 PPI Length: 497 A one octet field whose value indicates the length of 498 of the PPI field 500 PPI field: 502 A variable length field that contains the value of 503 the PPI (either an address or tuple 506 CPI AFI field: 508 A two octets field whose value indicates address 509 family of the CPI. 511 CPI Length: 513 A once octet field whose value indicates the 514 length of the CPI field. 516 CPI (variable): 518 A variable length field that contains the CPI 519 value (either an address or 520 tuple. 522 4.2.2 Encoding channel characteristics in BGP 524 [TBD] 526 5. Other issues 528 While the above text assumes that the service provider network 529 consists of ONEs and ports are connected via optical 530 connections, the mechanisms described in this document could be 531 applied in an environment, where the service provider network 532 consists of SONET/SDH cross connects and CE ports being either 533 SONET/SDH or Ethernet. 535 Since the protocol used to populate a PIT with remote 536 information is BGP, since BGP works across multiple routing 537 domains, and since GMPLS signaling isn't restricted to a single 538 routing domain, it follows that the mechanisms described in 539 this document could support an environment that consists of 540 multiple routing domains. 542 The mechanisms described in this document allow for a wide 543 range of choices with respect to addresses used for CPI, PPI, 544 and VPN-PPI. For example, one could use either IPv4 addresses, 545 or IPv6 addresses, or NSAPs. Different OVPN customers of a 546 given service provider may use different types of addresses. 547 Moreover, different OVPNs attaching to the same PE ONE may use 548 different addressing schemes. The types of addresses used for 549 PPIs within a given service provider network are independent 550 from the type of addresses used for CPI and VPN-PPI by the OVPN 551 customers of that provider. 553 6. Security Considerations 555 [TBD] 557 7. References 559 [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities 560 Attribute", February 2000, work in progress. 562 [Framework] Rajagopalan, B. et al., "IP over Optical Networks: 563 A Framework ", November 2000, work in progress. 565 [GMPLS] Ashwood-Smith, P., Berger, L. et al., "Generalized MPLS 566 -Signaling Functional Description", November 2000, work in 567 progress. 569 [LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link 570 Bundling in MPLS Traffic Engineering", work in progress. 572 [OVPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service 573 Requirements for Optical Virtual Private Networks", work in 574 progress, July 2001. 576 [RFC-2858] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 577 Extensions for BGP4", RFC2858, June 2000. 579 [RFC-2026] Bradner, S., "The Internet Standards Process -- 580 Revision 3", RFC2026, October 1996. 582 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", RFC 2119, March 1997. 585 [VPN-BGP] Ould-Brahim H., Gleeson B., Ashwood-Smith P., Rosen 586 E., Rekhter Y., Declerq J., Fang L., Hartani R., "Using BGP 587 as an Auto-Discovery Mechanism for Network-based VPNs", work 588 in progress, July 2001. 590 8. Acknowledgments. 592 The authors would like to thank Osama Aboul-Magd, Dimitri 593 Papadimitriou, Penno Reinaldo, Erning Ye, and Bryan Gleeson for 594 reviewing the draft and providing comments. 596 9. Author's Addresses 598 Hamid Ould-Brahim 599 Nortel Networks 600 P O Box 3511 Station C 601 Ottawa ON K1Y 4H7 Canada 602 Phone: +1 (613) 765 3418 603 Email: hbrahim@nortelnetworks.com 605 Don Fedyk 606 Nortel Networks 607 600 Technology Park 608 Billerica, Massachusetts 609 01821 U.S.A. 610 Phone: +1 (978) 288 3041 611 Email: dwfedyk@nortelnetworks.com 613 Peter Ashwood-Smith 614 Nortel Networks 615 P.O. Box 3511 Station C, 616 Ottawa, ON K1Y 4H7, Canada 617 Phone: +1 613 763 4534 618 Email: petera@nortelnetworks.com 620 Yakov Rekhter 621 Juniper Networks 622 1194 N. Mathilda Avenue 623 Sunnyvale, CA 94089 624 Email: yakov@juniper.net 626 Eric C. Rosen 627 Cisco Systems, Inc. 628 250 Apollo drive 629 Chelmsford, MA, 01824 630 E-mail: erosen@cisco.com 632 Eric Mannie 633 Ebone (GTS) 634 Terhulpsesteenweg 6A 635 1560 Hoeilaart 636 Belgium 637 Phone: +32 2 658 56 52 638 Email: eric.mannie@gts.com 640 Luyuan Fang 641 AT&T 642 200 Laurel Avenue 643 Middletown, NJ 07748 644 Email: Luyuanfang@att.com 645 Phone: +1 (732) 420 1920 647 Ould-Brahim, et. al 13 648 draft-ouldbrahim-bgpgmpls-ovpn-01.txt July 2001 650 John Drake 651 Calient Networks 652 5853 Rue Ferrari 653 San Jose, CA 95138 654 USA 655 Phone: +1 408 972 3720 656 Email: jdrake@calient.net 658 Yong Xue 659 UUNET/WorldCom 660 Ashburn, Virginia 661 (703)-886-5358 662 yxue@uu.net 664 Riad Hartani 665 Caspian Networks 666 170 Baytech Drive 667 San Jose, CA 95143 668 Phone: 408 382 5216 669 Email: riad@caspiannetworks.com 671 Full Copyright Statement 673 Copyright (C) The Internet Society (2000). All Rights Reserved. 674 This document and translations of it may be copied and 675 furnished to others, and derivative works that comment on or 676 otherwise explain it or assist in its implementation may be 677 prepared, copied, published and distributed, in whole or in 678 part, without restriction of any kind, provided that the above 679 copyright notice and this paragraph are included on all such 680 copies and derivative works. However, this document itself may 681 not be modified in any way, such as by removing the copyright 682 notice or references to the Internet Society or other Internet 683 organizations, except as needed for the purpose of developing 684 Internet standards in which case the procedures for copyrights 685 defined in the Internet Standards process must be followed, or 686 as required to translate it into languages other than English. 688 The limited permissions granted above are perpetual and will 689 not be revoked by the Internet Society or its successors or 690 assigns.