Skip to content

Commit

Permalink
doc: update sbfd.rst for code review comments
Browse files Browse the repository at this point in the history
Signed-off-by: wumu.zsl <wumu.zsl@alibaba-inc.com>
  • Loading branch information
forrestchu committed Jan 15, 2025
1 parent 0a64bcc commit 7b31f00
Show file tree
Hide file tree
Showing 3 changed files with 140 additions and 88 deletions.
128 changes: 128 additions & 0 deletions doc/developer/sbfd.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,128 @@
.. _sbfd:

****
SBFD
****

:abbr:`SBFD (Seamless Bidirectional Forwarding Detection)` is:

Seamless Bidirectional Forwarding Detection, a simplified mechanism for using BFD with a large
proportion of negotiation aspects eliminated, thus providing benefits
such as quick provisioning, as well as improved control and
flexibility for network nodes initiating path monitoring.

-- :rfc:`7880`

It is described and extended by the following RFCs:

* :rfc:`7880`
* :rfc:`7881`

.. _sbfd-sate-machine:

SBFD state machine
==================

SBFD takes the same data packet format as BFD, but with a much simpler state machine.
According to RFC7880, SBFD has a stateless SBFDReflector and a stateful SBFDInitiator with the state machine as below:

::
+--+
ADMIN DOWN, | |
TIMER | V
+------+ UP +------+
| |-------------------->| |----+
| DOWN | | UP | | UP
| |<--------------------| |<---+
+------+ ADMIN DOWN, +------+
TIMER

Figure 1: SBFDInitiator Finite State Machine

.. _sbfd-extention:

SBFD extension - SRv6 encapsulation
===================================

SBFDInitiator periodically send packets to monitor the connection to SBFDReflector. We set up an SBFD connection between the source and the destination node of a path,
with the source node serving as Initiator and the destination node as Reflector. The communicated SBFD packets should also follow every exact hop in the path,
from the source to the destination, which could be achieved by segment routing. This requirement extends the node verification to the path verification.

.. _sbfd-implement:

implementation
===============

Some considerations when implementing sbfd.



.. _sbfd-implement-coexist:

SBFD Co-exist with BFD
--------------------------

Both SBFD and Classical BFD have their unique discriminator, SBFD can co-exist with BFD since they sharing a same discriminator pool in bfdd.
Also in bfdd SBFD and BFD can share most code logic, SBFD packet and BFD packet are demultiplexed by different discriminators.


.. _sbfd-implement-bfdname:

SBFD name
---------

We introduced a bfd-name for every sbfd session. A unique bfd-name can be used to identify a sbfd session quickly. This is quite useful in our Srv6 deployment for path protection case.
A bfd-name is always associated with a TE path, for example if we use the sbfd session to protect the path A-B-D, we would assign the name 'path-a-b-d' or 'a-b-d' to the session.

Meanwhile bfdd will notify the sbfd status to the Pathd, we should add the bfd-name field in PTM bfd notify message ZEBRA_BFD_DEST_REPLAY:

::
* Message format:
* - header: command, vrf
* - l: interface index
* - c: family
* - AF_INET:
* - 4 bytes: ipv4
* - AF_INET6:
* - 16 bytes: ipv6
* - c: prefix length
* - l: bfd status
* - c: family
* - AF_INET:
* - 4 bytes: ipv4
* - AF_INET6:
* - 16 bytes: ipv6
* - c: prefix length
* - c: cbit
* - c: bfd name len <---- new field
* - Xbytes: bfd name <---- new field
*
* Commands: ZEBRA_BFD_DEST_REPLAY
*
* q(64), l(32), w(16), c(8)



.. _sbfd-implement-port:

SBFD UDP port
-------------

According to RFC7881, SBFD Control packet dst port should be 7784, src port can be any but NOT 7784. In our implementation, the UDP ports in packet are set as:


::
UDP(sport=4784, dport=7784)/BFD() or UDP(sport=3784, dport=7784)/BFD()

