I agree with Ketan. This is definitely a “sin of omission” motivated by the fact that the FRR implementation (https://github.com/FRRouting/frr) is sending these LS Updates as multicast on all interface types other than NBMA. I had thought this must be covered in RFC 2328 but found the case of LS Updates retransmissions is there but this case is missing.
I also have a PR open to modify FRR ospfd. Thanks, Acee > On Mar 16, 2024, at 04:03, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > Hi John, > > My view is that these erratum are introducing certain "details" which were > missed and resulted in some implementers following procedures that are > inefficient or incorrect based on the individual "bar" (I personally lean > towards incorrect). > > As such, this is perhaps an error of omission in the RFC. > > These clarifications are certainly required and will be helpful - so no > concerns from my side with marking as "verified". > > Thanks, > Ketan > > > On Sat, Mar 16, 2024 at 11:19 AM John Scudder <j...@juniper.net > <mailto:j...@juniper.net>> wrote: >> Regarding whether it should be verified or HFDU, I haven’t taken a hard look >> yet. The operative question from the guidance [1] though, is if the change >> corrects “errors at the time the document was published”. >> >> The guidance is necessarily not completely prescriptive and my impression is >> that these errata could be verified in that they do not change the operation >> of the protocol from what was intended (“Technical items that have a clear >> resolution in line with the original intent should be classified as >> Verified.”) >> >> I’d be interested in any further discussion, though, and won’t immediately >> verify the errata. >> >> —John >> >> [1] >> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ >> >>> On Mar 16, 2024, at 3:19 PM, Ketan Talaulikar <ketant.i...@gmail.com >>> <mailto:ketant.i...@gmail.com>> wrote: >>> >>> >>> >>> [External Email. Be cautious of content] >>> >>> >>> 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 >>> <rfc-edi...@rfc-editor.org <mailto:rfc-edi...@rfc-editor.org>> 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 >>>> <https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7850__;!!NEt6yMaO-gk!HwIp5PZkRjlTKoSPhbXzVwPGGfDGvAJPbFU3DQHxLs4GT4ib86TODbfFg2kc8wl0MbLAregdpczroM9_EA$> >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Alfred Lindem <acee.i...@gmail.com >>>> <mailto:acee.i...@gmail.com>> >>>> >>>> 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 >>>> Lsr@ietf.org <mailto:Lsr@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/lsr >>>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!HwIp5PZkRjlTKoSPhbXzVwPGGfDGvAJPbFU3DQHxLs4GT4ib86TODbfFg2kc8wl0MbLAregdpcw3s-wxEA$>
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
