draft-ietf-ospf-abr-alt-00.txt   draft-ietf-ospf-abr-alt-01.txt 
Network Working Group Alex Zinin Network Working Group Alex Zinin
Internet Draft AMT Group Internet Draft AMT Group
Expiration Date: January 2000 Acee Lindem Expiration Date: April 2000 Acee Lindem
File name: draft-ietf-ospf-abr-alt-00.txt IBM File name: draft-ietf-ospf-abr-alt-01.txt IBM
Derek Yeung Derek Yeung
Cisco Systems Cisco Systems
July 1999 October 1999
Alternative OSPF ABR Implementations Alternative OSPF ABR Implementations
draft-ietf-ospf-abr-alt-00.txt draft-ietf-ospf-abr-alt-01.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 4, line 41 skipping to change at page 4, line 41
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 must 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 originates 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 Though this document is initially oriented to processing Type-3 LSAs
and, consequently, is targeted to improving OSPF inter-area routing, and, consequently, is targeted to improving OSPF inter-area routing,
it's acceptable to apply described methods to Type-4 LSAs, which will it's acceptable to apply described methods to Type-4 LSAs, which will
skipping to change at page 9, line 43 skipping to change at page 9, line 43
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 must 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 Compatibility 4 Virtual Link Treatment
Cisco ABR approach described in this document requires an ABR to have
at least one active interface in the backbone area. This requirement
may cause problems with virtual links in those rare situations where
the backbone area is purely virtual, as shown in Figure 3.
....... ........... ......
. . . .
+--+ VL +--+
|R1|***********|R2|
+--+ +--+
Area 1 . . Area 2 . . Area 3
....... ........... ......
Figure 3. Purely Virtual Backbone
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,
which is, in turn, because the routers do not have active interfaces
(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
real interface in the backbone, as it usually is in real networks.
Though described situation is deemed to be rather rare, it is
recommended to change the implementation supporting Cisco ABR
behavior so that a virtual link is reported up (an InterfaceUp event
is generated) when a router with corresponding 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 configured virtual links
must be done not in step 4 of the 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 algorithm.
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.
5 Deployment Considerations 6 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 2. Consider an OSPF domain depicted in Figure 4.
....................... .......................
. Backbone . . Backbone .
. . . .
. --------------------- . . --------------------- .
. |1 1| . . |1 1| .
..+--+.............+--+.. ..+--+.............+--+..
..|R1|..... ....|R4|.. ..|R1|..... ....|R4|..
. +--+ . . +--+ . . +--+ . . +--+ .
. 1| . . /4 . . 1| . . /4 .
skipping to change at page 10, line 43 skipping to change at page 11, line 34
. +--+ / . . \ 4 +--+ . . +--+ / . . \ 4 +--+ .
. |R2|/8 . . +--|R5| . . |R2|/8 . . +--|R5| .
. +--+ . . +--+ . . +--+ . . +--+ .
. | . . | . . | . . | .
. --------- . . -------- . . --------- . . -------- .
. net N . . net M . . net N . . net M .
. . . . . . . .
. Area 1 . . Area 2 . . Area 1 . . Area 2 .
........... .......... ........... ..........
Figure 2. 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 get into R3. R3 will have an intra-area route to network N via will get into R3. R3 will have an intra-area route to network N via
R2 and will, of course, route it directly to it (because intra-area R2 and will, of course, route it directly to it (because intra-area
routes are always preferred over inter-area ones). Traffic going back routes are always preferred over inter-area ones). Traffic going back
from network N to network M will get into R2 and will be routed to from network N to network M will get into R2 and will be routed to
R1, as R2 will not have any inter-area routes via R3. So, traffic R1, as R2 will not have any inter-area routes via R3. So, traffic
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.
6 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].
7 References 8 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.
8 Authors' Address 9 Authors' Address
Alex D. Zinin Alex D. Zinin
AMT Group AMT Group
8 Maly Znamensky per., bld. 1 8 Maly Znamensky per., bld. 1
Office 3b Office 3b
121019 Moscow, Russia 121019 Moscow, Russia
E-mail: zinin@amt.ru E-mail: zinin@amt.ru
Acee Lindem Acee Lindem
IBM Corporation IBM Corporation
 End of changes. 

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