idnits 2.17.00 (12 Aug 2021) /tmp/idnits64277/draft-ietf-mpls-smp-requirements-09.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 (September 28, 2014) is 2785 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'G.7710' is mentioned on line 540, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Weingarten 3 INTERNET-DRAFT 4 Intended status: Informational S. Aldrin 5 Expires: April 1, 2015 Huawei Technologies 6 P. Pan 7 Infinera 8 J. Ryoo 9 ETRI 10 G. Mirsky 11 Ericsson 12 September 28, 2014 14 Requirements for MPLS-TP Shared Mesh Protection 15 draft-ietf-mpls-smp-requirements-09.txt 17 Abstract 19 This document presents the basic network objectives for the behavior 20 of shared mesh protection (SMP) which are not based on control plane 21 support. This is an expansion of the basic requirements presented in 22 RFC 5654 "Requirements for the Transport Profile of MPLS" and RFC 23 6372 "MPLS Transport Profile (MPLS-TP) Survivability Framework". This 24 document provides requirements for any mechanism that would be used 25 to implement SMP for MPLS-TP data paths, in networks that delegate 26 protection switch coordination to the data plane. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 1, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 64 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Terms Defined in This Document . . . . . . . . . . . . . . 4 66 3. Shared Mesh Protection Reference Model . . . . . . . . . . . . 4 67 3.1. Protection or Restoration . . . . . . . . . . . . . . . . 4 68 3.2. Scope of Document . . . . . . . . . . . . . . . . . . . . 5 69 3.2.1. Relationship to MPLS . . . . . . . . . . . . . . . . . 5 70 4. SMP Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. Coordination of Resources . . . . . . . . . . . . . . . . 7 72 4.2. Control Plane or Data Plane . . . . . . . . . . . . . . . 8 73 5. SMP Network Objectives . . . . . . . . . . . . . . . . . . . . 8 74 5.1. Resource Reservation and Coordination . . . . . . . . . . 8 75 5.1.1. Checking Resource Availability for Multiple 76 protection Paths . . . . . . . . . . . . . . . . . . . 9 77 5.2. Multiple Triggers . . . . . . . . . . . . . . . . . . . . 9 78 5.2.1. Soft-preemption . . . . . . . . . . . . . . . . . . . . 9 79 5.2.2. Hard-preemption . . . . . . . . . . . . . . . . . . . . 9 80 5.3. Notification . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.4. Reversion . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.5. Protection Switching Time . . . . . . . . . . . . . . . . 11 83 5.6. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.7. Communication Channel and Fate Sharing . . . . . . . . . . 11 85 6. Manageability Considerations . . . . . . . . . . . . . . . . . 12 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 90 11. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14 91 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 93 1. Introduction 95 The MPLS Transport Profile (MPLS-TP) is described in [RFC5921], and 96 [RFC6372] provides a survivability framework for MPLS-TP and is the 97 foundation for this document. 99 Terminology for recovery of connectivity in networks is provided in 100 [RFC4427] and includes the concept of surviving network faults 101 (survivability) through the use of re-established connections 102 (restoration) and switching of traffic to pre-established back-up 103 paths (protection). MPLS provides control plane tools to support 104 various survivability schemes, some of which are identified in 105 [RFC4426]. In addition, recent efforts in the IETF have started 106 providing for data plane tools to address aspects of data protection. 107 In particular, [RFC6378] and [RFC7271] define a set of triggers and 108 coordination protocol for 1:1 and 1+1 linear protection of point-to- 109 point paths. 111 When considering a full-mesh network and the protection of different 112 paths that traverse the mesh, it is possible to provide an acceptable 113 level of protection while conserving the amount of protection 114 resources needed to protect the different data paths. As pointed out 115 in [RFC6372] and [RFC4427], applying 1+1 protection requires that 116 resources are allocated for use by both the working and protection 117 paths. Applying 1:1 protection requires that the same resources are 118 allocated, but allows the resources of the protection path to be 119 utilized for pre-emptible extra traffic. Extending this to 1:n or m:n 120 protection allows the resources of the protection path to be shared 121 in the protection of several working paths. However, 1:n or m:n 122 protection architecture is limited by the restriction that all of the 123 n+1 or m+n paths must have the same endpoints. m:n protection 124 architecture provides m protection paths to protect n working path, 125 where m or n can be 1. 127 This document provides requirements for any mechanism that would be 128 used to implement SMP for MPLS-TP data paths, in networks that 129 delegate protection switch coordination to the data plane. 131 2. Terminology and Notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 Although this document is not a protocol specification, the use of 138 this language clarifies the instructions to protocol designers 139 producing solutions that satisfy the requirements set out in this 140 document. 142 The terminology used in this document is based on the terminology 143 defined in the MPLS-TP Survivability Framework document [RFC6372] 144 which in-turn is based on [RFC4427]. 146 2.1. Acronyms 148 This document uses the following acronyms: 150 LSP Label Switched Path 151 SLA Service Level Agreement 152 SMP Shared Mesh Protection 153 SRLG Shared Risk Link Group 155 2.2. Terms Defined in This Document 156 This document defines the following terms: 158 SMP Protection Group: the set of different protection paths that 159 share a common segment. 161 3. Shared Mesh Protection Reference Model 163 As described in [RFC6372] Shared Mesh Protection (SMP) supports the 164 sharing of protection resources, while providing protection for 165 multiple working paths that need not have common endpoints and do not 166 share common points of failure. Note that some protection resources 167 may be shared, while some others may not be. An example of data paths 168 that employ SMP is shown in Figure 1. It shows two working paths 169 and that are protected employing 1:1 linear 170 protection by protection paths and respectively. The 171 two protection paths that traverse segment share the protection 172 resources on this segment. 174 A----B----C----D----E 175 \ / 176 \ / 177 \ / 178 P-----Q-----R 179 / \ 180 / \ 181 / \ 182 V----W----X----Y----Z 184 Figure 1: Basic SMP architecture 186 3.1. Protection or Restoration 188 [RFC6372], based upon the definitions in [RFC4427], differentiates 189 between "protection" and "restoration" dependent upon the dynamism of 190 the resource allocation. The same distinction is used in [RFC3945], 191 [RFC4426], and [RFC4428]. 193 This document also uses the same distinction between protection and 194 restoration as stated in [RFC6372]. 196 3.2. Scope of Document 198 [RFC5654] establishes that MPLS-TP SHOULD support shared protection 199 (Requirement 68) and that MPLS-TP MUST support sharing of protection 200 resources (Requirement 69). This document presents the network 201 objectives and a framework for applying SMP within an MPLS network, 202 without the use of control plane protocols. Although there are 203 existing control plane solutions for SMP within MPLS, a data plane 204 solution is required for networks that do not employ a full control 205 plane operation for some reason (e.g. service provider preferences or 206 limitations), or require service restoration faster than is 207 achievable with control plane mechanisms. 209 The network objectives will also address possible additional 210 restrictions of the behavior of SMP in networks that delegate 211 protection switching for resiliency to the data plane. Definition of 212 logic and specific protocol messaging is out of scope of this 213 document. 215 3.2.1. Relationship to MPLS 217 While some of the restrictions presented by this document originate 218 from the properties of transport networks, nothing prevents the 219 information presented here being applied to MPLS networks outside the 220 scope of the Transport Profile of MPLS. 222 4. SMP Architecture 224 Figure 1 shows a very basic configuration of working and protection 225 paths that may employ SMP. We may consider a slightly more complex 226 configuration, such as the one in Figure 2 in order to illustrate 227 characteristics of a mesh network that implements SMP. 229 A----B----C----D----E---N 230 \ / / \ 231 \ M ---/-- \ 232 \ / \ \ 233 P-----Q-----R-----S----T 234 /| \ \ \ \ 235 / F---G---H J--K---L \ 237 / \ 238 V------W-------X-------Y-------Z 240 Figure 2: Larger sample SMP architecture 242 Consider the network presented in Figure 2. There are five working 243 paths 245 - 247 - 249 - 251 - 253 - 255 Each of these has a corresponding protection path 257 - (p1) 259 - (p2) 261 - (p3) 263 - (p4) 265 - (p5) 267 The following segments are shared by two or more of the protection 268 paths - is shared by p1, p3, and p5, is shared by p1 and 269 p5, is shared by p4 and p5, and is shared by p2 and p5. In 270 Figure 2, we have the following SMP Protection Groups - {p1, p3, p5} 271 for , {p1, p5} for , {p4, p5} for , {p2, p5} for . 273 We assume that the available protection resources for these shared 274 segments are not sufficient to support the complete traffic capacity 275 of the respective working paths that may use the protection paths. We 276 can further observe that with a method of coordinating sharing and 277 preemption there is no co-routing constraints on shared components at 278 the segment level. 280 The use of preemption in the network is typically a business or 281 policy decision such that when protection resources are contended, 282 priority can be applied to determine which parties utilize the 283 protection resources. 285 As opposed to the case of simple linear protection, where the 286 relationship between the working and protection paths is defined and 287 the resources for the protection path are fully dedicated, the 288 protection path in the case of SMP consists of segments that are used 289 for the protection of the related working path and also segments that 290 are shared with other protection paths such that typically the 291 protection resources are oversubscribed to support working paths that 292 do not share common points of failure. What is required is a 293 preemption mechanism to implement business priority when multiple 294 failure scenarios occur. As such, the protection resources may be 295 allocated but would not be utilized until requested and resolved in 296 relation to other members of the SMP Protection Group as part of a 297 protection switchover. 299 [RFC6372] defines two types of preemption that can be considered for 300 how the resources of SMP Protection Groups, are shared. These are 301 "soft preemption" whereby traffic of lower priority paths is degraded 302 and "hard preemption" where traffic of lower priority paths is 303 completely blocked. The traffic of lower priority paths in this 304 document can be viewed as the extra traffic being preempted in 305 [RFC6372]. "Hard Preemption" requires the programming of selectors at 306 the ingress of each shared segment to specify the priorities of 307 backup paths, so that traffic of lower priority paths can be 308 preempted. When any protection mechanism whereby the protection end 309 point may have a choice of protection paths (e.g. m:n or m:1) is 310 deployed the shared segment selectors require coordination with the 311 protection end points as well. 313 Typical deployment of services that use SMP requires various network 314 planning activities. These include: 316 o Determining the number of working and protection paths required to 317 achieve resiliency targets for the service. 319 o Reviewing network topology to determine which working or 320 protection paths are required to be disjoint from each other, and 321 exclude specified resources such as links, nodes, or shared risk 322 link groups (SRLGs). 324 o Determining the size (bandwidth) of the shared resource 326 4.1. Coordination of Resources 328 When a protection switch is triggered, the SMP network performs two 329 operations - switch data traffic over to a protection path and 330 coordinate the utilization of the associated shared resources. Both 331 operations should occur at the same time, or as closely as possible 332 to provide fast protection. The resource utilization coordination is 333 dependent upon their availability at each of the shared segments. 335 When the reserved resources of the shared segments are utilized by a 336 particular protection path, there may not be sufficient resources 337 available for an additional protection path. This then implies that 338 if another working path of the SMP domain triggers a protection 339 switch, the resource utilization coordination may fail. The different 340 working paths in the SMP network are involved in the resource 341 utilization coordination, which is a part of whole SMP protection 342 switching coordination. 344 4.2. Control Plane or Data Plane 346 As stated in both [RFC6372] and [RFC4428], full control of SMP 347 including both configuration and the coordination of the protection 348 switching is potentially very complex. Therefore, it is suggested 349 that this be carried out under the control of a dynamic control plane 350 based on GMPLS [RFC3945]. Implementations for SMP with GMPLS exist 351 and the general principles of its operation are well known, if not 352 fully documented. 354 However, there are operators, in particular in the transport sector, 355 that do not operate their MPLS-TP networks under the control of a 356 control plane or for other reasons have delegated executive action 357 for resilience to the data plane, and require the ability to utilize 358 SMP protection. For such networks it is imperative that it be 359 possible to perform all required coordination of selectors and end 360 points for SMP via data plane operations. 362 5. SMP Network Objectives 364 5.1. Resource Reservation and Coordination 366 SMP is based on pre-configuration of the working paths and the 367 corresponding protection paths. This configuration may be based on 368 either a control protocol or static configuration by the management 369 system. However, even when the configuration is performed by a 370 control protocol, e.g. Generalized MPLS (GMPLS), the control 371 protocol SHALL NOT be used as the primary mechanism for detecting or 372 reporting network failures, or for initiating or coordinating 373 protection switch-over. That is, it SHALL NOT be used as the primary 374 resilience mechanism. 376 The protection relationship between the working and protection paths 377 SHOULD be configured and the shared segments of the protection path 378 MUST be identified prior to use of the protection paths. Relative 379 priority for working paths to be used to resolve contention for 380 protection path usage by multiple working paths MAY also be specified 381 ahead of time. 383 When a protection switch is triggered by any fault condition or 384 operator command, the SMP network MUST perform two operations - 385 switch data traffic over to a protection path and coordinate the 386 utilization of the associated shared resources. Both operations MUST 387 occur at the same time, or as closely as possible to provide fast 388 protection. 390 In the case of multiple working paths failing, the shared resource 391 utilization coordination SHALL be between the different working paths 392 in the SMP network. 394 5.1.1. Checking Resource Availability for Multiple protection Paths 396 In a hard-preemption scenario, when an end point identifies a 397 protection switching trigger and has more than one potential action 398 (e.g. m:1 protection) it MUST verify that the necessary protection 399 resources are available on the selected protection path. The 400 resources may not be available because they already have been 401 utilized for the protection of, for example, one or more higher 402 priority working paths. 404 5.2. Multiple Triggers 406 If more than one working path is triggering a protection switch such 407 that a protection segment is oversubscribed, there are two different 408 actions that the SMP network can choose - soft preemption and hard 409 preemption [RFC6372]. 411 5.2.1. Soft-preemption 413 For networks that support multiplexing packets over the shared 414 segments, the requirement is: 416 o All of the protection paths MAY be allowed to share the resources 417 of the shared segments 419 5.2.2. Hard-preemption 421 There are networks that require the exclusive use of the protection 422 resources when a protection segment is oversubscribed. Traffic of 423 lower priority paths is completely blocked. These include networks 424 that support the requirements in [RFC5654], and in particular support 425 requirement 58. For such networks, the following requirements apply: 427 1. Relative priority MAY be assigned to each of the working paths of 428 an SMP domain. If the priority is not assigned, the working paths 429 are assumed to have equal priority. 431 2. Resources of the shared segments SHALL be utilized by the 432 protection path according to the highest priority amongst those 433 requesting use of the resources. 435 3. If multiple protection paths of equal priority are requesting the 436 shared resources, the resources SHALL be utilized on a first come 437 first served basis. Traffic of the protection paths that request 438 the shared resources late SHALL be preempted. In order to cover 439 the situation where the first come first served principle cannot 440 resolve the contention among multiple equal priority requests, 441 i.e., when the requests occur simultaneously, tie-breaking rules 442 SHALL be defined in scope of an SMP domain. 444 4. If a higher priority path requires the protection resources that 445 are being utilized by a lower priority path, the resources SHALL 446 be utilized by the higher priority path. Traffic with the lower 447 priority SHALL be preempted. 449 5. Once resources of shared segments have been successfully utilized 450 by a protection path, the traffic on that protection path SHALL 451 NOT be interrupted by any protection traffic whose priority is 452 equal or lower than the protecting path currently in-use. 454 6. During preemption, shared segment resources MAY be used by both 455 existing traffic (that is being preempted) and higher priority 456 traffic. 458 5.3. Notification 460 When a working path endpoint has a protection switch triggered, it 461 SHOULD attempt to switch the traffic to the protection path and 462 request the coordination of the shared resource utilization. If the 463 necessary shared resources are unavailable, the endpoints of the 464 requesting working path SHALL be notified of protection switchover 465 failure, and switchover will not be completed. 467 Similarly, if preemption is supported and the resources currently 468 utilized by a particular working path are being preempted then the 469 endpoints of the affected working path whose traffic is being 470 preempted SHALL be notified that the resources are being preempted. 471 As described in [RFC6372], the event of preemption may be detected by 472 OAM and reported as a fault or a degradation of traffic delivery. 474 5.4. Reversion 475 When the condition that triggered the protection switch is cleared, 476 it is possible to either revert to using the working path resources 477 or continue to utilize the protection resources. Continuing the use 478 of protection resources allows the operator to delay the disruption 479 of service caused by the switchover until periods of lighter traffic. 480 The switchover would need to be performed via an explicit operator 481 command unless the protection resources are preempted by a higher 482 priority fault. Hence, both automatic and manual revertive behaviors 483 MUST be supported for hard-preemption in an SMP domain. Normally the 484 network should revert to use of the working path resources in order 485 to clear the protection resources for protection of other path 486 triggers. However, the protocol MUST support non-revertive 487 configurations. 489 5.5. Protection Switching Time 491 Protection switching time refers to the transfer time (Tt) defined in 492 [G.808.1] and recovery switching time defined in [RFC4427], and is 493 defined as the interval after a switching trigger is identified until 494 the traffic begins to be transmitted on the protection path. This 495 time does not include the time needed to initiate the protection 496 switching process after a failure occurred, and the time needed to 497 complete preemption of existing traffic on the shared segments as 498 described in Section 4.2. The time needed to initiate the protection 499 switching process, which is known as detection and correlation time 500 in [RFC4427], is related to the OAM or management process, but the 501 time needed to complete preemption is related to the actions within 502 an SMP domain. Support for a protection switching time of 50ms is 503 dependent upon the initial switchover to the protection path, but the 504 preemption time SHOULD also be taken into account to minimize total 505 service interruption time. 507 When triggered, protection switching action SHOULD be initiated 508 immediately to minimize service interruption time. 510 5.6. Timers 512 In order to prevent multiple switching actions for a single switching 513 trigger, when there are multiple layers of networks, SMP SHOULD be 514 controlled by a hold-off timer that would allow lower layer 515 mechanisms to complete their switching actions before invoking SMP 516 protection actions as described in [RFC6372]. 518 In order to prevent an unstable recovering working path from invoking 519 intermittent switching operation, SMP SHOULD employ a wait-to-restore 520 timer during any reversion switching as described in [RFC6372]. 522 5.7. Communication Channel and Fate Sharing 523 SMP SHOULD provide a communication channel, along the protection 524 path, between the endpoints of the protection path to support fast 525 protection switching. 527 SMP in hard-preemption mode SHOULD include support for communicating 528 information to coordinate the use of the shared protection resources 529 among multiple working paths. The message encoding and communication 530 channel between the nodes of the shared protection resource and the 531 endpoints of the protection path are out of the scope of this 532 document. 534 Bidirectional protection switching SHOULD be supported in SMP. 536 6. Manageability Considerations 538 The network management architecture and requirements for MPLS-TP are 539 specified in [RFC5951]. They derive from the generic specifications 540 described in ITU-T G.7710/Y.1701 [G.7710] for transport technologies. 541 This document does not introduce any new manageability requirements 542 beyond those covered in those documents. 544 7. Security Considerations 546 General security considerations for MPLS-TP are covered in [RFC5921]. 547 The security considerations for the generic associated control 548 channel are described in [RFC5586]. 550 Security considerations for any proposed solution should consider 551 exhaustion of resources related to preemption, especially by a 552 malicious actor as a threat vector to protect against. Protections 553 should also be considered to prevent a malicious actor from 554 attempting to cause an alternate path to force traffic by a 555 sensor/device, thereby enabling pervasive monitoring [RFC7258]. 557 8. IANA Considerations 559 This document makes no request of IANA. 561 Note to RFC Editor: this section may be removed on publication as an 562 RFC. 564 9. Acknowledgements 566 This document is the outcome of discussions on Shared Mesh Protection 567 for MPLS-TP. The authors would like to thank all contributors to 568 these discussions, and especially Eric Osborne for facilitating them. 570 We would also like to thank Matt Hartley for working on the English 571 review and Lou Berger for his valuable comments and suggestions on 572 this document. 574 10. Normative References 576 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", BCP 14, RFC 2119, March 1997. 579 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 580 (GMPLS) Architecture", RFC 3945, Oct 2004. 582 [RFC4426] Lang, J., Rajagopalan, B., and Papadimitriou, D.E. "GMPLS 583 Recovery Functional Specification", RFC 4426, March 2006. 585 [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and 586 Restoration) Terminology for GMPLS", RFC 4427, March 2006. 588 [RFC4428] Mannie, E. and D. Papadimitriou, "Analysis of Generalized 589 Multi-Protocol Label Switching (GMPLS)-based Recovery 590 Mechanisms (including Protection and Restoration)", 591 RFC 4428, March 2006. 593 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 594 "MPLS Generic Associated Channel", RFC 5586, June 2009. 596 [RFC5654] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 597 "Requirements for the Transport Profile of MPLS", 598 RFC 5654, Sept 2009. 600 [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, 601 L., and L. Berger, "A Framework for MPLS in Transport 602 Networks", RFC 5921, July 2010. 604 [RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management 605 Requirements for MPLS-based Transport Networks", RFC 5951, 606 September 2010. 608 [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability 609 Framework", RFC 6372, Sept 2011. 611 [RFC6378] Sprecher, N., Bryant, S., Osborne, E., Fulignoli, A., and 612 Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378, 613 Nov 2011. 615 [RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., 616 Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS- 617 TP) Linear Protection to Match the Operational 618 Expectations of Synchronous Digital Hierarchy, Optical 619 Transport Network, and Ethernet Transport Network 620 Operators", RFC 7271, June 2014. 622 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 623 Attack", RFC 7258, May 2014. 625 [G.808.1] ITU, "Generic Protection Switching - Linear trail and 626 subnetwork protection", ITU-T G.808.1, May 2014. 628 11. Contributing Authors 630 David Allan 631 Ericsson 632 Email: david.i.allan@ericsson.com 634 Daniel King 635 Old Dog Consulting 636 Email: daniel@olddog.co.uk 638 Taesik Cheung 639 ETRI 640 Email: cts@etri.re.kr 642 12. Authors' Addresses 644 Yaacov Weingarten 645 34 Hagefen St. 646 Karnei Shomron, 4485500 647 Israel 649 Email: wyaacov@gmail.com 651 Sam Aldrin 652 Huawei Technologies 653 2330 Central Express Way 654 Santa Clara, CA 95951 655 United States 657 Email: aldrin.ietf@gmail.com 659 Ping Pan 660 Infinera 662 Email: ppan@infinera.com 663 Jeong-dong Ryoo 664 ETRI 665 218 Gajeongno 666 Yuseong, Daejeon 305-700 667 South Korea 669 Email: ryoo@etri.re.kr 671 Greg Mirsky 672 Ericsson 674 Email: gregory.mirsky@ericsson.com