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
