RFC 9270

GMPLS Signaling Extensions for Shared Mesh Protection

📅 published August 2022, from ietf

RFC 9270 💖 GMPLS Signaling Extensions for Shared Mesh Protection

Okay bestie, this is RFC 9270 🎀 and it's all about making GMPLS signaling work for Shared Mesh Protection. Here's the title block tea ☕:

  • Stream: Internet Engineering Task Force (IETF) 🌸
  • Authors: J. He, I. Busi (Huawei Technologies), J. Ryoo, B. Yoon (ETRI), and P. Park (KT) 🫶
  • Category: Standards Track 👑 (ISSN: 2070-1721)
  • Date: August 2022 📅
  • Updates: RFC 4872 and RFC 4873 ✨
  • Obsoletes: none listed 🦋

Abstract 🦋

Okay so ITU-T Recommendation G.808.3 is the one that defines the generic aspects of a Shared Mesh Protection (SMP) mechanism, and it also spells out the difference between SMP and Shared Mesh Restoration (SMR) 👀. Then ITU-T Recommendation G.873.3 covers the protection switching operation and the associated protocol for SMP at the Optical Data Unit (ODU) layer. And RFC 7412 gives the requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network 💅.

This document updates RFCs 4872 and 4873 to add extensions for Generalized Multi-Protocol Label Switching (GMPLS) signaling so you can control the SMP mechanism 🔥.

Status of This Memo 🌈

This is an Internet Standards Track document 👑.

It's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🧚.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9270 💜.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as laid out in the Revised BSD License 💅.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications of it outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🫶.

Table of Contents 🧚

   1.  Introduction
   2.  Conventions Used in This Document
   3.  SMP Definition
   4.  Operation of SMP with GMPLS Signaling Extensions
   5.  GMPLS Signaling Extensions for SMP
     5.1.  Identifiers
     5.2.  Signaling Primary LSPs
     5.3.  Signaling Secondary LSPs
     5.4.  SMP Preemption Priority
     5.5.  Availability of Shared Resources: The Notify Message
     5.6.  SMP APS Configuration
   6.  Updates to PROTECTION Object
     6.1.  New Protection Type
     6.2.  Updates to Definitions of Notification and Operational Bits
     6.3.  Preemption Priority
   7.  IANA Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction ✨

Okay so RFC 4872 [RFC4872] defines extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration (SMR) mechanisms 💖. SMR is basically a special case of preplanned Label Switched Path (LSP) rerouting that cuts down on recovery resources by letting multiple protecting LSPs share common link and node resources 🦋. The recovery resources for the protecting LSPs get pre-reserved during the provisioning phase. Then explicit restoration signaling is required to activate a specific protecting LSP that was set up during provisioning, which means committing the resource allocation at the data plane 🔥. And RFC 4873 [RFC4873] details the encoding of the last 32-bit Reserved field of the PROTECTION object defined in [RFC4872] 👑.

ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a Shared Mesh Protection (SMP) mechanism. These aren't tied to any one network technology, so they cover things like architecture types, preemption principles, and path monitoring methods 🌸. ITU-T Recommendation G.873.3 [G873.3] covers the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer 💅. And RFC 7412 [RFC7412] gives requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - Transport Profile (MPLS-TP) network 🧚.

SMP and SMR differ in how they do activation and protection switching. SMP activates a protecting LSP through the Automatic Protection Switching (APS) protocol in the data plane when the working LSP fails. SMR does the same job through control plane signaling 🙈. So during provisioning you need to tell SMP apart from SMR, which lets each node involved behave correctly in the recovery phase when a protecting LSP gets activated. SMP also has an edge on recovery speed compared with SMR ⚡.

This document updates [RFC4872] and [RFC4873] to add extensions for Generalized Multi-Protocol Label Switching (GMPLS) signaling, so you can control the SMP mechanism 💜. Specifically, it:

  • defines a new LSP Protection Type, "Shared Mesh Protection", for the LSP Flags field [RFC4872] of the PROTECTION object (see Section 6.1) 🎀,
  • updates the definitions of the Notification (N) and Operational (O) fields [RFC4872] of the PROTECTION object so they take the new SMP type into account (see Section 6.2) 🌈, and
  • updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object so 8 bits get allocated to signal the SMP preemption priority (see Section 6.3) 👑.

Only the generic aspects of signaling SMP are covered in this document. The technology-specific aspects are expected to be handled by other documents 🦋.

