RFC 2328, "OSPF Version 2", April 1998

Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454

Errata ID: 3746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-10-09
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10

Throughout the document, when it says:

*. Section 3.3. (Classification of routers) says:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS.  This classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) says:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, generate the neighbor event SeqNumberMismatch and
        stop processing the packet.

*. Section 13. (The Flooding Procedure) says:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

It should say:

*. Section 3.3. (Classification of routers) should say:

        AS boundary routers
            A router that exchanges routing information with routers
            belonging to other Autonomous Systems.  Such a router
            advertises AS external routing information throughout the
            Autonomous System.  The paths to each AS boundary router are
            known by every router in the AS (except stub areas).  This
            classification is
            completely independent of the previous classifications: AS
            boundary routers may be internal or area border routers, and
            may or may not participate in the backbone.

*. Section 10.6 (Receiving Database Description Packets) should say:

	      When the router accepts a received Database Description Packet
        as the next in sequence the packet contents are processed as
        follows.  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, or if this is a type-4 summary LSA and the neighbor
		is associated with a stub area, generate the neighbor event
        SeqNumberMismatch and stop processing the packet.

*. Section 13. (The Flooding Procedure) should say:

There should be an additional step in between steps 3 and 4  in
Section 13. The additional step below is denoted 3.5:

    (3) Else if this is an AS-external-LSA (LS type = 5), and the area
        has been configured as a stub area, discard the LSA and get the
        next one from the Link State Update Packet.  AS-external-LSAs
        are not flooded into/throughout stub areas (see Section 3.6).

    (3.5) Else if this is a type-4 Summary LSA (LS type = 4), and the
        area has been configured as a stub area, discard the LSA and get
        the next one from the Link State Update Packet.  Type-4 Summary
        LSAs are not flooded into/throughout stub areas.

    (4) Else if the LSA's LS age is equal to MaxAge, and there is
        currently no instance of the LSA in the router's link state
        database, and none of router's neighbors are in states Exchange

Notes:

This whole note is regarding stub areas.

RFC 2328 is already consistent with respect to AS-external-LSAs
(LS type =5). The RFC explicitly indicates that they should be neither
sent nor received in stub areas.

But RFC 2328 seems to have some omissions with respect to type-4
Summary LSA (LS type = 4). The RFC explicitly indicates that these
LSAs should never be sent in stub areas. But it does not mention what
should be done if these LSAs are received in stub areas.

The above updates try to remedy this omission.

If the neighbor is associated with a stub area, then we should never
receive a type-4 summary LSA from that neighbor. Here are the relevant
quotes from the RFC:

Section 12.4.3.1.(Originating summary-LSAs into stub areas):

"As specified in Section 12.4.3, Type 4 summary-LSAs
(ASBR-summary-LSAs) are never originated into stub
areas."

Section 4.2. (AS external routes):

"To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of
these AS boundary routers are summarized by the (non-stub) area
border routers."


This is an omission from RFC 2328.

http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html

Report New Errata