Hi Acee, I agree with this errata and thanks for raising it.
Not sure if it can be "Verified" or "Held for Document Update" though. Thanks, Ketan On Fri, Mar 15, 2024 at 8:07 PM RFC Errata System <[email protected]> wrote: > The following errata report has been submitted for RFC2328, > "OSPF Version 2". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid7850 > > -------------------------------------- > Type: Technical > Reported by: Alfred Lindem <[email protected]> > > Section: 10.7/A.3.5 > > Original Text > ------------- > Section 10.7 > > Each LSA specified in the Link State Request packet should be > located in the router's database, and copied into Link State > Update packets for transmission to the neighbor. These LSAs > should NOT be placed on the Link state retransmission list for > the neighbor. If an LSA cannot be found in the database, > something has gone wrong with the Database Exchange process, and > neighbor event BadLSReq should be generated. > > Section A.3.5 > > Link State Update packets are multicast on those physical networks > that support multicast/broadcast. In order to make the flooding > procedure reliable, flooded LSAs are acknowledged in Link State > Acknowledgment packets. If retransmission of certain LSAs is > necessary, the retransmitted LSAs are always sent directly to the > neighbor. For more information on the reliable flooding of LSAs, > consult Section 13. > > Corrected Text > -------------- > Section 10.7 > > Each LSA specified in the Link State Request packet should be > located in the router's database, and copied into Link State > Update packets for transmission directly to the neighbor, > i.e., unicast on all interface types except point-to-point > interfaces where all OSPF packets are sent to the address > AllSPFRouters. These LSAs should NOT be placed on the Link > state retransmission list for the neighbor. If an LSA cannot > be found in the database, something has gone wrong with the > Database Exchange process, and neighbor event BadLSReq should > be generated. > > Section A.3.5 > > Link State Update packets are multicast on those physical networks > that support multicast/broadcast. In order to make the flooding > procedure reliable, flooded LSAs are acknowledged in Link State > Acknowledgment packets. If retransmission of certain LSAs is > necessary, the retransmitted LSAs are always sent directly to the > neighbor. For more information on the reliable flooding of LSAs, > consult Section 13. Link State Update packets are also sent > directly to the neighbor in response to Link State Request > packets as specified in Section 10.7. > > > Notes > ----- > Clarify that OSPF Link State Updates sent in response to OSPF Link > Requests should be unicast. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will 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 > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
