Hello Jeff and BFD experts,
> Section 6.8.4 covers the calculation of the detection interval. > After the start of a poll, the remote system may take some time to respond > to the poll and set the Final bit. During that time, it is permissable to > send Async packets following the packet reception rules - including > authentication - without setting the Final bit. really? the "demand mode" part of 6.8.4 talks about the local system being in demand mode, if I understand it correctly. This means the remote system MUST NOT send packets periodically, unless the remote system itself started a Poll sequence. See 6.8.7, paragraph 7. So for 6.8.4 the local system would not expect any async packets from the remote side other than a packet with the "F" bit, as this exception is allowed for the remote system. There is also section 6.6, saying: When a system in Demand mode wishes to verify bidirectional connectivity, it initiates a Poll Sequence (see section 6.5). If no response is received to a Poll, the Poll is repeated until the Detection Time expires, at which point the session is declared to be Down. Note that if Demand mode is operating only on the local system, the Poll Sequence is performed by simply setting the Poll (P) bit in regular periodic BFD Control packets, as required by section 6.5. One could argue what "no response" means but as it says "the Poll is repeated" and knowing how the Poll sequence works (6.5) it seems to be the "F" bit packet that the local system needs to receive. Saying all this I still agree with you that the errata is not necessary. What the errata wants to say is already said in RFC5880. We probably could pick many paragraphs in RFC5880 and point out sentences that by themselves are not sufficient - ubt are okay in the context of the overall document. Regards, Marc On Tue, 16 Feb 2016 15:59:25 -0500, Jeffrey Haas wrote: > I do not believe the errata in question is necessary. > > Section 6.8.4 covers the calculation of the detection interval. > After the start of a poll, the remote system may take some time to respond > to the poll and set the Final bit. During that time, it is permissable to > send Async packets following the packet reception rules - including > authentication - without setting the Final bit. > > The text recommended by this proposed errata constrains this time to the > completion of a Poll within the originally negotiated detection interval. > While this may happen, it is not required. > > -- Jeff (speaking as an individual contributor) > > On Tue, Feb 16, 2016 at 12:26:08PM -0800, RFC Errata System wrote: >> The following errata report has been held for document update >> for RFC5880, "Bidirectional Forwarding Detection (BFD)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5880&eid=4410 >> >> -------------------------------------- >> Status: Held for Document Update >> Type: Editorial >> >> Reported by: Liu Lin <[email protected]> >> Date Reported: 2015-07-07 >> Held by: Alvaro Retana (IESG) >> >> Section: 6.8.4 >> >> Original Text >> ------------- >> If Demand mode is active, and a period of time equal to the Detection >> Time passes after the initiation of a Poll Sequence (the transmission >> of the first BFD Control packet with the Poll bit set), the session >> has gone down >> >> Corrected Text >> -------------- >> If Demand mode is active, and a period of time equal to the Detection >> Time passes after the initiation of a Poll Sequence (the transmission >> of the first BFD Control packet with the Poll bit set),and without >> receiving a BFD Control packet with the Final (F) bit set from the >> remote system, the session has gone down >> >> Notes >> ----- >> If has received BFD Control packet with the Final (F) bit set from the >> remote system, the session will not gone down >> >> -------------------------------------- >> RFC5880 (draft-ietf-bfd-base-11) >> -------------------------------------- >> Title : Bidirectional Forwarding Detection (BFD) >> Publication Date : June 2010 >> Author(s) : D. Katz, D. Ward >> Category : PROPOSED STANDARD >> Source : Bidirectional Forwarding Detection >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >
