draft-ietf-rtgwg-ipfrr-notvia-addresses-05.txt   draft-ietf-rtgwg-ipfrr-notvia-addresses-06.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: September 6, 2010 Cisco Systems Expires: April 24, 2011 Cisco Systems
March 5, 2010 October 21, 2010
IP Fast Reroute Using Not-via Addresses IP Fast Reroute Using Not-via Addresses
draft-ietf-rtgwg-ipfrr-notvia-addresses-05 draft-ietf-rtgwg-ipfrr-notvia-addresses-06
Abstract Abstract
This draft describes a mechanism that provides fast reroute in an IP This draft describes a mechanism that provides fast reroute in an IP
network through encapsulation to "not-via" addresses. A single level network through encapsulation to "not-via" addresses. A single level
of encapsulation is used. The mechanism protects unicast, multicast of encapsulation is used. The mechanism protects unicast, multicast
and LDP traffic against link, router and shared risk group failure, and LDP traffic against link, router and shared risk group failure,
regardless of network topology and metrics. regardless of network topology and metrics.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. 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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 This Internet-Draft will expire on April 24, 2011.
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 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 10
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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
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 17, line 21 skipping to change at page 17, line 21
| |
| |
+--------------R------D +--------------R------D
Figure 10: Local Area Networks Figure 10: Local Area Networks
Consider the LAN shown in Figure 10. For connectivity purposes, we Consider the LAN shown in Figure 10. For connectivity purposes, we
consider that the LAN is represented by the pseudonode (N). To consider that the LAN is represented by the pseudonode (N). To
provide IPFRR protection, S must run a connectivity check to each of provide IPFRR protection, S must run a connectivity check to each of
its protected LAN adjacencies P, Q, and R, using, for example BFD its protected LAN adjacencies P, Q, and R, using, for example BFD
[I-D.ietf-bfd-base]. [RFC5880].
When S discovers that it has lost connectivity to P, it is unsure When S discovers that it has lost connectivity to P, it is unsure
whether the failure is: whether the failure is:
o its own interface to the LAN, o its own interface to the LAN,
o the LAN itself, o the LAN itself,
o the LAN interface of P, o the LAN interface of P,
skipping to change at page 30, line 7 skipping to change at page 30, line 7
15. References 15. References
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]
Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-11 (work in progress),
January 2010.
[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
Routing Encapsulation (GRE)", RFC 1701, October 1994. Routing Encapsulation (GRE)", RFC 1701, October 1994.
skipping to change at page 30, line 38 skipping to change at page 30, line 33
[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", [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010. RFC 5714, January 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 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. 10 change blocks. 
21 lines changed or deleted 14 lines changed or added

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