draft-ietf-rtgwg-ipfrr-notvia-addresses-04.txt   draft-ietf-rtgwg-ipfrr-notvia-addresses-05.txt 
Network Working Group M. Shand Network Working Group M. Shand
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Experimental S. Previdi Intended status: Experimental S. Previdi
Expires: January 11, 2010 Cisco Systems Expires: September 6, 2010 Cisco Systems
July 10, 2009 March 5, 2010
IP Fast Reroute Using Not-via Addresses IP Fast Reroute Using Not-via Addresses
draft-ietf-rtgwg-ipfrr-notvia-addresses-04 draft-ietf-rtgwg-ipfrr-notvia-addresses-05
Abstract
This draft describes a mechanism that provides fast reroute in an IP
network through encapsulation to "not-via" addresses. A single level
of encapsulation is used. The mechanism protects unicast, multicast
and LDP traffic against link, router and shared risk group failure,
regardless of network topology and metrics.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 47
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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 January 11, 2010. This Internet-Draft will expire on September 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This draft describes a mechanism that provides fast reroute in an IP described in the BSD License.
network through encapsulation to "not-via" addresses. A single level
of encapsulation is used. The mechanism protects unicast, multicast
and LDP traffic against link, router and shared risk group failure,
regardless of network topology and metrics.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Not-via Repairs . . . . . . . . . . . . . . . . . 4 2. Overview of Not-via Repairs . . . . . . . . . . . . . . . . . 4
2.1. Use of Equal Cost Multi-Path . . . . . . . . . . . . . . . 6 2.1. Use of Equal Cost Multi-Path . . . . . . . . . . . . . . . 6
2.2. Use of LFA repairs . . . . . . . . . . . . . . . . . . . . 6 2.2. Use of LFA repairs . . . . . . . . . . . . . . . . . . . . 6
3. Not-via Repair Path Computation . . . . . . . . . . . . . . . 6 3. Not-via Repair Path Computation . . . . . . . . . . . . . . . 6
3.1. Computing not-via repairs in routing vector protocols . . 7 3.1. Computing not-via repairs in routing vector protocols . . 7
4. Operation of Repairs . . . . . . . . . . . . . . . . . . . . . 8 4. Operation of Repairs . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 4, line 9 skipping to change at page 4, line 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29
15.2. Informative References . . . . . . . . . . . . . . . . . . 30 15.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
When a link or a router fails, only the neighbors of the failure are When a link or a router fails, only the neighbors of the failure are
initially aware that the failure has occurred. In a network initially aware that the failure has occurred. In a network
operating IP fast reroute [I-D.ietf-rtgwg-ipfrr-framework], the operating IP fast reroute [RFC5714], the routers that are the
routers that are the neighbors of the failure repair the failure. neighbors of the failure repair the failure. These repairing routers
These repairing routers have to steer packets to their destinations have to steer packets to their destinations despite the fact that
despite the fact that most other routers in the network are unaware most other routers in the network are unaware of the nature and
of the nature and location of the failure. location of the failure.
A common limitation in most IPFRR mechanisms is an inability to A common limitation in most IPFRR mechanisms is an inability to
indicate the identity of the failure and to explicitly steer the indicate the identity of the failure and to explicitly steer the
repaired packet round the failure. The extent to which this repaired packet round the failure. The extent to which this
limitation affects the repair coverage is topology dependent. The limitation affects the repair coverage is topology dependent. The
mechanism proposed here is to encapsulate the packet to an address mechanism proposed here is to encapsulate the packet to an address
that explicitly identifies the network component that the repair must that explicitly identifies the network component that the repair must
avoid. This produces a repair mechanism, which, provided the network avoid. This produces a repair mechanism, which, provided the network
is not partitioned by the failure, will always achieve a repair. is not partitioned by the failure, will always achieve a repair.
2. Overview of Not-via Repairs 2. Overview of Not-via Repairs
When a link or a router fails, only the neighbors of the failure are When a link or a router fails, only the neighbors of the failure are
initially aware that the failure has occurred. In a network initially aware that the failure has occurred. In a network
operating IP fast reroute [I-D.ietf-rtgwg-ipfrr-framework], the operating IP fast reroute [RFC5714], the routers that are the
routers that are the neighbors of the failure repair the failure. neighbors of the failure repair the failure. These repairing routers
These repairing routers have to steer packets to their destinations have to steer packets to their destinations despite the fact that
despite the fact that most other routers in the network are unaware most other routers in the network are unaware of the nature and
of the nature and location of the failure. location of the failure.
A common limitation in most IPFRR mechanisms is an inability to A common limitation in most IPFRR mechanisms is an inability to
indicate the identity of the failure and to explicitly steer the indicate the identity of the failure and to explicitly steer the
repaired packet round the failure. The extent to which this repaired packet round the failure. The extent to which this
limitation affects the repair coverage is topology dependent. The limitation affects the repair coverage is topology dependent. The
mechanism proposed here is to encapsulate the packet to an address mechanism proposed here is to encapsulate the packet to an address
that explicitly identifies the network component that the repair must that explicitly identifies the network component that the repair must
avoid. This produces a repair mechanism, which, provided the network avoid. This produces a repair mechanism, which, provided the network
is not partitioned by the failure, will always achieve a repair. is not partitioned by the failure, will always achieve a repair.
skipping to change at page 30, line 9 skipping to change at page 30, line 9
15.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2. Informative References 15.2. Informative References
[I-D.ietf-bfd-base] [I-D.ietf-bfd-base]
Katz, D. and D. Ward, "Bidirectional Forwarding Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-09 (work in progress), Detection", draft-ietf-bfd-base-11 (work in progress),
February 2009. January 2010.
[I-D.ietf-rtgwg-ipfrr-framework]
Shand, M. and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-11 (work in progress),
June 2009.
[I-D.shen-mpls-ldp-nnhop-label] [I-D.shen-mpls-ldp-nnhop-label]
Shen, N., "Discovering LDP Next-Nexthop Labels", Shen, N., "Discovering LDP Next-Nexthop Labels",
draft-shen-mpls-ldp-nnhop-label-02 (work in progress), draft-shen-mpls-ldp-nnhop-label-02 (work in progress),
May 2005. May 2005.
[ISPF] McQuillan, J., Richer, I., and E. Rosen, "ARPANET Routing [ISPF] McQuillan, J., Richer, I., and E. Rosen, "ARPANET Routing
Algorithm Improvements"", BBN Technical Report 3803, 1978. Algorithm Improvements"", BBN Technical Report 3803, 1978.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
skipping to change at page 30, line 40 skipping to change at page 30, line 35
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
Reroute: Loop-Free Alternates", RFC 5286, September 2008. Reroute: Loop-Free Alternates", RFC 5286, September 2008.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010.
Authors' Addresses Authors' Addresses
Mike Shand Mike Shand
Cisco Systems Cisco Systems
250, Longwater Avenue. 250, Longwater Avenue.
Reading, Berks RG2 6GB Reading, Berks RG2 6GB
UK UK
Email: mshand@cisco.com Email: mshand@cisco.com
Stewart Bryant Stewart Bryant
 End of changes. 9 change blocks. 
41 lines changed or deleted 42 lines changed or added

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