ovn-northd: Remove info log in extract_lport_addresses().
[cascardo/ovs.git] / ovn / ovn-architecture.7.xml
index 0bf9337..d539db8 100644 (file)
       A field that denotes the logical datapath through which a packet is being
       processed.
       <!-- Keep the following in sync with MFF_LOG_DATAPATH in
-           ovn/controller/lflow.h. -->
+           ovn/lib/logical-fields.h. -->
       OVN uses the field that OpenFlow 1.1+ simply (and confusingly) calls
       ``metadata'' to store the logical datapath.  (This field is passed across
       tunnels as part of the tunnel key.)
         A field that denotes the logical port from which the packet
         entered the logical datapath.
         <!-- Keep the following in sync with MFF_LOG_INPORT in
-             ovn/controller/lflow.h. -->
+             ovn/lib/logical-fields.h. -->
         OVN stores this in Nicira extension register number 6.
       </p>
 
         leave the logical datapath.  This is initialized to 0 at the
         beginning of the logical ingress pipeline.
         <!-- Keep the following in sync with MFF_LOG_OUTPORT in
-             ovn/controller/lflow.h. -->
+             ovn/lib/logical-fields.h. -->
         OVN stores this in Nicira extension register number 7.
       </p>
 
         to enter the logical ingress pipeline.
       </p>
 
-      <p>
-        It's possible that a single ingress physical port maps to multiple
-        logical ports with a type of <code>localnet</code>. The logical datapath
-        and logical input port fields will be reset and the packet will be
-        resubmitted to table 16 multiple times.
-      </p>
-
       <p>
         Packets that originate from a container nested within a VM are treated
         in a slightly different way.  The originating container can be
         egress port are the same.
       </p>
 
+      <p>
+        Logical patch ports are a special case.  Logical patch ports do not
+        have a physical location and effectively reside on every hypervisor.
+        Thus, flow table 33, for output to ports on the local hypervisor,
+        naturally implements output to unicast logical patch ports too.
+        However, applying the same logic to a logical patch port that is part
+        of a logical multicast group yields packet duplication, because each
+        hypervisor that contains a logical port in the multicast group will
+        also output the packet to the logical patch port.  Thus, multicast
+        groups implement output to logical patch ports in table 32.
+      </p>
+
       <p>
         Each flow in table 32 matches on a logical output port for unicast or
         multicast logical ports that include a logical port on a remote
 
       <p>
         Flows in table 33 resemble those in table 32 but for logical ports that
-        reside locally rather than remotely.  (This includes logical patch
-        ports, which do not have a physical location and effectively reside on
-        every hypervisor.)  For unicast logical output ports
+        reside locally rather than remotely.  For unicast logical output ports
         on the local hypervisor, the actions just resubmit to table 34.  For
         multicast output ports that include one or more logical ports on the
         local hypervisor, for each such logical port <var>P</var>, the actions
 
     <!-- Keep the following in sync with ovn/controller/physical.h. -->
     OVN transmits the logical ingress and logical egress ports in a TLV with
-    class 0xffff, type 0, and a 32-bit value encoded as follows, from MSB to
+    class 0x0102, type 0, and a 32-bit value encoded as follows, from MSB to
     LSB:
   </p>