I already responded to Ramakrishna on the OSPF list that he is correct and this is an omission from RFC 2328.
http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html This errata should be accepted. Thanks, Acee On Oct 9, 2013, at 6:29 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=2328&eid=3746 > > -------------------------------------- > Type: Technical > Reported by: Ramakrishna DTV <[email protected]> > > Section: GLOBAL > > Original Text > ------------- > *. 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 > > > Corrected Text > -------------- > *. 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." > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC2328 (no draft string recorded) > -------------------------------------- > Title : OSPF Version 2 > Publication Date : April 1998 > Author(s) : J. Moy > Category : INTERNET STANDARD > Source : Open Shortest Path First IGP > Area : Routing > Stream : IETF > Verifying Party : IESG _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
