RFC 8104
Pseudowire (PW) Endpoint Fast Failure Protection
Pages: 43
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 29 to 43
5. Restorative and Revertive Behaviors
Subsequent to local repair, there are three strategies for a network to restore traffic to a fully functional alternative path: o Global repair If the ingress CE is multihomed (Figure 1), it MAY switch the traffic to the backup AC, which is bound to the backup PW. Alternatively, if the ingress PE hosts a backup PW (Figure 2), the ingress PE MAY switch the traffic to the backup PW. These procedures are referred to as global repair. Possible triggers of global repair include PW status notification, Virtual Circuit Connectivity Verification (VCCV) [RFC5085] [RFC5885], BFD, end-to-end OAM between CEs, and others. o Control-plane convergence In egress PE node protection and S-PE node protection, it is possible that the failure is limited to the link between the PLR and the primary PE, whereas the primary PE is still operational. In this case, the PLR or an upstream router on the transport tunnel MAY reroute the tunnel around the link via an alternative path to the primary PE. Thus, the transport tunnel can heal and continue to carry the PW to the primary PE. This procedure is driven by control-plane convergence on the new topology. o Local reversion The PLR MAY move traffic back to the primary PW, after the failure is resolved. In egress AC protection, upon detecting that the primary AC is restored, the PLR MAY start forwarding traffic over the AC again. Likewise, in egress PE node protection and S-PE node protection, upon detecting that the primary PE is restored, the PLR MAY re-establish the transport tunnel to the primary PE and move the traffic from the bypass tunnel back to the transport tunnel. These procedures are referred to as local reversion.
It is RECOMMENDED that the fast protection mechanism SHOULD be used in conjunction with global repair. Particularly in the case of egress PE and S-PE node failures, if the ingress PE or the protector loses communication with the egress PE or S-PE for an extensive period of time, the LDP session may go down. Consequently, the ingress PE may bring down the primary PW completely, or the protector may remove the forwarding entry of the primary PW label. In either case, the service will be disrupted. In other words, although the mechanism can temporarily repair traffic, control-plane state may eventually expire if the failure persists. Therefore, global repair SHOULD take place in a timely manner to move traffic to a fully functional alternative path. Control-plane convergence may automatically happen as control-plane protocols react to the new topology. However, it is only applicable to the specific link failure scenario described above. Local reversion is optional. In the circumstances where the failure is caused by resource flapping, local reversion MAY be dampened to limit potential disruption. Local reversion MAY be disabled completely by configuration.6. LDP Extensions
As described in previous sections, a targeted LDP session MUST be established between each pair of primary PE and protector. The primary PE sends a Label Mapping message over this session to advertise primary PW labels to the protector. In the centralized protector model, a targeted LDP session MUST also be established between a backup (S-)PE and the protector. The backup PE sends a Label Mapping message over this session to advertise backup PW labels to the protector. To support the procedures, this document defines a new "Protection FEC Element" TLV. The Label Mapping messages of both the LDP sessions above MUST carry this TLV to identify a primary PW. Specifically, in the centralized protector model, the Protection FEC Element TLV advertised by a backup (S-)PE MUST match the one advertised by the primary PE, so that the protector can associate the primary PW's label with the backup PW's label and perform a label swap. The backup (S-)PE builds such a Protection FEC Element TLV based on local configuration. This document also defines a new "Egress Protection Capability" TLV as a new type of Capability Parameter TLV [RFC5561], to allow a protector to announce its capability of processing the above Protection FEC Element TLV and performing context-specific label switching for PW labels.
The procedures in this section are only applicable if the protector advertises the Egress Protection Capability TLV, the primary PE supports the advertisement of the Protection FEC Element TLV, and in the centralized protector model, the backup PE also supports the advertisement of the Protection FEC Element TLV.6.1. Egress Protection Capability TLV
A protector MUST advertise the Egress Protection Capability TLV in its Initialization message and Capability message over the LDP session with a primary PE. In the centralized protector model, the protector MUST also advertise the TLV over the LDP session with a backup PE. The TLV carries one or multiple context identifiers. To the primary PE, the TLV MUST carry the context identifier of the {primary PE, protector}. In the centralized protector model, the TLV MUST carry multiple context identifiers to the backup PE, one for each {primary PE, protector} where the backup PE serves as a backup for the primary PE. This TLV MUST NOT be advertised by the primary PE or the backup PE to the protector. The processing of the Egress Protection Capability TLV by a receiving router MUST follow the procedures defined in [RFC5561]. In particular, the router MUST advertise PW information to the protector by using the Protection FEC Element TLV, only after it has received the Egress Protection Capability TLV from the protector. It MUST validate each context identifier included in the TLV and advertise the information of only the PWs that are associated with the context identifier. It MUST withdraw previously advertised Protection FEC TLVs, when the protector has withdrawn a previously advertised context identifier or the entire Egress Protection Capability TLV via a Capability message. The encoding of the Egress Protection Capability TLV is defined below. It conforms to the format of Capability Parameter TLV specified in [RFC5561].
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Egress Protection (0x0974)| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ | | | ~ Capability Data = context identifier(s) ~ | | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15 The U-bit MUST be set to 1, so that a receiver MUST silently ignore this TLV if unknown to it and continue processing the rest of the message. The F-bit MUST be set to 0 since this TLV is sent only in Initialization and Capability messages, which are not forwarded. The TLV code point is 0x0974. The S-bit indicates whether the sender is advertising (S=1) or withdrawing (S=0) the capability. The Capability Data field is encoded with the context identifiers of the {primary PE, protector} pairs for which the advertiser is the protector.6.2. PW Label Distribution from Primary PE to Protector
A primary PE MUST advertise a primary PW's label to a protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV (see Section 6.4 for encoding) and an Upstream- Assigned Label TLV [RFC6389] encoded with the PW's label. The combination of the Protection FEC Element TLV and the PW label represents the primary PE's forwarding state for the PW. The Label Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC3471] [RFC6389] encoded with the context identifier of the {primary PE, protector}. The protector that receives this Label Mapping message MUST install a forwarding entry for the PW label in the label space identified by the context identifier. The next hop of the forwarding entry MUST ensure that packets are sent towards the target CE via a backup AC or
a backup (S-)PE, depending on the protection scenario. The protector MUST silently discard a Label Mapping message if the included context identifier is unknown to it.6.3. PW Label Distribution from Backup PE to Protector
In the centralized protector model, a backup PE MUST advertise a backup PW's label to the protector by sending a Label Mapping message. The message includes a Protection FEC Element TLV and a Generic Label TLV encoded with the backup PW's label. This Protection FEC Element MUST be identical to the Protection FEC Element TLV that the primary PE advertises to the protector (Section 6.2). This is achieved through configuration on the backup PE. The context identifier MUST NOT be encoded in an Interface_ID TLV in this message. The protector that receives this Label Mapping message MUST associate the backup PW with the primary PW, based on the common Protection FEC Element TLV. It MUST distinguish between the Label Mapping message from the primary PE and the Label Mapping message from the backup PE based on the respective presence and absence of a context identifier in the Interface_ID TLV. It MUST install a forwarding entry for the primary PW's label in the label space identified by the context identifier. The next hop of the forwarding entry MUST indicate a label swap to the backup PW's label, followed by a label push or IP header push for a transport tunnel to the backup PE.
6.4. Protection FEC Element TLV
The Protection FEC Element TLV has type 0x83. Its format is defined below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x83) | Reserved | Encoding Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ PW Information ~ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16 - Encoding Type Type of encoding format of the PW Information field. The following types are defined, corresponding to the PWid FEC Element and Generalized PWid FEC Element defined in [RFC8077]. 1 - PWid FEC Element with IPv4 PE addresses (Section 6.4.1). 2 - Generalized PWid FEC Element with IPv4 PE addresses (Section 6.4.2). 3 - PWid FEC Element with IPv6 PE addresses (Section 6.4.3). 4 - Generalized PWid FEC Element with IPv6 PE addresses (Section 6.4.4). - Length Length of the PW Information field in octets. - PW Information Field of variable length that specifies a PW.
6.4.1. Encoding Format for PWid with IPv4 PE Addresses
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x83) | Reserved | Enc Type(1) | Length(20) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17 - Ingress PE IPv4 Address IPv4 address of the ingress PE of PW. - Egress PE IPv4 Address IPv4 address of the egress PE of PW. - Group ID An arbitrary 32-bit value that represents a group of PWs and that is used to create groups in the PW space. - PW ID A non-zero 32-bit connection ID that, together with the PW Type field, identifies a particular PW. - Control word bit (C) A bit that flags the presence of a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present. - PW Type A 15-bit quantity that represents the type of PW.
6.4.2. Encoding Format for Generalized PWid with IPv4 PE Addresses
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type(0x83) | Reserved | Enc Type(2) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress PE IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| PW Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Type | Length | AGI Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ AGI Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | SAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AII Type | Length | TAII Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TAII Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18 - Ingress PE IPv4 Address IPv4 address of the ingress PE of PW. - Egress PE IPv4 Address IPv4 address of the egress PE of PW. - Control word bit (C) A bit that flags the presence of a control word on this PW. If C = 1, control word is present; if C = 0, control word is not present. - PW Type A 15-bit quantity that represents the type of PW.
- AGI Type, Length, AGI Value
Attachment Group Identifier of PW.
- AII Type, Length, SAII Value
Source Attachment Individual Identifier of PW.
- AII Type, Length, TAII Value
Target Attachment Individual Identifier of PW.
6.4.3. Encoding Format for PWid with IPv6 PE Addresses
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(3) | Length(44) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ingress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Egress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
- Ingress PE IPv6 Address
IPv6 address of the ingress PE of PW; 16 octets.
- Egress PE IPv6 Address
IPv6 address of the egress PE of PW; 16 octets.
- Group ID
An arbitrary 32-bit value that represents a group of PWs and that
is used to create groups in the PW space.
- PW ID
A non-zero 32-bit connection ID that, together with the PW Type
field, identifies a particular PW.
- Control word bit (C)
A bit that flags the presence of a control word on this PW. If
C = 1, control word is present; if C = 0, control word is not
present.
- PW Type
A 15-bit quantity that represents the type of PW.
6.4.4. Encoding Format for Generalized PWid with IPv6 PE Addresses
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(0x83) | Reserved | Enc Type(4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Ingress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Egress PE IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| PW Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | SAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AII Type | Length | TAII Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ TAII Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20
- Ingress PE IPv6 Address
IPv6 address of the ingress PE of PW; 16 octets.
- Egress PE IPv6 Address
IPv6 address of the egress PE of PW; 16 octets.
- Control word bit (C)
A bit that flags the presence of a control word on this PW. If
C = 1, control word is present; if C = 0, control word is not
present.
- PW Type
A 15-bit quantity that represents the type of PW.
- AGI Type, Length, AGI Value
Attachment Group Identifier of PW.
- AII Type, Length, SAII Value
Source Attachment Individual Identifier of PW.
- AII Type, Length, TAII Value
Target Attachment Individual Identifier of PW.
7. IANA Considerations
This document defines a new Egress Protection Capability TLV in
Section 6. IANA has assigned value 0x0974 for it in the "TLV Type
Name Space" registry.
This document defines a new Protection FEC Element TLV in Section 6.
IANA assigned value 0x83 for it in the "Forwarding Equivalence Class
(FEC) Type Name Space" registry per RFC 7358. IANA has updated the
registry to also reference this document.
8. Security Considerations
In this document, PW traffic can be temporarily rerouted by a PLR to a protector. In the centralized protector scenario, the traffic can be further rerouted to a backup PE. In the control plane, there is a targeted LDP session between a primary PE and a protector. In the centralized protector scenario, there is also a targeted LDP session between a backup PE and a protector. In all scenarios, traffic rerouting via PLRs, protectors, and backup PEs is planned and anticipated, and backup PEs can be used anyway to host PWs and LDP sessions. Hence, the rerouted traffic and the LDP sessions introduced in this document should not be viewed as a new security threat. In general, [RFC5920] describes the security framework for MPLS networks. [RFC3209] describes the security considerations for RSVP Label Switched Paths (LSPs). [RFC5036] describes the security considerations for the base LDP specification. [RFC5561] describes the security considerations that apply when using the LDP capability mechanism. All these security frameworks and considerations apply to this document as well.9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <http://www.rfc-editor.org/info/rfc8077>. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, <http://www.rfc-editor.org/info/rfc5331>. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <http://www.rfc-editor.org/info/rfc5561>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>. [RFC3472] Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR- LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January 2003, <http://www.rfc-editor.org/info/rfc3472>. [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011, <http://www.rfc-editor.org/info/rfc6389>. [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>. [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>. [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, <http://www.rfc-editor.org/info/rfc7812>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <http://www.rfc-editor.org/info/rfc3031>.9.2. Informative References
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>. [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <http://www.rfc-editor.org/info/rfc3985>.
[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, <http://www.rfc-editor.org/info/rfc3209>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>. [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, DOI 10.17487/RFC5659, October 2009, <http://www.rfc-editor.org/info/rfc5659>. [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, <http://www.rfc-editor.org/info/rfc5714>. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>. [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <http://www.rfc-editor.org/info/rfc5085>. [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, DOI 10.17487/RFC5885, June 2010, <http://www.rfc-editor.org/info/rfc5885>. [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. Pallagatti, "Seamless Bidirectional Forwarding Detection (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, <http://www.rfc-editor.org/info/rfc7880>.
Acknowledgements
This document leverages work done by Hannes Gredler, Yakov Rekhter, Minto Jeyananth, Kevin Wang, and several others on MPLS edge protection. Thanks to Nischal Sheth and Bhupesh Kothari for their contributions. Thanks to John E. Drake, Andrew G. Malis, Alexander Vainshtein, Stewart Bryant, and Mach(Guoyi) Chen for valuable comments that helped shape this document and improve its clarity.Authors' Addresses
Yimin Shen Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America Phone: +1 9785890722 Email: yshen@juniper.net Rahul Aggarwal Arktan, Inc. Email: raggarwa_1@yahoo.com Wim Henderickx Nokia Copernicuslaan 50 2018 Antwerp Belgium Email: wim.henderickx@nokia.com Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129 China Email: jiangyuanlong@huawei.com