draft-ietf-ospf-abr-alt-05.txt   rfc3509.txt 
Network Working Group Alex Zinin Network Working Group A. Zinin
Internet Draft Alcatel Request for Comments: 3509 Alcatel
Expiration Date: April 2003 Acee Lindem Category: Informational A. Lindem
File name: draft-ietf-ospf-abr-alt-05.txt Redback Networks Redback Networks
Derek Yeung D. Yeung
Procket Networks Procket Networks
October 2002 April 2003
Alternative OSPF ABR Implementations Alternative Implementations of OSPF Area Border Routers
draft-ietf-ospf-abr-alt-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress".
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2003). All Rights Reserved.
http://www.ietf.org/shadow.html.
Abstract Abstract
OSPF is a link-state intra-domain routing protocol used for routing Open Shortest Path First (OSPF) is a link-state intra-domain routing
in IP networks. Though the definition of the Area Border Router (ABR) protocol used for routing in IP networks. Though the definition of
in the OSPF specification does not require a router with multiple the Area Border Router (ABR) in the OSPF specification does not
attached areas to have a backbone connection, it is actually require a router with multiple attached areas to have a backbone
necessary to provide successful routing to the inter-area and connection, it is actually necessary to provide successful routing to
external destinations. If this requirement is not met, all traffic the inter-area and external destinations. If this requirement is not
destined for the areas not connected to such an ABR or out of the met, all traffic destined for the areas not connected to such an ABR
OSPF domain, is dropped. This document describes alternative ABR or out of the OSPF domain, is dropped. This document describes
behaviors implemented in Cisco and IBM routers. alternative ABR behaviors implemented in Cisco and IBM routers.
1 Overview 1 Overview
1.1 Introduction 1.1 Introduction
An OSPF routing domain can be split into several subdomains, called An OSPF routing domain can be split into several subdomains, called
areas, which limit the scope of LSA flooding. According to [Ref1] a areas, which limit the scope of LSA flooding. According to [Ref1] a
router having attachments to multiple areas is called an "area border router having attachments to multiple areas is called an "area border
router" (ABR). The primary function of an ABR is to provide its router" (ABR). The primary function of an ABR is to provide its
attached areas with Type-3 and Type-4 LSAs (which are used for attached areas with Type-3 and Type-4 LSAs, which are used for
describing routes and ASBRs in other areas) as well as to perform describing routes and AS boundary routers (ASBRs) in other areas, as
actual inter-area routing. well as to perform actual inter-area routing.
1.2 Motivation 1.2 Motivation
In OSPF domains the area topology is restricted so that there must be In OSPF domains the area topology is restricted so that there must be
a backbone area (area 0) and all other areas must have either a backbone area (area 0) and all other areas must have either
physical or virtual connections to the backbone. The reason for this physical or virtual connections to the backbone. The reason for this
star-like topology is that OSPF inter-area routing uses the distance- star-like topology is that OSPF inter-area routing uses the
vector approach and a strict area hierarchy permits avoidance of the distance-vector approach and a strict area hierarchy permits
"counting to infinity" problem. OSPF prevents inter-area routing avoidance of the "counting to infinity" problem. OSPF prevents
loops by implementing a split-horizon mechanism, allowing ABRs to inter-area routing loops by implementing a split-horizon mechanism,
inject into the backbone only Summary-LSAs derived from the intra- allowing ABRs to inject into the backbone only Summary-LSAs derived
area routes, and limiting ABRs' SPF calculation to consider only from the
Summary-LSAs in the backbone area's link-state database. intra-area routes, and limiting ABRs' SPF calculation to consider
only Summary-LSAs in the backbone area's link-state database.
The last restriction leads to a problem when an ABR has no backbone The last restriction leads to a problem when an ABR has no backbone
connection (in OSPF, an ABR does not need to be attached to the connection (in OSPF, an ABR does not need to be attached to the
backbone). Consider a sample OSPF domain depicted in the Figure 1. backbone). Consider a sample OSPF domain depicted in the Figure 1.
. . . .
. Area 0 . . Area 0 .
+--+ +--+ +--+ +--+
..|R1|.. ..|R2|.. ..|R1|.. ..|R2|..
. +--+ .. +--+ . . +--+ .. +--+ .
. .. . . .. .
. +--+ . . +--+ .
. Area1 |R3| Area2 . . Area1 |R3| Area2 .
. +--+ +--+ . . +--+ +--+ .
. .. |R4| . . .. |R4| .
. . . +--+ . . . . +--+ .
....... ....... ....... .......
Figure 1. ABR dropping transit traffic Figure 1. ABR dropping transit traffic
In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone In this example R1, R2, and R3 are ABRs. R1 and R2 have backbone
connections, while R3 doesn't. connections, while R3 doesn't.
Following the section 12.4.1 of [Ref1], R3 will identify itself as an Following the section 12.4.1 of [Ref1], R3 will identify itself as an
ABR by setting the bit B in its router-LSA. Being an ABR, R3 can only ABR by setting the bit B in its router-LSA. Being an ABR, R3 can
consider summary-LSAs from the backbone when building the routing only consider summary-LSAs from the backbone when building the
table (according to section 16.2 of [Ref1]), so it will not have any routing table (according to section 16.2 of [Ref1]), so it will not
inter-area routes in its routing table, but only intra-area routes have any inter-area routes in its routing table, but only intra-area
from both Area 1 and Area 2. Consequently, according to section routes from both Area 1 and Area 2. Consequently, according to
12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only summary- section 12.4.3 of [Ref1], R3 will originate into Areas 1 and 2 only
LSAs covering destinations in the directly attached areas, i.e., in summary-LSAs covering destinations in the directly attached areas,
Area 2---the summary-LSAs for Area 1, and in Area 1---the summary- i.e., in Area 2---the summary-LSAs for Area 1, and in Area 1---the
LSAs for Area 2. summary-LSAs for Area 2.
At the same time, router R2, as an ABR connected to the backbone, At the same time, router R2, as an ABR connected to the backbone,
will inject into Area 2 summary-LSAs describing the destinations in will inject into Area 2 summary-LSAs describing the destinations in
Area 0 (the backbone), Area 1 and other areas reachable through the Area 0 (the backbone), Area 1 and other areas reachable through the
backbone. backbone.
This results in a situation where internal router R4 calculates its This results in a situation where internal router R4 calculates its
routes to destinations in the backbone and areas other than Area 1 routes to destinations in the backbone and areas other than Area 1
via R2. The topology of Area 2 itself can be such that the best path via R2. The topology of Area 2 itself can be such that the best path
from R4 to R2 is via R3, so all traffic destined for the backbone and from R4 to R2 is via R3, so all traffic destined for the backbone and
backbone-attached areas goes through R3. Router R3 in turn, having backbone-attached areas goes through R3. Router R3 in turn, having
only intra-area routes for areas 1 and 2, will drop all traffic not only intra-area routes for areas 1 and 2, will drop all traffic not
destined for the areas directly attached to it. The same problem can destined for the areas directly attached to it. The same problem can
occur when a backbone-connected ABR loses all of its adjacencies in occur when a backbone-connected ABR loses all of its adjacencies in
the backbone---even if there are other normally functioning ABRs in the backbone---even if there are other normally functioning ABRs in
the attached areas, all traffic going to the backbone (destined for the attached areas, all traffic going to the backbone (destined for
it or for other areas) will be dropped. it or for other areas) will be dropped.
In a standard OSPF implementation this situation can be remedied by In a standard OSPF implementation this situation can be remedied by
use of Virtual Links (see section 15 of [Ref1] for more details). In use of Virtual Links (see section 15 of [Ref1] for more details). In
this case, router R3 will have a virtual backbone connection, will this case, router R3 will have a virtual backbone connection, will
form an adjacency over it, will receive all LSAs directly from a form an adjacency over it, will receive all LSAs directly from a
backbone-attached router (R1 or R2, or both in our example) and will backbone-attached router (R1 or R2, or both in our example) and will
install intra- or inter-area routes. install intra- or inter-area routes.
While being an unavoidable technique for repairing a partitioned While being an unavoidable technique for repairing a partitioned
backbone area, the use of virtual links in the described situation backbone area, the use of virtual links in the described situation
adds extra configuration headaches and system traffic overhead. adds extra configuration headaches and system traffic overhead.
Another situation where standard ABR behavior does not provide Another situation where standard ABR behavior does not provide
acceptable results is when it is necessary to provide redundant acceptable results is when it is necessary to provide redundant
connectivity to an ASBR via several different OSPF areas. This would connectivity to an ASBR via several different OSPF areas. This would
allow a provider to aggregate all their customers connecting through allow a provider to aggregate all their customers connecting through
a single access point into one area while still offering a redundant a single access point into one area while still offering a redundant
connection through another access point in a different area, as shown connection through another access point in a different area, as shown
in Figure 2. in Figure 2.
. . . .
. Area 0 . . Area 0 .
+--+ +--+ +--+ +--+
..|R1|.. ..|R2|.. ..|R1|.. ..|R2|..
. +--+ .. +--+ . . +--+ .. +--+ .
. .. . . .. .
. .. . . .. .
. Area1 .. Area2 . . Area1 .. Area2 .
. .. . . .. .
. .. . . .. .
. +--+ . . +--+ .
.......|R3|....... .......|R3|.......
ASBR+--+ ASBR+--+
/..\ /..\
--+- -+-- --+- -+--
CN1 CNx CN1 CNx
Customer Networks (CN1--CNx) Advertised Customer Networks (CN1--CNx) Advertised
as AS External or NSSA External Routes as AS External or NSSA External Routes
Figure 2. Dual Homed Customer Router Figure 2. Dual Homed Customer Router
This technique is already used in a number of networks including one This technique is already used in a number of networks including one
of a major provider. of a major provider.
The next section describes alternative ABR behaviors, implemented in The next section describes alternative ABR behaviors, implemented in
Cisco and IBM routers. The changes are in the ABR definition and Cisco and IBM routers. The changes are in the ABR definition and
inter-area route calculation. Any other parts of standard OSPF are inter-area route calculation. Any other parts of standard OSPF are
not changed. not changed.
These solutions are targeted to the situation when an ABR has no These solutions are targeted to the situation when an ABR has no
backbone connection. They imply that a router connected to multiple backbone connection. They imply that a router connected to multiple
areas without a backbone connection is not an ABR and should function areas without a backbone connection is not an ABR and should function
as a router internal to every attached area. This solution emulates a as a router internal to every attached area. This solution emulates
situation where separate OSPF processes are run for each area and a situation where separate OSPF processes are run for each area and
supply routes to the routing table. It remedies the situation supply routes to the routing table. It remedies the situation
described in the examples above by not dropping transit traffic. described in the examples above by not dropping transit traffic.
Note that a router following it does not function as a real border Note that a router following it does not function as a real border
router---it doesn't originate summary-LSAs. Nevertheless such a router---it doesn't originate summary-LSAs. Nevertheless such a
behavior may be desirable in certain situations. behavior may be desirable in certain situations.
Note that the proposed solutions do not obviate the need of virtual Note that the proposed solutions do not obviate the need of virtual
link configuration in case an area has no physical backbone link configuration in case an area has no physical backbone
connection at all. The methods described here improve the behavior of connection at all. The methods described here improve the behavior
a router connecting two or more backbone-attached areas. of a router connecting two or more backbone-attached areas.
2 Changes to ABR Behavior 2 Changes to ABR Behavior
2.1 Definitions 2.1 Definitions
The following definitions will be used in this document to describe The following definitions will be used in this document to describe
the new ABR behaviors: the new ABR behaviors:
Configured area: Configured area:
An area is considered configured if the router has at least one An area is considered configured if the router has at least one
interface in any state assigned to that area. interface in any state assigned to that area.
Actively Attached area: Actively Attached area:
An area is considered actively attached if the router has at An area is considered actively attached if the router has at least
least one interface in that area in the state other than Down. one interface in that area in the state other than Down.
Active Backbone Connection: Active Backbone Connection:
A router is considered to have an active backbone connection if A router is considered to have an active backbone connection if
the backbone area is actively attached and there is at least one the backbone area is actively attached and there is at least one
fully adjacent neighbor in it. fully adjacent neighbor in it.
Area Border Router (ABR): Area Border Router (ABR):
Cisco Systems Interpretation: Cisco Systems Interpretation:
A router is considered to be an ABR if it has more than one area A router is considered to be an ABR if it has more than one
Actively Attached and one of them is the backbone area. area Actively Attached and one of them is the backbone area.
IBM Interpretation: IBM Interpretation:
A router is considered to be an ABR if it has more than one A router is considered to be an ABR if it has more than one
Actively Attached area and the backbone area Configured. Actively Attached area and the backbone area Configured.
2.2 Implementation Details 2.2 Implementation Details
The following changes are made to the base OSPF, described in [Ref1]: The following changes are made to the base OSPF, described in [Ref1]:
1. The algorithm of Type 1 LSA (router-LSA) origination is changed 1. The algorithm for Type 1 LSA (router-LSA) origination is changed
to prevent a multi-area connected router from identifying itself to prevent a multi-area connected router from identifying itself
as an ABR by the bit B (as described in section 12.4.1 of [Ref1]) as an ABR by the bit B (as described in section 12.4.1 of [Ref1])
until it considers itself as an ABR according to the definitions until it considers itself as an ABR according to the definitions
given in section 2.1. given in section 2.1.
2. The algorithm of the routing table calculation is changed to 2. The algorithm for the routing table calculation is changed to
allow the router to consider the summary-LSAs from all attached allow the router to consider the summary-LSAs from all attached
areas if it is not an ABR, but has more than one attached area, areas if it is not an ABR, but has more than one attached area,
or it does not have an Active Backbone Connection. Definitions of or it does not have an Active Backbone Connection. Definitions
the terms used in this paragraph are given in section 2.1. of the terms used in this paragraph are given in section 2.1.
So, the paragraph 1 of section 16.2 of [Ref1] should be So, the paragraph 1 of section 16.2 of [Ref1] should be
interpreted as follows: interpreted as follows:
"The inter-area routes are calculated by examining summary-LSAs. "The inter-area routes are calculated by examining summary-LSAs.
If the router is an ABR and has an Active Backbone Connection, If the router is an ABR and has an Active Backbone Connection,
only backbone summary-LSAs are examined. Otherwise (either the only backbone summary-LSAs are examined. Otherwise (either the
router is not an ABR or it has no Active Backbone Connection), router is not an ABR or it has no Active Backbone Connection),
the router should consider summary-LSAs from all Actively the router should consider summary-LSAs from all Actively
Attached areas..." Attached areas..."
3. For Cisco ABR approach, the algorithm of the summary-LSAs 3. For Cisco ABR approach, the algorithm for the summary-LSAs
origination is changed to prevent loops of summary-LSAs in origination is changed to prevent loops of summary-LSAs in
situations where the router considers itself an ABR but doesn't situations where the router considers itself an ABR but doesn't
have an Active Backbone Connection (and, consequently, examines have an Active Backbone Connection (and, consequently, examines
summaries from all attached areas). The algorithm is changed to summaries from all attached areas). The algorithm is changed to
allow an ABR to announce only intra-area routes in such a allow an ABR to announce only intra-area routes in such a
situation. situation.
So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be
interpreted as follows: interpreted as follows:
"Summary-LSAs are originated by area border routers. The precise "Summary-LSAs are originated by area border routers. The precise
summary routes to advertise into an area are determined by summary routes to advertise into an area are determined by
examining the routing table structure (see Section 11) in examining the routing table structure (see Section 11) in
accordance with the algorithm described below. Note that while accordance with the algorithm described below. Note that while
only intra-area routes are advertised into the backbone, if the only intra-area routes are advertised into the backbone, if the
router has an Active Backbone Connection, both intra-area and router has an Active Backbone Connection, both intra-area and
inter-area routes are advertised into the other areas; otherwise, inter-area routes are advertised into the other areas; otherwise,
the router only advertises intra-area routes into non-backbone the router only advertises intra-area routes into non-backbone
areas." areas."
For this policy to be applied we change steps 6 and 7 in the For this policy to be applied we change steps 6 and 7 in the
summary origination algorithm to be as follows: summary origination algorithm to be as follows:
Step 6: Step 6:
"Else, if the destination of this route is an AS boundary "Else, if the destination of this route is an AS boundary
router, a summary-LSA should be originated if and only if the router, a summary-LSA should be originated if and only if the
routing table entry describes the preferred path to the AS routing table entry describes the preferred path to the AS
boundary router (see Step 3 of Section 16.4). If so, a Type 4 boundary router (see Step 3 of Section 16.4). If so, a Type 4
summary-LSA is originated for the destination, with Link State summary-LSA is originated for the destination, with Link State
ID equal to the AS boundary router's Router ID and metric equal ID equal to the AS boundary router's Router ID and metric
to the routing table entry's cost. If the ABR performing this equal to the routing table entry's cost. If the ABR
algorithm does not have an Active Backbone Connection, it can performing this algorithm does not have an Active Backbone
originate Type 4 summary-LSA only if the type of the route to Connection, it can originate Type 4 summary-LSA only if the
the ASBR is intra-area. Note: Type 4 summary-LSAs should not type of the route to the ASBR is intra-area. Note: Type 4
be generated if Area A has been configured as a stub area." summary-LSAs should not be generated if Area A has been
configured as a stub area."
Step 7: Step 7:
"Else, the Destination type is network. If this is an inter- "Else, the Destination type is network. If this is an
area route and the ABR performing this algorithm has an Active inter-area route and the ABR performing this algorithm has an
Backbone Connection, generate a Type 3 summary-LSA for the Active Backbone Connection, generate a Type 3 summary-LSA for
destination, with Link State ID equal to the network's address the destination, with Link State ID equal to the network's
(if necessary, the Link State ID can also have one or more of address (if necessary, the Link State ID can also have one or
the network's host bits set; see Appendix E for details) and more of the network's host bits set; see Appendix E for
metric equal to the routing table cost." details) and metric equal to the routing table cost."
The changes in the ABR behavior described in this section allow a The changes in the ABR behavior described in this section allow a
multi-area connected router to successfully route traffic destined multi-area connected router to successfully route traffic destined
for the backbone and other areas. Note that if the router does not for the backbone and other areas. Note that if the router does not
have a backbone area Configured it does not actively attract inter- have a backbone area Configured it does not actively attract
area traffic, because it does not consider itself an ABR and does not inter-area traffic, because it does not consider itself an ABR and
originate summary-LSAs. It still can forward traffic from one does not originate summary-LSAs. It still can forward traffic from
attached area to another along intra-area routes in case other one attached area to another along intra-area routes in case other
routers in corresponding areas have the best inter-area paths over routers in corresponding areas have the best inter-area paths over
it, as described in section 1.2. it, as described in section 1.2.
By processing all summaries when the backbone is not active, we By processing all summaries when the backbone is not active, we
prevent the ABR, which has just lost its last backbone adjacency, prevent the ABR, which has just lost its last backbone adjacency,
from dropping any packets going through the ABR in question to from dropping any packets going through the ABR in question to
another ABR and destined towards the backbone or other areas not another ABR and destined towards the backbone or other areas not
connected to the ABR directly. connected to the ABR directly.
3 Virtual Link Treatment 3 Virtual Link Treatment
skipping to change at page 8, line 5 skipping to change at page 7, line 47
Figure 3, and the state of the VL is determined as in [Ref1]. Figure 3, and the state of the VL is determined as in [Ref1].
....... ........... ...... ....... ........... ......
. . . . . . . .
+--+ VL +--+ +--+ VL +--+
|R1|***********|R2| |R1|***********|R2|
+--+ +--+ +--+ +--+
Area 1 . . Area 2 . . Area 3 Area 1 . . Area 2 . . Area 3
....... ........... ...... ....... ........... ......
Figure 3. Purely Virtual Backbone Figure 3. Purely Virtual Backbone
If R1 and R3 treat virtual links as in [Ref1], their virtual links If R1 and R2 treat virtual links as in [Ref1], their virtual links
will never go up, because their router-LSAs do not contain the B-bit, will never go up, because their router-LSAs do not contain the B-bit,
which is, in turn, because the routers do not have active interfaces which is, in turn, because the routers do not have active interfaces
(virtual links) in the backbone and do not consider themselves ABRs. (virtual links) in the backbone and do not consider themselves ABRs.
Note that this problem does not appear if one of the routers has a Note that this problem does not appear if one of the routers has a
real interface in the backbone, as it usually is in real networks. real interface in the backbone, as it usually is in real networks.
Though the situation described is deemed to be rather rare, Though the situation described is deemed to be rather rare,
implementations supporting Cisco ABR behavior may consider changing implementations supporting Cisco ABR behavior may consider changing
VL-specific code so that a virtual link is reported up (an VL-specific code so that a virtual link is reported up (an
InterfaceUp event is generated) when a router with corresponding InterfaceUp event is generated) when a router with corresponding
router-ID is seen via Dijkstra, no matter whether its router-LSA router-ID is seen via Dijkstra, no matter whether its router-LSA
indicates that it is an ABR or not. This means that checking of indicates that it is an ABR or not. This means that checking of
configured virtual links should be done not in step 4 of the configured virtual links should be done not in step 4 of the
skipping to change at page 8, line 35 skipping to change at page 8, line 29
4 Compatibility 4 Compatibility
The changes of the OSPF ABR operations do not influence any aspects The changes of the OSPF ABR operations do not influence any aspects
of the router-to-router cooperation and do not create routing loops, of the router-to-router cooperation and do not create routing loops,
and hence are fully compatible with standard OSPF. Proof of and hence are fully compatible with standard OSPF. Proof of
compatibility is outside the scope of this document. compatibility is outside the scope of this document.
5 Deployment Considerations 5 Deployment Considerations
This section discusses the deployments details of the ABR behaviors This section discusses the deployments details of the ABR behaviors
described in this document. Note that this approach is fully described in this document. Note that this approach is fully
compatible with standard ABR behavior, so ABRs acting as described in compatible with standard ABR behavior, so ABRs acting as described in
[Ref1] and in this document can coexist in an OSPF domain and will [Ref1] and in this document can coexist in an OSPF domain and will
function without problems. function without problems.
Deployment of ABRs using the alternative methods improves the Deployment of ABRs using the alternative methods improves the
behavior of a router connected to multiple areas without a backbone behavior of a router connected to multiple areas without a backbone
attachment, but can lead to unexpected routing asymmetry, as attachment, but can lead to unexpected routing asymmetry, as
described below. described below.
Consider an OSPF domain depicted in Figure 4. Consider an OSPF domain depicted in Figure 4.
.......................
. Backbone . . Backbone .
. . . .
. --------------------- . . --------------------- .
. |1 1| . . |1 1| .
..+--+.............+--+.. ..+--+.............+--+..
..|R1|..... ....|R4|.. ..|R1|..... ....|R4|..
. +--+ . . +--+ . . +--+ . . +--+ .
. 1| . . /4 . . 1| . . /4 .
. | 8 +--+ 4 / . . | 8 +--+ 4 / .
. | +-|R3|---+ . . | +-|R3|---+ .
skipping to change at page 9, line 29 skipping to change at page 9, line 28
. +--+ . . +--+ . . +--+ . . +--+ .
. | . . | . . | . . | .
. --------- . . -------- . . --------- . . -------- .
. net N . . net M . . net N . . net M .
. . . . . . . .
. Area 1 . . Area 2 . . Area 1 . . Area 2 .
........... .......... ........... ..........
Figure 4. Inter-area routing asymmetry Figure 4. Inter-area routing asymmetry
Assume that R3 uses the approach described in this document. In this Assume that R3 uses the approach described in this document. In this
case R2 will have inter-area routes to network M via ABR R1 only. R5 case R2 will have inter-area routes to network M via ABR R1 only. R5
in turn will have its inter-area route to network N via R4, but as in turn will have its inter-area route to network N via R4, but as
far as R4 is only reachable via R3, all traffic destined to network N far as R4 is only reachable via R3, all traffic destined to network N
will pass through R3. R3 will have an intra-area route to network N will pass through R3. R3 will have an intra-area route to network N
via R2 and will, of course, route it directly to it (because intra- via R2 and will, of course, route it directly to it (because
area routes are always preferred over inter-area ones). Traffic going intra-area routes are always preferred over inter-area ones).
back from network N to network M will pass through R2 and will be Traffic going back from network N to network M will pass through R2
routed to R1, as R2 will not have any inter-area routes via R3. So, and will be routed to R1, as R2 will not have any inter-area routes
traffic from N to M will always go through the backbone while traffic via R3. So, traffic from N to M will always go through the backbone
from M to N will cross the areas directly via R3 and, in this while traffic from M to N will cross the areas directly via R3 and,
example, will not use a more optimal path through the backbone. in this example, will not use a more optimal path through the
backbone.
Note that this problem is not caused by the fact that R3 uses the Note that this problem is not caused by the fact that R3 uses the
alternative approach. The reason for attracting the attention to it alternative approach. The reason for attracting the attention to it
is that R3 is not really functioning as an ABR in case this new is that R3 is not really functioning as an ABR in case this new
behavior is used, i.e., it does not inject summary-LSAs into the behavior is used, i.e., it does not inject summary-LSAs into the
attached areas, but inter-area traffic can still go through it. attached areas, but inter-area traffic can still go through it.
6 Security Considerations 6 Security Considerations
The alternative ABR behaviors specified in this document do not raise The alternative ABR behaviors specified in this document do not raise
any security issues that are not already covered in [Ref1]. any security issues that are not already covered in [Ref1].
7 Acknowledgements 7 Acknowledgements
Authors would like to thank Alvaro Retana, Russ White, and Liem Authors would like to thank Alvaro Retana, Russ White, and Liem
Nguyen for their review of the document. Nguyen for their review of the document.
8 Disclaimer 8 Disclaimer
This document describes OSPF ABR implementations of respective This document describes OSPF ABR implementations of respective
vendors "as is", only for informational purposes, and without any vendors "as is", only for informational purposes, and without any
warranties, guarantees or support. These implementations are subject warranties, guarantees or support. These implementations are subject
to possible future changes. For the purposes of easier deployment, to possible future changes. For the purposes of easier deployment,
information about software versions where described behavior was information about software versions where described behavior was
integrated is provided below. integrated is provided below.
Initial Cisco ABR implementation (slightly different from the one Initial Cisco ABR implementation (slightly different from the one
described in this memo, requiring non-backbone areas to be described in this memo, requiring non-backbone areas to be
configured, and not necessarily actively attached in the ABR configured, and not necessarily actively attached in the ABR
definition) was introduced in Cisco IOS (tm) version 11.1(6). Cisco definition) was introduced in Cisco IOS (tm) version 11.1(6). Cisco
ABR behavior described in this document was integrated in Cisco IOS ABR behavior described in this document was integrated in Cisco IOS
(tm) in version 12.1(3)T. (tm) in version 12.1(3)T.
The ABR behavior described as IBM ABR approach was implemented by IBM The ABR behavior described as IBM ABR approach was implemented by IBM
in IBM Nways Multiprotocol Routing Services (MRS) 3.3. in IBM Nways Multiprotocol Routing Services (MRS) 3.3.
Note that the authors do not intend to keep this document in sync Note that the authors do not intend to keep this document in sync
with actual implementations. with actual implementations.
10 References 10 References
[Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet [Ref1] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.
Engineering Task Force, 1998. ftp://ftp.isi.edu/in-
notes/rfc2328.txt.
11 Authors' Addresses 11 Authors' Addresses
Alex Zinin Derek M. Yeung Alex Zinin
Alcatel Procket Networks Alcatel
E-mail: zinin@psg.com 3850 N.First Street
San Jose, CA 95134 EMail: zinin@psg.com
Phone: 408-954-7911
E-mail: myeung@procket.com Derek M. Yeung
Procket Networks
1100 Cadillac Ct
Milpitas, CA 95035
Phone: 408-635-7911
EMail: myeung@procket.com
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Apex, NC 27502 USA Cary, NC 27519 USA
919-387-6971
E-mail: acee@redback.com Phone: 919-387-6971
EMail: acee@redback.com
12 Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 58 change blocks. 
166 lines changed or deleted 162 lines changed or added

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