RFC 8776 [RFC8776] defines a collection of common YANG data types for Traffic Engineering (TE) configuration and state capabilities. It defines several identities for LSP Protection Types. Since this document introduces a new LSP Protection Type, [RFC8776] is expected to be updated to support the SMP mechanism specified here 🫶. [YANG-TE] defines a YANG data model for provisioning and managing TE tunnels, LSPs, and interfaces, and it includes some protection and restoration data nodes that are relevant to this document ✨. Management aspects of the SMP mechanism are outside the scope of this document, and they're expected to be covered by other documents 💅.

2. Conventions Used in This Document 🌸

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔥.

Also, the reader is assumed to already know the terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372] 🧚.

3. SMP Definition 💖

[G808.3] defines the generic aspects of an SMP mechanism. [G873.3] defines the protection switching operation and associated protocol for SMP at the ODU layer. [RFC7412] gives requirements for any mechanism that would be used to implement SMP in an MPLS-TP network 🦋.

The SMP mechanism is based on precomputed protecting LSPs that are preconfigured into the network elements 🎀. Preconfiguration here means pre-reserving resources for the protecting LSPs without activating a particular protecting LSP. For example, in circuit networks, the cross-connects in the intermediate nodes of the protecting LSP are not preestablished 🙈. Preconfiguring without activating the protecting LSPs lets link and node resources get shared by the protecting LSPs of multiple working LSPs. Those working LSPs are disjoint from each other, so they're unlikely to fail at the same time 👑. Protecting LSPs get activated in response to working LSP failures or operator commands, using the APS protocol, which runs in the data plane 💅. The APS protocol messages are exchanged along the protecting LSP. And SMP is always revertive 🌈.

SMP is very similar to SMR. The one big difference is how activation works: with SMR it happens through control plane signaling during the recovery operation, while with SMP the APS protocol in the data plane takes care of it ✨.

4. Operation of SMP with GMPLS Signaling Extensions ✨

Okay bestie, let's look at this topology 🦋 It's giving mesh energy:

                             A---B---C---D
                              \         /
                               E---F---G
                              /         \
                             H---I---J---K

                  Figure 1: An Example of an SMP Topology

So the working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC 3209 [RFC3209], to get resource sharing while these protecting LSPs are being signaled, they're supposed to have the same Tunnel Endpoint Address (it lives in their SESSION object) 💅 But in this example, the addresses are not the same, ngl. So, just like SMR, this document defines a new LSP Protection Type for the secondary LSP called "Shared Mesh Protection" (see Section 6.1) 🔥 That's what lets resources get shared along nodes E, F, and G. Shared resources can be things like a link's capacity or the cross-connects in a node. In this setup the protecting LSPs don't get merged (which is useful, since the paths split apart at G), but E, F, and G can still share their resources 🌸

