rfc9270.original   rfc9270.txt 
TEAS Working Group J. He Internet Engineering Task Force (IETF) J. He
Internet-Draft I. Busi Request for Comments: 9270 I. Busi
Updates: 4872, 4873 (if approved) Huawei Technologies Updates: 4872, 4873 Huawei Technologies
Intended status: Standards Track J. Ryoo Category: Standards Track J. Ryoo
Expires: October 21, 2022 B. Yoon ISSN: 2070-1721 B. Yoon
ETRI ETRI
P. Park P. Park
KT KT
April 19, 2022 August 2022
GMPLS Signaling Extensions for Shared Mesh Protection GMPLS Signaling Extensions for Shared Mesh Protection
draft-ietf-teas-gmpls-signaling-smp-12
Abstract Abstract
ITU-T Recommendation G.808.3 defines the generic aspects of a Shared ITU-T Recommendation G.808.3 defines the generic aspects of a Shared
Mesh Protection (SMP) mechanism, where the difference between SMP and Mesh Protection (SMP) mechanism, where the difference between SMP and
Shared Mesh Restoration (SMR) is also identified. ITU-T Shared Mesh Restoration (SMR) is also identified. ITU-T
Recommendation G.873.3 defines the protection switching operation and Recommendation G.873.3 defines the protection switching operation and
associated protocol for SMP at the Optical Data Unit (ODU) layer. associated protocol for SMP at the Optical Data Unit (ODU) layer.
RFC 7412 provides requirements for any mechanism that would be used RFC 7412 provides requirements for any mechanism that would be used
to implement SMP in a Multi-Protocol Label Switching - Transport to implement SMP in a Multi-Protocol Label Switching - Transport
Profile (MPLS-TP) network. Profile (MPLS-TP) network.
This document updates RFC 4872 and RFC 4873 to provide the extensions This document updates RFCs 4872 and 4873 to provide extensions for
to the Generalized Multi-Protocol Label Switching (GMPLS) signaling Generalized Multi-Protocol Label Switching (GMPLS) signaling to
to support the control of the SMP. support the control of the SMP mechanism.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on October 21, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9270.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Revised BSD License. in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document
3. SMP Definition . . . . . . . . . . . . . . . . . . . . . . . 4 3. SMP Definition
4. Operation of SMP with GMPLS Signaling Extension . . . . . . . 5 4. Operation of SMP with GMPLS Signaling Extensions
5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 6 5. GMPLS Signaling Extensions for SMP
5.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Identifiers
5.2. Signaling Primary LSPs . . . . . . . . . . . . . . . . . 7 5.2. Signaling Primary LSPs
5.3. Signaling Secondary LSPs . . . . . . . . . . . . . . . . 7 5.3. Signaling Secondary LSPs
5.4. SMP Preemption Priority . . . . . . . . . . . . . . . . . 8 5.4. SMP Preemption Priority
5.5. Notifying Availability of Shared Resources . . . . . . . 8 5.5. Availability of Shared Resources: The Notify Message
5.6. SMP APS Configuration . . . . . . . . . . . . . . . . . . 9 5.6. SMP APS Configuration
6. Updates to PROTECTION Object . . . . . . . . . . . . . . . . 10 6. Updates to PROTECTION Object
6.1. New Protection Type . . . . . . . . . . . . . . . . . . . 10 6.1. New Protection Type
6.2. Updates on Notification and Operational Bits . . . . . . 10 6.2. Updates to Definitions of Notification and Operational Bits
6.3. Preemption Priority . . . . . . . . . . . . . . . . . . . 11 6.3. Preemption Priority
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References
10. Contributor . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 Acknowledgements
11.2. Informative References . . . . . . . . . . . . . . . . . 13 Contributors
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses
1. Introduction 1. Introduction
RFC 4872 [RFC4872] defines extension of Resource Reservation Protocol RFC 4872 [RFC4872] defines extensions for Resource Reservation
- Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration Protocol - Traffic Engineering (RSVP-TE) to support Shared Mesh
(SMR) mechanisms. SMR can be seen as a particular case of pre- Restoration (SMR) mechanisms. SMR can be seen as a particular case
planned Label Switched Path (LSP) rerouting that reduces the recovery of preplanned Label Switched Path (LSP) rerouting that reduces the
resource requirements by allowing multiple protecting LSPs to share recovery resource requirements by allowing multiple protecting LSPs
common link and node resources. The recovery resources for the to share common link and node resources. The recovery resources for
protecting LSPs are pre-reserved during the provisioning phase, and the protecting LSPs are pre-reserved during the provisioning phase,
explicit restoration signaling is required to activate (i.e., commit and explicit restoration signaling is required to activate (i.e.,
resource allocation at the data plane) a specific protecting LSP that commit resource allocation at the data plane) a specific protecting
was instantiated during the provisioning phase. RFC 4873 [RFC4873] LSP that was instantiated during the provisioning phase. RFC 4873
details the encoding of the last 32-bit Reserved field of the [RFC4873] details the encoding of the last 32-bit Reserved field of
PROTECTION object defined in [RFC4872] the PROTECTION object defined in [RFC4872].
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of
a shared mesh protection (SMP) mechanism, which are not specific to a a Shared Mesh Protection (SMP) mechanism, which are not specific to a
particular network technology in terms of architecture types, particular network technology in terms of architecture types,
preemption principle, and path monitoring methods, etc. ITU-T preemption principle, path monitoring methods, etc. ITU-T
Recommendation G.873.3 [G873.3] defines the protection switching Recommendation G.873.3 [G873.3] defines the protection switching
operation and associated protocol for SMP at the Optical Data Unit operation and associated protocol for SMP at the Optical Data Unit
(ODU) layer. RFC 7412 [RFC7412] provides requirements for any (ODU) layer. RFC 7412 [RFC7412] provides requirements for any
mechanism that would be used to implement SMP in a Multi-Protocol mechanism that would be used to implement SMP in a Multi-Protocol
Label Switching - Transport Profile (MPLS-TP) network. Label Switching - Transport Profile (MPLS-TP) network.
SMP differs from SMR in the activation/protection switching SMP differs from SMR in the activation/protection switching
operation. The former activates a protecting LSP via the automatic operation. The former activates a protecting LSP via the Automatic
protection switching (APS) protocol in the data plane when the Protection Switching (APS) protocol in the data plane when the
working LSP fails, while the latter does it via control plane working LSP fails, while the latter does it via control plane
signaling. It is therefore necessary to distinguish SMP from SMR signaling. It is therefore necessary to distinguish SMP from SMR
during provisioning so that each node involved behaves appropriately during provisioning so that each node involved behaves appropriately
in the recovery phase when activation of a protecting LSP is done. in the recovery phase when activation of a protecting LSP is done.
SMP has advantages with regard to the recovery speed compared with SMP has advantages with regard to the recovery speed compared with
SMR. SMR.
This document updates [RFC4872] and [RFC4873] to provide the This document updates [RFC4872] and [RFC4873] to provide extensions
extensions to the Generalized Multi-Protocol Label Switching (GMPLS) for Generalized Multi-Protocol Label Switching (GMPLS) signaling to
signaling to support the control of the SMP mechanism. Specifically, support the control of the SMP mechanism. Specifically, it
it;
o defines a new LSP protection type, "Shared Mesh Protection," for * defines a new LSP Protection Type, "Shared Mesh Protection", for
the LSP Flags field [RFC4872] of the PROTECTION object (see the LSP Flags field [RFC4872] of the PROTECTION object (see
Section 6.1), Section 6.1),
o updates the definitions of the Notification (N) and Operational * updates the definitions of the Notification (N) and Operational
(O) fields [RFC4872] of the PROTECTION object to take the new SMP (O) fields [RFC4872] of the PROTECTION object to take the new SMP
type into account (see Section 6.2), and type into account (see Section 6.2), and
o updates the definition of the 16-bit Reserved field [RFC4873] of * updates the definition of the 16-bit Reserved field [RFC4873] of
the PROTECTION object to allocate 8 bits to signal the SMP the PROTECTION object to allocate 8 bits to signal the SMP
preemption priority (see Section 6.3). preemption priority (see Section 6.3).
Only the generic aspects for signaling SMP are addressed by this Only the generic aspects for signaling SMP are addressed by this
document. The technology-specific aspects are expected to be document. The technology-specific aspects are expected to be
addressed by other documents. addressed by other documents.
RFC 8776 [RFC8776] defines a collection of common YANG data types for RFC 8776 [RFC8776] defines a collection of common YANG data types for
Traffic Engineering (TE) configuration and state capabilities. It Traffic Engineering (TE) configuration and state capabilities. It
defines several identities for LSP protection types. As this defines several identities for LSP Protection Types. As this
document introduces a new LSP Protection Type, [RFC8776] is expected document introduces a new LSP Protection Type, [RFC8776] is expected
to be updated to support the SMP specified in this document. to be updated to support the SMP mechanism specified in this
[I-D.ietf-teas-yang-te] defines a YANG data model for the document. [YANG-TE] defines a YANG data model for the provisioning
provisioning and management of TE tunnels, LSPs, and interfaces. It and management of TE tunnels, LSPs, and interfaces. It includes some
includes some protection and restoration data nodes relevant to this protection and restoration data nodes relevant to this document.
document. Management aspects of the SMP are outside the scope of Management aspects of the SMP mechanism are outside the scope of this
this document, and they are expected to be addressed by other document, and they are expected to be addressed by other documents.
documents.
2. Conventions Used in This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In addition, the reader is assumed to be familiar with the In addition, the reader is assumed to be familiar with the
terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372
[RFC6372]. [RFC6372].
3. SMP Definition 3. SMP Definition
[G808.3] defines the generic aspects of an SMP mechanism. [G873.3] [G808.3] defines the generic aspects of an SMP mechanism. [G873.3]
defines the protection switching operation and associated protocol defines the protection switching operation and associated protocol
for SMP at the ODU layer. [RFC7412] provides requirements for any for SMP at the ODU layer. [RFC7412] provides requirements for any
mechanism that would be used to implement SMP in a MPLS-TP network. mechanism that would be used to implement SMP in an MPLS-TP network.
The SMP mechanism is based on pre-computed protecting LSPs that are The SMP mechanism is based on precomputed protecting LSPs that are
pre-configured into the network elements. Pre-configuration here preconfigured into the network elements. Preconfiguration here means
means pre-reserving resources for the protecting LSPs without pre-reserving resources for the protecting LSPs without activating a
activating a particular protecting LSP (e.g., in circuit networks, particular protecting LSP (e.g., in circuit networks, the cross-
the cross-connects in the intermediate nodes of the protecting LSP connects in the intermediate nodes of the protecting LSP are not
are not pre-established). Pre-configuring but not activating preestablished). Preconfiguring but not activating protecting LSPs
protecting LSPs allows link and node resources to be shared by the allows link and node resources to be shared by the protecting LSPs of
protecting LSPs of multiple working LSPs (that are themselves multiple working LSPs (which are themselves disjoint and thus
disjoint and thus unlikely to fail simultaneously). Protecting LSPs unlikely to fail simultaneously). Protecting LSPs are activated in
are activated in response to failures of working LSPs or operator's response to failures of working LSPs or operator commands by means of
commands by means of the APS protocol that operates in the data the APS protocol, which operates in the data plane. The APS protocol
plane. The APS protocol messages are exchanged along the protecting messages are exchanged along the protecting LSP. SMP is always
LSP. SMP is always revertive. revertive.
SMP has a lot of similarity to SMR except that the activation in case SMP is very similar to SMR, except that activation in the case of SMR
of SMR is achieved by control plane signaling during the recovery is achieved by control plane signaling during the recovery operation,
operation, while SMP is done by the APS protocol in the data plane. while the same is done for SMP by the APS protocol in the data plane.
4. Operation of SMP with GMPLS Signaling Extension 4. Operation of SMP with GMPLS Signaling Extensions
Consider the following network topology: Consider the network topology shown in Figure 1:
A---B---C---D A---B---C---D
\ / \ /
E---F---G E---F---G
/ \ / \
H---I---J---K H---I---J---K
Figure 1: An example of SMP topology Figure 1: An Example of an SMP Topology
The working LSPs [A,B,C,D] and [H,I,J,K] could be protected by the 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 protecting LSPs [A,E,F,G,D] and [H,E,F,G,K], respectively. Per RFC
3209 [RFC3209], in order to achieve resource sharing during the 3209 [RFC3209], in order to achieve resource sharing during the
signaling of these protecting LSPs, they MUST have the same Tunnel signaling of these protecting LSPs, they have the same Tunnel
Endpoint Address (as part of their SESSION object). However, these Endpoint Address (as part of their SESSION object). However, these
addresses are not the same in this example. Similar to SMR, this addresses are not the same in this example. Similar to SMR, this
document defines a new LSP Protection Type of the secondary LSP as document defines a new LSP Protection Type of the secondary LSP as
"Shared Mesh Protection" (see Section 6.1) to allow resource sharing "Shared Mesh Protection" (see Section 6.1) to allow resource sharing
along nodes E, F, and G. Examples of shared resources include the along nodes E, F, and G. Examples of shared resources include the
capacity of a link and the cross-connects in a node. In this case, capacity of a link and the cross-connects in a node. In this case,
the protecting LSPs are not merged (which is useful since the paths the protecting LSPs are not merged (which is useful, since the paths
diverge at G), but the resources along E, F, G can be shared. diverge at G), but the resources along E, F, and G can be shared.
When a failure, such as Signal Fail (SF) and Signal Degrade (SD), When a failure, such as Signal Fail (SF) or Signal Degrade (SD),
occurs on one of the working LSPs (say working LSP [A,B,C,D]), the occurs on one of the working LSPs (say, working LSP [A,B,C,D]), the
end node (say node A) that detects the failure initiates the end node (say, node A) that detects the failure initiates the
protection switching operation. End node A will send a protection protection switching operation. End node A will send a protection
switching request APS message (for example, SF) to its adjacent switching request APS message (for example, SF) to its adjacent
(downstream) intermediate node (say node E) to activate the (downstream) intermediate node (say, node E) to activate the
corresponding protecting LSP and will wait for a confirmation message corresponding protecting LSP and will wait for a confirmation message
from node E. from node E.
If the protection resource is available, node E will send the If the protection resource is available, node E will send the
confirmation APS message to the end node A and forward the switching confirmation APS message to the end node (node A) and forward the
request APS message to its adjacent (downstream) node (say node F). switching request APS message to its adjacent (downstream) node (say,
When the confirmation APS message is received by node A, the cross- node F). When the confirmation APS message is received by node A,
connection on node A is established. At this time traffic is bridged the cross-connection on node A is established. At this time, traffic
to and selected from the protecting LSP at node A. After forwarding is bridged to and selected from the protecting LSP at node A. After
the switching request APS message, node E will wait for a forwarding the switching request APS message, node E will wait for a
confirmation APS message from node F, which triggers node E to set up confirmation APS message from node F, which triggers node E to set up
the cross-connection for the protecting LSP being activated. the cross-connection for the protecting LSP being activated.
If the protection resource is not available (due to failure or being If the protection resource is not available (due to failure or being
used by higher priority connections), the switching will not be used by higher-priority connections), the switching will not be
successful; the intermediate node (node E) MUST send a message to successful; the intermediate node (node E) MUST send a message to
notify the end node (node A) (see Section 5.5). If the resource is notify the end node (node A) (see Section 5.5). If the resource is
in use by a lower priority protecting LSP, the lower priority service in use by a lower-priority protecting LSP, the lower-priority service
will be removed and then the intermediate node will follow the will be removed, and the intermediate node will then follow the
procedure as described for the case when the protection resource is procedure as described for the case when the protection resource is
available for the higher priority protecting LSP. available for the higher-priority protecting LSP.
If node E fails to allocate the protection resource, it MUST send a 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 will stop message to notify node A (see Section 5.5). Then, node A will stop
bridging and selecting traffic to/from the protecting LSP and proceed bridging and selecting traffic to/from the protecting LSP and proceed
with the procedure of removing the protection allocation according to with the procedure of removing the protection allocation according to
the APS protocol. the APS protocol.
5. GMPLS Signaling Extension for SMP 5. GMPLS Signaling Extensions for SMP
The following subsections detail how LSPs using SMP can be signaled The following subsections detail how LSPs using SMP can be signaled
in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC
3473 [RFC3473]). This signaling enables: 3473 [RFC3473]). This signaling enables:
(1) the ability to identify a "secondary protecting LSP" (LSP (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, hereby called the [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" "secondary LSP") used to recover another "primary working LSP"
(LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, hereby called the (LSP [A,B,C,D] or LSP [H,I,J,K] from Figure 1, here called the
"protected LSP"), "protected LSP"),
(2) the ability to associate the secondary LSP with the protected (2) the ability to associate the secondary LSP with the protected
LSP, LSP,
(3) the capability to include information about the resources used (3) the capability to include information about the resources used
by the protected LSP while instantiating the secondary LSP, by the protected LSP while instantiating the secondary LSP,
(4) the capability to instantiate during the provisioning phase (4) the capability to instantiate several secondary LSPs efficiently
several secondary LSPs efficiently, and during the provisioning phase, and
(5) the capability to support activation of a secondary LSP after (5) the capability to support activation of a secondary LSP via the
failure occurrence via APS protocol in the data plane. APS protocol in the data plane if a failure occurs.
5.1. Identifiers 5.1. Identifiers
To simplify association operations, both LSPs (i.e., the protected To simplify association operations, both LSPs (i.e., the protected
and the secondary LSPs) belong to the same session. Thus, the LSP and the secondary LSP) belong to the same session. Thus, the
SESSION object MUST be the same for both LSPs. The LSP ID, however, SESSION object MUST be the same for both LSPs. The LSP ID, however,
MUST be different to distinguish between the protected LSP and the MUST be different to distinguish between the protected LSP and the
secondary LSP. secondary LSP.
A new LSP Protection Type "Shared Mesh Protection" is defined (see A new LSP Protection Type, "Shared Mesh Protection", is defined (see
Section 6.1) for the LSP Flags of PROTECTION object (see [RFC4872]) Section 6.1) for the LSP Flags field of the PROTECTION object (see
to set up the two LSPs. This LSP Protection Type value is applicable [RFC4872]) to set up the two LSPs. This LSP Protection Type value is
only to bidirectional LSPs as required in [G808.3]. only applicable to bidirectional LSPs as required in [G808.3].
5.2. Signaling Primary LSPs 5.2. Signaling Primary LSPs
The PROTECTION object (see [RFC4872]) is included in the Path message The PROTECTION object (see [RFC4872]) is included in the Path message
during signaling of the primary working LSPs, with the LSP Protection during signaling of the primary working LSPs, with the LSP Protection
Type value set to "Shared Mesh Protection". Type value set to "Shared Mesh Protection".
Primary working LSPs are signaled by setting in the PROTECTION object Primary working LSPs are signaled by setting in the PROTECTION object
the S bit to 0, the P bit to 0, and the N bit to 1, and in the the S bit to 0, the P bit to 0, and the N bit to 1; and setting in
ASSOCIATION object, the Association ID to the associated secondary the ASSOCIATION object the Association ID to the associated secondary
protecting LSP_ID. protecting LSP_ID.
Note: N bit is set to indicate that the protection switching | Note: The N bit is set to indicate that the protection
signaling is done via data plane. | switching signaling is done via the data plane.
5.3. Signaling Secondary LSPs 5.3. Signaling Secondary LSPs
The PROTECTION object (see [RFC4872]) is included in the Path message The PROTECTION object (see [RFC4872]) is included in the Path message
during signaling of the secondary protecting LSPs, with the LSP during signaling of the secondary protecting LSPs, with the LSP
Protection Type value set to "Shared Mesh Protection". Protection Type value set to "Shared Mesh Protection".
Secondary protecting LSPs are signaled by setting in the PROTECTION Secondary protecting LSPs are signaled by setting in the PROTECTION
object the S bit, the P bit, and the N bit to 1, and in the object the S bit, the P bit, and the N bit to 1; and setting in the
ASSOCIATION object, the Association ID to the associated primary ASSOCIATION object the Association ID to the associated primary
working LSP_ID, which MUST be known before signaling of the secondary working LSP_ID, which MUST be known before signaling of the secondary
LSP. Moreover, the Path message used to instantiate the secondary LSP. Moreover, the Path message used to instantiate the secondary
LSP MUST include at least one PRIMARY_PATH_ROUTE object (see LSP MUST include at least one PRIMARY_PATH_ROUTE object (see
[RFC4872]) that further allows for recovery resource sharing at each [RFC4872]) that further allows for recovery resource sharing at each
intermediate node along the secondary path. intermediate node along the secondary path.
With this setting, the resources for the secondary LSP MUST be pre- With this setting, the resources for the secondary LSP MUST be pre-
reserved, but not committed at the data plane level, meaning that the reserved but not committed at the data plane level, meaning that the
internals of the switch need not be established until explicit action internals of the switch need not be established until explicit action
is taken to activate this LSP. Activation of a secondary LSP and is taken to activate this LSP. Activation of a secondary LSP and
protection switching to the activated protecting LSP is done using protection switching to the activated protecting LSP is done using
APS protocol in the data plane. the APS protocol in the data plane.
After protection switching completes the protecting LSP MUST be After protection switching completes, the protecting LSP MUST be
signaled with the S bit set to 0 and O bit set to 1 in the PROTECTION signaled by setting the S bit to 0 and the O bit to 1 in the
object. At this point, the link and node resources MUST be allocated PROTECTION object. At this point, the link and node resources MUST
for this LSP that becomes a primary LSP (ready to carry traffic). be allocated for this LSP, which becomes a primary LSP (ready to
The formerly working LSP MAY be signaled with the A bit set in the carry traffic). The formerly working LSP MAY be signaled with the A
ADMIN_STATUS object (see [RFC3473]). bit set in the ADMIN_STATUS object (see [RFC3473]).
Support for extra traffic in SMP is for further study. Therefore, Support for extra traffic in SMP is left for further study.
mechanisms to set up LSPs for extra traffic are outside the scope of Therefore, mechanisms to set up LSPs for extra traffic are outside
this document. the scope of this document.
5.4. SMP Preemption Priority 5.4. SMP Preemption Priority
The SMP preemption priority of a protecting LSP that the APS protocol The SMP preemption priority of a protecting LSP is used by the APS
uses to resolve the competition for shared resources among multiple protocol to resolve competition for shared resources among multiple
protecting LSPs, is indicated in Preemption Priority field of the protecting LSPs and is indicated in the Preemption Priority field of
PROTECTION object in the Path message of the protecting LSP. the PROTECTION object in the Path message of the protecting LSP.
The Setup and Holding priorities in the SESSION_ATTRIBUTE object can The Setup and Holding priorities in the SESSION_ATTRIBUTE object can
be used by GMPLS to control LSP preemption, but, they are not used by be used by GMPLS to control LSP preemption, but they are not used by
the APS to resolve the competition among multiple protecting LSPs. the APS to resolve competition among multiple protecting LSPs. This
This avoids the need to define a complex policy for defining Setup avoids the need to define a complex policy for defining Setup and
and Holding priorities when used for both GMPLS control plane LSP Holding priorities when used for both GMPLS control plane LSP
preemption and SMP shared resource competition resolution. preemption and SMP shared resource competition resolution.
When an intermediate node on the protecting LSP receives the Path When an intermediate node on the protecting LSP receives the Path
message, the priority value in the Preemption Priority field MUST be message, the priority value in the Preemption Priority field MUST be
stored for that protecting LSP. When resource competition among stored for that protecting LSP. When resource competition among
multiple protecting LSPs occurs, the APS protocol will use their multiple protecting LSPs occurs, the APS protocol will use their
priority values to resolve the competition. A lower value has a priority values to resolve this competition. A lower value has a
higher priority. higher priority.
In SMP, a preempted LSP MUST NOT be terminated even after its In SMP, a preempted LSP MUST NOT be terminated even after its
resources have been deallocated. Once the working LSP and the resources have been deallocated. Once the working LSP and the
protecting LSP are configured or pre-configured, the end node MUST protecting LSP are configured or preconfigured, the end node MUST
keep refreshing both working and protecting LSPs regardless of keep refreshing both working and protecting LSPs, regardless of
failure or preempted situation. failure or preemption status.
5.5. Notifying Availability of Shared Resources 5.5. Availability of Shared Resources: The Notify Message
When a lower priority protecting LSP is preempted, the intermediate When a lower-priority protecting LSP is preempted, the intermediate
node that performed preemption MUST send a Notify message with error node that performed the preemption MUST send a Notify message with
code "Notify Error" (25) (see [RFC4872]) and error sub-code "Shared error code "Notify Error" (25) (see [RFC4872]) and error sub-code
resources unavailable" (TBA1) to the end nodes of that protecting "Shared resources unavailable" (17) to the end nodes of that
LSP. Upon receipt of this Notify message, the end node MUST stop protecting LSP. Upon receipt of this Notify message, the end node
sending and selecting traffic to/from its protecting LSP and try MUST stop sending and selecting traffic to/from its protecting LSP
switching the traffic to another protecting LSP, if available. and try switching the traffic to another protecting LSP, if
available.
When a protecting LSP occupies the shared resources and they become When a protecting LSP occupies the shared resources and they become
unavailable, the same Notify message MUST be generated by the unavailable, the same Notify message MUST be generated by the
intermediate node to all the end nodes of the protecting LSPs that intermediate node to all the end nodes of the protecting LSPs that
have lower SMP preemption priorities than the one that has occupied have lower SMP preemption priorities than the one that has occupied
the shared resources. In case the shared resources become the shared resources. If the shared resources become unavailable due
unavailable due to a failure in the shared resources, the same Notify to a failure in the shared resources, the same Notify message MUST be
message MUST be generated by the intermediate node to all the end generated by the intermediate node to all the end nodes of the
nodes of the protecting LSPs that have been configured to use the protecting LSPs that have been configured to use the shared
shared resources. These end nodes, in case of a failure of the resources. In the case of a failure of the working LSP, these end
working LSP, MUST avoid trying to switch traffic to these protecting nodes MUST avoid trying to switch traffic to these protecting LSPs
LSPs that have been configured to use the shared resources and try that have been configured to use the shared resources and try
switching the traffic to other protecting LSPs, if available. switching the traffic to other protecting LSPs, if available.
When the shared resources become available, a Notify message with When the shared resources become available, a Notify message with
error code "Notify Error" (25) and error sub-code "Shared resources error code "Notify Error" (25) and error sub-code "Shared resources
available" (TBA2) MUST be generated by the intermediate node. The available" (18) MUST be generated by the intermediate node. The
recipients of this Notify message are the end nodes of the lower recipients of this Notify message are the end nodes of the lower-
priority protecting LSPs that have been preempted and/or all the end priority protecting LSPs that have been preempted and/or all the end
nodes of the protecting LSPs that have lower SMP preemption nodes of the protecting LSPs that have lower SMP preemption
priorities than the one that does not need the shared resources priorities than the one that does not need the shared resources
anymore. Upon receipt of this Notify message, the end node is anymore. Upon receipt of this Notify message, the end node is
allowed to reinitiate the protection switching operation as described allowed to reinitiate the protection switching operation as described
in Section 4, if it still needs the protection resource. in Section 4, if it still needs the protection resource.
5.6. SMP APS Configuration 5.6. SMP APS Configuration
SMP relies on APS protocol messages being exchanged between the nodes SMP relies on APS protocol messages being exchanged between the nodes
along the path to activate an SMP protecting LSP. along the path to activate a protecting LSP.
In order to allow the exchange of APS protocol messages, an APS In order to allow the exchange of APS protocol messages, an APS
channel has to be configured between adjacent nodes along the path of channel has to be configured between adjacent nodes along the path of
the SMP protecting LSP. This is done by other means than GMPLS the protecting LSP. This is done by means other than GMPLS
signaling, before any SMP protecting LSP has been set up. Therefore, signaling, before any protecting LSP has been set up. Therefore,
there are likely additional requirements for APS configuration which there are likely additional requirements for APS configuration that
are outside the scope of this document. are outside the scope of this document.
Depending on the APS protocol message format, the APS protocol may Depending on the APS protocol message format, the APS protocol may
use different identifiers than GMPLS signaling to identify the SMP use different identifiers than GMPLS signaling to identify the
protecting LSP. protecting LSP.
Since APS protocol is for further study in [G808.3], it can be Since the APS protocol is left for further study per [G808.3], it can
assumed that APS message format and identifiers are technology- be assumed that the APS message format and identifiers are technology
specific and/or vendor-specific. Therefore, additional requirements specific and/or vendor specific. Therefore, additional requirements
for APS configuration are outside the scope of this document. for APS configuration are outside the scope of this document.
6. Updates to PROTECTION Object 6. Updates to PROTECTION Object
GMPLS extension requirements for SMP introduce several updates to the GMPLS extension requirements for SMP introduce several updates to the
Protection Object (see [RFC4872]). PROTECTION object (see [RFC4872]), as detailed below.
6.1. New Protection Type 6.1. New Protection Type
A new LSP protection type "Shared Mesh Protection" is added in the A new LSP Protection Type, "Shared Mesh Protection", is added in the
PROTECTION object. This LSP Protection Type value is applicable to PROTECTION object. This LSP Protection Type value is only applicable
only bidirectional LSPs. to bidirectional LSPs.
LSP (Protection Type) Flags: LSP (Protection Type) Flags:
0x20: Shared Mesh Protection 0x20: Shared Mesh Protection
The rules defined in Section 14.2 of [RFC4872] ensure that all the The rules defined in Section 14.2 of [RFC4872] ensure that all the
nodes along an SMP LSP are SMP aware. Therefore, there are no nodes along an SMP LSP are SMP aware. Therefore, there are no
backward compatibility issues. backward-compatibility issues.
6.2. Updates on Notification and Operational Bits 6.2. Updates to Definitions of Notification and Operational Bits
The definitions of the N and O bits in Section 14.1 of [RFC4872] are The definitions of the N and O bits in Section 14.1 of [RFC4872] are
replaced as follows: replaced as follows:
Notification (N): 1 bit Notification (N): 1 bit
When set to 1, this bit indicates that the control plane message When set to 1, this bit indicates that the control plane message
exchange is only used for notification during protection exchange is only used for notification during protection
switching. When set to 0 (default), it indicates that the control switching. When set to 0 (default), it indicates that the control
plane message exchanges are used for protection-switching plane message exchanges are used for purposes of protection
purposes. The N bit is only applicable when the LSP Protection switching. The N bit is only applicable when the LSP Protection
Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08
(1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional
Protection), or 0x20 (Shared Mesh Protection). The N bit MUST be Protection), or 0x20 (Shared Mesh Protection). The N bit MUST be
set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set set to 0 in any other case. If 0x20 (SMP), the N bit MUST be set
to 1. to 1.
Operational (O): 1 bit Operational (O): 1 bit
When set to 1, this bit indicates that the protecting LSP is When set to 1, this bit indicates that the protecting LSP is
carrying traffic after protection switching. The O bit is only carrying traffic after protection switching. The O bit is only
applicable when the P bit is set to 1, and the LSP Protection Type applicable when (1) the P bit is set to 1 and (2) the LSP
Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 Protection Type Flag is set to 0x04 (1:N Protection with Extra-
Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), Traffic), 0x08 (1+1 Unidirectional Protection), 0x10 (1+1
or 0x20 (Shared Mesh Protection). The O bit MUST be set to 0 in Bidirectional Protection), or 0x20 (Shared Mesh Protection). The
any other case. O bit MUST be set to 0 in any other case.
6.3. Preemption Priority 6.3. Preemption Priority
[RFC4872] reserved a 32-bit field in the PROTECTION object header. [RFC4872] reserved a 32-bit field in the PROTECTION object header.
Subsequently, [RFC4873] allocated several fields from that field, and Subsequently, [RFC4873] allocated several bits from that field and
left the remainder of the bits reserved. This specification further left the remainder of the bits reserved. This specification further
allocates the preemption priority field from those formerly-reserved allocates the Preemption Priority field from the remaining formerly
bits. The 32-bit field in the PROTECTION object defined in [RFC4873] reserved bits. The 32-bit field in the PROTECTION object as defined
are updated as follows: in [RFC4872] and modified by [RFC4873] is updated by this document as
follows:
0 1 2 3 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 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 | |I|R| Reserved | Seg.Flags | Reserved | Preempt Prio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority (Preempt Prio): 8 bit Preemption Priority (Preempt Prio): 8 bits
This field indicates the SMP preemption priority of a protecting This field indicates the SMP preemption priority of a protecting
LSP, when the LSP Protection Type field indicates "Shared Mesh LSP, when the LSP Protection Type field indicates "Shared Mesh
Protection". The SMP preemption priority value is configured at Protection". The SMP preemption priority value is configured at
the end nodes of the protecting LSP by a network operator. A the end nodes of the protecting LSP by a network operator. A
lower value has a higher priority. The decision of how many lower value has a higher priority. The decision regarding how
priority levels to be operated in an SMP network is a network many priority levels should be implemented in an SMP network is
operator's choice. left to network operators.
See [RFC4873] for the definition of other fields. See [RFC4873] for the definitions of the other fields.
7. IANA Considerations 7. IANA Considerations
IANA maintains a registry called "Resource Reservation Protocol IANA maintains a group of registries called "Resource Reservation
(RSVP) Parameters" with a subregistry called "Error Codes and Protocol (RSVP) Parameters", which includes the "Error Codes and
Globally-Defined Error Value Sub-Codes". Within this subregistry Globally-Defined Error Value Sub-Codes" registry. IANA has added the
there is a definition of the "Notify Error" error code (25). The following values to the "Sub-Codes - 25 Notify Error" subregistry,
definition lists a number of error value sub-codes that may be used which lists error value sub-codes that may be used with error code
with this error code. IANA is requested to allocate further error 25. IANA has allocated the following error value sub-codes (Table 1)
value sub-codes for use with this error code as described in this for use with this error code as described in this document.
document.
Value Description Reference +=======+==============================+===========+
----- ---------------------------- --------------- | Value | Description | Reference |
TBA1 Shared resources unavailable (this document) +=======+==============================+===========+
TBA2 Shared resources available (this document) | 17 | Shared resources unavailable | RFC 9270 |
+-------+------------------------------+-----------+
| 18 | Shared resources available | RFC 9270 |
+-------+------------------------------+-----------+
Table 1: New Error Sub-Codes
8. Security Considerations 8. Security Considerations
Since this document makes use of the exchange of RSVP messages Since this document makes use of the exchange of RSVP messages that
including a Notify message, the security threats discussed in include a Notify message, the security threats discussed in [RFC4872]
[RFC4872] also apply to this document. also apply to this document.
Additionally, it may be possible to cause disruption to traffic on Additionally, it may be possible to cause disruption to traffic on
one protecting LSP by targeting a link used by the primary LSP of one protecting LSP by targeting a link used by the primary LSP of
another, higher priority LSP somewhere completely different in the another, higher-priority LSP somewhere completely different in the
network. For example, in Figure 1, assume that the preemption network. For example, in Figure 1, assume that the preemption
priority of LSP [A,E,F,G,D] is higher than that of LSP [H,E,F,G,K] 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 being used to transport and the protecting LSP [H,E,F,G,K] is being used to transport
traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be traffic. If link B-C is attacked, traffic on LSP [H,E,F,G,K] can be
disrupted. For this reason, it is important not only to use security disrupted. For this reason, it is important not only to use security
mechanisms as discussed in [RFC4872] but also to acknowledge that mechanisms as discussed in [RFC4872] but also to acknowledge that
detailed knowledge of a network's topology, including routes and detailed knowledge of a network's topology, including routes and
priorities of LSPs, can help an attacker better target or improve the priorities of LSPs, can help an attacker better target or improve the
efficacy of an attack. efficacy of an attack.
9. Acknowledgements 9. References
The authors would like to thank Adrian Farrel, Vishnu Pavan Beeram,
Tom Petch, Ines Robles, John Scudder, Dale Worley, Dan Romascanu,
Eric Vyncke, Roman Danyliw, Paul Wouters, Lars Eggert, Francesca
Palombini, and Robert Wilton for their valuable comments and
suggestions on this document.
10. Contributor
The following person contributed significantly to the content of this
document and should be considered as a co-author.
Yuji Tochio
Fujitsu
Email: tochio@fujitsu.com
11. References
11.1. Normative References 9.1. Normative References
[G808.3] International Telecommunication Union, "Generic protection [G808.3] International Telecommunication Union, "Generic protection
switching - Shared mesh protection", ITU-T Recommendation switching - Shared mesh protection", ITU-T Recommendation
G.808.3, October 2012. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 13, line 17 skipping to change at line 570
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003, DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>. <https://www.rfc-editor.org/info/rfc3473>.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou, [RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, Recovery Functional Specification", RFC 4426,
DOI 10.17487/RFC4426, March 2006, DOI 10.17487/RFC4426, March 2006,
<https://www.rfc-editor.org/info/rfc4426>. <https://www.rfc-editor.org/info/rfc4426>.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, [RFC4872] Lang, J P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS) Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>. <https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>. May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 9.2. Informative References
[G873.3] International Telecommunication Union, "Optical transport [G873.3] International Telecommunication Union, "Optical transport
network - Shared mesh protection", ITU-T Recommendation network - Shared mesh protection", ITU-T Recommendation
G.873.3, September 2017. G.873.3, September 2017,
<https://www.itu.int/rec/T-REC-G.873.3-201709-I/en>.
[I-D.ietf-teas-yang-te]
Saad, T., Gandhi, R., Liu, X., Beeram, V. P., Bryskin, I.,
and O. G. D. Dios, "A YANG Data Model for Traffic
Engineering Tunnels, Label Switched Paths and Interfaces",
draft-ietf-teas-yang-te-29 (work in progress), February
2022.
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372, Profile (MPLS-TP) Survivability Framework", RFC 6372,
DOI 10.17487/RFC6372, September 2011, DOI 10.17487/RFC6372, September 2011,
<https://www.rfc-editor.org/info/rfc6372>. <https://www.rfc-editor.org/info/rfc6372>.
[RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G. [RFC7412] Weingarten, Y., Aldrin, S., Pan, P., Ryoo, J., and G.
Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP) Mirsky, "Requirements for MPLS Transport Profile (MPLS-TP)
Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412, Shared Mesh Protection", RFC 7412, DOI 10.17487/RFC7412,
December 2014, <https://www.rfc-editor.org/info/rfc7412>. December 2014, <https://www.rfc-editor.org/info/rfc7412>.
[RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin, [RFC8776] Saad, T., Gandhi, R., Liu, X., Beeram, V., and I. Bryskin,
"Common YANG Data Types for Traffic Engineering", "Common YANG Data Types for Traffic Engineering",
RFC 8776, DOI 10.17487/RFC8776, June 2020, RFC 8776, DOI 10.17487/RFC8776, June 2020,
<https://www.rfc-editor.org/info/rfc8776>. <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-
29, 7 February 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-te-29>.
Acknowledgements
The authors would like 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.
Contributors
The following person contributed significantly to the content of this
document and should be considered a coauthor.
Yuji Tochio
Fujitsu
Email: tochio@fujitsu.com
Authors' Addresses Authors' Addresses
Jia He Jia He
Huawei Technologies Huawei Technologies
F3-1B, R&D Center, Huawei Industrial Base, Bantian, Longgang District F3-1B, R&D Center, Huawei Industrial Base
Bantian, Longgang District
Shenzhen Shenzhen
China China
Email: hejia@huawei.com Email: hejia@huawei.com
Italo Busi Italo Busi
Huawei Technologies Huawei Technologies
Email: italo.busi@huawei.com Email: italo.busi@huawei.com
Jeong-dong Ryoo Jeong-dong Ryoo
ETRI ETRI
218 Gajeongno 218 Gajeongno
Yuseong-gu, Daejeon 34129 Yuseong-gu
Daejeon
34129
South Korea South Korea
Phone: +82-42-860-5384 Phone: +82-42-860-5384
Email: ryoo@etri.re.kr Email: ryoo@etri.re.kr
Bin Yeong Yoon Bin Yeong Yoon
ETRI ETRI
Email: byyun@etri.re.kr Email: byyun@etri.re.kr
Peter Park Peter Park
KT KT
Email: peter.park@kt.com Email: peter.park@kt.com
 End of changes. 90 change blocks. 
266 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.48.