idnits 2.17.1 draft-crabbe-pce-stateful-pce-protection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-pce-stateful-pce]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2012) is 4214 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: 'TBD' is mentioned on line 326, but not defined == Unused Reference: 'RFC2205' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC5089' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 430, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RFC3346' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC5394' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC5557' is defined on line 459, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-crabbe-pce-pce-initiated-lsp-00 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-01 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Crabbe 3 Internet-Draft Google, Inc. 4 Intended status: Standards Track J. Medved 5 Expires: April 15, 2013 Cisco Systems, Inc. 6 I. Minei 7 R. Torvi 8 Juniper Networks, Inc. 9 October 12, 2012 11 PCEP Extensions for MPLS-TE LSP protection with stateful PCE 12 draft-crabbe-pce-stateful-pce-protection-00 14 Abstract 16 Stateful PCE [I-D.ietf-pce-stateful-pce] can apply global concurrent 17 optimizations to optimize LSP placement. In a deployment where a PCE 18 is used to compute all the paths, it may be beneficial for the 19 protection paths to also be computed by the PCE. This document 20 defines extensions needed for the setup and management of MPLS-TE 21 protection paths by the PCE. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119]. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 15, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Architectural Overview . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Path Protection Overview . . . . . . . . . . . . . . . . . 3 67 3.2. Local Protection Overview . . . . . . . . . . . . . . . . 4 68 4. Extensions for the LSPA object . . . . . . . . . . . . . . . . 5 69 4.1. The Standby flag in the LSPA object . . . . . . . . . . . 5 70 4.2. The Weight TLV . . . . . . . . . . . . . . . . . . . . . . 6 71 4.3. The Bypass TLV . . . . . . . . . . . . . . . . . . . . . . 6 72 4.4. The LOCALLY-PROTECTED-LSPS TLV . . . . . . . . . . . . . . 7 73 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 9 75 5.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 9 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 [RFC5440] describes the Path Computation Element Protocol PCEP. PCEP 86 defines the communication between a Path Computation Client (PCC) and 87 a Path Control Element (PCE), or between PCE and PCE, enabling 88 computation of Multiprotocol Label Switching (MPLS) for Traffic 89 Engineering Label Switched Path (TE LSP) characteristics. 91 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 92 extensions to PCEP to enable stateful control of paths such as MPLS 93 TE LSPs between and across PCEP sessions in compliance with 94 [RFC4657]. It includes mechanisms to effect LSP state 95 synchronization between PCCs and PCEs, delegation of control of LSPs 96 to PCEs, and PCE control of timing and sequence of path computations 97 within and across PCEP sessions and focuses on a model where LSPs are 98 configured on the PCC and control over them is delegated to the PCE. 100 Stateful PCE can apply global concurrent optimizations to optimize 101 LSP placement. In a deployment where a PCE is used to compute all 102 the paths, it may be beneficial for the protection paths to also be 103 controlled through the PCE. This document defines extensions needed 104 for the setup and management of protection paths by the PCE. 106 Benefits of controlling the protection paths include: better control 107 over traffic after a failure and more deterministic path computation 108 (paths not affected by overload after a failure). 110 2. Terminology 112 This document uses the following terms defined in [RFC5440]: PCC, 113 PCE, PCEP Peer. 115 This document uses the following terms defined in 116 [I-D.ietf-pce-stateful-pce]: Stateful PCE, Delegation, Delegation 117 Timeout Interval, LSP State Report, LSP Update Request. 119 The message formats in this document are specified using Routing 120 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 122 3. Architectural Overview 124 3.1. Path Protection Overview 126 Path protection refers to switching to a new path on failure. 127 Several cases exist: 129 (1) MPLS-TE Global Default Restoration - protection paths are 130 computed dynamically by the LSR after the failure. This can be 131 supported without any PCEP protocol changes by specifying a 132 secondary path with an ERO of just the end points of the LSP. 133 Once reestablished, the path is communicated to the PCE via the 134 LSP State Report message. 136 (2) MPLS-TE Global Path Protection - protection paths are fully 137 specified ahead of the failure. The base Stateful PCE 138 specification [I-D.ietf-pce-stateful-pce] supports sending 139 multiple fully-specified paths in the PCUpd requests.There are 2 140 further sub-cases: 142 (a) Protection paths are pre-signaled ahead of the failure 143 (standby paths). 145 (b) Protection paths are set up after the failure. 147 The protection path setup regimen (standby or not) is specified in 148 the path using a new per-path flag in the LSPA object, the S 149 (standby) flag (see section Section 4.1). Paths for which the S flag 150 is set MUST have a name associated with them, specified using the 151 SYMBOLIC-PATH-NAME TLV in the LSPA object. 153 Because multiple secondary standby paths are possible, there is also 154 a need for the PCE to be able to specify the relative priorities 155 between the paths (which one to take if there are 3 available). This 156 is done through a weight assigned to each path. See details in 157 Section 4.2. 159 Reversion from protection paths to the primary path when possible 160 will be controlled by the PCE, by sending a new LSP Update Request. 161 If the primary can be successfully signaled and the secondary does 162 not have the S flag set, then the secondary MUST be torn down. Thus, 163 there is no need to signal the desire for revertive behavior. 165 3.2. Local Protection Overview 167 Local protection refers to the ability to locally route around 168 failure of an LSP. Two types of local protection are possible: 170 (1) 1:1 protection - the protection path protects a single LSP. 172 (2) 1:N protection - the protection path protects multiple LSPs 173 traversing the protected resource. 175 It is assumed that the PCE knows what resources require protection 176 through mechanisms outside the scope of this document. In a PCE- 177 controlled deployment, support of 1:1 protection has limited 178 applicability, and can be achieved as a degenerate case of 1:N 179 protection. For this reason, local protection will be disccussed 180 only for the 1:N case. 182 Local protection requires the setup of a bypass at the PLR. This 183 bypass can be locally initiated and delegated, or PCE-initiated. In 184 either case, the PLR must maintain a PCEP session to the PCE. A 185 bypass identifier (the name of the bypass) is required for 186 disambiguation as multiple bypasses are possible at the PLR. Mapping 187 of LSPs to bypass is done through a new TLV, the LOCALLY-PROTECTED- 188 LSPS TLV in the LSP Update message from PCE to PLR. See section 189 Section 4.4. When an LSP requiring protection is set up through the 190 PLR, the PLR checks if it has a mapping to a bypass and only provides 191 protection if such a mapping exists. The status of bypasses and what 192 LSPs are protected by them is communicated to the PCE via LSP Status 193 Report messages. 195 4. Extensions for the LSPA object 197 4.1. The Standby flag in the LSPA object 199 The LSPA object is defined in [RFC5440] and replicated below for easy 200 reference. This document defines a new flag, the S flag in the flags 201 field of the LSPA object. 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Exclude-any | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Include-any | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Include-all | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Setup Prio | Holding Prio | Flags |S|L| Reserved | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 // Optional TLVs // 216 | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 1: STATEFUL-PCE-CAPABILITY TLV format 221 The L flag is defined in [RFC5440]. 223 If set to 1, the S Flag indicates this is a standby path. 225 If the S flag is set, the LSPA object MUST also carry the SYMBOLIC- 226 PATH-NAME TLV as one of the optional TLVs. Failure to include the 227 mandatory SYMBOLIC-PATH-NAME TLV when the S flag is set MUST trigger 228 PCErr of type 6 (Mandatory Object missing) and value TBD (SYMBOLIC- 229 PATH-NAME TLV missing for standby LSP). 231 4.2. The Weight TLV 233 This TLV will be discussed in a future version of tihs document. 235 4.3. The Bypass TLV 237 The facility backup method creates a bypass tunnel to protect a 238 potential failure point. The bypass tunnel protects a set of LSPs 239 with similar backup constraints {RFC4090]. 241 A PCC can delegate a bypass tunnel to PCE control or a PCE can 242 provision the bypass tunnel via a PCC. The procedures for bypass 243 instantiation rely on the extensions defined in 244 [I-D.crabbe-pce-pce-initiated-lsp] and will be detailed in a future 245 version of this document. 247 The Bypass TLV carries information about the bypass tunnel. It is 248 included in the LSPA Object in LSP State Report and LSP Update 249 Request messages. 251 The format of the Bypass TLV is shown in the following figure: 253 0 1 2 3 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type=[TBD] | Length=8 | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | MUST be zero | Flags |I|N| 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Bypass IPv4 Address | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: Bypass TLV format 265 The type of the TLV is [TBD] and it has a fixed length of 8 octets. 266 The value contains the following fields: 268 Flags 270 N (Node Protection - 1 bit): The N Flag indicates whether the 271 Bypass is used for node-protection. If the N flag is set to 1, 272 the Bypass is used for node-protection. If the N flag is 0, 273 the Bypass is used for link-protection. 275 I (Local Protection In Use - 1 bit): The I Flag indicates that 276 local repair mechanism is in use. 278 Bypass IPv4 address: For link protection, the Bypass IPv4 Address is 279 the nexthop address of the protected link in the paths of the 280 protected LSPs. For node protection, the Bypass IPv4 Address is 281 the node addresses of the protected node. 283 If the Bypass TLV is included, then the LSPA object MUST also carry 284 the SYMBOLIC-PATH-NAME TLV as one of the optional TLVs. Failure to 285 include the mandatory SYMBOLIC-PATH-NAME TLV MUST trigger PCErr of 286 type 6 (Mandatory Object missing) and value TBD (SYMBOLIC-PATH-NAME 287 TLV missing for bypass LSP) 289 4.4. The LOCALLY-PROTECTED-LSPS TLV 291 The LOCALLY-PROTECTED-LSPS TLV in the LSPA Object contains a list of 292 LSPs protected by the bypass tunnel. 294 The format of the Bypass TLV is shown in the following figure: 296 0 1 2 3 297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type=[TBD] | Length (variable) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | IPv4 tunnel end point address | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Flags |R| Tunnel ID | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Extended Tunnel ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | IPv4 Tunnel Sender Address | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | MUST be zero | LSP ID | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 // .... // 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | IPv4 tunnel end point address | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Flags |R| Tunnel ID | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Extended Tunnel ID | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | IPv4 Tunnel Sender Address | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | MUST be zero | LSP ID | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 3: Locally protected LSPs TLV format 326 The type of the TLV is [TBD] and it is of variable length.The value 327 contains one or more LSP descriptors including the following fields 328 filled per [RFC3209]. 330 IPv4 Tunnel end point address: [RFC3209] 332 Flags 334 R(Remove - 1 bit): The R Flag indicates that the LSP has been 335 removed from the list of LSPs protected by the bypass tunnel. 337 Tunnel ID: [RFC3209] 338 Extended Tunnel ID: [RFC3209] 340 IPv4 Tunnel Sender address: [RFC3209] 342 LSP ID: [RFC3209] 344 5. IANA considerations 346 5.1. PCEP-Error Object 348 This document defines new Error-Type and Error-Value for the 349 following new error conditions: 351 Error-Type Meaning 352 6 Mandatory Object missing 353 Error-value=TBD: SYMBOLIC-PATH-NAME TLV missing for a 354 path where the S-bit is set in the LSPA 355 object. 356 Error-value=TBD: SYMBOLIC-PATH-NAME TLV missing for a 357 bypass path. 359 5.2. PCEP TLV Type Indicators 361 This document defines the following new PCEP TLVs: 363 Value Meaning Reference 364 ??? Bypass This document 365 ??? weight This document 366 ??? LOCALLY-PROTECTED-LSPS This document 368 6. Security Considerations 370 The same security considerations apply at the PLR as those describe 371 for the head end in [I-D.crabbe-pce-pce-initiated-lsp]. 373 7. Acknowledgements 375 We would like to thank Ambrose Kwong for his contributions to this 376 document. 378 8. References 379 8.1. Normative References 381 [I-D.crabbe-pce-pce-initiated-lsp] 382 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 383 Extensions for PCE-initiated LSP Setup in a Stateful PCE 384 Model", draft-crabbe-pce-pce-initiated-lsp-00 (work in 385 progress), October 2012. 387 [I-D.ietf-pce-stateful-pce] 388 Crabbe, E., Medved, J., Varga, R., and I. Minei, "PCEP 389 Extensions for Stateful PCE", 390 draft-ietf-pce-stateful-pce-01 (work in progress), 391 July 2012. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, March 1997. 396 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 397 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 398 Functional Specification", RFC 2205, September 1997. 400 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 401 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 402 Tunnels", RFC 3209, December 2001. 404 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 405 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 406 May 2005. 408 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 409 "OSPF Protocol Extensions for Path Computation Element 410 (PCE) Discovery", RFC 5088, January 2008. 412 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 413 "IS-IS Protocol Extensions for Path Computation Element 414 (PCE) Discovery", RFC 5089, January 2008. 416 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 417 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 418 May 2008. 420 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 421 (PCE) Communication Protocol (PCEP)", RFC 5440, 422 March 2009. 424 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 425 Used to Form Encoding Rules in Various Routing Protocol 426 Specifications", RFC 5511, April 2009. 428 8.2. Informative References 430 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 431 McManus, "Requirements for Traffic Engineering Over MPLS", 432 RFC 2702, September 1999. 434 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 435 Label Switching Architecture", RFC 3031, January 2001. 437 [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., 438 Christian, B., and W. Lai, "Applicability Statement for 439 Traffic Engineering with MPLS", RFC 3346, August 2002. 441 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 442 (TE) Extensions to OSPF Version 2", RFC 3630, 443 September 2003. 445 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 446 Element (PCE)-Based Architecture", RFC 4655, August 2006. 448 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 449 Communication Protocol Generic Requirements", RFC 4657, 450 September 2006. 452 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 453 Engineering", RFC 5305, October 2008. 455 [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, 456 "Policy-Enabled Path Computation Framework", RFC 5394, 457 December 2008. 459 [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path 460 Computation Element Communication Protocol (PCEP) 461 Requirements and Protocol Extensions in Support of Global 462 Concurrent Optimization", RFC 5557, July 2009. 464 Authors' Addresses 466 Edward Crabbe 467 Google, Inc. 468 1600 Amphitheatre Parkway 469 Mountain View, CA 94043 470 US 472 Email: edc@google.com 473 Jan Medved 474 Cisco Systems, Inc. 475 170 West Tasman Dr. 476 San Jose, CA 95134 477 US 479 Email: jmedved@cisco.com 481 Ina Minei 482 Juniper Networks, Inc. 483 1194 N. Mathilda Ave. 484 Sunnyvale, CA 94089 485 US 487 Email: ina@juniper.net 489 Raveendra Torvi 490 Juniper Networks, Inc. 491 1194 N. Mathilda Ave. 492 Sunnyvale, CA 94089 493 US 495 Email: rtorvi@juniper.net