Now say a failure happens, like Signal Fail (SF) or Signal Degrade (SD), on one of the working LSPs (let's say working LSP [A,B,C,D]). The end node that spots the failure (node A, in this story) kicks off the protection switching operation 😭 Node A sends a protection switching request APS message (like SF) to its adjacent (downstream) intermediate node (node E, say) to activate the matching protecting LSP. Then it waits for a confirmation message from node E 🫶

If the protection resource is available, node E sends the confirmation APS message back to the end node (node A) and forwards the switching request APS message to its adjacent (downstream) node (node F, say). When node A receives the confirmation APS message, the cross-connection on node A gets established. At that point, traffic is bridged to and selected from the protecting LSP at node A ✨ After forwarding the switching request APS message, node E waits for a confirmation APS message from node F. Once that shows up, node E sets up the cross-connection for the protecting LSP being activated 🎀

If the protection resource is not available (because it failed or because higher-priority connections are using it), the switch won't succeed. The intermediate node (node E here) MUST send a message to notify the end node (node A) (see Section 5.5) 🙈 If the resource is being used by a lower-priority protecting LSP, that lower-priority service gets removed, and then the intermediate node follows the same procedure it would if the resource were available for the higher-priority protecting LSP 👑

If node E fails to allocate the protection resource, it MUST send a message to notify node A (see Section 5.5). Then node A stops bridging and selecting traffic to/from the protecting LSP and goes through the steps for removing the protection allocation, following the APS protocol 🧚

5. GMPLS Signaling Extensions for SMP 🌈

The subsections below break down how LSPs using SMP can be signaled in an interoperable way with GMPLS RSVP-TE extensions (see RFC 3473 [RFC3473]). This signaling enables:

  1. the ability to identify a "secondary protecting LSP" (LSP [A,E,F,G,D] or LSP [H,E,F,G,K] from Figure 1, here called the "secondary LSP") used to recover another "primary working LSP" (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, here called the "protected LSP"),
  2. the ability to associate the secondary LSP with the protected LSP,
  3. the capability to include information about the resources used by the protected LSP while instantiating the secondary LSP,
  4. the capability to instantiate several secondary LSPs efficiently during the provisioning phase, and
  5. the capability to support activation of a secondary LSP via the APS protocol in the data plane if a failure occurs.

5.1. Identifiers

To keep association simple, both LSPs (the protected LSP and the secondary LSP) belong to the same session. So the SESSION object MUST be the same for both LSPs 💖 The LSP ID, though, MUST be different so you can tell the protected LSP and the secondary LSP apart.

A new LSP Protection Type, "Shared Mesh Protection", is defined (see Section 6.1) for the LSP Flags field of the PROTECTION object (see [RFC4872]) so the two LSPs can be set up. This LSP Protection Type value only applies to bidirectional LSPs, as required in [G808.3] 🦋

5.2. Signaling Primary LSPs

The PROTECTION object (see [RFC4872]) gets included in the Path message while the primary working LSPs are being signaled, with the LSP Protection Type value set to "Shared Mesh Protection" 🍓

Primary working LSPs are signaled by setting the S bit to 0, the P bit to 0, and the N bit to 1 in the PROTECTION object. In the ASSOCIATION object, the Association ID gets set to the associated secondary protecting LSP_ID ✨

   |  Note: The N bit is set to indicate that the protection
   |  switching signaling is done via the data plane.

5.3. Signaling Secondary LSPs

The PROTECTION object (see [RFC4872]) gets included in the Path message while the secondary protecting LSPs are being signaled, with the LSP Protection Type value set to "Shared Mesh Protection" 💜

Secondary protecting LSPs are signaled by setting the S bit, the P bit, and the N bit to 1 in the PROTECTION object. In the ASSOCIATION object, the Association ID gets set to the associated primary working LSP_ID, which MUST be known before the secondary LSP is signaled. Also, the Path message used to instantiate the secondary LSP MUST include at least one PRIMARY_PATH_ROUTE object (see [RFC4872]), which allows recovery resource sharing at each intermediate node along the secondary path 🧚

With this setting, the resources for the secondary LSP MUST be pre-reserved but not committed at the data plane level. That means the internals of the switch don't need to be set up until someone explicitly takes action to activate this LSP. Activating a secondary LSP, and switching protection over to the activated protecting LSP, is done using the APS protocol in the data plane 🌸

After protection switching completes, the protecting LSP MUST be signaled by setting the S bit to 0 and the O bit to 1 in the PROTECTION object. At this point, the link and node resources MUST be allocated for this LSP, which becomes a primary LSP (ready to carry traffic) 👑 The formerly working LSP MAY be signaled with the A bit set in the ADMIN_STATUS object (see [RFC3473]).

Support for extra traffic in SMP is left for further study. So mechanisms for setting up LSPs for extra traffic are outside the scope of this document 🙈

5.4. SMP Preemption Priority

The SMP preemption priority of a protecting LSP is what the APS protocol uses to settle competition for shared resources among multiple protecting LSPs. It's indicated in the Preemption Priority field of the PROTECTION object in the protecting LSP's Path message 🔥

The Setup and Holding priorities in the SESSION_ATTRIBUTE object can be used by GMPLS to control LSP preemption. But the APS does not use them to resolve competition among multiple protecting LSPs. This avoids the mess of defining a complicated policy for Setup and Holding priorities that would have to serve both GMPLS control plane LSP preemption and SMP shared resource competition resolution 💅

When an intermediate node on the protecting LSP receives the Path message, the priority value in the Preemption Priority field MUST be stored for that protecting LSP. When resource competition among multiple protecting LSPs happens, the APS protocol uses their priority values to resolve it. A lower value has a higher priority 🎀

In SMP, a preempted LSP MUST NOT be terminated, even after its resources have been deallocated. Once the working LSP and the protecting LSP are configured or preconfigured, the end node MUST keep refreshing both the working and protecting LSPs, regardless of failure or preemption status 😭

5.5. Availability of Shared Resources: The Notify Message

When a lower-priority protecting LSP gets preempted, the intermediate node that did the preempting MUST send a Notify message with error code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared resources unavailable" (17) to the end nodes of that protecting LSP. When the end node gets this Notify message, it MUST stop sending and selecting traffic to/from its protecting LSP and try switching the traffic to another protecting LSP, if one is available ✨

When a protecting LSP is occupying the shared resources and they become unavailable, the intermediate node MUST generate the same Notify message to all the end nodes of protecting LSPs that have lower SMP preemption priorities than the one occupying the shared resources. If the shared resources become unavailable because of a failure in the shared resources, the intermediate node MUST generate the same Notify message to all the end nodes of protecting LSPs that have been configured to use the shared resources. In the case of a failure of the working LSP, these end nodes MUST avoid trying to switch traffic to those protecting LSPs that have been configured to use the shared resources, and they try switching the traffic to other protecting LSPs, if available 🙈

When the shared resources become available again, the intermediate node MUST generate a Notify message with error code "Notify Error" (25) and error sub-code "Shared resources available" (18). The recipients of this Notify message are the end nodes of the lower-priority protecting LSPs that were preempted, and/or all the end nodes of protecting LSPs with lower SMP preemption priorities than the one that no longer needs the shared resources. When an end node receives this Notify message, it is allowed to reinitiate the protection switching operation as described in Section 4, if it still needs the protection resource 🦋

5.6. SMP APS Configuration

SMP relies on APS protocol messages being exchanged between the nodes along the path to activate a protecting LSP 🌈

To allow those APS protocol messages to be exchanged, an APS channel has to be configured between adjacent nodes along the path of the protecting LSP. This is done by means other than GMPLS signaling, before any protecting LSP has been set up. So there are likely additional requirements for APS configuration that are outside the scope of this document 💖

Depending on the APS protocol message format, the APS protocol may use different identifiers than GMPLS signaling does to identify the protecting LSP 🧚

Since the APS protocol is left for further study per [G808.3], it can be assumed that the APS message format and identifiers are technology specific and/or vendor specific. Therefore, additional requirements for APS configuration are outside the scope of this document 🫶

6. Updates to PROTECTION Object 🎀

GMPLS extension requirements for SMP introduce several updates to the PROTECTION object (see [RFC4872]), as detailed below 💅

6.1. New Protection Type ✨

Okay so a brand-new LSP Protection Type called "Shared Mesh Protection" is getting added to the PROTECTION object 💖 and it is only for bidirectional LSPs, bestie. The flag value is:

   LSP (Protection Type) Flags:

      0x20: Shared Mesh Protection

The rules in Section 14.2 of [RFC4872] make sure every node along an SMP LSP is SMP aware 🫶 so there are no backward-compatibility issues. Iconic, honestly.

6.2. Updates to Definitions of Notification and Operational Bits 🔥

So the N and O bit definitions from Section 14.1 of [RFC4872] are getting a glow-up 💅 and here's the new tea.

Notification (N): 1 bit 🎀

When it's set to 1, this bit tells you the control plane message exchange is only used for notification during protection switching. When it's set to 0 (default), the control plane message exchanges are used for purposes of protection switching. 🌸

The N bit only matters when the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). In any other case, the N bit MUST be set to 0. And if it's 0x20 (SMP), the N bit MUST be set to 1. No wiggle room, periodt 💀