if "multihop" is specified for sbfd initiator we choose the 4784 as the source port, so the reflected packet will take 4784 as the dst port, this is a local BFD_MULTI_HOP_PORT so the reflected packet can be handled by the existing bfd_recv_cb function.
if "multihop" is not specified for sbfd initiator we choose the 3784 as the source port, this is a local BFD_DEFDESTPORT so the reflected packet can be handled by the existing bfd_recv_cb function.


For echo SBFD with SRv6 encapsulation case, we re-use the BFD Echo port, the UDP ports in packet are set as:

::
UDP(sport=3785, dport=3785)/BFD()


we choose the 3785 as the source port, so the echo back packet will take 3785 as the dst port, this is a local BFD_DEF_ECHO_PORT so the packet can be handled by the existing bfd_recv_cb function.
1 change: 1 addition & 0 deletions doc/developer/subdir.am
Original file line number Diff line number Diff line change
Expand Up @@ -82,6 +82,7 @@ dev_RSTFILES = \
doc/developer/northbound/transactional-cli.rst \
doc/developer/northbound/yang-module-translator.rst \
doc/developer/northbound/yang-tools.rst \
doc/developer/sbfd.rst \
# end

EXTRA_DIST += \
Expand Down
99 changes: 11 additions & 88 deletions doc/user/sbfd.rst
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ SBFD
Seamless Bidirectional Forwarding Detection, a simplified mechanism for using BFD with a large
proportion of negotiation aspects eliminated, thus providing benefits
such as quick provisioning, as well as improved control and
flexibility for network nodes initiating path monitoring.
flexibility for network nodes initiating path monitoring.

-- :rfc:`7880`

Expand All @@ -25,6 +25,7 @@ SBFD state machine

SBFD takes the same data packet format as BFD, but with a much simpler state machine.
According to RFC7880, SBFD has a stateless SBFDReflector and a stateful SBFDInitiator with the state machine as below:

::
+--+
Expand Down Expand Up @@ -52,8 +53,8 @@ According to RFC7880, SBFD has a stateless SBFDReflector and a stateful SBFDInit
SBFD extension - SRv6 encapsulation
===================================

SBFDInitiator periodically send packets to monitor the connection to SBFDReflector. We set up an SBFD connection between the source and the destination node of a path,
with the source node serving as Initiator and the destination node as Reflector. The communicated SBFD packets should also follow every exact hop in the path,
SBFDInitiator periodically send packets to monitor the connection to SBFDReflector. We set up an SBFD connection between the source and the destination node of a path,
with the source node serving as Initiator and the destination node as Reflector. The communicated SBFD packets should also follow every exact hop in the path,
from the source to the destination, which could be achieved by segment routing. This requirement extends the node verification to the path verification.
In the following example, we set up a sbfd session to monitor the path A-B-D (all nodes in the topo are SRv6 ready, which can decap and forward SRv6 packets).

Expand Down Expand Up @@ -99,7 +100,7 @@ This packet will be routed in the topo according to the dst ip 200::A, it will g

In this example, Command used to configure the SBFDInitiator on A is:

.. clicmd:: peer 200::D bfd-mode sbfd-init bfd-name a-b-d local-address 200::A remote-discr 456 encap-type SRv6 encap-data 100::B,100::D source-ipv6 200::A
.. clicmd:: peer 200::D bfd-mode sbfd-init bfd-name a-b-d multihop local-address 200::A remote-discr 456 encap-type srv6 encap-data 100::B,100::D source-ipv6 200::A


Command used to configure the SBFDReflector on D is:
Expand Down Expand Up @@ -152,7 +153,7 @@ This packet will be routed in the topo according to the dst ip 200::A, it will g

In this example, Command used to configure the SBFDInitiator on A is:

.. clicmd:: peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A encap-type SRv6 encap-data 100::B,100::D source-ipv6 200::A
.. clicmd:: peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A encap-type srv6 encap-data 100::B,100::D source-ipv6 200::A


no configuration needed on D.
Expand Down Expand Up @@ -214,7 +215,7 @@ This packet will be routed in the topo according to the dst ip 200::A, it will g

.. _sbfd-show:

show commond
show command
============

The exsiting bfd show command is also appliable to SBFD sessions, for example:
Expand All @@ -225,7 +226,7 @@ This command will show all the BFD and SBFD sessions in the bfdd:

