diff --git a/doc/source/contributor/internals/sriov_nic_agent.rst b/doc/source/contributor/internals/sriov_nic_agent.rst
index e878ea1b2cd..fada860e827 100644
--- a/doc/source/contributor/internals/sriov_nic_agent.rst
+++ b/doc/source/contributor/internals/sriov_nic_agent.rst
@@ -51,9 +51,35 @@ to support network node functionality.
The SR-IOV network agent does not implement any port firewalling.
+Trusted virtual functions
+-------------------------
+
+In order to enable VF (SR-IOV virtual function) to request “trusted mode”, a
+new trusted VF concept was introduced in Linux kernel 4.4. It allows VF to
+become “trusted” by the Physical Function and perform some privileged
+operations, such as enabling VF promiscuous mode and changing VF MAC address
+within the guest.
+
+This last operation (VF MAC change) implies, in many NIC drivers, that the
+host VF interface changes the MAC address too. The SR-IOV agent will detect
+this change and declare the port as DOWN; the MAC address must be the same
+as the one configured by Neutron. If the MAC address is restored, matching
+the Neutron DB port MAC address, the SR-IOV agent will declare the port as UP
+again.
+
+It could happen that the MAC change happens during the SR-IOV agent periodic
+hardware inspection. This event will raise an error in the (MAC, PCI) tuple
+for this specific port. The SR-IOV agent will declare itself as out of sync
+and will force a full resync. During this resync process, all ports bound to
+this agent will set their status first to BUILD and then to ACTIVE again,
+causing a port status flapping. This event does not affect the user traffic.
+
+
Further Reading
---------------
`Nir Yechiel - SR-IOV Networking – Part I: Understanding the Basics `_
`SR-IOV Passthrough For Networking `_
+
+`Trusted Virtual Functions `_