draft-ietf-ospf-abr-alt-03.txt   draft-ietf-ospf-abr-alt-04.txt 
Network Working Group Alex Zinin Network Working Group Alex Zinin
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: July 2001 Acee Lindem Expiration Date: September 2001 Acee Lindem
File name: draft-ietf-ospf-abr-alt-03.txt Redback Networks File name: draft-ietf-ospf-abr-alt-04.txt Redback Networks
Derek Yeung Derek Yeung
Procket Networks Procket Networks
November 2000 February 2001
Alternative OSPF ABR Implementations Alternative OSPF ABR Implementations
draft-ietf-ospf-abr-alt-03.txt draft-ietf-ospf-abr-alt-04.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 6, line 13 skipping to change at page 6, line 13
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. The algorithm of the summary-LSAs origination is changed to 3. For Cisco ABR approach, the algorithm of the summary-LSAs
prevent loops of summary-LSAs in situations where the router origination is changed to prevent loops of summary-LSAs in
considers itself an ABR but doesn't have an Active Backbone situations where the router considers itself an ABR but doesn't
Connection (and, consequently, examines summaries from all have an Active Backbone Connection (and, consequently, examines
attached areas). The algorithm is changed to allow an ABR summaries from all attached areas). The algorithm is changed to
announce only intra-area routes in such a situation. allow an ABR announce only intra-area routes in such a 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 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,
skipping to change at page 7, line 29 skipping to change at page 7, line 29
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
connected to the ABR directly. connected to the ABR directly.
3 Handling Transitions 3 Virtual Link Treatment
The behavior described in this document requires special processing
when the router's ABR status or backbone connection status changes.
3.1 ABR status change
The router's ABR flag can change due to the following events:
For Cisco ABR definition:
1. The state machine of an OSPF-enabled interface in an area has
transitioned to a state higher than Down. (The router becomes
an ABR if the area becomes Actively Attached and the ABR
condition is met.)
2. The state machine of an OSPF-enabled interface in an area has
transitioned to the state Down. (The router stops being an ABR
if the area stops being Actively Attached and the ABR
condition is not met.)
3. An area has been deconfigured. (The router stops being an
the area is the backbone or if it was Actively Attached the
ABR condition is not met.)
For IBM ABR definition:
1. A new area has been configured. (The router becomes an ABR
if the new area is the backbone and the router is Actively
Attached to two or more areas.)
2. An area has been deconfigured. The router stops being an ABR
if only one configured area has left or the area in question
is the backbone.
3. The state machine of an OSPF-enabled interface transitions
into a state higher than Down, an area becomes Actively
Attached. If this is the second actively attached area and
the backbone area is Configured the router becomes an ABR.
4. The state machine of an OSPF-enabled interface transitions
into Down state. If this is the last active interface in the
area, it is no more considered Actively Attached. The router
stops being an ABR if there are no longer multiple Actively
Attached areas.
If after one of the events listed above the router's ABR flag has
changed to the positive state, the router should do the following:
a) reconstruct the router-LSAs for all area databases, setting
the bit B to 1.
b) flood the new router-LSA to all neighbors according to
[Ref1].
c) if the router has an Active Backbone Connection---schedule
the routing table recalculation for all areas to get rid of the
inter-area routes through non-backbone areas.
If the router's ABR flag has changed to the negative state, the
router should do the following:
a) reconstruct the router-LSAs for all areas, setting the bit B
to 0.
b) flood the new router-LSA to all neighbors according to
[Ref1].
c) schedule the routing table recalculation to install the
inter-area routes via non-backbone areas.
d) flush all locally originated summary-LSAs from all non-
backbone areas.
3.2 Backbone connection state change
A change of the backbone connection state can be a result of the
following events:
1. The state machine for a neighbor in the backbone area has
transitioned to the state Full. If the neighbor in question is the
first fully adjacent neighbor, the backbone connection becomes
active.
2. The state machine for a neighbor in the backbone area has
transitioned to a state other than Full or a neighbor has been
deleted from the neighbor list of an interface in the backbone
area. The backbone connection becomes inactive if the neighbor in
question was the last fully adjacent neighbor in the backbone.
If the state of the backbone connection has changed due to one of the
events listed above, the router should schedule the routing table
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
flush old inter-area routes from the routing table and install new
ones.
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, and the the backbone area is purely virtual, as shown in Figure 3, and the
state of the VL is determined as in [Ref1]. state of the VL is determined as in [Ref1].
....... ........... ...... ....... ........... ......
. . . . . . . .
+--+ VL +--+ +--+ VL +--+
skipping to change at page 10, line 33 skipping to change at page 8, line 22
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
algorithm in 16.1 of [Ref1] when a router routing entry is added, but algorithm in 16.1 of [Ref1] when a router routing entry is added, but
every time a vertex is added to the SPT in step 3 of the same every time a vertex is added to the SPT in step 3 of the same
algorithm. algorithm.
5 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.
6 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
skipping to change at page 11, line 51 skipping to change at page 9, line 48
from N to M will always go through the backbone while traffic from M from N to M will always go through the backbone while traffic from M
to N will cross the areas directly via R3 and, in this example, will to N will cross the areas directly via R3 and, in this example, will
not use a more optimal path through the backbone. 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.
7 Security Considerations 6 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 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.
9 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. Also, authors do not have any warranties, guarantees or support. These implementations are subject
intention to keep this document in sync with actual implementations. to possible future changes. For the purposes of easier deployment,
information about software versions where described behavior was
integrated is provided below.
Initial Cisco ABR implementation (slightly different from the one
described in this memo, requiring non-backbone areas to be
configured, and not necessarily actively attached in the ABR
definition) was introduced in Cisco IOS (tm) version 11.1(6). Cisco
ABR behavior described in this document was integrated in Cisco IOS
(tm) in version 12.1(3)T.
The ABR behavior described as IBM ABR approach was implemented by IBM
in IBM Nways Multiprotocol Routing Services (MRS) 3.3.
Note that the authors do not intend to keep this document in sync
with actual implementations.
10 References 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.
11 Authors' Addresses 11 Authors' Addresses
Alex Zinin Derek M. Yeung Alex Zinin Derek M. Yeung
Cisco Systems Procket Networks Cisco Systems Procket Networks
150 West Tasman Dr. 3850 N.First Street 150 West Tasman Dr. 3850 N.First Street
San Jose,CA San Jose, CA 95134 San Jose, CA 95134 San Jose, CA 95134
95134 Phone: 408-954-7911 E-mail: azinin@cisco.com Phone: 408-954-7911
E-mail: azinin@cisco.com Fax: 408-987-6166 E-mail: myeung@procket.com
Email: myeung@procket.com
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Apex, NC 27502 USA Apex, NC 27502 USA
919-387-6971 919-387-6971
E-mail: acee@redback.com
 End of changes. 

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