idnits 2.17.1 draft-parent-obgp-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: ---------------------------------------------------------------------------- ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 644 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 326 has weird spacing: '...ext-Hop exte...' == Line 337 has weird spacing: '...ext-Hop exte...' == Line 398 has weird spacing: '...ext-Hop exte...' == Line 422 has weird spacing: '...ext-Hop exte...' == Line 429 has weird spacing: '...ext-Hop exte...' == (2 more instances...) -- 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 (March 2001) is 8442 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: 'BGP' is mentioned on line 52, but not defined == Unused Reference: 'OBGP' is defined on line 544, but no explicit reference was found in the text == Unused Reference: 'BGP4' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'BGPVPN' is defined on line 562, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'OBGP' == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-12 == Outdated reference: A later version (-09) exists of draft-ramachandra-bgp-ext-communities-08 -- Possible downref: Normative reference to a draft: ref. 'BGP-COMM' ** Obsolete normative reference: RFC 2858 (ref. 'BGP-MP') (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 2842 (ref. 'BGP-CAP') (Obsoleted by RFC 3392) -- Possible downref: Normative reference to a draft: ref. 'OROUTING' == Outdated reference: A later version (-03) exists of draft-ouldbrahim-bgpvpn-auto-00 -- Possible downref: Normative reference to a draft: ref. 'BGPVPN' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-00 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'ISIS-TE') -- No information found for draft-ietf-ospf-gmpls-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OSPF-TE' Summary: 7 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Marc Blanchet 3 Internet Draft Florent Parent 4 Expiration: August 2001 Viagenie 5 Bill St-Arnaud 6 Canarie 8 March 2001 10 Optical BGP (OBGP): InterAS lightpath provisioning 11 draft-parent-obgp-01.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as _work in progress._ 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This work investigates inter-AS lightpath provisioning using BGP. BGP 37 is currently deployed across the different autonomous systems on the 38 Internet, so investigating how a BGP approach to provision lightpaths 39 across autonomous systems is of great interest. This work proposes 40 extensions to BGP to this end. 42 1. Introduction 44 Much of the current work in IP optical focuses on using interior 45 gateway protocols such as ISIS and OSPF with TE extensions for routing 46 and GMPLS for signaling [ISIS-TE], [OSPF-TE], [CRLDP], [RSVP-TE]. 48 This draft considers optical lightpath provisioning at the inter-AS 49 scope. Other protocols may be use inside the autonomous system to 50 control the actual optical cross-connect (OXC). 52 BGP [BGP] is currently deployed across the different autonomous 53 systems on the Internet, so investigating how a BGP approach to 54 provision lightpaths across autonomous systems is of great interest. 56 The goal of this work is to propose a BGP approach to lightpath 57 provisioning. 59 2. Scope 61 The traditional networks are carrier based and the carrier manages the 62 customer transit connectivity. Customers are now acquiring fibre, 63 optical switch ports and wavelengths and this changes the traditionnal 64 model of network peering. 66 Customers in sites can now own their own wavelengths, and eventually 67 optical switch ports. Providers can deploy an optical infrastructure 68 and sell wavelengths and optical switch ports to their 69 customers. Customers now have multiple wavelengths and optical ports 70 from one or many providers. 72 This ownership of wavelengths and optical ports now brings new 73 operational requirements where customers at the edge need to control a 74 subset of lightpaths within another network's wavelength cloud 75 (provider) so that they can manage their own lightpath routing within 76 that cloud. 78 This new model allows distributed Internet Exchange facilities using 79 the exchange and trading of lightpaths between networks to minimize 80 the need for hierarchical network architectures to interconnect 81 peering networks. As an example, CA*net4 optical network in Canada 82 could provide lightpath transit to Renater/France and Wide/Japan 83 networks. 85 The scenario that is considered in this document is where autonomous 86 sites own their wavelengths and optical switch ports. End customer 87 have "virtual" control over its optical switches/ports/wavelengths. 89 The document covers inter-AS provisioning using BGP. Inside an 90 autonomous system, other protocols can be used, such as OSPF or ISIS 91 with TE extensions for routing and GMPLS for signaling. 93 3. Protocol operation 95 It is assumed that a BGP peering is already established between 96 participating sites, either using a non-optical path or a 97 pre-configured optical path between sites. This BGP peering will be 98 used in the following description. 100 The (egress) OXC are BGP speakers. The OXC and the BGP router are 101 closely tied together in the sense that information received from BGP 102 will be used to establish optical cross-connects inside the OXC. 104 The sites are eBGP peers. This document doesn't specify any intra-AS 105 routing and signaling protocols for lightpath provisioning, although 106 interaction between the inter-AS and intra-AS protocols will need to 107 be defined. 109 The protocol proposes two phases. 111 The first phase is the lightpath reachability phase. During this 112 phase, sites advertise through BGP the availability of the optical 113 lightpath to their site. These announcements will contain information 114 on the OXC and the available lightpath through that OXC. The 115 information will be encoded using multiprotocol BGP extensions and 116 extended community. 118 This first phase will allow sites to build up a "lightpath RIB" that 119 will be used to determine if a lightpath is feasible across a number 120 of OXC in different sites. 122 The second phase is the lightpath establishement. This phase uses the 123 information received from the lightpath reachability phase and then 124 uses a BGP update message to communicate the lightpath establishement 125 to the OXC sites on the path. The information will be encoded using 126 multiprotocol BGP extensions and extended community. 128 4. Encoding Optical Lightpath information in BGP 130 The BGP Multiprotocol extensions [BGP-MP] allow BGP to carry routes 131 from multiple "address families". 133 This document proposes to use MP-BGP extensions to encode the NLRI 134 such that the necessary optical and routing information can be 135 propagated in BGP. Figure 1 presents the MP_REACH_NLRI attribute 136 format. 138 +----------------------------------------------------+ 139 | Address Family Identifier (2 octets) | 140 +----------------------------------------------------+ 141 | Subsequent Address Family Identifier (1 octet) | 142 +----------------------------------------------------+ 143 | Length of Next Hop Network Address (1 octet) | 144 +----------------------------------------------------+ 145 | Network Address of Next Hop (variable) | 146 +----------------------------------------------------+ 147 | Number of SNPAs (1 octet) | 148 +----------------------------------------------------+ 149 | SNPA | 150 ~ ~ 151 +----------------------------------------------------+ 152 | Network Layer Reachability Information (variable) | 153 +----------------------------------------------------+ 154 Figure 1. 156 The address family identifier (AFI) represents the type of network 157 layer protocol used in the protocol. Since IP is used, the AFI value 158 is either 1 for IPv4 addresses or 2 for IPv6 addresses. 160 The subsequent address family identifier (SAFI) indicates what type of 161 information is carried in the NRLI. The NLRI will encode the necessary 162 information about the optical cross-connect (OXC) endpoint and the 163 reachable networks through that OXC. This document proposes using a 164 SAFI value of 131, which is part of the private use range. If this 165 proposal goes to standard track RFC, then an IANA assigned number 166 should be defined as defined in [BGP-MP]. 168 The necessary information to be carried inside BGP are: 169 - the IP address of the site egress OXC 170 - The reachable IP prefixes 171 - A lightpath identifier 173 The following sections will describe each of those items. 175 4.1 IP address of the local OXC and reachable IP prefixes 177 The update message includes the IP address of the local OXC. This 178 allows a site to determine if a lightpath has already been established 179 to the destination OXC [OROUTING]. The IP address of the local OXC is 180 encoded in the NLRI as showned in figure 2. 182 The reachable IP prefixes are used by remote sites to determine what 183 networks can be reached through the announced lightpath 184 availability. The reachable IP prefixes are carried in the NLRI, also 185 showned in figure 2. 187 +----------------------------------------------+ 188 | Length of the NLRI (2 octets) | 189 +----------------------------------------------+ 190 | Length of OXC IP address (2 octets) | 191 +----------------------------------------------+ 192 | OXC IP address (variable) | 193 +----------------------------------------------+ 194 | Length of Reachability Entries (2 octets) | 195 +----------------------------------------------+ 196 | First Reachability Entry (variable) | 197 +----------------------------------------------+ 198 | Second Reachability Entry (variable) | 199 +----------------------------------------------+ 200 ..... 201 +----------------------------------------------+ 202 | N-th Reachability Entry (variable) | 203 +----------------------------------------------+ 204 Figure 2: NLRI encoding 206 Length of the NLRI (2 octets): 207 Total length of the NLRI 209 Length of OXC IP address (2 octets): 210 Length of the OXC IP address 212 OXC IP address (variable): 213 IP address of the OXC 215 Length of Reachability Entries (2 octets): 216 Length of a reachability entry 218 Reachability Entry (variable): 219 Variable length field that lists the feasible routes associated with 220 this update. This is encoded as an NLRI tuple of the form 221 as described in [BGP-MP]. 223 4.2 Lightpath identifier attribute 225 A site can have one or many lightpaths available to its neighbor OXC. 226 The site may decide to send one message that aggregates all its 227 available lightpaths in one BGP message, or the site may make 228 available some lightpaths for special usage and others for general 229 use. 231 The lightpath reachability update message identifies the lightpath or 232 lightpath bundle using an extended community attribute 233 [BGP-COMM]. Figure 3 shows the format of the lightpath identifier 234 attribute. The extended community attribute is 8 octets long. 236 +--------------------------------------+ 237 | Type (2 Octets) | 238 +--------------------------------------+ 239 | source AS (2 Octets) | 240 +--------------------------------------+ 241 | reserved (2 Octets) | 242 +--------------------------------------+ 243 | Lightpath identifier (2 Octets) | 244 +--------------------------------------+ 245 Figure 3: Extended community for lightpath identifier 247 The lightpath identifier can also be used to enforce local policies 248 where a site wants to reserve a number of optical ports for special 249 purposes. In that case, a predefined lightpath identifier can be used 250 between participating sites. 252 The lightpath identifier attribute will be used during both the 253 lightpath reachability and the lightpath establishement phases. 255 The value(s) and length of the lightpath identifier attribute will 256 need to be further defined. 258 4.3 Capability Negociation 260 A BGP speaker that uses the BGP messages described in this document 261 should use the capability advertisement defined in [BGP-CAP]. This 262 will allow a speaker to determine if a peer supports the multiprotocol 263 extensions defined in this document. The capability negociation should 264 use the AFI and SAFI values of (to be completed) 266 5. First phase: Lightpath reachability 268 In this first phase, the sites advertise lightpath availability to 269 other sites using BGP lightpath reachability update messages. This 270 message contains the following information: 272 - The IP address of the site egress OXC 273 - The reachable IP prefixes 274 - A lightpath identifier 276 The IP address of the site egress OXC and the reachable IP prefix 277 through that announced lightpath are encoded as described in section 278 4.1. 280 The lightpath identifier is an extended community attribute encoded as 281 described in section 4.2. The type field uses a value of 0xA101 to 282 denote that the message contains a lightpath reachability message. The 283 type field value is chosen from the vendor-specific range [BGP-COMM]. 284 If this proposal goes to standard track RFC, then an IANA assigned 285 number should be defined as defined in [BGP-COMM]. 287 The reserved field has a value of 0x00 when the type field is 0xA101 288 (lightpath reachability message). 290 The lightpath identifier value is assigned by the local organisation. 292 +--------------------------------------+ 293 | Type (2 Octets) = 0xA101 | 294 +--------------------------------------+ 295 | source AS (2 Octets) | 296 +--------------------------------------+ 297 | 0x00 | 298 +--------------------------------------+ 299 | Lightpath identifier (2 Octets) | 300 +--------------------------------------+ 301 Figure 4: Extended community for lightpath identifier 303 The following is an example of BGP speakers connected together through 304 the connexions shown in figure 5. 306 A ----- X ----- Y ----- Z ----- B 307 \ / 308 \ / 309 W ------- U 311 Figure 5. 313 To illustrate the process, the following table shows what the 314 local-RIB at sites A and U would look like when updates from all sites 315 are received. 317 Note that the extended-community shows the type 0xA101 (lightpath 318 reachability message), the AS number of the originating site and a 319 lightpath identifier. 321 The identifier used here is of the form L(xa) and represents one or a 322 bundle of available optical ports on the originating site (in this 323 case, site X). The value of this identifier is choosen by the local 324 site. 326 Destination OXC_IP Next-Hop extended-community AS-path 327 ----------- ------ -------- ------------------ ------- 328 Network X IP_X IP_X 0xA101,X,L(xa) X 329 Network Y IP_Y IP_X 0xA101,Y,L(yx) X,Y 330 Network Z IP_Z IP_X 0xA101,Z,L(zy) X,Y,Z 331 Network B IP_B IP_X 0xA101,B,L(bz) X,Y,Z,B 332 Network W IP_W IP_X 0xA101,W,L(wx) X,W 333 Network U IP_U IP_X 0xA101,U,L(uw) X,W,U 335 Table 1. Local-RIB at site A 337 Destination OXC_IP Next-Hop extended-community AS-path 338 ----------- ------ -------- ------------------ ------- 339 Network Z IP_Z IP_Z 0xA101,Z,L(zu) Z 340 Network B IP_B IP_Z 0xA101,B,L(bz) Z,B 341 Network Y IP_Y IP_Z 0xA101,Y,L(yz) Z,Y 342 Network W IP_W IP_W 0xA101,W,L(wu) W 343 Network X IP_X IP_W 0xA101,X,L(xw) W,X 344 Network A IP_A IP_W 0xA101,A,L(ax) W,X,A 346 Table 2. Local-RIB at site U 348 Each site is responsible of sending its lightpath availability to its 349 neighbors. If a OXC can no longer offer a previously announced 350 lightpath, it must send a withdrawl. That withdrawl message will contain 351 the same extended-community attributes that were used to announce the 352 previously available lightpath(s). 354 After receiving BGP update messages from its neighbors, a site can 355 choose to request the establishement of a lightpath to that 356 destination sending a lightpath establishement BGP update message. 358 6. Second phase: Lightpath establishement 360 This work investigates inter-AS lightpath provisioning. BGP is 361 currently deployed across the different autonomous systems on the 362 Internet, so investigating how a BGP approach to provision lightpaths 363 across autonomous systems is of great interest. 365 The goal of this work is to propose a BGP only approach to lightpath 366 provisioning. To this end, this section describes extensions to BGP to 367 signal lightpath establishment between autonomous systems. 369 6.1 Using BGP for lightpath establishment 371 Following the lightpath reachability phase, a site has the following 372 information for each candidate lightpath: 374 - The reachable IP prefixes through that candidate lightpath 375 - The IP address of the destination site egress OXC 376 - A lightpath identifier 377 - The AS_PATH to the destination site 379 A site can choose to request the establishment of a lightpath from 380 the information received in the lightpath reachability phase. The 381 reachable IP prefix(es) can be used to determine which networks can be 382 reached through the lightpath if that lightpath is established. 384 The IP address of the destination site egress OXC can be used to 385 determine if a lightpath to the OXC has already been established. 387 To illustrate the proposed protocol mechanisms, the following 388 optical topology example is used: 390 A ----- X ----- Y ----- Z ----- B 391 \ / 392 \ / 393 W ------- U 395 Looking more closely at site A, the following local-RIB is formed from 396 the information in the reachability phase: 398 Destination OXC_IP Next-Hop extended-community AS-path 399 ----------- ------ -------- ------------------ ------- 400 Network X IP_X IP_X 0xA101,X,L(xa) X 401 Network Y IP_Y IP_X 0xA101,Y,L(yx) X,Y 402 Network Z IP_Z IP_X 0xA101,Z,L(zy) X,Y,Z 403 Network B IP_B IP_X 0xA101,B,L(bz) X,Y,Z,B 404 Network W IP_W IP_X 0xA101,W,L(wx) X,W 405 Network U IP_U IP_X 0xA101,U,L(uw) X,W,U 407 If site A wants to establish a lightpath to network U, Site A needs to 408 first lookup the "lightpath RIB" entries to find a complete path to 409 the site. The "lightpath RIB" entry for network U on the last line 410 shows that the AS-path is (X,W,U). 412 In order to establish a lightpath to site U, A need to do the 413 following steps: 415 1- Lookup the RIB entry for the destination site 416 2- Lookup the corresponding entries for the intermediary sites 417 3- Allocate optical port and create a BGP "establish" message using 418 the looked up information. 420 In the example, step 1 will lookup the entry: 422 Destination OXC_IP Next-Hop extended-community AS-path 423 ----------- ------ -------- ------------------ ------- 424 Network U IP_Z IP_X 0xA101,Z,L(uw) X,W,U 426 Step 2 will lookup for the intermediate sites, that is the path to (X) 427 and to (X,W): 429 Destination OXC_IP Next-Hop extended-community AS-path 430 ----------- ------ -------- ------------------ ------- 431 Network X IP_X IP_X 0xA101,X,L(xa) X 432 Network W IP_W IP_X 0xA101,W,L(wx) X,W 434 The reason for looking up the intermediate sites entries in the 435 "lightpath RIB" is to make sure that there is a complete path 436 available to the destination site. Lightpath availability on the 437 optical network may change at any time. 439 For example, if the state of site W were to change such that 440 lightpaths were no longer available to reach X from W, W must withdraw 441 its lightpath availability by sending BGP withdrawl of its own 442 lightpath, L(wx) in the example. If that were the case, X would now 443 advertise to A a different path to reach U (X,Y,Z,U) using the 444 standard BGP path selection process. 446 The BGP update message used to establish a specific lightpath contains 447 the AS_PATH information and the lightpath identifiers obtained in the 448 lightpath reachability phase. These information are encoded in 449 extended community attributes. 451 +--------------------------------------+ 452 | Type (2 Octets) = 0xA102 | 453 +--------------------------------------+ 454 | source AS (2 Octets) | 455 +--------------------------------------+ 456 | destination AS (2 Octets) | 457 +--------------------------------------+ 458 | Lightpath identifier (2 Octets) | 459 +--------------------------------------+ 460 Figure 4: Extended community for lightpath establishment message 462 Destination OXC_IP Next-Hop extended-community AS-path 463 ----------- ------ -------- ------------------ ------- 464 Network X IP_X IP_X 0xA101,X,L(xa) X 465 Network W IP_W IP_X 0xA101,W,L(wx) X,W 466 Network U IP_Z IP_X 0xA101,Z,L(uw) X,W,U 468 In order to establish the lightpath, site A must send a BGP update 469 message to its neighbor(s). Site creates a BGP update message using 470 the following extended community attribute: 472 type src AS dest AS lightpath id 473 ---- ------ ------- ------------ 474 0xA102 A X L(xa) 475 0xA102 X W L(wx) 476 0xA102 W U L(uw) 478 The lightpath establishment message is detected by the presence of 479 the extended community attribute type 0xA102. 481 Site A allocates an optical port to be used for the lightpath. This 482 port must be identified to its neighbor OXC. Site A will do that by 483 setting an appropriate the value for L(xa). This assumes that there 484 are some peering/trust relationships between neighboring OXC such that 485 some convention will be agreed upon between such neighbors. 487 Note that the value of L(xa) for this example may and will probably be 488 different from the L(xa) value obtained from the lightpath 489 reachability phase. The lightpath establishment phase requires precise 490 optical port assignements between the neighbors and this is the 491 proposed function here. The port assignement is of local scope and is 492 significant only to neighboring OXC. 494 Site A sends the BGP message to its neighbors. Upon receiving a 495 lightpath establishment update message, a BGP peer should discard the 496 message if its AS is not part of the destination AS in the extended 497 community attribute. This way, the establishment update message gets 498 processed only by the identified AS in the attribute. 500 Upon receiving the update, OXC X will have the information to do the 501 cross-connect to site A using the value L(xa), and assign an optical 502 port from the requested "bundle" L(wx). Again, OXC X will set the 503 value for L(wx) that identifies the allocated optical port. 505 The local RIB of each OXC will have a new entry that identifies the 506 establish/allocated lightpath. 508 6.2 Using RSVP-TE or CR-LDP for lightpath establishment 510 (to be completed) 512 The purpose of this section is to look at current signaling protocols 513 to provision lightpaths and how they could be used in the inter-AS 514 context, define the interaction with BGP. 516 7. Routing information exchange 518 When the lightpath is established, a new BGP peeringis established 519 between the two peers that are now directly connected together on the 520 new established lightpath. 522 8. Interaction with Intra-AS IPO protocols 524 Since the lightpath to be established can cross multiple ASes, then 525 there should be propagation of the requested lightpath inside the 526 crossed AS. This should be done by redistributing the lightpath 527 request parameters in the IPO intraAS protocol 529 (to be completed) 531 9. Issues to be solved 533 - how to unprovision: through a withdrawal, but details to be 534 discussed 536 - multiple reservations at the same time, reservations not being used 537 that should be discarded: typical reservation problems. 539 - Lightpath identifier: currently an extended attribute. Encode in 540 MP_NLRI instead ? 542 10. References 544 [OBGP] CA*Net4, Bill St-Arnaud. 546 [BGP4] Y. Rekhter, et al., "A Border Gateway Protocol 4 (BGP-4)", Work 547 in Progress, draft-ietf-idr-bgp4-12.txt, Jan 2001 549 [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", 550 Work in progress, draft-ramachandra-bgp-ext-communities-08.txt, 551 February 2000 553 [BGP-MP] Bates, T., et al., "Multiprotocol Extensions for BGP4", RFC 554 2858, June 2000. 556 [BGP-CAP] R. Chandra, J. Scudder, "Capabilities Advertisement with 557 BGP-4" RFC 2842, May 2000 559 [OROUTING] Dimitris Pendarakis, et al., "Routing Information Exchange 560 in Optical Networks", Work in Progress, draft-prs-optical-routing-01.txt 562 [BGPVPN] Hamid Ould-Brahim, et al., "Using BGP as an Auto-Discovery 563 Mechanism for Network-based VPNs", Work in Progress, 564 draft-ouldbrahim-bgpvpn-auto-00.txt, November 2000. 566 [CRLDP] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling - 567 CR-LDP Extensions", Work in Progress, 568 draft-ietf-mpls-generalized-cr-ldp-00.txt, November 2000. 570 [RSVP-TE] Peter Ashwood-Smith, et al., "Generalized MPLS Signaling - 571 RSVP-TE Extensions", Work in Progress, 572 draft-ietf-mpls-generalized-rsvp-te-00.txt, November 2000. 574 [ISIS-TE] Kompella, K., et. al. "IS-IS Extensions in Support of 575 Generalized MPLS", Work in Progress, 576 draft-ietf-isis-gmpls-extensions-01.txt, November 2000. 578 [OSPF-TE] Kompella, K., et. al. "OSPF Extensions in Support of 579 Generalized MPLS", Work in Progress, 580 draft-ietf-ospf-gmpls-extensions-00.txt, November 2000. 582 11. Security Considerations 584 - Provisioning on demand new lightpaths changes the network 585 infrastructure and the routing tables. This should only be done using 586 strong authentication. 588 - Authentication measures in BGP must be used. 590 12. Acknowledgements 592 The OBGP acronym, the seminal ideas as well as most of the thinking 593 are from Bill St-Arnaud. 595 13. Authors' Addresses 597 Marc Blanchet 598 Viagenie 599 2875 boul. Laurier, bureau 300 600 Sainte-Foy, QC G1V 2M2 Canada 601 Marc.Blanchet@viagenie.qc.ca 603 Florent Parent, Viagenie 604 Viagenie 605 2875 boul. Laurier, bureau 300 606 Sainte-Foy, QC G1V 2M2 Canada 607 Florent.Parent@viagenie.qc.ca 609 Bill St-Arnaud 610 Canarie 611 110 O'Connor, 4th floor 612 Ottawa, ON, K1P 1H1 Canada 613 Bill.St.Arnaud@canarie.ca