draft-ietf-ospf-abr-alt-01.txt   draft-ietf-ospf-abr-alt-02.txt 
Network Working Group Alex Zinin Network Working Group Alex Zinin
Internet Draft AMT Group Internet Draft Cisco Systems
Expiration Date: April 2000 Acee Lindem Expiration Date: January 2001 Acee Lindem
File name: draft-ietf-ospf-abr-alt-01.txt IBM File name: draft-ietf-ospf-abr-alt-02.txt Redback Networks
Derek Yeung Derek Yeung
Cisco Systems Procket Networks
October 1999 July 2000
Alternative OSPF ABR Implementations Alternative OSPF ABR Implementations
draft-ietf-ospf-abr-alt-01.txt draft-ietf-ospf-abr-alt-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 42
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.
Abstract Abstract
OSPF [Ref1] is a link-state intra-domain routing protocol used for OSPF [Ref1] is a link-state intra-domain routing protocol used for
routing in IP networks. Though the definition of the ABR in the routing in IP networks. Though the definition of the ABR in the
current OSPF specification does not require a router with multiple current OSPF specification does not require a router with multiple
attached areas to have a backbone connection, it is actually attached areas to have a backbone connection, it is actually
necessary to provide successful routing to the inter-area and necessary to provide successful routing to the inter-area and
external destinations. If this requirement is not met all traffic, external destinations. If this requirement is not met, all traffic
destined for the areas not connected to such an ABR or out of the destined for the areas not connected to such an ABR or out of the
OSPF domain, is dropped. This document describes alternative ABR OSPF domain, is dropped. This document describes alternative ABR
behaviors implemented in Cisco and IBM routers. 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
describing routes and ASBRs in other areas) as well as to perform describing routes and ASBRs in other areas) as well as to perform
actual inter-area routing. 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 star-like topology is that OSPF inter-area routing uses the
distance-vector approach and a strict area hierarchy permits distance-vector approach and a strict area hierarchy permits
avoidance of the "counting to infinity" technique. OSPF prevents avoidance of the "counting to infinity" problem. OSPF prevents
inter-area routing loops by implementing a split-horizon mechanism, inter-area routing loops by implementing a split-horizon mechanism,
permitting ABRs to inject into the backbone only Summary-LSAs derived allowing ABRs to inject into the backbone only Summary-LSAs derived
from the intra-area routes, and limiting ABRs' SPF calculation to from the intra-area routes, and limiting ABRs' SPF calculation to
consider only Summary-LSAs in the backbone area's link-state consider only Summary-LSAs in the backbone area's link-state
database. 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 .
skipping to change at page 3, line 36 skipping to change at page 3, line 36
having only intra-area routes for areas 1 and 2, will effectively having only intra-area routes for areas 1 and 2, will effectively
drop all traffic not destined for the areas directly attached to it. drop all traffic not destined for the areas directly attached to it.
The same problem can be seen when a backbone-connected ABR loses all The same problem can be seen when a backbone-connected ABR loses all
of its adjacencies in the backbone---even if there are other normally of its adjacencies in the backbone---even if there are other normally
functioning ABRs in the attached areas, all traffic going to the functioning ABRs in the attached areas, all traffic going to the
backbone (destined for it or for other areas) will be dropped. backbone (destined for 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 the Virtual Links (see section 15 of [Ref1] for more details). use of the Virtual Links (see section 15 of [Ref1] for more details).
In this case, router R3 will have a virtual backbone connection, will In this case, router R3 will have a virtual backbone connection, will
form an adjacency over it, will receive all summary-LSAs directly form an adjacency over it, will receive all LSAs directly from a
from a backbone-attached router (R1 or R2, or both in our example) backbone-attached router (R1 or R2, or both in our example) and will
and will install 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 is not applicable is Another situation where standard ABR behavior does not provide
when it is necessary to provide redundant connectivity to an ASBR via acceptable results is when it is necessary to provide redundant
several different OSPF areas. This would allow a provider to connectivity to an ASBR via several different OSPF areas. This would
aggregate all their customers connecting through a single access allow a provider to aggregate all their customers connecting through
point into one area while still offering a redundant connection a single access point into one area while still offering a redundant
through another access point in a different area, as shown in Figure connection through another access point in a different area, as shown
2. in Figure 2.
. . . .
. Area 0 . . Area 0 .
+--+ +--+ +--+ +--+
..|R1|.. ..|R2|.. ..|R1|.. ..|R2|..
. +--+ .. +--+ . . +--+ .. +--+ .
. .. . . .. .
. .. . . .. .
. Area1 .. Area2 . . Area1 .. Area2 .
. .. . . .. .
skipping to change at page 4, line 35 skipping to change at page 4, line 35
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.
Described solutions are targeted to the situation when an ABR has no Described solutions are targeted to the situation when an ABR has no
backbone connection. It implies that a router connected to multiple backbone connection. It implies that a router connected to multiple
areas without a backbone connection is not an ABR and must 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 a
situation where separate OSPF processes are run for each area and 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 in the meaning of not dropping described in the examples above in the meaning of not dropping
transit traffic. Note that a router following it does not function transit traffic. Note that a router following it does not function
as a real border router---it doesn't originate summary-LSAs. as a real border router---it doesn't originate summary-LSAs.
Nevertheless such a behavior may be desirable in certain situations. Nevertheless such a 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 of
a router connecting two or more backbone-attached areas. a router connecting two or more backbone-attached areas.
Though this document is initially oriented to processing Type-3 LSAs
and, consequently, is targeted to improving OSPF inter-area routing,
it's acceptable to apply described methods to Type-4 LSAs, which will
lead to improvement of external routing in an OSPF domain.
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 one interface in that area in the state other than Down. least 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 area
configured and the backbone area actively attached. Configured and the backbone area Actively Attached.
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 of 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 of 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 the backbone area connection is not available. Definitions of or it does not have an Active Backbone Connection. Definitions of
the terms used in this paragraph are given in section 2.1. the terms used in this paragraph are given in section 2.1.
So, the paragraph 1 of section 16.2 of [Ref1] should be read as So, the paragraph 1 of section 16.2 of [Ref1] should be
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 must consider summary-LSAs from all actively attached the router should consider summary-LSAs from all Actively
areas..." Attached areas..."
3. The algorithm of the summary-LSAs origination is changed to 3. The algorithm of the summary-LSAs origination is changed to
prevent loops of summary-LSAs in situations where the router prevent loops of summary-LSAs in situations where the router
considers itself an ABR but doesn't have an active backbone considers itself an ABR but doesn't have an Active Backbone
connection (and, consequently, examines summaries from all Connection (and, consequently, examines summaries from all
attached areas). The algorithm is changed to allow an ABR attached areas). The algorithm is changed to allow an ABR
announce only intra-area routes in such a situation. announce only intra-area routes in such a situation.
So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be read So, the paragraph 2 of subsection 12.4.3 of [Ref1] should be
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 only accordance with the algorithm described below. Note that only
intra-area routes are advertised into the backbone, both intra- intra-area routes are advertised into the backbone, both intra-
area and inter-area routes are advertised into the other areas, area and inter-area routes are advertised into the other areas,
provided that the router has an active backbone connection. provided that the router has an Active Backbone Connection.
Otherwise the router is allowed to advertise only intra-area Otherwise the router is allowed to advertise only intra-area
routes into non-backbone areas." routes into non-backbone 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 equal
to the routing table entry's cost. If the ABR performing this to the routing table entry's cost. If the ABR performing this
algorithm does not have an active backbone connection, it can algorithm does not have an Active Backbone Connection, it can
originate Type 4 summary-LSA only if the type of the route to originate Type 4 summary-LSA only if the type of the route to
the ASBR is intra-area. Note: Type 4 summary-LSAs should not the ASBR is intra-area. Note: Type 4 summary-LSAs should not
be generated if Area A has been configured as a stub area." 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 inter-
area route and the ABR performing this algorithm has an active area route and the ABR performing this algorithm has an Active
backbone connection, generate a Type 3 summary-LSA for the Backbone Connection, generate a Type 3 summary-LSA for the
destination, with Link State ID equal to the network's address destination, with Link State ID equal to the network's address
(if necessary, the Link State ID can also have one or more of (if necessary, the Link State ID can also have one or more of
the network's host bits set; see Appendix E for details) and the network's host bits set; see Appendix E for details) and
metric equal to the routing table cost." 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 inter-
area traffic, because it does not consider itself an ABR and does not area traffic, because it does not consider itself an ABR and does not
originate summary-LSAs. It still can forward traffic from one originate summary-LSAs. It still can forward traffic from one
attached area to another along intra-area routes in case other 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
skipping to change at page 7, line 43 skipping to change at page 7, line 42
when the router's ABR status or backbone connection status changes. when the router's ABR status or backbone connection status changes.
3.1 ABR status change 3.1 ABR status change
The router's ABR flag can change due to the following events: The router's ABR flag can change due to the following events:
For Cisco ABR definition: For Cisco ABR definition:
1. A new area has been configured. The router becomes an ABR 1. A new area has been configured. The router becomes an ABR
if the new area is the first non-backbone area and the router if the new area is the first non-backbone area and the router
has the backbone area actively attached. has the backbone area Actively Attached.
2. An area has been deconfigured. The router stops being an ABR 2. An area has been deconfigured. The router stops being an ABR
if only one configured area has left or the area in question if only one configured area has left or the area in question
is the backbone. is the backbone.
3. The state machine of an OSPF-enabled interface in the backbone 3. The state machine of an OSPF-enabled interface in the backbone
area has transitioned to a state higher than Down. The router area has transitioned to a state higher than Down. The router
becomes an ABR if there is at least one non-backbone area becomes an ABR if there is at least one non-backbone area
configured. Configured.
4. The state machine of an OSPF-enabled interface in the backbone 4. The state machine of an OSPF-enabled interface in the backbone
area has transitioned to the state Down. The router stops area has transitioned to the state Down. The router stops
being an ABR if the interface in question was the last one in being an ABR if the interface in question was the last one in
the backbone area. the backbone area.
For IBM ABR definition: For IBM ABR definition:
1. A new area has been configured. The router becomes an ABR 1. A new area has been configured. The router becomes an ABR
if the new area is the backbone and the router is actively if the new area is the backbone and the router is Actively
attached to two or more areas. Attached to two or more areas.
2. An area has been deconfigured. The router stops being an ABR 2. An area has been deconfigured. The router stops being an ABR
if only one configured area has left or the area in question if only one configured area has left or the area in question
is the backbone. is the backbone.
3. The state machine of an OSPF-enabled interface transitions 3. The state machine of an OSPF-enabled interface transitions
into a state higher than Down, an area becomes actively into a state higher than Down, an area becomes Actively
attached. If this is the second actively attached area and Attached. If this is the second actively attached area and
the backbone area is configured the router becomes an ABR. the backbone area is Configured the router becomes an ABR.
4. The state machine of an OSPF-enabled interface transitions 4. The state machine of an OSPF-enabled interface transitions
into Down state. If this is the last active interface in the into Down state. If this is the last active interface in the
area, it is no more considered actively attached. The router area, it is no more considered Actively Attached. The router
stops being an ABR if there are no longer multiple actively stops being an ABR if there are no longer multiple Actively
attached areas. Attached areas.
If after one of the events listed above the router's ABR flag has If after one of the events listed above the router's ABR flag has
changed to the positive state, the router must do the following: changed to the positive state, the router should do the following:
a) reconstruct the router-LSAs for all area databases, setting a) reconstruct the router-LSAs for all area databases, setting
the bit B to 1. the bit B to 1.
b) flood the new router-LSA to all neighbors according to b) flood the new router-LSA to all neighbors according to
[Ref1]. [Ref1].
c) if the router has an active backbone connection---schedule c) if the router has an Active Backbone Connection---schedule
the routing table recalculation for all areas to get rid of the the routing table recalculation for all areas to get rid of the
inter-area routes through non-backbone areas. inter-area routes through non-backbone areas.
If the router's ABR flag has changed to the negative state, the If the router's ABR flag has changed to the negative state, the
router must do the following: router should do the following:
a) reconstruct the router-LSAs for all areas, setting the bit B a) reconstruct the router-LSAs for all areas, setting the bit B
to 0. to 0.
b) flood the new router-LSA to all neighbors according to b) flood the new router-LSA to all neighbors according to
[Ref1]. [Ref1].
c) schedule the routing table recalculation to install the c) schedule the routing table recalculation to install the
inter-area routes via non-backbone areas. inter-area routes via non-backbone areas.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
first fully adjacent neighbor, the backbone connection becomes first fully adjacent neighbor, the backbone connection becomes
active. active.
2. The state machine for a neighbor in the backbone area has 2. The state machine for a neighbor in the backbone area has
transitioned to a state other than Full or a neighbor has been transitioned to a state other than Full or a neighbor has been
deleted from the neighbor list of an interface in the backbone deleted from the neighbor list of an interface in the backbone
area. The backbone connection becomes inactive if the neighbor in area. The backbone connection becomes inactive if the neighbor in
question was the last fully adjacent neighbor in the backbone. question was the last fully adjacent neighbor in the backbone.
If the state of the backbone connection has changed due to one of the If the state of the backbone connection has changed due to one of the
events listed above, the router must schedule the routing table events listed above, the router should schedule the routing table
calculation according to [Ref1] and the changes described in section calculation according to [Ref1] and the changes described in section
2.2 (even if the router is still an ABR). This will make the router 2.2 (even if the router is still an ABR). This will make the router
flush old inter-area routes from the routing table and install new flush old inter-area routes from the routing table and install new
ones. ones.
4 Virtual Link Treatment 4 Virtual Link Treatment
Cisco ABR approach described in this document requires an ABR to have Cisco ABR approach described in this document requires an ABR to have
at least one active interface in the backbone area. This requirement at least one active interface in the backbone area. This requirement
may cause problems with virtual links in those rare situations where may cause problems with virtual links in those rare situations where
the backbone area is purely virtual, as shown in Figure 3. the backbone area is purely virtual, as shown in 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 R3 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 described situation is deemed to be rather rare, it is Though described situation is deemed to be rather rare,
recommended to change the implementation supporting Cisco ABR implementations supporting Cisco ABR behavior may consider changing
behavior so that a virtual link is reported up (an InterfaceUp event VL-specific code so that a virtual link is reported up (an
is generated) when a router with corresponding router-ID is seen via InterfaceUp event is generated) when a router with corresponding
Dijkstra, no matter whether its router-LSA indicates that it is an router-ID is seen via Dijkstra, no matter whether its router-LSA
ABR or not. This means that checking of configured virtual links indicates that it is an ABR or not. This means that checking of
must be done not in step 4 of the algorithm in 16.1 of [Ref1] when a configured virtual links should be done not in step 4 of the
router routing entry is added, but every time a vertex is added to algorithm in 16.1 of [Ref1] when a router routing entry is added, but
the SPT in step 3 of the same algorithm. every time a vertex is added to the SPT in step 3 of the same
algorithm.
5 Compatibility 5 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.
6 Deployment Considerations 6 Deployment Considerations
skipping to change at page 12, line 11 skipping to change at page 12, line 13
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.
7 Security Considerations 7 Security Considerations
The alternative ABR behavior specified in this document does not The alternative ABR behavior specified in this document does not
raise any security issues that are not already covered in [Ref1]. raise any security issues that are not already covered in [Ref1].
8 References 8 Acknowledgements
Authors would like to thank Alvaro Retana and Russ White for their
review of the document.
9 Disclaimer
This document describes OSPF ABR implementations of respective
vendors "as is", only for informational purposes, and without any
warranties, guarantees or support. Also, authors do not have any
intention to keep this document in sync with actual implementations.
10 References
[Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet [Ref1] J. Moy. OSPF version 2. Technical Report RFC 2328, Internet
Engineering Task Force, 1998. ftp://ftp.isi.edu/in- Engineering Task Force, 1998. ftp://ftp.isi.edu/in-
notes/rfc2328.txt. notes/rfc2328.txt.
9 Authors' Address 11 Authors' Addresses
Alex D. Zinin Alex Zinin Derek M. Yeung
AMT Group Cisco Systems Procket Networks
8 Maly Znamensky per., bld. 1 150 West Tasman Dr. 3850 N.First Street
Office 3b San Jose,CA San Jose, CA 95134
121019 Moscow, Russia 95134 Phone: 408-954-7911
E-mail: zinin@amt.ru E-mail: azinin@cisco.com Fax: 408-987-6166
Email: myeung@procket.com
Acee Lindem Acee Lindem
IBM Corporation Redback Networks
Research Triangle Park, NC USA 102 Carric Bend Court
E-mail: acee@raleigh.ibm.com Apex, NC 27502 USA
919-387-6971
Derek M. Yeung
Cisco Systems Inc.
San Jose, CA, USA
E-mail: myeung@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/