--- 1/draft-ietf-teas-gmpls-lsp-fastreroute-07.txt 2017-05-12 15:13:10.287679182 -0700 +++ 2/draft-ietf-teas-gmpls-lsp-fastreroute-08.txt 2017-05-12 15:13:10.331680233 -0700 @@ -1,23 +1,23 @@ TEAS Working Group M. Taillon Internet-Draft T. Saad, Ed. Intended Status: Standards Track R. Gandhi, Ed. -Expires: June 22, 2017 Z. Ali - Cisco Systems +Expires: November 13, 2017 Z. Ali + Cisco Systems, Inc. M. Bhatia Nokia - December 19, 2016 + May 12, 2017 Extensions to Resource Reservation Protocol For Fast Reroute of Traffic Engineering GMPLS LSPs - draft-ietf-teas-gmpls-lsp-fastreroute-07 + draft-ietf-teas-gmpls-lsp-fastreroute-08 Abstract This document defines Resource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling extensions to support Fast Reroute (FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling extensions allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these @@ -35,21 +35,21 @@ Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -78,28 +78,28 @@ 5.1. Link Protection for Bidirectional GMPLS LSPs . . . . . . . 11 5.1.1. Behavior After Link Failure . . . . . . . . . . . . . 12 5.1.2. Revertive Behavior After Fast Reroute . . . . . . . . 12 5.2. Node Protection for Bidirectional GMPLS LSPs . . . . . . . 12 5.2.1. Behavior After Link Failure . . . . . . . . . . . . . 13 5.2.2. Behavior After Link Failure To Re-coroute . . . . . . 13 5.2.2.1. Re-coroute in Data-plane After Link Failure . . . 14 5.2.3. Revertive Behavior After Fast Reroute . . . . . . . . 15 5.3. Unidirectional Link Failures . . . . . . . . . . . . . . . 15 6. Fast Reroute For Bidirectional GMPLS LSPs with Out-of-band - Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Message and Object Definitions . . . . . . . . . . . . . . . . 16 7.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 16 - 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 17 + 7.2. FRR Bypass Assignment Error Notify Message . . . . . . . . 18 8. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 18 + 10.1. BYPASS_ASSIGNMENT Subobject . . . . . . . . . . . . . . . 19 10.2. FRR Bypass Assignment Error Notify Message . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 21 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction @@ -171,54 +171,54 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2.2. Terminology The reader is assumed to be familiar with the terminology in [RFC2205], [RFC3209], [RFC3471], [RFC3473] and [RFC4090]. Downstream PLR: Downstream Point of Local Repair. The PLR that - locally detects a failure in the downstream direction of the traffic - flow and reroutes traffic in the same direction of the protected - bidirectional LSP RSVP Path signaling. A downstream PLR has a - corresponding downstream MP. + locally detects a failure in the downstream direction of the + traffic flow and reroutes traffic in the same direction of the + protected bidirectional LSP RSVP Path signaling. A downstream PLR + has a corresponding downstream MP. Downstream MP: Downstream Merge Point. The LSR where one or more - backup tunnels rejoin the path of the protected LSP in the downstream - direction of the traffic flow. The same LSR may be both a downstream - MP and an upstream PLR simultaneously. + backup tunnels rejoin the path of the protected LSP in the + downstream direction of the traffic flow. The same LSR may be + both a downstream MP and an upstream PLR simultaneously. Upstream PLR: Upstream Point of Local Repair. The PLR that locally - detects a failure in the upstream direction of the traffic flow and - reroutes traffic in the opposite direction of the protected + detects a failure in the upstream direction of the traffic flow + and reroutes traffic in the opposite direction of the protected bidirectional LSP RSVP Path signaling. An upstream PLR has a corresponding upstream MP. Upstream MP: Upstream Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP in the upstream - direction of the traffic flow. The same LSR may be both an upstream - MP and a downstream PLR simultaneously. + direction of the traffic flow. The same LSR may be both an + upstream MP and a downstream PLR simultaneously. Point of Remote Repair (PRR): A downstream MP that assumes the role - of upstream PLR upon receiving protected LSP's rerouted Path message - and triggers reroute of traffic and signaling in the upstream - direction of the traffic flow using the procedures described in this - document. + of upstream PLR upon receiving protected LSP's rerouted Path + message and triggers reroute of traffic and signaling in the + upstream direction of the traffic flow using the procedures + described in this document. 2.3. Acronyms and Abbreviations GMPLS: Generalized Multi-Protocol Label Switching - LSP: An MPLS Label Switched Path + LSP: Label Switched Path - LSR: An MPLS Label Switching Router + LSR: Label Switching Router MP: Merge Point MPLS: Multi-Protocol Label Switching PLR: Point of Local Repair PSC: Packet Switched Capable RSVP: Resource ReSerVation Protocol @@ -482,21 +482,21 @@ bypass tunnel T3). For the protected co-routed bidirectional LSP whose head-end is on node R1 and tail-end is on node R6, each traversed node (a potential PLR) assigns a link protection co-routed bidirectional bypass tunnel. 5.1.1. Behavior After Link Failure Consider the link R3-R4 on the protected LSP path fails. The downstream PLR R3 and upstream PLR R4 independently trigger fast - reroute to redirect traffic onto bypass tunnels T3 in the forward and + reroute to redirect traffic onto bypass tunnel T3 in the forward and reverse directions. The downstream PLR R3 also reroutes RSVP Path messages onto the bypass tunnel T3 using the procedures described in [RFC4090]. The upstream PLR R4 reroutes RSVP Resv messages onto the reverse bypass tunnel T3 upon receiving RSVP Path message over bypass tunnel T3. 5.1.2. Revertive Behavior After Fast Reroute The revertive behavior defined in [RFC4090], Section 6.5.2, is applicable to the link protection of bidirectional GMPLS LSPs. When @@ -629,25 +629,20 @@ The revertive behavior defined in [RFC4090], Section 6.5.2, is applicable to the node protection of bidirectional GMPLS LSPs. When using the local revertive mode, after the link R3-R4 (in Figures 2 and 3) is restored, following node behaviors apply: o The downstream PLR R3 starts sending the Path messages and traffic flow of the protected LSP over the restored link and stops sending them over the bypass tunnel. - o The upstream PLR R4 starts sending the Resv messages and traffic - flow of the protected LSP over the restored link towards - downstream PLR R3 and forwarding the Path messages towards PRR R5 - and stops sending them over the bypass tunnel. - o When upstream PLR R4 receives the protected LSP Path messages over the restored link, if not already done, it starts sending Resv messages and traffic flow over the restored link towards downstream PLR R3 and forwarding the Path messages towards PRR R5 and stops sending them over the bypass tunnel. o When PRR R5 receives the protected LSP Path messages over the restored path, it starts sending Resv messages and traffic flow over the restored path and stops sending them over the bypass tunnel. @@ -699,90 +694,110 @@ of the bypass tunnel being assigned by the PLR. This can be used to coordinate the bypass tunnel assignment for the protected LSP by the downstream and upstream PLRs in the forward and reverse directions respectively prior or after the failure occurrence. This subobject SHOULD be inserted into the Path RRO by the downstream PLR. It SHOULD NOT be inserted into an RRO by a node which is not a downstream PLR. It MUST NOT be changed by downstream LSRs and MUST NOT be added to a Resv RRO. - The BYPASS_ASSIGNMENT subobject in RRO has the following format: + The BYPASS_ASSIGNMENT IPv4 subobject in RRO has the following format: 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:TBA | Length | Bypass Tunnel ID | + | Type:TBA5 | Length | Bypass Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Bypass Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: BYPASS ASSIGNMENT IPv4 RRO Subobject + Type + + Downstream Bypass Assignment. Value is TBA5 by IANA. + + Length + + The Length contains the total length of the subobject in bytes, + including the Type and Length fields. The length is 8 bytes. + + Bypass Tunnel ID + + The bypass tunnel identifier (16 bits). + + Bypass Destination Address + + The bypass tunnel IPv4 destination address. + + The BYPASS_ASSIGNMENT IPv6 subobject in RRO has the following format: + 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:TBA | Length | Bypass Tunnel ID | + | Type:TBA6 | Length | Bypass Tunnel ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Bypass Destination Address | + (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: BYPASS_ASSIGNMENT IPv6 RRO Subobject Type - Downstream Bypass Assignment. Value is TBA by IANA. + Downstream Bypass Assignment. Value is TBA6 by IANA. Length - The Length contains the total length of the subobject in - bytes, including the Type and Length fields. The length is 8 bytes - with IPv4 address and 20 bytes with IPv6 object. + The Length contains the total length of the subobject in bytes, + including the Type and Length fields. The length is 20 bytes. Bypass Tunnel ID The bypass tunnel identifier (16 bits). Bypass Destination Address - The bypass tunnel IPv4 or IPv6 destination address. + The bypass tunnel IPv6 destination address. 7.2. FRR Bypass Assignment Error Notify Message New Error-code - FRR Bypass Assignment Error (value: TBA1) and its sub-codes are defined for the ERROR_SPEC Object (C-Type 6) [RFC2205] in this document, that is carried by the Notify message (Type 21) - defined in [RFC3473] Section 4.3. This Error is sent by the upstream - PLR to the downstream PLR to notify a bypass assignment error. In - the Notify message, the IP destination address is set to the node - address of the downstream PLR that had initiated the bypass + defined in [RFC3473] Section 4.3. This Error message is sent by the + upstream PLR to the downstream PLR to notify a bypass assignment + error. In the Notify message, the IP destination address is set to + the node address of the downstream PLR that had initiated the bypass assignment. In the ERROR_SPEC Object, IP address is set to the node address of the upstream PLR that detected the bypass assignment error. This Error MUST NOT be sent in a Path Error message. This Error does not cause the protected LSP to be torn down. 8. Compatibility New RSVP subobject BYPASS_ASSIGNMENT is defined for RECORD_ROUTE Object in this document that is carried in the RSVP Path message. Per [RFC3209], nodes not supporting this subobject will ignore the subobject but forward it without modification. As described in Section 7 of this document, this subobject is not carried in the RSVP - Resv message. A new Notify message for FRR Bypass Assignment Error - is defined in this document. Nodes not supporting this message will - ignore it but forward it without modification. + Resv message and is ignored by sending the Notify message for FRR + Bypass Assignment Error (with Subcode: Bypass Assignment Cannot Be + Used) defined in this document. Nodes not supporting the Notify + message defined in this document will ignore it but forward it + without modification. 9. Security Considerations This document introduces a new BYPASS_ASSIGNMENT subobject for the RECORD_ROUTE Object that is carried in an RSVP signaling message. Thus in the event of the interception of a signaling message, more information about LSP's fast reroute protection can be deduced than was previously the case. This is judged to be a very minor security risk as this information is already available by other means. The Notify message for FRR Bypass Assignment Error defined in this @@ -801,24 +815,24 @@ . IANA is requested to assign a value for the new BYPASS_ASSIGNMENT subobject in the "Class Type 21 ROUTE_RECORD - Type 1 Route Record" registry. This document introduces a new subobject for RECORD_ROUTE Object: +--------+-------------------+---------+---------+---------------+ | Type | Description | Carried | Carried | Reference | | | | in Path | in Resv | | +--------+-------------------+---------+---------+---------------+ - | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | + | TBA5 By| BYPASS_ASSIGNMENT | Yes | No | This document | | IANA | IPv4 subobject | | | | +--------+-------------------+---------+---------+---------------+ - | TBA By | BYPASS_ASSIGNMENT | Yes | No | This document | + | TBA6 By| BYPASS_ASSIGNMENT | Yes | No | This document | | IANA | IPv6 subobject | | | | +--------+-------------------+---------+---------+---------------+ 10.2. FRR Bypass Assignment Error Notify Message IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" registry (see ). The "Error Codes and Globally-Defined Error Value Sub-Codes" subregistry is included in this registry. @@ -879,24 +893,25 @@ Protection", RFC 6378, October 2011. [RFC7551] Zhang, F., Ed., Jing, R., and Gandhi, R., Ed., "RSVP-TE Extensions for Associated Bidirectional LSPs", RFC 7551, May 2015. Acknowledgements Authors would like to thank George Swallow for many useful comments and suggestions. Authors would like to thank Lou Berger for the - guidance on this work. Authors would also like to thank Nobo Akiya, - Loa Andersson, Matt Hartley, Himanshu Shah and Gregory Mirsky for - reviewing this document and providing valuable comments. A special - thanks to Adrian Farrel for his thorough review of this document. + guidance on this work and for providing review comments. Authors + would also like to thank Nobo Akiya, Loa Andersson, Matt Hartley, + Himanshu Shah, Gregory Mirsky and Mach Chen for reviewing this + document and providing valuable comments. A special thanks to Adrian + Farrel for his thorough review of this document. Contributors Frederic Jounay Orange CH EMail: frederic.jounay@salt.ch Lizhong Jin Shanghai, China