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]