::
BFD Peers:
peer 200::D bfd-mode sbfd-init bfd-name a-d local-address 200::A remote-discr 456 vrf default
peer 200::D bfd-mode sbfd-init bfd-name a-d multihop local-address 200::A remote-discr 456 vrf default
ID: 1421669725
Remote ID: 456
Active mode
Expand Down Expand Up @@ -253,7 +254,7 @@ This command will show all the BFD and SBFD session packet counters:

::
BFD Peers:
peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A encap-type SRv6 encap-data 100::B,100::D source-ipv6 200::A
peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A encap-type srv6 encap-data 100::B,100::D source-ipv6 200::A
Control packet input: 0 packets
Control packet output: 0 packets
Echo packet input: 23807 packets
Expand All @@ -274,13 +275,13 @@ This command will show all the BFD and SBFD session packet counters:
Tx fail packet: 0


we also implemented a new show command to display SBFD session only, the bfd-name is the key to search the sessioon.
we also implemented a new show command to display BFD sessions with a bfd-name, the bfd-name is the key to search the sessioon.

.. clicmd:: show bfd bfd-name a-b-d

::
BFD Peers:
peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A encap-type SRv6 encap-data 100::B,100::D source-ipv6 200::A
peer 200::A bfd-mode sbfd-echo bfd-name a-b-d local-address 200::A encap-type srv6 encap-data 100::B,100::D source-ipv6 200::A
ID: 123
Remote ID: 123
Active mode
Expand All @@ -300,81 +301,3 @@ we also implemented a new show command to display SBFD session only, the bfd-nam
Receive interval: -
Transmission interval: -
Echo receive interval: -


.. _sbfd-implement:

implementation
===============

Some considerations when implementing sbfd.



.. _sbfd-implement-coexist:

SBFD Co-exist with BFD
--------------------------

Both SBFD and Classical BFD have their unique discriminator, SBFD can co-exist with BFD since they sharing a same discriminator pool in bfdd.
Also in bfdd SBFD and BFD can share most code logic, SBFD packet and BFD packet are demultiplexed by different discriminators.


.. _sbfd-implement-bfdname:

SBFD name
---------

We introduced a bfd-name for every sbfd session. A unique bfd-name can be used to identify a sbfd session quickly. This is quite useful in our Srv6 deployment for path protection case.
In the previous example, if use the sbfd session to protect the path A-B-D, we would assign the name 'path-a-b-d' or 'a-b-d' to the session.

Meanwhile bfdd will notify the sbfd status to the Pathd, we should add the bfd-name field in PTM bfd notify message ZEBRA_BFD_DEST_REPLAY:

::
* Message format:
* - header: command, vrf
* - l: interface index
* - c: family
* - AF_INET:
* - 4 bytes: ipv4
* - AF_INET6:
* - 16 bytes: ipv6
* - c: prefix length
* - l: bfd status
* - c: family
* - AF_INET:
* - 4 bytes: ipv4
* - AF_INET6:
* - 16 bytes: ipv6
* - c: prefix length
* - c: cbit
* - c: bfd name len <---- new field
* - Xbytes: bfd name <---- new field
*
* Commands: ZEBRA_BFD_DEST_REPLAY
*
* q(64), l(32), w(16), c(8)



.. _sbfd-implement-port:

SBFD UDP port
-------------

According to RFC7881, SBFD Control packet dst port should be 7784, src port can be any but NOT 7784. In our implementation, the UDP ports in packet are set as:

::
UDP(sport=4784, dport=7784)/BFD()

we choose the 4784 as the source port, so the reflected packet will take 4784 as the dst port, this is a local BFD_MULTI_HOP_PORT so the reflected packet can be handled by the existing bfd_recv_cb function.



For echo SBFD with SRv6 encapsulation case, we re-use the BFD Echo port, the UDP ports in packet are set as:

::
UDP(sport=3785, dport=3785)/BFD()


we choose the 3785 as the source port, so the echo back packet will take 3785 as the dst port, this is a local BFD_DEF_ECHO_PORT so the packet can be handled by the existing bfd_recv_cb function.

0 comments on commit 7b31f00

Please sign in to comment.