Gyan, Exchanging BFD control packets does not guarantee data path liveness nor it guarantees that subsequent BFD Echo packets will succeed.
BFD UDP control packets can use a different IP address (src or dst) than the one used for data path probing. Both UDP ports are also different (3784 vs 3785). Please also observe that BFD control packets are handled by RE/RP while BFD Echo packet processing is very often offloaded to the line card(s). So to me bringing up OSPF adj. immediately after BFD session transitions to UP state is neither a good thing nor should be stated so by the subject draft to bring up OSPF adj. without risk of it to shortly go down. Thx, R On Sun, Feb 6, 2022 at 6:24 PM Gyan Mishra <hayabusa...@gmail.com> wrote: > Hi Robert > > On Sun, Feb 6, 2022 at 6:11 AM Robert Raszuk <rob...@raszuk.net> wrote: > >> Gyan, >> >> > Overall I believe the goal of the strict mode BFD “wait for BFD” is >> accomplished >> > and solve all problems >> >> I do not agree with this statement. >> > > >> As currently defined in the posted version of the draft "wait for BFD" >> means wait for BFD control packets to bring the session up. >> >> The session comes up - yet no BFD Echo packets have been exchanged. That >> in turn triggers OSPF adj. to come up. >> > > Gyan>. My understanding with RFC 5880 is that BFD control packets have > been sent in asynchronous mode per the interval and multiplier period > specified with the 3 way handshake being completed which tests the bi > directional path between the client endpoints before the session BFD FSM > transitions to the “UP” state. We can get confirmation from Greg on the > behavior. > > Key Excerpts from RFC 5880 below related to this topic. BFD control > packets are sent during init and 3 way handshake in async mode until BFD > FSM transitions to UP state and only in UP state is Echo if configured is > sent. So the 3 way handshake from reading below verifies the bi > directional communication between the endpoints which according to the > draft would all occur prior to client coming UP. However if Echo is > configured for looping the packets for testing that would happen after OSPF > FSM has started. > > Section 1 > > The goal of Bidirectional Forwarding Detection (BFD) is to provide > low-overhead, short-duration detection of failures in the path > between adjacent forwarding engines, including the interfaces, data > link(s), and, to the extent possible, the forwarding engines > themselves. > > An additional goal is to provide a single mechanism that can be used > for liveness detection over any media, at any protocol layer, with a > wide range of Detection Times and overhead, to avoid a proliferation > of different methods. > > > An additional goal is to provide a single mechanism that can be used > for liveness detection over any media, at any protocol layer, with a > wide range of Detection Times and overhead, to avoid a proliferation > of different methods. > > > BFD had a per link concept “BFD over bundle member” > > > BFD can provide failure detection on any kind of path between > systems, including direct physical links, virtual circuits, tunnels, > MPLS Label Switched Paths (LSPs), multihop routed paths, and > unidirectional links (so long as there is some return path, of > course). Multiple BFD sessions can be established between the same > pair of systems when multiple paths between them are present in at > least one direction, even if a lesser number of paths are available > in the other direction (multiple parallel unidirectional links or > MPLS LSPs, for example). > > > Section 2 > > > The BFD state machine implements a three-way handshake, both when > establishing a BFD session and when tearing it down for any reason, > to ensure that both systems are aware of the state change. > > > BFD can be abstracted as a simple service. The service primitives > provided by BFD are to create, destroy, and modify a session, given > the destination address and other parameters. BFD in return provides > a signal to its clients indicating when the BFD session goes up or > down. > > > Section 3 > > A path is only declared to be operational when two-way communication > has been established between systems, though this does not preclude > the use of unidirectional links. > > A separate BFD session is created for each communications path and > data protocol in use between two systems. > > Each system estimates how quickly it can send and receive BFD packets > in order to come to an agreement with its neighbor about how rapidly > detection of failure will take place. These estimates can be > modified in real time in order to adapt to unusual situations. This > design also allows for fast systems on a shared medium with a slow > system to be able to more rapidly detect failures between the fast > systems while allowing the slow system to participate to the best of > its ability. > > > Section 3.2 - we are taking about asynchronous mode primarily > > > The primary mode is known as Asynchronous mode. In this mode, the > systems periodically send BFD Control packets to one another, and if > a number of those packets in a row are not received by the other > system, the session is declared to be down. > > > **note the echo can be enabled for dirty links for additional testing looping > the packets** > > > Caveat with echo mode is the interval has to be greater then 2 seconds > > An adjunct to both modes is the Echo function. When the Echo > function is active, a stream of BFD Echo packets is transmitted in > such a way as to have the other system loop them back through its > forwarding path. If a number of packets of the echoed data stream > are not received, the session is declared to be down. The Echo > function may be used with either Asynchronous or Demand mode. Since > the Echo function is handling the task of detection, the rate of > periodic transmission of Control packets may be reduced (in the case > of Asynchronous mode) or eliminated completely (in the case of Demand > mode). > > > Section 4.1 FSM > > > 0 -- AdminDown > 1 -- Down > 2 -- Init > 3 -- Up > > > Section 6.1 - So here in order for the session to come up one or both > clients must take active role to send control packets - so here it’s stated > that control packets are being sent during that 3 way handshake process > that tests the link prior to FSM going to the UP state. > > A system may take either an Active role or a Passive role in session > initialization. A system taking the Active role MUST send BFD > Control packets for a particular session, regardless of whether it > has received any BFD packets for that session. A system taking the > Passive role MUST NOT begin sending BFD packets for a particular > session until it has received a BFD packet for that session, and thus > has learned the remote system's discriminator value. At least one > system MUST take the Active role (possibly both). The role that a > system takes is specific to the application of BFD, and is outside > the scope of this specification. > > > A session begins with the periodic, slow transmission of BFD Control > packets. When bidirectional communication is achieved, the BFD > session becomes Up. > > Once the BFD session is Up, a system can choose to start the Echo > function if it desires and the other system signals that it will > allow it. The rate of transmission of Control packets is typically > kept low when the Echo function is active. > > If the Echo function is not active, the transmission rate of Control > packets may be increased to a level necessary to achieve the > Detection Time requirements for the session. > > > If sufficient Echo packets are lost, the session is declared Down in > the same manner. See section 6.8.5 > <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.5>. > > > **so here when session goes down slow packets are still sent** > > > If the session goes Down, the transmission of Echo packets (if any) > ceases, and the transmission of Control packets goes back to the slow > rate. > > > **there is still control packet signaling in both directions before down > state is declared by both ends** > > Once a session has been declared Down, it cannot come back up until > the remote end first signals that it is down (by leaving the Up > state), thus implementing a three-way handshake. > > > > Section 6.2 this is really important as it describes the 3 way handshake > and transition to Up state and that connectivity between the end systems > have been verified and in UP state. > > Up state means that the BFD session has successfully been established, and > implies that connectivity between the systems is working. The session will > remain in the Up state until either connectivity fails or the session is > taken down administratively. If either the remote system signals Down state > or the Detection Time expires, the session advances to Down state. > > > > Section 6.8 > > When the BFD session transitions to Up state once 3 way handshake is > completed of control packets in async mode are sent up to this point at > which time if configured for Echo or demand the session transitions to Echo > in which case both Echo and Async control packets are sent or demand mode > where async control packet cease. > > When a system is said to have "the Echo function active" it means > that the system is sending BFD Echo packets, implying that the > session is Up and the other system has signaled its willingness to > loop back Echo packets. > > When the local system is said to have "Demand mode active," it means > that bfd.DemandMode is 1 in the local system (see section 6.8.1 > <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.1>), the > session is Up, and the remote system is signaling that the session is > in state Up. > > > > 6.8.1 state variables > > > When the text refers to initializing a state variable, this takes > place only at the time that the session (and the corresponding state > variables) is created. The state variables are subsequently > manipulated by the state machine and are never reinitialized, even if > the session fails and is reestablished. > > Once session state is created, and at least one BFD Control packet is > received from the remote end, it MUST be preserved for at least one > Detection Time (see section 6.8.4 > <https://datatracker.ietf.org/doc/html/rfc5880#section-6.8.4>) subsequent to > the receipt of the > last BFD Control packet, regardless of the session state. This > preserves timing parameters in case the session flaps. A system MAY > preserve session state longer than this. The preservation or > destruction of session state when no BFD Control packets for this > session have been received from the remote system is outside the > scope of this specification. > > > Section 7 > > It is worth noting that a single BFD session does not consume a large > amount of bandwidth. An aggressive session that achieves a detection > time of 50 milliseconds, by using a transmit interval of 16.7 > milliseconds and a detect multiplier of 3, will generate 60 packets > per second. The maximum length of each packet on the wire is on the > order of 100 bytes, for a total of around 48 kilobits per second of > bandwidth consumption in each direction. > > > BFD is bootstrapped to the IGP client per RFC 5882 which states that BFD > should block the client adjacency from coming Up prior to BFD coming up. > Ketan has added this text to the next revision and we should add as well to > the BGP draft. > > Section 4.1 > > BFD sessions are typically bootstrapped by the control protocol, > using the mechanism (discovery, configuration) used by the control > protocol to find neighbors. Note that it is possible in some failure > scenarios for the network to be in a state such that the control > protocol is capable of coming up, but the BFD session cannot be > established, and, more particularly, data cannot be forwarded. To > avoid this situation, it would be beneficial not to allow the control > protocol to establish a neighbor adjacency. However, this would > preclude the operation of the control protocol in an environment in > which not all systems support BFD. > > > Therefore, the establishment of control protocol adjacencies SHOULD > be blocked if both systems are willing to establish a BFD session but > a BFD session cannot be established. One method for determining that > both systems are willing to establish a BFD session is if the control > protocol carries explicit signaling of this fact. If there is no > explicit signaling, the willingness to establish a BFD session may be > determined by means outside the scope of this specification. > > > >> So we bring OSPF adj UP knowing literally nothing about BFD test results >> over subject link. >> > > Gyan> See above > > If the BFD timer is set to 2 seconds and the multiplier is 3 only in 6 >> seconds the BFD session could go down and take OSPF adj. down with it which >> means nothing what this draft aims to accomplish has been achieved. >> > > > >> Sure one can argue if this is proper for BFD to signal UP state without >> at least once exchanging a set of Echo packets - but this is currently not >> the case in BFD FSM. >> > > Gyan> BFD FSM control packets are sent async mode for the 3 way handshake > to complete before the session transitions to the Up state. The major > caveat with echo mode is it can only be used if the interval is greater > than 2 seconds as the packets have to be looped and when enabled it’s on > top of the async mode control packets still sent. Most operators don’t use > echo mode for that reason. > > If you want to "fix" BFD go for it, but for now the delay associated with >> any client action should be based on how BFD works per definition in >> RFC5880 and therefore should be specified on the client side. >> >> Rgs, >> Robert. >> >> >> >> On Sun, Feb 6, 2022 at 8:16 AM Gyan Mishra <hayabusa...@gmail.com> wrote: >> >>> >>> All >>> >>> I have finally caught up with this thread and I agree with Les, Ketan >>> and Albert that the “wait for BFD” goal is accomplished with both the OSPF >>> and BGP draft. There is extra verbiage in BGP draft in case BFD does not >>> come up for BGP to wait. Agreed not applicable to OSPF. >>> >>> I agree with the spirit of Roberts idea of a delay as it would help as >>> far as stability having a “pause” button for degraded links and quality >>> issues, however I do agree with the WG that this is outside of LSRs scope >>> and should really be with BFD or better yet IPPM for link quality >>> monitoring. >>> >>> Overall I believe the goal of the strict mode BFD “wait for BFD” is >>> accomplished and solve all problems except issues related to poor link >>> quality issues. >>> >>> I support both the OSPF and BGP strict mode drafts and I think think >>> this will be a big gain in itself for operators. >>> >>> As mentioned in the OSPF draft section 5 on use of hold down timers, BFD >>> dampening and on ML use of carrier delay and interface dampening can help >>> operators with link quality issues until we are able to make some headway >>> in BFD and IPPM WG. >>> >>> I would be happy to work with Greg and IPPM WGs as a follow up to this >>> thread related to link quality issues. >>> >>> Kind Regards >>> Gyan >>> >> -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
