Network Working Group Evelyne Roch Internet Draft Lyndon Ong Intended status: Informational Ciena March 5, 2012 Revertive Recovery Requirements draft-roch-ccamp-full-reroute-reversion-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 5, 2012. Copyright Notice Copyright (c) 2012 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 described in the Simplified BSD License. Abstract Roch Expires September 5, 2012 [Page 1] Internet-Draft draft-roch-ccamp-full-reroute-reversion March 2012 This draft identifies requirements for support of full rerouting recovery scheme in a revertive manner. Table of Contents 1. Introduction and Problem Statement.............................2 2. Basic Requirements.............................................2 3. Analysis of Current Text.......................................2 4. Example Scenario...............................................3 5. Security Considerations........................................4 6. IANA Considerations............................................4 7. References.....................................................4 7.1. Normative References...........Error! Bookmark not defined. 7.2. Informative References.........Error! Bookmark not defined. 8. Acknowledgments................................................4 1. Introduction and Problem Statement Carriers have expressed interest in supporting full-rerouting with reversion capability. Additional clarification of how this can be supported within GMPLS is needed. 2. Basic Requirements We would like to be able to support of a version of rerouting that has the following characteristics: - First the original LSP is established on demand. - Secondly failure of the original LSP causes an alternate LSP to be created without any prior reservation of backup resources, potentially sharing some resources - Finally, traffic reverts to the original LSP path once the failure is repaired. 3. Analysis of Current Text The authors would like to get clarifications on how the combination of reversion and rerouting is supported in GMPLS as current specifications are not very explicit about this. In our reading of [RFC4872], section 11, full LSP rerouting (protection type 0x01) involves tearing down the original LSP, although it says make-before-break can be used to establish the Roch Expires September 5, 2012 [Page 2] Internet-Draft draft-roch-ccamp-full-reroute-reversion March 2012 alternate LSP before tearing down the original, so that some of the resources can be reused. Rerouting without extra traffic (protection type 0x02) involves pre- establishment of the alternate LSP using a disjoint path, with no sharing of resources. We also found that section 12 on reversion describes how reversion is supported for 1+1 bidirectional protection, 1:n protection with extra traffic, and rerouting without extra traffic, but has no description for reversion for the full LSP rerouting case. It has been suggested that the decision to maintain the original LSP in the case of full LSP rerouting is made by the head-end despite the make-before-break terminology but we are concerned that this may lead to undefined behavior at the tail-end in case of multiple failures. 4. Example Scenario For example, let's consider the following network topology: B --- C --- D / \ A --- E --- F --- Z \ / G --- H --- I If we start with an "original" connection A-B-C-D-Z that fails and is restored using "restoration 1" A-E-F-Z that later also fails and is restored to "restoration 2" A-G-H-I-Z. In networks where the SCN is congruent with the data path, the teardown of "original" and "restoration 1" connections may not reach the Z node until much later. If Z receives a request to establish "restoration 2" LSP A-G-H-I-Z, it may still have "original" LSP A-B-C-D-Z and "restoration 1" LSP A-E-F-Z in place if the teardown of either or both of them failed. If Z cannot determine how to setup the bridge/selector, it cannot accept the request. If Z was informed or the revertiveness of the LSP, it could make that determination based on the type. If it is revertive, bridge with "original", otherwise no bridge needed. Roch Expires September 5, 2012 [Page 3] Internet-Draft draft-roch-ccamp-full-reroute-reversion March 2012 It may be beneficial for this scenario and potentially other scenarios to distinguish between revertive and non-revertive full rerouting. 5. Security Considerations None identified at this time. 6. IANA Considerations None identified at this time. 7. Normative References [RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. 8. Informative References 9. Acknowledgements The authors would like to thank members of the OIF Network & Operations WG and the CCAMP co-chairs for their comments and suggestions to this document. Roch Expires September 5, 2012 [Page 4] Internet-Draft draft-roch-ccamp-full-reroute-reversion March 2012 Authors' Addresses Evelyne Roch Ciena Email: eroch@ciena.com Lyndon Ong Ciena Email: lyong@ciena.com Roch Expires September 5, 2012 [Page 5]