E.1 A fix for a problem with OSPF Virtual links

In RFC 1247, certain configurations of OSPF virtual links can cause routing loops. The root of the problem is that while there is an information mismatch at the boundary of any virtual link's Transit area, a backbone path can still cross the boundary. RFC 1247 attempted to compensate for this information mismatch by adjusting any backbone path as it enters the transit area (see Section 16.3 in RFC 1247). However, this proved not to be enough. This memo fixes the problem by having all area border routers determine, by looking at summary links, whether better backbone paths can be found through the transit areas.

This fix simplifies the OSPF virtual link logic, and consists of the following components:

• A new bit has been defined in the router links advertisement, called bit V. Bit V is set in a router's router links advertisement for Area A if and only if the router is an endpoint of an active virtual link that uses Area A as its Transit area (see Sections 12.4.1 and A.4.2). This enables the other routers attached to Area A to discover whether the area supports any virtual links (i.e., is a transit area). This discovery is done during the calculation of Area A's shortest-path tree (see Section 16.1).

• To aid in the description of the algorithm, a new parameter has been added to the OSPF area structure: TransitCapability. This parameter indicates whether the area supports any active virtual links. Equivalently, it indicates whether the area can carry traffic that neither originates nor terminates in the area itself.

• The calculation in Section 16.3 of RFC 1247 has been replaced. The new calculation, performed by area border routers only, examines the summary links belonging to all attached transit areas to see whether the transit areas can provide better paths than those already found in Sections 16.1 and 16.2.

• The incremental calculations in Section 16.5 have been updated as a result of the new calculations in Section 16.3.