Operational (O): 1 bit 🦋

When it's set to 1, this bit means the protecting LSP is carrying traffic after protection switching. The O bit only applies when (1) the P bit is set to 1 and (2) the LSP Protection Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or 0x20 (Shared Mesh Protection). In any other case, the O bit MUST be set to 0. 🧚

6.3. Preemption Priority 🌸

Okay so [RFC4872] reserved a 32-bit field in the PROTECTION object header 👑 and then [RFC4873] grabbed a few bits from it and left the rest reserved. Now this spec is taking the Preemption Priority field out of those leftover reserved bits. The 32-bit field, as defined in [RFC4872] and tweaked by [RFC4873], now looks like this:

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |I|R|   Reserved    | Seg.Flags |   Reserved    | Preempt Prio  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Preemption Priority (Preempt Prio): 8 bits 💜

This field tells you the SMP preemption priority of a protecting LSP, when the LSP Protection Type field says "Shared Mesh Protection". A network operator sets the SMP preemption priority value at the end nodes of the protecting LSP. A lower value means a higher priority. How many priority levels an SMP network should actually use is up to the network operators 🫠

See [RFC4873] for the definitions of the other fields. Go read it, it's giving thorough 📚

7. IANA Considerations 🦋

IANA maintains a group of registries called "Resource Reservation Protocol (RSVP) Parameters", and that group includes the "Error Codes and Globally-Defined Error Value Sub-Codes" registry. IANA added the following values to the "Sub-Codes - 25 Notify Error" subregistry, which lists the error value sub-codes that may be used with error code 25. IANA has allocated the error value sub-codes in Table 1 for use with this error code, as described in this document. 🌈

