idnits 2.17.1 draft-roch-ccamp-full-reroute-reversion-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Evelyne Roch 2 Internet Draft Lyndon Ong 3 Intended status: Informational Ciena 4 March 5, 2012 6 Revertive Recovery Requirements 7 draft-roch-ccamp-full-reroute-reversion-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with 12 the provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on September 5, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 48 This draft identifies requirements for support of full rerouting 49 recovery scheme in a revertive manner. 51 Table of Contents 53 1. Introduction and Problem Statement.............................2 54 2. Basic Requirements.............................................2 55 3. Analysis of Current Text.......................................2 56 4. Example Scenario...............................................3 57 5. Security Considerations........................................4 58 6. IANA Considerations............................................4 59 7. References.....................................................4 60 7.1. Normative References...........Error! Bookmark not defined. 61 7.2. Informative References.........Error! Bookmark not defined. 62 8. Acknowledgments................................................4 64 1. Introduction and Problem Statement 66 Carriers have expressed interest in supporting full-rerouting with 67 reversion capability. Additional clarification of how this can be 68 supported within GMPLS is needed. 70 2. Basic Requirements 72 We would like to be able to support of a version of rerouting that 73 has the following characteristics: 75 - First the original LSP is established on demand. 77 - Secondly failure of the original LSP causes an alternate LSP to 78 be created without any prior reservation of backup resources, 79 potentially sharing some resources 81 - Finally, traffic reverts to the original LSP path once the 82 failure is repaired. 84 3. Analysis of Current Text 86 The authors would like to get clarifications on how the combination 87 of reversion and rerouting is supported in GMPLS as current 88 specifications are not very explicit about this. 90 In our reading of [RFC4872], section 11, full LSP rerouting 91 (protection type 0x01) involves tearing down the original LSP, 92 although it says make-before-break can be used to establish the 93 alternate LSP before tearing down the original, so that some of the 94 resources can be reused. 96 Rerouting without extra traffic (protection type 0x02) involves pre- 97 establishment of the alternate LSP using a disjoint path, with no 98 sharing of resources. 100 We also found that section 12 on reversion describes how reversion 101 is supported for 1+1 bidirectional protection, 1:n protection with 102 extra traffic, and rerouting without extra traffic, but has no 103 description for reversion for the full LSP rerouting case. 105 It has been suggested that the decision to maintain the original LSP 106 in the case of full LSP rerouting is made by the head-end despite 107 the make-before-break terminology but we are concerned that this may 108 lead to undefined behavior at the tail-end in case of multiple 109 failures. 111 4. Example Scenario 113 For example, let's consider the following network topology: 115 B --- C --- D 116 / \ 117 A --- E --- F --- Z 118 \ / 119 G --- H --- I 121 If we start with an "original" connection A-B-C-D-Z that fails and 122 is restored using "restoration 1" A-E-F-Z that later also fails and 123 is restored to "restoration 2" A-G-H-I-Z. In networks where the SCN 124 is congruent with the data path, the teardown of "original" and 125 "restoration 1" connections may not reach the Z node until much 126 later. 128 If Z receives a request to establish "restoration 2" LSP A-G-H-I-Z, 129 it may still have "original" LSP A-B-C-D-Z and "restoration 1" LSP 130 A-E-F-Z in place if the teardown of either or both of them failed. 131 If Z cannot determine how to setup the bridge/selector, it cannot 132 accept the request. If Z was informed or the revertiveness of the 133 LSP, it could make that determination based on the type. If it is 134 revertive, bridge with "original", otherwise no bridge needed. 136 It may be beneficial for this scenario and potentially other 137 scenarios to distinguish between revertive and non-revertive full 138 rerouting. 140 5. Security Considerations 142 None identified at this time. 144 6. IANA Considerations 146 None identified at this time. 148 7. Normative References 150 [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 151 Ed., "RSVP-TE Extensions in support of End-to-End 152 Generalized Multi-Protocol Label Switching (GMPLS) 153 Recovery", RFC 4872, May 2007. 155 8. Informative References 157 9. Acknowledgements 159 The authors would like to thank members of the OIF Network & Operations 160 WG and the CCAMP co-chairs for their comments and suggestions to this 161 document. 163 Authors' Addresses 165 Evelyne Roch 166 Ciena 167 Email: eroch@ciena.com 169 Lyndon Ong 170 Ciena 171 Email: lyong@ciena.com