idnits 2.17.1 draft-sitaraman-mpls-rsvp-shared-labels-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2017) is 2604 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) == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-11 == Outdated reference: A later version (-09) exists of draft-ietf-teas-rsvp-te-scaling-rec-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group H. Sitaraman 3 Internet-Draft V. Beeram 4 Intended status: Standards Track Juniper Networks 5 Expires: September 11, 2017 T. Parikh 6 Verizon 7 March 10, 2017 9 Signaling RSVP-TE tunnels on a shared MPLS forwarding plane 10 draft-sitaraman-mpls-rsvp-shared-labels-00.txt 12 Abstract 14 As the scale of MPLS RSVP-TE LSPs has grown, various implementation 15 recommendations have been proposed to manage control plane state. 16 However, the forwarding plane footprint of labels at a transit LSR 17 has remained proportional to the total LSP state in the control 18 plane. This draft defines a mechanism to prevent the label space 19 limit on an LSR from being a constraint to control plane scaling on 20 that node. It introduces the notion of pre-installed per TE link 21 'pop labels' that are shared by MPLS RSVP-TE LSPs that traverse these 22 links and thus significantly reducing the forwarding plane state 23 required. This couples the feature benefits of the RSVP-TE control 24 plane with the simplicity of the Segment Routing MPLS forwarding 25 plane. This document also introduces the ability to mix different 26 types of label operations along the path of the LSP, thereby allowing 27 the ingress or an external controller to influence how to optimally 28 place a LSP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 11, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions used in this document . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Allocation of pop labels . . . . . . . . . . . . . . . . . . 4 68 5. RSVP-TE pop and forward tunnel setup . . . . . . . . . . . . 4 69 6. Mixing pop and swap labels in a RSVP-TE tunnel . . . . . . . 6 70 7. Distributing label stack imposition . . . . . . . . . . . . . 7 71 8. Facility backup protection . . . . . . . . . . . . . . . . . 7 72 8.1. Link Protection . . . . . . . . . . . . . . . . . . . . . 7 73 8.2. Node Protection . . . . . . . . . . . . . . . . . . . . . 8 74 9. Quantifying pop labels . . . . . . . . . . . . . . . . . . . 8 75 10. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 77 10.2. Attributes Flags TLV: Pop Label . . . . . . . . . . . . 9 78 10.3. RRO Label Subobject Flag: Pop Label . . . . . . . . . . 10 79 10.4. Attributes TLV: Label Stack Imposition TLV . . . . . . . 10 80 11. OAM considerations . . . . . . . . . . . . . . . . . . . . . 11 81 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 83 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 14.1. Attribute Flags: Pop Label . . . . . . . . . . . . . . . 11 85 14.2. Attribute TLV: Label Stack Imposition TLV . . . . . . . 11 86 14.3. Record Route Label Sub-object Flags: Pop Label . . . . . 12 87 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 16.1. Normative References . . . . . . . . . . . . . . . . . . 12 90 16.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 Various RSVP-TE scaling recommendations [RFC2961] 96 [I-D.ietf-teas-rsvp-te-scaling-rec] have been proposed for 97 implementations to adopt guidelines that would allow the RSVP-TE 98 [RFC3209] control plane to scale better. The forwarding plane state 99 required to handle the equivalent control plane state remains 100 unchanged and is proportional to the total LSP state in the control 101 plane. The motivation of this draft is to prevent the platform 102 specific label space limit on an LSR from being a constraint to 103 pushing the limits of control plane scaling on that node. 105 This document proposes the allocation of a 'pop label' by a LSR for 106 each of its TE links. The label is installed in the MPLS forwarding 107 plane with a pop label operation and to forward the received packet 108 over the TE link. This label is sent normally by the LSR in the 109 Label object in the Resv message as LSPs are setup. The ingress LER 110 SHOULD construct and push a stack of labels [RFC3031] as received in 111 the Record Route object(RRO) in the Resv message. 113 This pop and forward data plane behavior is similar to that used by 114 Segment Routing (SR) [I-D.ietf-spring-segment-routing] using a MPLS 115 forwarding plane and a series of adjacency segments. The RSVP-TE pop 116 and forward tunnels can co-exist with SR LSPs as described in 117 [I-D.sitaraman-sr-rsvp-coexistence-rec]. 119 RSVP-TE using a pop and forward data plane offers the following 120 benefits: 122 1. Shared forwarding plane: The transit label on a TE link is shared 123 among RSVP-TE tunnels traversing the link and is used independent 124 of the ingress and egress of the LSPs. 126 2. Faster LSP setup time: The forwarding plane state is not 127 programmed during LSP setup and teardown resulting in faster LSP 128 setup time. 130 3. Hitless routes: New transit labels are not required on complete 131 path overlap during make-before-break (MBB) resulting in a faster 132 MBB event. This avoids the ingress LER and the services that 133 might be using the tunnel from needing to update its forwarding 134 plane with new tunnel labels. Periodic MBB events are relatively 135 common in networks that deploy auto-bandwidth on RSVP-TE LSPs to 136 monitor bandwidth utilization and periodically adjust LSP 137 bandwidth. 139 4. Mix and match labels: Both 'pop' and 'swap' labels can be mixed 140 across transit hops for a single RSVP-TE tunnel (see Section 6). 142 This allows local policy at an ingress or path computation engine 143 to influence RSVP-TE to mix and match different types of labels 144 across a LSP path. 146 No additional extensions are required to IGP-TE in order to support 147 this pop and forward data plane. Functionalities such as bandwidth 148 admission control, LSP priorities, preemption, auto-bandwidth and 149 Fast Reroute continue to work with this forwarding plane. 151 2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 3. Terminology 159 Pop label: An incoming label at a LSR that will be popped and 160 forwarded over a specific TE link to a neighbor. 162 Swap label: An incoming label at a LSR that will be swapped to an 163 outgoing label and forwarded over a specific downstream TE link. 165 Pop and forward data plane: A forwarding plane where every LSR along 166 the path uses a pop label. 168 RSVP-TE pop and forward tunnel: A MPLS RSVP-TE tunnel that uses a pop 169 and forward data plane. 171 4. Allocation of pop labels 173 A LSR SHOULD allocate a unique pop label for each TE link. The 174 forwarding action for the pop label should it appear on top of the 175 label stack MUST be to pop the label and forward the packet over the 176 TE link to the downstream neighbor of the RSVP-TE tunnel. Multiple 177 labels MAY be allocated for the TE link to accommodate tunnels 178 requesting no protection, link-protection and node-protection over 179 the specific TE link. 181 5. RSVP-TE pop and forward tunnel setup 183 This section provides an example of how the RSVP-TE signaling 184 procedure works to setup a tunnel utilizing a pop and forward data 185 plane. The sample topology below will be used to explain the setup. 187 Labels shown at each node are pop labels for that neighbor 189 +---+100 +---+150 +---+200 +---+250 +---+ 190 | A |-----| B |-----| C |-----| D |-----| E | 191 +---+ +---+ +---+ +---+ +---+ 192 |110 |450 |550 |650 |850 193 | | | | | 194 | |400 |500 |600 |800 195 | +---+ +---+ +---+ +---+ 196 +-------| F |-----|G |-----|H |-----|I | 197 +---+300 +---+350 +---+700 +---+ 199 Figure 1: Pop and forward label topology 201 RSVP-TE tunnel T1: From A to E on path A-B-C-D-E 202 RSVP-TE tunnel T2: From F to E on path F-B-C-D-E 204 Both tunnels share the TE links B-C, C-D and D-E. 206 As RSVP-TE signals the setup (using the pop label attributes flag 207 defined in Section 10.2) of tunnel T1, when LSR D receives the Resv 208 message from the egress E, it checks the next-hop TE link (D-E) and 209 provides the pop label (250) in the Resv message for the tunnel. The 210 label is sent in the Label object and is also recorded in the Label 211 sub-object (using the pop label bit defined in Section 10.3) carried 212 in the RRO. Similarly, C provides the pop label (200) for the next- 213 hop TE link C-D and B provides the pop label (150) for the next-hop 214 TE link B-C. For the tunnel T2, the transit LSRs provide the same 215 pop labels as described for tunnel T1. 217 Both LER A and F will push the same stack of labels {150(top), 200, 218 250} for tunnels T1 and T2 respectively. It should be noted that a 219 transit LSR does not use the pop label provided in the label object 220 by its downstream LSR in the NHLFE as the outgoing label. The 221 recorded labels in the RRO are of interest to the ingress LER in 222 order to construct a stack of labels. 224 If there were another RSVP-TE tunnel T3 from F to I on path 225 F-B-C-D-E-I, then this would also share the TE links B-C, C-D and D-E 226 and additionally traverse link E-I. The label stack used by F would 227 be {150(top), 200, 250, 850}. Hence, regardless of the ingress and 228 egress LERs from where the LSPs start and end, they will share LSR 229 labels at shared hops in the pop and forward data plane. 231 There MAY be local operator policy at the ingress LER that influences 232 the maximum depth of the label stack that can be pushed for a RSVP-TE 233 pop and forward tunnel. Prior to signaling the LSP, if the ingress 234 LER decides that it would be unable to push the entire label stack 235 should every transit hop provide a pop label, then the LER can choose 236 to either not signal a RSVP-TE pop and forward tunnel or can adopt 237 techniques mentioned in Section 6 or Section 7. 239 6. Mixing pop and swap labels in a RSVP-TE tunnel 241 Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP. 242 Certain LSRs can use pop labels and others can use swap labels. The 243 ingress can construct a label stack appropriately based on what type 244 of label is recorded from every transit LSR. 246 Labels shown at each node are pop labels for that TE link. (#) are 247 swap labels. 249 (#) (#) 250 +---+100 +---+150 +---+200 +---+250 +---+ 251 | A |-----| B |-----| C |-----| D |-----| E | 252 +---+ +---+ +---+ +---+ +---+ 253 |110 |450 |550 |650 |850 254 | | | | | 255 | |400 |500 |600 |800 256 | +---+ +---+ +---+ +---+ 257 +-------| F |-----|G |-----|H |-----|I | 258 +---+300 +---+350 +---+700 +---+ 260 Figure 2: Mix pop and swap label topology 262 If the transit LSR is allocating a swap label to be sent upstream in 263 the Resv, then the label operation in the NHLFE MUST be a swap to any 264 label received from the downstream LSR. If the transit LSR is using 265 a pop label to be sent upstream in the Resv, then the label operation 266 in the NHLFE MUST be a pop and forward regardless of any label 267 received from the downstream LSR. 269 The ingress LER MUST check the type of label received from each 270 transit hop as recorded in the RRO in the Resv message and generate 271 the appropriate label stack to use for the RSVP-TE tunnel. 273 The following logic could be used by the ingress LER while 274 constructing the label stack: 276 Each RRO label sub-object SHOULD be processed starting with the label 277 sub-object from the first downstream hop. Any label provided by the 278 first downstream hop MUST always be pushed on the label stack 279 regardless of the label type. If the label type is a pop label, then 280 any label from the next downstream hop MUST also be pushed on the 281 constructed label stack. If the label type is a swap label, then any 282 label from the next downstream hop MUST NOT be pushed on the 283 constructed label stack. For example, the LSP from A to I using path 284 A-B-C-D-E-I will use a label stack of {150(top), 200}. 286 Signaling extensions for the ingress LER to request a certain type of 287 label from a particular hop is defined in Section 10.2. A Hop-Count 288 value of 1 (Label Stack Imposition Attribute) SHOULD be used for the 289 specific hops to allocate a swap label. 291 7. Distributing label stack imposition 293 One or more transit LSRs can assist the ingress LER by imposing part 294 of the label stack required for the path. From Figure 1, ingress LER 295 A can use the assistance of transit LSRs to push labels downstream of 296 that LSR. For example, LER A can push label 150 and LSR C can push 297 {200(top), 250} for the LSP taking path A-B-C-D-E. 299 The ingress LER can request one or more specific transit hops to 300 handle pushing labels for N of its downstream hops. To achieve this 301 request properly, the ingress can learn the label stack depth push 302 limit of the transit LSRs. The mechanism by which the ingress or 303 controller (hosting the path computation element) learns this 304 information is outside the scope of this document. The particular 305 transit hops SHOULD allocate a swap label that will result in that 306 label being replaced and a set of labels pushed to accommodate N 307 downstream hops. 309 Signaling extensions for the ingress LER to request one or more 310 transit LSRs to handle label stack imposition for N downstream hops 311 or for the transit hop to indicate to the ingress that it can handle 312 label stack imposition for N downstream hops is defined in 313 Section 10.2. The Hop-Count field (Label Stack Imposition Attribute) 314 can be used to indicate the value of N. 316 8. Facility backup protection 318 The following section describe how link and node protection works 319 with facility backup protection [RFC4090] for the RSVP-TE pop and 320 forward tunnels. 322 8.1. Link Protection 324 To provide link protection at a PLR with a pop and forward data 325 plane, the LSR SHOULD allocate a separate pop label for the TE link 326 that will be used for RSVP-TE tunnels that request link-protection 327 from the ingress. No signaling extensions are required to support 328 link protection for RSVP-TE tunnels over the pop and forward data 329 plane. 331 (*) are pop labels to offer link protection for that TE link 333 101(*) 151(*) 201(*) 251(*) 334 +---+100 +---+150 +---+200 +---+250 +---+ 335 | A |-----| B |-----| C |-----| D |-----| E | 336 +---+ +---+ +---+ +---+ +---+ 337 |110 |450 |550 |650 |850 338 | | | | | 339 | |400 |500 |600 |800 340 | +---+ +---+ +---+ +---+ 341 +-------| F |-----|G |-----|H |-----|I | 342 +---+300 +---+350 +---+700 +---+ 344 Figure 3: Link protection topology 346 At each LSR, link protected pop labels can be allocated for each TE 347 link and a link protecting facility backup LSP can be created to 348 protect the TE link. This label can be sent by the LSR for LSPs 349 requesting link-protection over the specific TE link. Since the 350 facility backup terminates at the next-hop (merge point), the 351 incoming label on the packet will be what the merge point expects. 353 As an example, LSR B can install a facility backup LSP for the link 354 protected pop label 151. When the TE link B-C is up, LSR B will pop 355 151 and send the packet to C. If the TE link B-C is down, the LSR 356 can pop 151 and send the packet via the facility backup to C. 358 8.2. Node Protection 360 The solutions for the PLR to provide node-protection for the pop and 361 forward RSVP-TE tunnel will be explained in the next version of the 362 document. 364 9. Quantifying pop labels 366 This section attempts to quantify the number of labels required in 367 the forwarding plane to provide sharing of labels across RSVP-TE pop 368 and forward tunnels. A MPLS RSVP-TE tunnel offers either no 369 protection, link protection or node protection and only one of these 370 labels is required per tunnel during signaling. The scale of the 371 number of pop labels required per LSR can be deduced as follows: 373 o For a LSR having X neighbors reachable across Y interfaces, the 374 number of unprotected pop labels = X 376 o For a PLR having X neighbors reachable across Y interfaces, number 377 of link protected pop labels = X 379 o For a PLR having X neighbors, each having Nx neighbors (i.e. next- 380 nexthop for PLR), number of node protected pop labels = 381 SUM_OF_ALL(Nx) 383 Total number of pop labels = Unprotected pop labels + link protected 384 pop labels + node protected pop labels = 2X + SUM(Nm) 386 10. Protocol Extensions 388 10.1. Requirements 390 The functionality discussed in this document imposes the following 391 requirements on the signaling protocol. 393 o The Ingress of the LSP SHOULD have the ability to mandate/request 394 the use and recording of pop labels at all hops along the path of 395 the LSP. 397 o When the use of pop labels is mandated/requested for the entire 398 path, 400 the node recording the pop label SHOULD have the ability to 401 indicate if the recorded label is a pop label. 403 the ingress SHOULD have the ability to override this path 404 specific behavior by 406 explicitly mandating specific hops to not use pop labels (or) 408 mandating specific hops to share the onus of imposing the 409 label stack (and also specifying the desired number of hops 410 that need to be accounted for at that node) 412 the node which was mandated to share the onus of imposing the 413 label stack SHOULD have the ability to indicate the actual number 414 of hops that it can account for. 416 10.2. Attributes Flags TLV: Pop Label 418 Bit Number (TBD1): Pop Label 420 The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES 421 object of a Path message indicates that the ingress has requested/ 422 mandated the use and recording of pop labels at all hops along the 423 path of this LSP. When a node that does not cater to the request/ 424 mandate receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES 425 object with this flag set, it MUST send a PathErr message with an 426 error code of 'routing problem' and an error value of 'pop label 427 usage failure'. 429 10.3. RRO Label Subobject Flag: Pop Label 431 Bit Number (TBD2): Pop Label 433 The presence of this flag indicates that the recorded label is a pop 434 label. This flag SHOULD be used by a node only if the use and 435 recording of pop labels is requested/mandated for this LSP. 437 10.4. Attributes TLV: Label Stack Imposition TLV 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Reserved | Hop-Count | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Attribute TLV Type: TBD3 447 The presence of this in the HOP_ATTRIBUTES subobject [RFC7570] of an 448 ERO object in the Path message mandates the hop identified by the 449 preceding IPv4 or IPv6 or Unnumbered Interface ID subobject to share 450 the onus of imposing the label stack. This attribute MUST be used 451 only if the use and recording of pop labels is requested/mandated for 452 this LSP (only if Pop Label flag is present in the LSP_ATTRIBUTES/ 453 LSP_REQUIRED_ATTRIBUTES object). If the node is not able to comply 454 with this mandate, it MUST send a PathErr message with an error code 455 of 'routing problem' and an error value of 'label stack imposition 456 failure'. 458 The Hop-Count field specifies the desired number of hops that this 459 node needs to account for. A Hop-Count value of 0 is considered 460 invalid and a value of 1 implies that this hop perform a normal swap 461 or pop (if this hop is PHP) operation towards the next downstream 462 hop. 464 The presence of this in the HOP_ATTRIBUTES subobject of an RRO object 465 in the RESV message indicates that the hop identified by the 466 preceding IPv4 or IPv6 or Unnumbered Interface ID subobject is 467 sharing the onus of imposing the label stack. The Hop-Count field 468 specifies the actual number of hops that this node can account for. 469 This should not be included in the RESV message unless this TLV is 470 also present in the corresponding Path message for this hop. 472 11. OAM considerations 474 Any extensions necessary for MPLS LSP traceroute for the RSVP-TE pop 475 and forward tunnel will be explained in the next version of the 476 document. 478 12. Acknowledgements 480 The authors would like to thank Adrian Farrel, Kireeti Kompella, 481 Markus Jork and Ross Callon for their input from discussions. 483 13. Contributors 485 The following individuals contributed to this document: 487 Raveendra Torvi 488 Juniper Networks 489 Email: rtorvi@juniper.net 491 Chandra Ramachandran 492 Juniper Networks 493 Email: csekar@juniper.net 495 14. IANA Considerations 497 14.1. Attribute Flags: Pop Label 499 IANA manages the 'Attribute Flags' registry as part of the 'Resource 500 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters' 501 registry located at http://www.iana.org/assignments/rsvp-te- 502 parameters. This document introduces a new Attribute Flag. 504 Bit Name Attribute Attribute RRO ERO Reference 505 No. FlagsPath FlagsResv 506 TBD1 Pop Label Yes No No No This document 507 (Section 5) 509 14.2. Attribute TLV: Label Stack Imposition TLV 511 IANA manages the "Attribute TLV Space" registry as part of the 512 'Resource Reservation Protocol-Traffic Engineering (RSVP-TE) 513 Parameters' registry located at http://www.iana.org/assignments/rsvp- 514 te-parameters. This document introduces a new Attribute TLV. 516 Type Name Allowed on Allowed on Allowed on Reference 517 LSP LSP REQUIRED LSP Hop 518 ATTRIBUTES ATTRIBUTES Attributes 520 TBD3 Label No No Yes This document 521 Stack (Section 7) 522 Imposition 523 TLV 525 14.3. Record Route Label Sub-object Flags: Pop Label 527 IANA manages the 'Record Route Object Sub-object Flags' registry as 528 part of the 'Resource Reservation Protocol-Traffic Engineering (RSVP- 529 TE) Parameters' registry located at http://www.iana.org/assignments/ 530 rsvp-te-parameters. This registry currently does not include Label 531 Sub-object Flags. This document proposes the addition of a new sub- 532 registry for Label Sub-object Flags as shown below. 534 Flag Name Reference 536 0x1 Global Label RFC 3209 537 TBD2 Pop Label This document (Section 5) 539 15. Security Considerations 541 This document does not introduce new security issues. The security 542 considerations pertaining to the original RSVP protocol [RFC2205] and 543 RSVP-TE [RFC3209] and those that are described in [RFC5920] remain 544 relevant. 546 16. References 548 16.1. Normative References 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, 552 DOI 10.17487/RFC2119, March 1997, 553 . 555 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 556 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 557 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 558 September 1997, . 560 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 561 Label Switching Architecture", RFC 3031, 562 DOI 10.17487/RFC3031, January 2001, 563 . 565 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 566 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 567 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 568 . 570 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast 571 Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 572 DOI 10.17487/RFC4090, May 2005, 573 . 575 [RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. 576 Wright, "Label Switched Path (LSP) Attribute in the 577 Explicit Route Object (ERO)", RFC 7570, 578 DOI 10.17487/RFC7570, July 2015, 579 . 581 16.2. Informative References 583 [I-D.ietf-spring-segment-routing] 584 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 585 and R. Shakir, "Segment Routing Architecture", draft-ietf- 586 spring-segment-routing-11 (work in progress), February 587 2017. 589 [I-D.ietf-teas-rsvp-te-scaling-rec] 590 Beeram, V., Minei, I., Shakir, R., Pacella, D., and T. 591 Saad, "Implementation Recommendations to Improve the 592 Scalability of RSVP-TE Deployments", draft-ietf-teas-rsvp- 593 te-scaling-rec-03 (work in progress), October 2016. 595 [I-D.sitaraman-sr-rsvp-coexistence-rec] 596 Sitaraman, H., Beeram, V., Minei, I., and S. Sivabalan, 597 "Recommendations for RSVP-TE and Segment Routing LSP co- 598 existence", draft-sitaraman-sr-rsvp-coexistence-rec-02 599 (work in progress), February 2017. 601 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 602 and S. Molendini, "RSVP Refresh Overhead Reduction 603 Extensions", RFC 2961, DOI 10.17487/RFC2961, April 2001, 604 . 606 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 607 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 608 . 610 Authors' Addresses 612 Harish Sitaraman 613 Juniper Networks 614 1133 Innovation Way 615 Sunnyvale, CA 94089 616 US 618 Email: hsitaraman@juniper.net 620 Vishnu Pavan Beeram 621 Juniper Networks 622 10 Technology Park Drive 623 Westford, MA 01886 624 US 626 Email: vbeeram@juniper.net 628 Tejal Parikh 629 Verizon 630 400 International Parkway 631 Richardson, TX 75081 632 US 634 Email: tejal.parikh@verizon.com