+=======+==============================+===========+
| Value | Description                  | Reference |
+=======+==============================+===========+
| 17    | Shared resources unavailable | RFC 9270  |
+-------+------------------------------+-----------+
| 18    | Shared resources available   | RFC 9270  |
+-------+------------------------------+-----------+

Table 1: New Error Sub-Codes

8. Security Considerations 🔒

Okay bestie, this part is serious, so read it carefully 🙈

Since this document uses RSVP messages that include a Notify message, the security threats discussed in [RFC4872] also apply to this document. Full stop.

Also, it may be possible to disrupt traffic on one protecting LSP by targeting a link that's used by the primary LSP of a different, higher-priority LSP somewhere else in the network 😭 For example, in Figure 1, assume the preemption priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K], and the protecting LSP [H,E,F,G,K] is carrying traffic. If link B-C gets attacked, traffic on LSP [H,E,F,G,K] can be disrupted. So it's super important to use the security mechanisms discussed in [RFC4872], and also to remember that detailed knowledge of a network's topology, including routes and LSP priorities, can help an attacker aim better or make an attack work better. Not me giving the attacker a roadmap 💀

9. References 📚

9.1. Normative References

[G808.3]   International Telecommunication Union, "Generic protection
           switching - Shared mesh protection", ITU-T Recommendation
           G.808.3, October 2012,
           <https://www.itu.int/rec/T-REC-G.808.3>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
           <https://www.rfc-editor.org/info/rfc3209>.

[RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Signaling Resource ReserVation Protocol-
           Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
           DOI 10.17487/RFC3473, January 2003,
           <https://www.rfc-editor.org/info/rfc3473>.

[RFC4426]  Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
           Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
           Recovery Functional Specification", RFC 4426,
           DOI 10.17487/RFC4426, March 2006,
           <https://www.rfc-editor.org/info/rfc4426>.

[RFC4872]  Lang, J P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
           Ed., "RSVP-TE Extensions in Support of End-to-End
           Generalized Multi-Protocol Label Switching (GMPLS)
           Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
           <https://www.rfc-editor.org/info/rfc4872>.

[RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
           "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
           May 2007, <https://www.rfc-editor.org/info/rfc4873>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[G873.3]   International Telecommunication Union, "Optical transport
           network - Shared mesh protection", ITU-T Recommendation
           G.873.3, September 2017,
           <https://www.itu.int/rec/T-REC-G.873.3-201709-I/en>.

[RFC6372]  Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
           Profile (MPLS-TP) Survivability Framework", RFC 6372,
           DOI 10.17487/RFC6372, September 2011,
           <https://www.rfc-editor.org/info/rfc6372>.

[RFC7412]  Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.
           Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP)
           Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412,
           December 2014, <https://www.rfc-editor.org/info/rfc7412>.

[RFC8776]  Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
           "Common YANG Data Types for Traffic Engineering",
           RFC 8776, DOI 10.17487/RFC8776, June 2020,
           <https://www.rfc-editor.org/info/rfc8776>.

[YANG-TE]  Saad, T., Gandhi, R., Liu, X., Beeram, V.P., Bryskin, I.,
           and O. Gonzalez de Dios, "A YANG Data Model for Traffic
           Engineering Tunnels, Label Switched Paths and Interfaces",
           Work in Progress, Internet-Draft, draft-ietf-teas-yang-te-
           30, 11 July 2022, <https://datatracker.ietf.org/doc/html/
           draft-ietf-teas-yang-te-30>.

Acknowledgements 🫶

The authors want to thank Adrian Farrel, Vishnu Pavan Beeram, Tom Petch, Ines Robles, John Scudder, Dale Worley, Dan Romascanu, Éric Vyncke, Roman Danyliw, Paul Wouters, Lars Eggert, Francesca Palombini, and Robert Wilton for their valuable comments and suggestions on this document. Real ones, thank you all 💖

Contributors 💜

The following person contributed significantly to the content of this document and should be considered a coauthor. Iconic contribution, no notes 👑

Yuji Tochio
Fujitsu
Email: tochio@fujitsu.com

Authors' Addresses 🌈

Jia He
Huawei Technologies
F3-1B, R&D Center, Huawei Industrial Base
Bantian, Longgang District
Shenzhen
China
Email: hejia@huawei.com

Italo Busi
Huawei Technologies
Email: italo.busi@huawei.com

Jeong-dong Ryoo
ETRI
218 Gajeongno
Yuseong-gu
Daejeon
34129
South Korea
Phone: +82-42-860-5384
Email: ryoo@etri.re.kr

Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr

Peter Park
KT
Email: peter.park@kt.com
📦 where this page comes from