draft-ietf-rtgwg-ipfrr-notvia-addresses-02.txt   draft-ietf-rtgwg-ipfrr-notvia-addresses-03.txt 
Network Working Group M. Shand Network Working Group M. Shand
Internet-Draft S. Bryant Internet-Draft S. Bryant
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: August 28, 2008 Cisco Systems Expires: May 3, 2009 Cisco Systems
February 25, 2008 October 30, 2008
IP Fast Reroute Using Not-via Addresses IP Fast Reroute Using Not-via Addresses
draft-ietf-rtgwg-ipfrr-notvia-addresses-02.txt draft-ietf-rtgwg-ipfrr-notvia-addresses-03
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 35 skipping to change at page 1, line 35
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 August 28, 2008. This Internet-Draft will expire on May 3, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
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.
Table of Contents Table of Contents
skipping to change at page 5, line 30 skipping to change at page 5, line 30
not-via repair. not-via repair.
A router computing a not-via repair path MAY subject the repair to A router computing a not-via repair path MAY subject the repair to
ECMP. ECMP.
3.2. Use of LFA repairs 3.2. Use of LFA repairs
The not-via approach provides complete repair coverage and therefore The not-via approach provides complete repair coverage and therefore
may be used as the sole repair mechanism. There are, however, may be used as the sole repair mechanism. There are, however,
advantages in using not-via in combination with loop free alternates advantages in using not-via in combination with loop free alternates
(LFA) and or downstream paths as documented in (LFA) and or downstream paths as documented in [RFC5286].
[I-D.ietf-rtgwg-ipfrr-spec-base].
LFAs are computed on a per destination basis and in general, only a LFAs are computed on a per destination basis and in general, only a
subset of the destinations requiring repair will have a suitable LFA subset of the destinations requiring repair will have a suitable LFA
repair. In this case, those destinations which are repairable by repair. In this case, those destinations which are repairable by
LFAs are so repaired and the remainder of the destinations are LFAs are so repaired and the remainder of the destinations are
repaired using the not-via encapsulation. This has the advantage of repaired using the not-via encapsulation. This has the advantage of
reducing the volume of traffic that requires encapsulation. On the reducing the volume of traffic that requires encapsulation. On the
other hand, the path taken by an LFA repair may be less optimal than other hand, the path taken by an LFA repair may be less optimal than
that of the equivalent not-via repair for traffic destined to nodes that of the equivalent not-via repair for traffic destined to nodes
close to the far end of the failure, but may be more optimal for some close to the far end of the failure, but may be more optimal for some
skipping to change at page 8, line 26 skipping to change at page 8, line 26
itself had failed, the repaired packet from S would arrive at A itself had failed, the repaired packet from S would arrive at A
encapsulated to Ps. A would have detected that the AP link had encapsulated to Ps. A would have detected that the AP link had
failed and would normally attempt to repair the packet. However, no failed and would normally attempt to repair the packet. However, no
repair path is provided for any not-via address, and so A would be repair path is provided for any not-via address, and so A would be
forced to drop the packet, thus preventing the formation of loop. forced to drop the packet, thus preventing the formation of loop.
5.3. Multi-homed Prefixes 5.3. Multi-homed Prefixes
A multi-homed Prefix (MHP) is a prefix that is reachable via more A multi-homed Prefix (MHP) is a prefix that is reachable via more
than one router in the network. Some of these may be repairable than one router in the network. Some of these may be repairable
using LFAs as described in [I-D.ietf-rtgwg-ipfrr-spec-base]. Only using LFAs as described in [RFC5286]. Only those without such a
those without such a repair need be considered here. repair need be considered here.
When IPFRR router S (Figure 3) discovers that P has failed, it needs When IPFRR router S (Figure 3) discovers that P has failed, it needs
to send packets addressed to the MHP X, which is normally reachable to send packets addressed to the MHP X, which is normally reachable
through P, to an alternate router, which is still able to reach X. through P, to an alternate router, which is still able to reach X.
X X X X X X
| | | | | |
| | | | | |
| Sp |Pb | | Sp |Pb |
Z...............S----------P----------B...............Y Z...............S----------P----------B...............Y
skipping to change at page 9, line 44 skipping to change at page 9, line 44
The following algorithm is used by node S (Figure 3) to pre- The following algorithm is used by node S (Figure 3) to pre-
calculate and install repair paths in the FIB, ready for immediate calculate and install repair paths in the FIB, ready for immediate
use in the event of a failure. It is assumed that the not-via repair use in the event of a failure. It is assumed that the not-via repair
paths have already been calculated as described above. paths have already been calculated as described above.
For each neighbor P, consider all destinations which are reachable For each neighbor P, consider all destinations which are reachable
via P in the current topology:- via P in the current topology:-
1. For all destinations with an ECMP or LFA repair (as described in 1. For all destinations with an ECMP or LFA repair (as described in
[I-D.ietf-rtgwg-ipfrr-spec-base]) install that repair. [RFC5286]) install that repair.
2. For each destination (DR) that remains, identify in the current 2. For each destination (DR) that remains, identify in the current
topology the next-next-hop (H) (i.e. the neighbor of P that P topology the next-next-hop (H) (i.e. the neighbor of P that P
will use to send the packet to DR). This can be determined will use to send the packet to DR). This can be determined
during the normal SPF run by recording the additional during the normal SPF run by recording the additional
information. If S has a path to the not-via address Hp (H not information. If S has a path to the not-via address Hp (H not
via P), install a not-via repair to Hp for the destination DR. via P), install a not-via repair to Hp for the destination DR.
3. Identify all remaining destinations (M) which can still be 3. Identify all remaining destinations (M) which can still be
reached when node P fails. These will be multi-homed prefixes reached when node P fails. These will be multi-homed prefixes
skipping to change at page 15, line 4 skipping to change at page 15, line 4
complexity of performing the diagnostics, this requires multiple complexity of performing the diagnostics, this requires multiple
not-via addresses per interface, which has poor scaling not-via addresses per interface, which has poor scaling
properties. properties.
6.1.1. Use of LFAs with SRLGs 6.1.1. Use of LFAs with SRLGs
Section 4.1 above describes the repair of links which are members of Section 4.1 above describes the repair of links which are members of
one or more SRLGs. LFAs can be used for the repair of such links one or more SRLGs. LFAs can be used for the repair of such links
provided that any other link with which S-P shares an SRLG is avoided provided that any other link with which S-P shares an SRLG is avoided
when computing the LFA. This is described for the simple case of when computing the LFA. This is described for the simple case of
"local-SRLGs" in [I-D.ietf-rtgwg-ipfrr-spec-base]. "local-SRLGs" in [RFC5286].
6.2. Local Area Networks 6.2. Local Area Networks
LANs are a special type of SRLG and are solved using the SRLG LANs are a special type of SRLG and are solved using the SRLG
mechanisms outlined above. With all SRLGs there is a trade-off mechanisms outlined above. With all SRLGs there is a trade-off
between the sophistication of the fault detection and the size of the between the sophistication of the fault detection and the size of the
SRLG. Protecting against link failure of the LAN link(s) is SRLG. Protecting against link failure of the LAN link(s) is
relatively straightforward, but as with all fast reroute mechanisms, relatively straightforward, but as with all fast reroute mechanisms,
the problem becomes more complex when it is desired to protect the problem becomes more complex when it is desired to protect
against the possibility of failure of the nodes attached to the LAN against the possibility of failure of the nodes attached to the LAN
skipping to change at page 21, line 21 skipping to change at page 21, line 21
17.1. Normative References 17.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.
17.2. Informative References 17.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-07 (work in progress), Detection", draft-ietf-bfd-base-08 (work in progress),
January 2008. March 2008.
[I-D.ietf-rtgwg-ipfrr-framework] [I-D.ietf-rtgwg-ipfrr-framework]
Shand, M. and S. Bryant, "IP Fast Reroute Framework", Shand, M. and S. Bryant, "IP Fast Reroute Framework",
draft-ietf-rtgwg-ipfrr-framework-07 (work in progress), draft-ietf-rtgwg-ipfrr-framework-08 (work in progress),
July 2007. February 2008.
[I-D.ietf-rtgwg-ipfrr-spec-base]
Atlas, A., Zinin, A., Torvi, R., Choudhury, G., Martin,
C., Imhoff, B., and D. Fedyk, "Basic Specification for IP
Fast-Reroute: Loop-free Alternates",
draft-ietf-rtgwg-ipfrr-spec-base-10 (work in progress),
November 2007.
[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 22, line 8 skipping to change at page 21, line 49
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996. October 1996.
[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
Reroute: Loop-Free Alternates", RFC 5286, September 2008.
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
skipping to change at page 23, line 44 skipping to change at line 1024
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 11 change blocks. 
25 lines changed or deleted 16 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/