draft-ietf-mpls-gmpls-lsp-reroute-01.txt   draft-ietf-mpls-gmpls-lsp-reroute-02.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent) Updates: 3209 Dimitri Papadimitriou (Alcatel Lucent)
Category: Standards Track JP. Vasseur (Cisco) Category: Standards Track JP. Vasseur (Cisco)
Expiration Date: March 2, 2009 Expiration Date: March 19, 2009
September 2, 2008 September 19, 2008
PathErr Message Triggered MPLS and GMPLS LSP Reroute PathErr Message Triggered MPLS and GMPLS LSP Reroute
draft-ietf-mpls-gmpls-lsp-reroute-01.txt draft-ietf-mpls-gmpls-lsp-reroute-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 2, 2009. This Internet-Draft will expire on March 19, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes how Resource ReserVation Protocol (RSVP) This document describes how Resource ReserVation Protocol (RSVP)
PathErr Messages may be used to trigger rerouting of Multi-Protocol PathErr Messages may be used to trigger rerouting of Multi-Protocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic
skipping to change at page 4, line 23 skipping to change at page 4, line 23
This section describes how a downstream node can indicate that it This section describes how a downstream node can indicate that it
desires a node upstream (along the LSP path) to initiate the re- desires a node upstream (along the LSP path) to initiate the re-
routing of an LSP, and how the upstream nodes can respond to such a routing of an LSP, and how the upstream nodes can respond to such a
request. Initiating nodes, transit nodes, and ingress nodes are request. Initiating nodes, transit nodes, and ingress nodes are
described separately. described separately.
2.1. Processing at Requesting Node 2.1. Processing at Requesting Node
When a transit or egress node desires to request the rerouting of an When a transit or egress node desires to request the rerouting of an
established LSP, it first determines if it can act on the reroute established LSP, it first determines if it can act on the reroute
request locally. A reroute request SHOULD be acted on locally if the request locally. Such a check MUST be performed on the condition that
ERO received in the LSP's incoming Path message does not precluded the ERO received in the LSP's incoming Path message does not preclude
the reroute and the node's policy allows local repair. Examples of LSP re-routing. Examples of events that may trigger reroutes are
reroute requests that may be permissible are reroutes avoiding avoiding an outgoing interface, a component, label resource, or a
outgoing interface, component, label resource, or next hops not next hop not explicitly listed in the ERO. In all cases, the actual
explicitly listed in the ERO. When the reroute request can be repair action SHOULD be performed after verification that the local
processed locally, standard local repair processing MUST be followed. policy allows local repair for that LSP/state. That is, any traffic
The node SHOULD limit the number of local repair attempts. The re-routing action (associated to this state) must be initiated and
expected norm is for local repair and, thereby, this case to be completed only as allowed by local node policy.
precluded by policy.
When the requesting node cannot act on a reroute request locally, it When the node cannot act locally, it MUST issue a PathErr message
MUST issue a PathErr message indicating a reroute request. A reroute indicating its inability to perform local rerouting. Such a message
request MUST be indicated via one of the following combinations of MUST include one of the following combinations of error codes and
error codes and error values: error values:
1. "Notify/Local node maintenance required" to support backwards 1. "Notify/Local node maintenance required" to support backwards
compatibility and to reroute around the local node. compatibility and to reroute around the local node.
2. "Notify/Local link maintenance required" to support backwards 2. "Notify/Local link maintenance required" to support backwards
compatibility and to reroute around a local interface. compatibility and to reroute around a local interface.
3. "Reroute/<any Reroute error value>" for future compatibility 3. "Reroute/<any Reroute error value>" for future compatibility
and when backwards compatibility is not a concern. and when backwards compatibility is not a concern.
The rest of the ERROR_SPEC object is constructed based on the local The rest of the ERROR_SPEC object is constructed based on the local
reroute request. When the local reroute request directs a reroute rerouting decision. When the reroute decision redirects traffic
around the local node, the local node MUST be indicated in the around the local node, the local node MUST be indicated in the
ERROR_SPEC object. When the local request does not direct to reroute ERROR_SPEC object. Otherwise, i.e., when the reroute decision does
around the local node, the impacted interface MUST be indicated in not redirect traffic around the local node, the impacted interface
the ERROR_SPEC object. The IF_ID ERROR_SPEC SHOULD also be used when MUST be indicated in the ERROR_SPEC object. The IF_ID ERROR_SPEC
supported. The TLVs defined in [RFC4920] MAY also be used when SHOULD also be used when supported. The TLVs defined in [RFC4920]
supported and when they can provide specific additional reroute MAY also be used when supported and when they can provide specific
request information, e.g., reroute around a specific label. The additional reroute request information, e.g., reroute around a
principles related to ERROR_SPEC object construction defined in specific label. The principles related to ERROR_SPEC object
section 6.3.1. of [RFC4920] SHOULD be followed. construction defined in section 6.3.1. of [RFC4920] SHOULD be
followed.
2.1.1. Reroute Request Timeouts 2.1.1. Reroute Request Timeouts
Reroute request timeouts are used to remove an LSP when there is no Reroute request timeouts are used to remove an LSP when there is no
response to a reroute request. Reroute request timeouts MUST NOT be response to a reroute request. Reroute request timeouts MUST NOT be
used, when the LSP is not to be removed at the expiration of the used, when the LSP is not to be removed at the expiration of the
Reroute request timeout period. When such LSP removal is desired and Reroute request timeout period. When such LSP removal is desired and
after initiating a reroute request, the initiating node MUST initiate after initiating a reroute request, the initiating node MUST initiate
a timeout during which it expects to receive a response to the a timeout during which it expects to receive a response to the
reroute request. Valid responses are a PathTear message or a trigger reroute request. Valid responses are a PathTear message or a trigger
skipping to change at page 8, line 38 skipping to change at page 8, line 38
receiving Resource ReserVation Protocol (RSVP) Path receiving Resource ReserVation Protocol (RSVP) Path
Error message", draft-ietf-mpls-3209-patherr-03.txt, Error message", draft-ietf-mpls-3209-patherr-03.txt,
Work in Progress, August 2008. Work in Progress, August 2008.
[PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft [PREEMPTION] Meyer, M., Ed. "MPLS Traffic Engineering Soft
Preemption", draft-ietf-mpls-soft-preemption-12.txt, Preemption", draft-ietf-mpls-soft-preemption-12.txt,
Work in Progress, September 2008. Work in Progress, September 2008.
6. Acknowledgments 6. Acknowledgments
This document was conceived along with Matthew Meyer. This document was conceived along with Matthew Meyer. George Swallow
provided valuable feedback.
7. Author's Addresses 7. Author's Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Lucent Alcatel Lucent
Francis Wellesplein 1, Francis Wellesplein 1,
skipping to change at line 404 skipping to change at line 405
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Tue Sep 2 13:05:25 EDT 2008 Generated on: Fri Sep 19 10:17:15 EDT 2008
 End of changes. 10 change blocks. 
28 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/