Internet DRAFT - draft-roch-ccamp-full-reroute-reversion

draft-roch-ccamp-full-reroute-reversion



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]