Re: [ovs-dev] [patch_v6 2/3] ovn: Add additional comments regarding arp responders.

[Mickey Spiegel]

Acked-by: Mickey Spiegel 


On Fri, Nov 4, 2016 at 10:06 AM, Darrell Ball  wrote:

> There has been enough confusion regarding logical switch datapath
> arp responders in ovn to warrant some additional comments;
> hence add a general description regarding why they exist and
> document the special cases.
>
> Signed-off-by: Darrell Ball 
> Signed-off-by: Ramu Ramamurthy 
> Co-authored-by: Ramu Ramamurthy 
> Acked-by: Han Zhou 
> ---
>
> v5->v6: Rewording based on review feedback including designating
> peer logical router port correctly.
>
> v4->v5: Splice in some rewording from review from multiple sources.
>
> v3->v4: Capitalization fixes.
> Reinstate comment regarding L2 learning confusion.
>
> v2->v3: Reword and further elaborate.
>
> v1->v2: Dropped RFC code change for logical switch router
> type ports.
>
>  ovn/northd/ovn-northd.8.xml | 67 ++
> +++
>  1 file changed, 61 insertions(+), 6 deletions(-)
>
> diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
> index df53d4c..9c61f66 100644
> --- a/ovn/northd/ovn-northd.8.xml
> +++ b/ovn/northd/ovn-northd.8.xml
> @@ -435,20 +435,75 @@
>  Ingress Table 10: ARP/ND responder
>
>  
> -  This table implements ARP/ND responder for known IPs.  It contains
> these
> -  logical flows:
> +  This table implements ARP/ND responder in a logical switch for known
> +  IPs.  The advantage of the ARP responder flow is to limit ARP
> +  broadcasts by locally responding to ARP requests without the need to
> +  send to other hypervisors.  One common case is when the inport is a
> +  logical port associated with a VIF and the broadcast is responded to
> +  on the local hypervisor rather than broadcast across the whole
> +  network and responded to by the destination VM.  This behavior is
> +  proxy ARP.
>  
>
> +
> +  ARP requests arrive from VMs from a logical switch inport of type
> +  default.  For this case, the logical switch proxy ARP rules can be
> +  for other VMs or logical router ports.  Logical switch proxy ARP
> +  rules may be programmed both for mac binding of IP addresses on
> +  other logical switch VIF ports (which are of the default logical
> +  switch port type, representing connectivity to VMs or containers),
> +  and for mac binding of IP addresses on logical switch router type
> +  ports, representing their logical router port peers.  In order to
> +  support proxy ARP for logical router ports, an IP address must be
> +  configured on the logical switch router type port, with the same
> +  value as the peer logical router port.  The configured MAC addresses
> +  must match as well.  When a VM sends an ARP request for a
> distributed
> +  logical router port and if the peer router type port of the attached
> +  logical switch does not have an IP address configured, the ARP
> request
> +  will be broadcast on the logical switch.  One of the copies of the
> ARP
> +  request will go through the logical switch router type port to the
> +  logical router datapath, where the logical router ARP responder will
> +  generate a reply.  The MAC binding of a distributed logical router,
> +  once learned by an associated VM, is used for all that VM's
> +  communication needing routing.  Hence, the action of a VM re-arping
> for
> +  the mac binding of the logical router port should be rare.
> +
> +
> +
> +  Logical switch ARP responder proxy ARP rules can also be hit when
> +  receiving ARP requests externally on a L2 gateway port.  In this
> case,
> +  the hypervisor acting as an L2 gateway, responds to the ARP request
> on
> +  behalf of a destination VM.
> +
> +
> +
> +  Note that ARP requests received from localnet or
> +  vtep logical inports can either go directly to VMs, in
> +  which case the VM responds or can hit an ARP responder for a logical
> +  router port if the packet is used to resolve a logical router port
> +  next hop address.  In either case, logical switch ARP responder
> rules
> +  will not be hit.  It contains these logical flows:
> + 
> +
>  
>
> -Priority-100 flows to skip ARP responder if inport is of type
> -localnet, and advances directly to the next table.
> +Priority-100 flows to skip the ARP responder if inport is of type
> +localnet or vtep and advances directly
> +to the next table.  ARP requests sent to localnet or
> +vtep ports can be received by multiple hypervisors.
> +Now, because the same mac binding rules are downloaded to all
> +hypervisors, each of the multiple hypervisors will respond.  This
> +will confuse L2 learning on the source 

Re: [ovs-dev] [PATCH 3/3] ovn-northd: SNAT in either direction of gateway router.

[Mickey Spiegel]

Forgot to copy the list on the last reply, but also realized something and
asking for one change below.

On Fri, Nov 4, 2016 at 9:54 AM, Guru Shetty  wrote:

>
>
> On 3 November 2016 at 20:42, Mickey Spiegel  wrote:
>
>> On Thu, Nov 3, 2016 at 6:06 PM, Guru Shetty  wrote:
>>
>> 
>>
>>
>>> > 2. If a stateful action such as DNAT or LB is taken on a
>>> >   gateway router, such that it is necessary for the reverse
>>> >   packet flow to come back to the same gateway router,
>>> >   then there should be an SNAT action coupled with the
>>> >   DNAT or LB action. If we could implement such composite
>>> >   actions, then there would be no need for a general purpose
>>> >   SNAT 0.0.0.0/0 catch all. Perhaps instead of SNAT
>>> >   0.0.0.0/0, DNAT or LB could set a flag that indicates that
>>> >   SNAT should be applied?
>>>
>>> That is one option. But I could not think of a nice way to express it in
>>> nb database. The other option is to set it as an option in the gateway
>>> router itself.
>>
>>
>> Coming back to this option because IMO it is the most straightforward in
>> terms of understanding what the knobs do, even if figuring out what knobs
>> to provide is not so straightforward.
>>
>> For the trigger, I am somewhat torn between putting it in the DNAT and LB
>> rules, versus a gateway router option. I can think of cases where it is
>> driven by topology (your multiple gateway case), as well as cases where it
>> is driven by application (whether direct server return works with the
>> application or not). If the trigger goes in the DNAT and LB rules, then a
>> force_snat column of type boolean in the NAT and Load_Balancer tables would
>> take care of the trigger.
>>
>> The part that is not as obvious is where to specify the IP address that
>> replaces the packet's source IP address. I would lean towards specifying
>> this separately from the existing NAT table, partly because the terminology
>> of the existing NAT table (logical_ip/external_ip) does not match the use
>> case, and partly because my somewhat hazy memory of hardware load balancer
>> configuration involves specification of a reference to a NAT pool, i.e. it
>> is not a separate SNAT rule specification but just the extra bit of
>> specification necessary to make the SNAT part work. If my memory is right,
>> that involved a relatively complex reference from the DNAT or LB rule to a
>> NAT pool. The equivalent of your SNAT 0.0.0.0/0 rule would be just a
>> single SNAT IP address on the gateway router for all force_snat cases,
>> rather than a reference to one of many IP addresses or IP address pools.
>>
>> As long as the trigger is only needed for DNAT and LB in the gateway
>> router itself, a force_snat flag should work. If you want a trigger for
>> other cases such as stateful services in a switch upstream from the gateway
>> router, at first glance it does not seem like this option can handle such a
>> case. You would need interface related configuration in order to identify
>> the subset of traffic, and some pipeline stage with conntrack so that you
>> could weed out ct.rpl traffic.
>>
>
> Thanks. I think the trigger is only needed for LB and DNAT use cases. I am
> thinking of going with the following approach:
>
> * options:force-snat="$IP" in the gateway router.
>
> Whenever there is a DNAT or LB done on the gateway router, you get a force
> snat done with the set IP address.  If application specific use cases come
> up as we go forward, then it is a matter of providing the same knob in LB
> and NAT tables too - which can be designed better when the use cases are
> more obvious.
>

That works for me. A bit of explanation is required with regard to which
traffic is subject to force-snat, but all in all I think this is easy to
understand and avoids complex side effects.

I just realized that this is the missing piece that I need to allow
centralized load balancing on a distributed router. In that case, I need
force-snat for load balancing but not for dnat. Wondering if there should
be two options instead:
dnat-force-snat="$IP"
lb-force-snat="$IP"

That also takes care of the explanation.

Mickey
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [patch_v6 0/3] ovn: arp responder fixes and documentation.

[Darrell Ball]

The first patch fixes arping from vtep-gw physical ports
and the code change was done by Ramu Ramamurthy.

The second patch adds additional comments regarding arp responders
in ovn.  This is intended to aid in understanding and hopefully
prevent future bugs in this area.

The third patch adds a test to verify that arp requests from vtep
ports are not responded to by logical switch arp responders after
the fix for patch 1 is applied.

Darrell Ball (3):
  ovn: Fix arping from vtep-gw physical port.
  ovn: Add additional comments regarding arp responders.
  ovn: Test arp requests received from vtep ports.

 ovn/northd/ovn-northd.8.xml | 67 +
 ovn/northd/ovn-northd.c |  6 ++--
 tests/ovn.at| 30 
 3 files changed, 95 insertions(+), 8 deletions(-)

-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [patch_v6 1/3] ovn: Fix arping from vtep-gw physical port.

[Darrell Ball]

from: Ramu Ramamurthy 

Currently, arping from a vtep-gw physical-switch port to
a VIF IP address does not work.

When a physical-switch-port arps for an IP address
of a VIF, that arp packet comes into the VIF hypervisor via a
vxlan tunnel. That arp packet must not be responded-to by the
arp responder table because, potentially, multiple hypervisors
could independently respond and confuse L2 learning at the
arp originator.

Signed-off-by: Ramu Ramamurthy 
Signed-off-by: Darrell Ball 
Co-authored-by: Darrell Ball 
---
 ovn/northd/ovn-northd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/ovn/northd/ovn-northd.c b/ovn/northd/ovn-northd.c
index 07c7b2d..ea6aec9 100644
--- a/ovn/northd/ovn-northd.c
+++ b/ovn/northd/ovn-northd.c
@@ -2844,13 +2844,15 @@ build_lswitch_flows(struct hmap *datapaths, struct hmap 
*ports,
 }
 
 /* Ingress table 10: ARP/ND responder, skip requests coming from localnet
- * ports. (priority 100). */
+ * and vtep ports. (priority 100); see ovn-northd.8.xml for the
+ * rationale. */
 HMAP_FOR_EACH (op, key_node, ports) {
 if (!op->nbsp) {
 continue;
 }
 
-if (!strcmp(op->nbsp->type, "localnet")) {
+if ((!strcmp(op->nbsp->type, "localnet")) ||
+(!strcmp(op->nbsp->type, "vtep"))) {
 ds_clear();
 ds_put_format(, "inport == %s", op->json_key);
 ovn_lflow_add(lflows, op->od, S_SWITCH_IN_ARP_ND_RSP, 100,
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [patch_v6 3/3] ovn: Test arp requests received from vtep ports.

[Darrell Ball]

Add a test that verifies that arp requests received from
vtep ports are not responded to by logical switch arp
responders.

Signed-off-by: Darrell Ball 
---

v1->v2: Remove redundant MAC address binding command.

 tests/ovn.at | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/tests/ovn.at b/tests/ovn.at
index 6ae4247..ddede93 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -1690,6 +1690,15 @@ ovn-nbctl lsp-set-type lp-vtep vtep
 ovn-nbctl lsp-set-options lp-vtep vtep-physical-switch=br-vtep 
vtep-logical-switch=lsw0
 ovn-nbctl lsp-set-addresses lp-vtep unknown
 
+# lpr, lr and lrp1 are used for the ARP request handling test only.
+ovn-nbctl lsp-add lsw0 lpr
+ovn-nbctl lr-add lr
+ovn-nbctl lrp-add lr lrp1 f0:00:00:00:00:f1 192.168.1.1/24
+ovn-nbctl set Logical_Switch_Port lpr type=router \
+ options:router-port=lrp1 \
+addresses='"f0:00:00:00:00:f1 192.168.1.1"'
+
+
 net_add n1   # Network to connect hv1, hv2, and vtep
 net_add n2   # Network to connect vtep and hv3
 
@@ -1812,11 +1821,32 @@ for s in 1 2 3; do
 test_packet $s f000 f00$s 0${s}66 $unknown   #3
 done
 
+# ARP request should not be responded to by logical switch router
+# type arp responder on HV1 and HV2 and should reach directly to
+# vif1 and vif2
+ip_to_hex() {
+printf "%02x%02x%02x%02x" "$@"
+}
+sha=f003
+spa=`ip_to_hex 192 168 1 2`
+tpa=`ip_to_hex 192 168 1 1`
+request=${sha}08060001080006040001${sha}${spa}${tpa}
+as hv3 ovs-appctl netdev-dummy/receive vif3 $request
+echo $request >> 1.expected
+echo $request >> 2.expected
+
 # dump information with counters
 echo "-- OVN dump --"
 ovn-nbctl show
 ovn-sbctl show
 
+echo "-SB dump-"
+ovn-sbctl list datapath_binding
+echo "-"
+ovn-sbctl list port_binding
+echo "-"
+ovn-sbctl dump-flows
+
 echo "-- hv1 dump --"
 as hv1 ovs-vsctl show
 as hv1 ovs-ofctl -O OpenFlow13 show br-int
-- 
1.9.1

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [patch_v6 2/3] ovn: Add additional comments regarding arp responders.

[Darrell Ball]

There has been enough confusion regarding logical switch datapath
arp responders in ovn to warrant some additional comments;
hence add a general description regarding why they exist and
document the special cases.

Signed-off-by: Darrell Ball 
Signed-off-by: Ramu Ramamurthy 
Co-authored-by: Ramu Ramamurthy 
Acked-by: Han Zhou 
---

v5->v6: Rewording based on review feedback including designating
peer logical router port correctly.

v4->v5: Splice in some rewording from review from multiple sources.

v3->v4: Capitalization fixes.
Reinstate comment regarding L2 learning confusion.

v2->v3: Reword and further elaborate.

v1->v2: Dropped RFC code change for logical switch router
type ports.

 ovn/northd/ovn-northd.8.xml | 67 +
 1 file changed, 61 insertions(+), 6 deletions(-)

diff --git a/ovn/northd/ovn-northd.8.xml b/ovn/northd/ovn-northd.8.xml
index df53d4c..9c61f66 100644
--- a/ovn/northd/ovn-northd.8.xml
+++ b/ovn/northd/ovn-northd.8.xml
@@ -435,20 +435,75 @@
 Ingress Table 10: ARP/ND responder
 
 
-  This table implements ARP/ND responder for known IPs.  It contains these
-  logical flows:
+  This table implements ARP/ND responder in a logical switch for known
+  IPs.  The advantage of the ARP responder flow is to limit ARP
+  broadcasts by locally responding to ARP requests without the need to
+  send to other hypervisors.  One common case is when the inport is a
+  logical port associated with a VIF and the broadcast is responded to
+  on the local hypervisor rather than broadcast across the whole
+  network and responded to by the destination VM.  This behavior is
+  proxy ARP.
 
 
+
+  ARP requests arrive from VMs from a logical switch inport of type
+  default.  For this case, the logical switch proxy ARP rules can be
+  for other VMs or logical router ports.  Logical switch proxy ARP
+  rules may be programmed both for mac binding of IP addresses on
+  other logical switch VIF ports (which are of the default logical
+  switch port type, representing connectivity to VMs or containers),
+  and for mac binding of IP addresses on logical switch router type
+  ports, representing their logical router port peers.  In order to
+  support proxy ARP for logical router ports, an IP address must be
+  configured on the logical switch router type port, with the same
+  value as the peer logical router port.  The configured MAC addresses
+  must match as well.  When a VM sends an ARP request for a distributed
+  logical router port and if the peer router type port of the attached
+  logical switch does not have an IP address configured, the ARP request
+  will be broadcast on the logical switch.  One of the copies of the ARP
+  request will go through the logical switch router type port to the
+  logical router datapath, where the logical router ARP responder will
+  generate a reply.  The MAC binding of a distributed logical router,
+  once learned by an associated VM, is used for all that VM's
+  communication needing routing.  Hence, the action of a VM re-arping for
+  the mac binding of the logical router port should be rare.
+
+
+
+  Logical switch ARP responder proxy ARP rules can also be hit when
+  receiving ARP requests externally on a L2 gateway port.  In this case,
+  the hypervisor acting as an L2 gateway, responds to the ARP request on
+  behalf of a destination VM.
+
+
+
+  Note that ARP requests received from localnet or
+  vtep logical inports can either go directly to VMs, in
+  which case the VM responds or can hit an ARP responder for a logical
+  router port if the packet is used to resolve a logical router port
+  next hop address.  In either case, logical switch ARP responder rules
+  will not be hit.  It contains these logical flows:
+ 
+
 
   
-Priority-100 flows to skip ARP responder if inport is of type
-localnet, and advances directly to the next table.
+Priority-100 flows to skip the ARP responder if inport is of type
+localnet or vtep and advances directly
+to the next table.  ARP requests sent to localnet or
+vtep ports can be received by multiple hypervisors.
+Now, because the same mac binding rules are downloaded to all
+hypervisors, each of the multiple hypervisors will respond.  This
+will confuse L2 learning on the source of the ARP requests.  ARP
+requests received on an inport of type router are not
+expected to hit any logical switch ARP responder flows.  However,
+no skip flows are installed for these packets, as there would be
+some additional flow cost for this and the value appears limited.
   

Re: [ovs-dev] [PATCH 0/4] Convert remaining docs to rST

[Stephen Finucane]

On 2016-11-04 15:28, Russell Bryant wrote:

On Fri, Nov 4, 2016 at 11:03 AM, Stephen Finucane 
wrote:


This is the fourth and final conversion series. This was kept
separate
due to the size and complexity of the tutorial guides. There are
also
ancillary changes to a previously unformatted TODO file (missed
previously due to the lack of an extension) and the AUTHORS file.

Stephen Finucane (4):
doc: Convert tutorial/Tutorial to rST
doc: Convert tutorial/OVN-Tutorial to rST
doc: Convert ovn/TODO to rST
AUTHORS: Add Stephen Finucane


It seems patch 4 didn't make it to the mailing list.  I had checked
AUTHORS before and your name is already there.  It's your old intel
address though, so I suspect you may want to update it to something
current.  Would you like to use the that.guru address?


Yup, I don't know if I need to add an additional entry or to change the 
existing one. I opted for the former, but do whatever suits.


Stephen
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 3/3] ovn-northd: SNAT in either direction of gateway router.

[Guru Shetty]

On 3 November 2016 at 20:42, Mickey Spiegel  wrote:

> On Thu, Nov 3, 2016 at 6:06 PM, Guru Shetty  wrote:
>
> 
>
>
>> > 2. If a stateful action such as DNAT or LB is taken on a
>> >   gateway router, such that it is necessary for the reverse
>> >   packet flow to come back to the same gateway router,
>> >   then there should be an SNAT action coupled with the
>> >   DNAT or LB action. If we could implement such composite
>> >   actions, then there would be no need for a general purpose
>> >   SNAT 0.0.0.0/0 catch all. Perhaps instead of SNAT
>> >   0.0.0.0/0, DNAT or LB could set a flag that indicates that
>> >   SNAT should be applied?
>>
>> That is one option. But I could not think of a nice way to express it in
>> nb database. The other option is to set it as an option in the gateway
>> router itself.
>
>
> Coming back to this option because IMO it is the most straightforward in
> terms of understanding what the knobs do, even if figuring out what knobs
> to provide is not so straightforward.
>
> For the trigger, I am somewhat torn between putting it in the DNAT and LB
> rules, versus a gateway router option. I can think of cases where it is
> driven by topology (your multiple gateway case), as well as cases where it
> is driven by application (whether direct server return works with the
> application or not). If the trigger goes in the DNAT and LB rules, then a
> force_snat column of type boolean in the NAT and Load_Balancer tables would
> take care of the trigger.
>
> The part that is not as obvious is where to specify the IP address that
> replaces the packet's source IP address. I would lean towards specifying
> this separately from the existing NAT table, partly because the terminology
> of the existing NAT table (logical_ip/external_ip) does not match the use
> case, and partly because my somewhat hazy memory of hardware load balancer
> configuration involves specification of a reference to a NAT pool, i.e. it
> is not a separate SNAT rule specification but just the extra bit of
> specification necessary to make the SNAT part work. If my memory is right,
> that involved a relatively complex reference from the DNAT or LB rule to a
> NAT pool. The equivalent of your SNAT 0.0.0.0/0 rule would be just a
> single SNAT IP address on the gateway router for all force_snat cases,
> rather than a reference to one of many IP addresses or IP address pools.
>
> As long as the trigger is only needed for DNAT and LB in the gateway
> router itself, a force_snat flag should work. If you want a trigger for
> other cases such as stateful services in a switch upstream from the gateway
> router, at first glance it does not seem like this option can handle such a
> case. You would need interface related configuration in order to identify
> the subset of traffic, and some pipeline stage with conntrack so that you
> could weed out ct.rpl traffic.
>

Thanks. I think the trigger is only needed for LB and DNAT use cases. I am
thinking of going with the following approach:

* options:force-snat="$IP" in the gateway router.

Whenever there is a DNAT or LB done on the gateway router, you get a force
snat done with the set IP address.  If application specific use cases come
up as we go forward, then it is a matter of providing the same knob in LB
and NAT tables too - which can be designed better when the use cases are
more obvious.




> Mickey
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 0/4] Convert remaining docs to rST

[Russell Bryant]

On Fri, Nov 4, 2016 at 11:03 AM, Stephen Finucane  wrote:

> This is the fourth and final conversion series. This was kept separate
> due to the size and complexity of the tutorial guides. There are also
> ancillary changes to a previously unformatted TODO file (missed
> previously due to the lack of an extension) and the AUTHORS file.
>
> Stephen Finucane (4):
>   doc: Convert tutorial/Tutorial to rST
>   doc: Convert tutorial/OVN-Tutorial to rST
>   doc: Convert ovn/TODO to rST
>   AUTHORS: Add Stephen Finucane
>

It seems patch 4 didn't make it to the mailing list.  I had checked AUTHORS
before and your name is already there.  It's your old intel address though,
so I suspect you may want to update it to something current.  Would you
like to use the that.guru address?
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 23/23] doc: Convert vswitchd/INTERNALS to rST

[Russell Bryant]

On Fri, Nov 4, 2016 at 10:40 AM, Stephen Finucane  wrote:

> On 2016-11-04 00:43, Russell Bryant wrote:
>
>> On Sun, Oct 30, 2016 at 2:30 PM, Stephen Finucane 
>> wrote:
>>
>> Signed-off-by: Stephen Finucane 
>>> ---
>>> lib/mac-learning.c |   3 +-
>>> lib/mac-learning.h |   2 +-
>>> vswitchd/INTERNALS | 239
>>> 
>>> vswitchd/INTERNALS.rst | 244
>>> +
>>> vswitchd/automake.mk [1]   |   2 +-
>>> 5 files changed, 248 insertions(+), 242 deletions(-)
>>> delete mode 100644 vswitchd/INTERNALS
>>> create mode 100644 vswitchd/INTERNALS.rst
>>>
>>
>> This whole series has been applied to master.  Thanks!
>>
>
> That was fast. Thanks :) Tutorial docs incoming, followed by the first
> pass at the Sphinx integration.
>

Thanks to you, too.  I want to keep things moving because I know this stuff
can go into conflict quickly.  I'm also excited to get to sphinx.  :-)

-- 
Russell Bryant
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 4/5 v2] datapath-windows: clean code in geneve

[Guru Shetty]

On 3 November 2016 at 16:27, Sairam Venugopal  wrote:

> Acked-by: Sairam Venugopal 
>

Applied the first 4 patches of the series. Thanks!


>
>
> On 10/27/16, 11:57 AM, "Alin Serdean" 
> wrote:
>
> >The purpose of this patch is to make the code more readable and
> >fix a static analyzer warning.
> >
> >Signed-off-by: Alin Gabriel Serdean 
> >---
> > datapath-windows/ovsext/Geneve.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> >diff --git a/datapath-windows/ovsext/Geneve.c
> >b/datapath-windows/ovsext/Geneve.c
> >index 5712e4d..efdf9f7 100644
> >--- a/datapath-windows/ovsext/Geneve.c
> >+++ b/datapath-windows/ovsext/Geneve.c
> >@@ -170,10 +170,10 @@ NDIS_STATUS OvsEncapGeneve(POVS_VPORT_ENTRY vport,
> >
> > /* L2 header */
> > ethHdr = (EthHdr *)bufferStart;
> >-ASSERT(((PCHAR) + sizeof fwdInfo.dstMacAddr)
> >==
> >-   (PCHAR));
> > NdisMoveMemory(ethHdr->Destination, fwdInfo.dstMacAddr,
> >-   sizeof ethHdr->Destination + sizeof
> >ethHdr->Source);
> >+   sizeof ethHdr->Destination);
> >+NdisMoveMemory(ethHdr->Source, fwdInfo.srcMacAddr,
> >+   sizeof ethHdr->Source);
> > ethHdr->Type = htons(ETH_TYPE_IPV4);
> >
> > /* IP header */
> >--
> >2.9.2.windows.1
> >___
> >dev mailing list
> >dev@openvswitch.org
> >https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__openvswitch.org_mailma
> >n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-
> YihVMNtXt-uEs=Dc
> >ruz40PROJ40ROzSpxyQSLw6fcrOWpJgEcEmNR3JEQ=
> eLFTV4YDHXlRcAzrUIHZJVdeHQCkIq
> >Jpaqd-3rY_N40=rMgWehrHeV8ZOAxTok8cLkUXXwTWYom8ySBbCfBbymY=
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 1/2] netdev-windows: fix ofpbuf initialization

[Guru Shetty]

On 3 November 2016 at 16:25, Sairam Venugopal  wrote:

> Guru,
>
> Any reason why the acked-by doesn’t show up on Patchwork -
> https://patchwork.ozlabs.org/patch/687913/


Not sure. Just flaky maybe.
I applied this series. Thanks.


>
>
> Thanks,
> Sairam
>
> On 10/27/16, 1:49 PM, "Sairam Venugopal"  wrote:
>
> >I thought we had set warnings to be treated as error. Appveyor didn¹t
> >catch this one either. Thanks for fixing this.
> >
> >Acked-by: Sairam Venugopal 
> >
> >
> >On 10/27/16, 12:20 PM, "Alin Serdean" 
> >wrote:
> >
> >>ofpbuf_const_initializer takes only two parameters see:
> >>
> >>https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__github.com_openvswit
> >>c
> >>h_ovs_blob_master_include_openvswitch_ofpbuf.h-23L96=
> CwIGaQ=Sqcl0Ez6M
> >>0
> >>X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=Dcruz40PROJ40ROzSpxyQSLw6fcrOW
> pJgEcEm
> >>N
> >>R3JEQ=hW8JkDjtdjUkx6FWcuFVzuV1QybnJJUmFaqnKtac2xQ=
> 2QeOkFwLYxAhyEcQGyK
> >>o
> >>6GJ8Z8KgavEI1u1sVymnHag=
> >>
> >>the compiler only gives the following warning:
> >>
> >>lib/netdev-windows.c(229) : warning C4020: 'ofpbuf_const_initializer' :
> >>too many actual parameters
> >>
> >>which in result will put junk data into "ofpbuf b".
> >>
> >>This patch fixes the initialization.
> >>
> >>Signed-off-by: Alin Gabriel Serdean 
> >>---
> >> lib/netdev-windows.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/lib/netdev-windows.c b/lib/netdev-windows.c
> >>index 3218490..423a00b 100644
> >>--- a/lib/netdev-windows.c
> >>+++ b/lib/netdev-windows.c
> >>@@ -226,7 +226,7 @@ netdev_windows_netdev_from_ofpbuf(struct
> >>netdev_windows_netdev_info *info,
> >>
> >> netdev_windows_info_init(info);
> >>
> >>-struct ofpbuf b = ofpbuf_const_initializer(, buf->data,
> >>buf->size);
> >>+struct ofpbuf b = ofpbuf_const_initializer(buf->data, buf->size);
> >> struct nlmsghdr *nlmsg = ofpbuf_try_pull(, sizeof *nlmsg);
> >> struct genlmsghdr *genl = ofpbuf_try_pull(, sizeof *genl);
> >> struct ovs_header *ovs_header = ofpbuf_try_pull(, sizeof
> >>*ovs_header);
> >>--
> >>2.9.2.windows.1
> >>___
> >>dev mailing list
> >>dev@openvswitch.org
> >>https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__openvswitch.org_mailm
> >>a
> >>n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-
> YihVMNtXt-uEs=D
> >>c
> >>ruz40PROJ40ROzSpxyQSLw6fcrOWpJgEcEmNR3JEQ=
> hW8JkDjtdjUkx6FWcuFVzuV1QybnJ
> >>J
> >>UmFaqnKtac2xQ=2ytbuFMxEgjkrn_32J0RWcRQUSDgjhkggbU5trvf20Q=
> >
> >___
> >dev mailing list
> >dev@openvswitch.org
> >https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__openvswitch.org_mailma
> >n_listinfo_dev=CwIGaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-
> YihVMNtXt-uEs=Dc
> >ruz40PROJ40ROzSpxyQSLw6fcrOWpJgEcEmNR3JEQ=_-
> l0g8rwmrlE8Ufx_RbepqYhnePTJD
> >QmVKjt4xtNu-I=tcKKbLgVheb4vDUa05jPwCaEPaz-pTMz9dwfB-3Ec_o=
>
> ___
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH v4 1/3] Windows: Add internal switch port per OVS bridge

[Guru Shetty]

On 10 October 2016 at 15:47, Sairam Venugopal  wrote:

> Sorry for the delay in the review.
>
> Acked-by: Sairam Venugopal 
>

There is a v5 of this series. Would you mind looking at that.


>
>
>
> On 8/12/16, 6:06 PM, "Alin Serdean" 
> wrote:
>
> >This patch updates the following commands in the vswitch:
> >ovs-vsctl add-br br-test
> >ovs-vsctl del-br br-test
> >
> >ovs-vsctl add-br br-test:
> >This command will now create an internal port on the MSFT virtual
> >switch
> >  using the WMI interface from Msvm_VirtualEthernetSwitchManagemen
> tService
> >  leveraging the method AddResourceSettings.
> >Before creating the actual port, the switch will be queried to see if
> >there
> >  is not a port already created (good for restarts when restarting the
> >  vswitch daemon). If there is a port defined it will return success and
> >log
> >  a message.
> >After checking if the port already exists the command will also verify
> >  if the forwarding extension (windows datapath) is enabled and on a
> >single
> >  switch. If it is not activated or if it is activated on multiple
> >switches
> >  it will return an error and a message will be logged.
> >After the port was created on the switch, we will disable the adapter
> >on
> >  the host and rename to the corresponding OVS bridge name for
> >consistency.
> >The user will enable and set the values he wants after creation.
> >
> >ovs-vsctl del-br br-test
> >This command will remove an internal port on the MSFT virtual switch
> >  using the Msvm_VirtualEthernetSwitchManagementService class and
> >executing
> >  the method RemoveResourceSettings.
> >
> >Both commands will be blocking until the WMI job is finished, this allows
> >us
> >to guarantee that the ports are created and their name are set before
> >issuing
> >a netlink message to the windows datapath.
> >
> >This patch also includes helpers for normal WMI retrievals and
> >initializations.
> >Appveyor and documentation has been modified to include the libraries
> >needed
> >for COM objects.
> >
> >This patch was tested individually using IMallocSpy and CRT heap checks
> >to ensure no new memory leaks are introduced.
> >
> >Tested on the following OS's:
> >Windows 2012 and Windows 2012r2
> >
> >Signed-off-by: Alin Gabriel Serdean 
> >Acked-by: Paul Boca 
> >---
> >v4: address comments (sanitize input, short refactor)
> >use full stop on comments
> >update coding style
> >v3: rebase, add acked
> >v2: Address comments. Rebase
> >---
> > appveyor.yml   |2 +-
> > lib/automake.mk|4 +-
> > lib/dpif-netlink.c |   21 +
> > lib/wmi.c  | 1276
> >
> > lib/wmi.h  |   51 +++
> > 5 files changed, 1352 insertions(+), 2 deletions(-)
> > create mode 100644 lib/wmi.c
> > create mode 100644 lib/wmi.h
> >
> >diff --git a/appveyor.yml b/appveyor.yml
> >index 0fd003b..1061df6 100644
> >--- a/appveyor.yml
> >+++ b/appveyor.yml
> >@@ -41,5 +41,5 @@ build_script:
> > - C:\MinGW\msys\1.0\bin\bash -lc "cp
> >/c/pthreads-win32/Pre-built.2/dll/x86/*.dll /c/openvswitch/."
> > - C:\MinGW\msys\1.0\bin\bash -lc "mv /bin/link.exe /bin/link_copy.exe"
> > - C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && ./boot.sh"
> >-- C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && ./configure
> >CC=build-aux/cccl LD=\"`which link`\" LIBS=\"-lws2_32 -liphlpapi\"
> >--with-pthread=C:/pthreads-win32/Pre-built.2
> >--with-openssl=C:/OpenSSL-Win32 --with-vstudiotarget=\"Debug\""
> >+- C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && ./configure
> >CC=build-aux/cccl LD=\"`which link`\" LIBS=\"-lws2_32 -liphlpapi
> >-lwbemuuid -lole32 -loleaut32\"
> >--with-pthread=C:/pthreads-win32/Pre-built.2
> >--with-openssl=C:/OpenSSL-Win32 --with-vstudiotarget=\"Debug\""
> > - C:\MinGW\msys\1.0\bin\bash -lc "cd /c/openvswitch && make"
> >diff --git a/lib/automake.mk b/lib/automake.mk
> >index 2faaeac..99bbdc0 100644
> >--- a/lib/automake.mk
> >+++ b/lib/automake.mk
> >@@ -387,7 +387,9 @@ lib_libopenvswitch_la_SOURCES += \
> >   lib/netlink-notifier.h \
> >   lib/netlink-protocol.h \
> >   lib/netlink-socket.c \
> >-  lib/netlink-socket.h
> >+  lib/netlink-socket.h \
> >+  lib/wmi.c \
> >+  lib/wmi.h
> > endif
> >
> > if HAVE_POSIX_AIO
> >diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> >index a39faa2..c8b0e37 100644
> >--- a/lib/dpif-netlink.c
> >+++ b/lib/dpif-netlink.c
> >@@ -58,6 +58,7 @@
> >
> > VLOG_DEFINE_THIS_MODULE(dpif_netlink);
> > #ifdef _WIN32
> >+#include "wmi.h"
> > enum { WINDOWS = 1 };
> > #else
> > enum { WINDOWS = 0 };
> >@@ -849,6 +850,16 @@ dpif_netlink_port_add__(struct dpif_netlink *dpif,
> >struct netdev *netdev,
> > #endif
> > }
> >
> >+#ifdef _WIN32
> >+if (request.type == OVS_VPORT_TYPE_INTERNAL) {
> >+if (!create_wmi_port(name)){
> >+  

[ovs-dev] Way forward: L3 tunneling, NSH, Packet type-aware pipeline and Generic encap/decap

[Jan Scheurich]

Hi,

With this mail we would like to re-focus the long-pending discussions on how to 
best support new tunnel stacks such as MPLS in GRE and new tunneling protocols 
like NSH in OVS. 

Contributions addressing individual aspects of the problem complex (L3 
tunneling, NSH) have been in the make for more than a year now and yet there is 
no acceptable overall solution in sight even for the known use cases.

Ericsson would like to engage more actively to help define and implement a 
comprehensive solution in OVS for a flexible and extensible support of 
tunneling protocols implemented either as tunnel ports, in OpenFlow, or both.

We would like to discuss our proposal on the OVS Conference next week and hope 
that we can reach agreement on the way forward.

Best regards, Jan


Situation:
--
1. OpenFlow up to version 1.4 only supports L2 (Ethernet) packets. At any point 
in time a packet in the OF pipeline must have an Ethernet header. Particular 
push/pop actions were defined to insert/delete certain "tunnel" headers within 
the packet (VLAN, MPLS, PBB).

2. OpenFlow 1.5 standardized the "Packet type-aware pipeline" (PTAP, EXT-112) 
[1], which allows an OpenFlow switch to handle non-Ethernet packets. It 
introduces the new match field packet_type encoding the type of packet and new 
pre-requisites for existing match fields. PTAP is not yet implemented in OVS. 
Jean Tourrilhes did a prototype implementation in OVS at the time of 
standardization [8,9].

3. OF extension "EXT-382: Generic tunnel Encap and Decap" [2] was proposed in 
ONF as means for an OF controller to push/pop individual tunnel headers at the 
front of a packet to handle arbitrary stacks of tunnel encapsulations within 
OpenFlow. As the encap/decap actions would change the packet_type of the packet 
in the pipeline, EXT-382 builds on PTAP. EXT-382 is candidate for inclusion in 
upcoming OF 1.6.
 
4. Traditionally OVS implements tunnels as logical OF ports. Supported tunnel 
types include GRE, VXLAN, GENEVE, STT. As the datapath and OF pipeline in OVS 
are Ethernet-only, all tunnel ports are L2 tunnels, even though some of the 
tunnel protocols would support other payload (GRE, GENEVE or VXLAN-GPE). The 
concept of tunnel ports only works for IP encapsulation as OVS relies on IP 
routing to select the outgoing interface for encapsulated packets.
 
5. The need in OVS for non-L2 tunnels such as MPLS in GRE or LISP to interwork 
with external network equipment has driven the development of a series of 
patches known as "L3 Tunneling support" by Lorand Jakub, Thomas Morin, Simon 
Horman and Jiri Benc. For the latest version see [3,4]. This work has been 
going on with interruptions for a long time.

In essence these patches make OVS pop the Ethernet header when sending a packet 
to an "L3" port and to push a dummy Ethernet header with the correct Ethertype 
when receiving a packet from an "L3" port. 

However, the actual implementation carries the non-Ethernet packets received on 
an L3 tunnel all the way through the datapath and the ofproto-dpif pipeline, 
but without any visibility to the OF controller. The missing Ethernet header is 
only pushed implicitly at transmission to a normal Ethernet port. Conversely, 
an Ethernet header is stripped off just before sending to an L3 tunnel. 
ofproto-dpif inserts internal push/pop_eth actions into the datapath when 
needed. 

This adds a lot of complexity to these patches without reaping the benefit of 
supporting the packet type-aware pipeline. Without PTAP, however, it would be 
sufficient to let the L3 tunnel vport push and pop Ethernet headers so that 
datapath and ofproto-dpif would see Ethernet packets only.

The current patches also have conceptual problems. The controller can, for 
example, match on and set MAC address fields of the non-existing Ethernet 
header in an L3 packet, as these are cached in the packet's struct flow, but it 
is prevented from pushing and popping VLAN headers and setting VLAN IDs.

Another issue with the patches is that a given tunnel port instance can either 
carry Ethernet packets or non-Ethernet packets, but not both, even if the 
tunnel protocol would allow that. This is a real limitation as it requires the 
setup of two parallel tunnel meshes if both L2 and L3 payload is needed.

6. Since autumn 2015 Yi Yang and Johnson Li have been working on a set of 
patches for OVS to support NSH encapsulation for SFC [5]. NSH is a service 
tunnel header that can encapsulate different packet types, typically Ethernet 
or IP. For transport it requires an outer Ethernet header or a "L3" transport 
tunnel such as VXLAN-GPE or GRE that can carry NSH frames. A complication with 
NSH is that in MD2 format the header includes optional TLV metadata fields, 
similar but not quite identical to GENEVE.

The NSH work is stuck mainly because of the difficulty to handle the variable 
encapsulations. For VXLAN-GPE transport it depends on the L3-Tunneling support. 
Furthermore the 

[ovs-dev] [PATCH 1/4] doc: Convert tutorial/Tutorial to rST

[Stephen Finucane]

Signed-off-by: Stephen Finucane 
---
 FAQ.rst  |   2 +-
 README.rst   |   2 +-
 tutorial/OVN-Tutorial.md |   2 +-
 tutorial/Tutorial.md | 859 --
 tutorial/automake.mk |   2 +-
 tutorial/tutorial.rst| 870 +++
 6 files changed, 874 insertions(+), 863 deletions(-)
 delete mode 100644 tutorial/Tutorial.md
 create mode 100644 tutorial/tutorial.rst

diff --git a/FAQ.rst b/FAQ.rst
index cc0f1bd..0e53301 100644
--- a/FAQ.rst
+++ b/FAQ.rst
@@ -2031,7 +2031,7 @@ Q: The "learn" action can't learn the action I want, can 
you improve it?
   http://openvswitch.org/pipermail/discuss/2016-June/021694.html
 
 - MAC learning in the middle of a pipeline, as described in `the tutorial
-  `__.
+  `__.
 
 - TCP state based firewalling, by learning outgoing connections based on
   SYN packets and matching them up with incoming packets.
diff --git a/README.rst b/README.rst
index a9eb7d9..ff5d3fd 100644
--- a/README.rst
+++ b/README.rst
@@ -104,7 +104,7 @@ To learn how to set up SSL support for Open vSwitch, see 
`here
 `__.
 
 To learn about some advanced features of the Open vSwitch software switch, read
-the `tutorial `__.
+the `tutorial `__.
 
 Each Open vSwitch userspace program is accompanied by a manpage.  Many of the
 manpages are customized to your configuration as part of the build process, so
diff --git a/tutorial/OVN-Tutorial.md b/tutorial/OVN-Tutorial.md
index 129e918..a9f591f 100644
--- a/tutorial/OVN-Tutorial.md
+++ b/tutorial/OVN-Tutorial.md
@@ -991,7 +991,7 @@ and `lport2`.
 $ ovn/env8/packet2.sh
 
 
[ovn-architecture(7)]:http://openvswitch.org/support/dist-docs/ovn-architecture.7.html
-[Tutorial.md]:https://github.com/openvswitch/ovs/blob/master/tutorial/Tutorial.md
+[Tutorial.md]:https://github.com/openvswitch/ovs/blob/master/tutorial/tutorial.rst
 [ovn-nb(5)]:http://openvswitch.org/support/dist-docs/ovn-nb.5.html
 [ovn-sb(5)]:http://openvswitch.org/support/dist-docs/ovn-sb.5.html
 [vtep(5)]:http://openvswitch.org/support/dist-docs/vtep.5.html
diff --git a/tutorial/Tutorial.md b/tutorial/Tutorial.md
deleted file mode 100644
index fefa8c8..000
--- a/tutorial/Tutorial.md
+++ /dev/null
@@ -1,859 +0,0 @@
-Open vSwitch Advanced Features Tutorial
-===
-
-Many tutorials cover the basics of OpenFlow.  This is not such a
-tutorial.  Rather, a knowledge of the basics of OpenFlow is a
-prerequisite.  If you do not already understand how an OpenFlow flow
-table works, please go read a basic tutorial and then continue reading
-here afterward.
-
-It is also important to understand the basics of Open vSwitch before
-you begin.  If you have never used `ovs-vsctl` or `ovs-ofctl` before,
-you should learn a little about them before proceeding.
-
-Most of the features covered in this tutorial are Open vSwitch
-extensions to OpenFlow.  Also, most of the features in this tutorial
-are specific to the software Open vSwitch implementation.  If you are
-using an Open vSwitch port to an ASIC-based hardware switch, this
-tutorial will not help you.
-
-This tutorial does not cover every aspect of the features that it
-mentions.  You can find the details elsewhere in the Open vSwitch
-documentation, especially `ovs-ofctl(8)` and the comments in the
-`include/openflow/nicira-ext.h` and `include/openvswitch/meta-flow.h`
-header files.
-
-> In this tutorial, paragraphs set off like this designate notes
-> with additional information that readers may wish to skip on a
-> first read.
-
-Getting Started

-
-This is a hands-on tutorial.  To get the most out of it, you will need
-Open vSwitch binaries.  You do not, on the other hand, need any
-physical networking hardware or even supervisor privilege on your
-system.  Instead, we will use a script called `ovs-sandbox`, which
-accompanies the tutorial, that constructs a software simulated network
-environment based on Open vSwitch.
-
-You can use `ovs-sandbox` three ways:
-
-  * If you have already installed Open vSwitch on your system, then
-you should be able to just run `ovs-sandbox` from this directory
-without any options.
-
-  * If you have not installed Open vSwitch (and you do not want to
-install it), then you can build Open vSwitch according to the
-instructions in [INSTALL.rst], without installing it.  Then run
-`./ovs-sandbox -b DIRECTORY` from this directory, substituting
-the Open vSwitch build directory for `DIRECTORY`.
-
-  * As a slight variant on the latter, you can run `make sandbox`
-from an Open vSwitch build directory.
-
-When you run `ovs-sandbox`, it does the following:
-
-  1. **CAUTION:** Deletes any subdirectory of the current directory
- named "sandbox" and any files in that directory.
-
-  2. Creates a new directory "sandbox" in the current directory.
-
-  3. Sets up special environment variables that ensure 

[ovs-dev] [PATCH 3/4] doc: Convert ovn/TODO to rST

[Stephen Finucane]

This might not be of much value, but let's be consistent where we can.

Signed-off-by: Stephen Finucane 
---
 ovn/TODO | 213 --
 ovn/TODO.rst | 233 +++
 2 files changed, 233 insertions(+), 213 deletions(-)
 delete mode 100644 ovn/TODO
 create mode 100644 ovn/TODO.rst

diff --git a/ovn/TODO b/ovn/TODO
deleted file mode 100644
index 5972ce5..000
--- a/ovn/TODO
+++ /dev/null
@@ -1,213 +0,0 @@
--*- outline -*-
-
-* Work out database for clustering or HA properly.
-
-* Compromised chassis mitigation.
-
-Possibly depends on database solution.
-
-Latest discussion:
-http://openvswitch.org/pipermail/dev/2016-August/078106.html
-
-* Get incremental updates in ovn-controller and ovn-northd in some
-  sensible way.
-
-* Testing improvements, possibly heavily based on ovn-trace.
-
-Justin Pettit: "I'm planning to write some ovn-trace tests for IPv6.
-Hopefully we can get those into 2.6."
-
-* Self-managing HA for ovn-northd (avoiding the need to set up
-  independent tooling for fail-over).
-
-Russell Bryant: "For bonus points, increasing N would scale out
-ovn-northd if it was under too much load, but that's a secondary
-concern."
-
-* Live migration.
-
-Russell Bryant: "When you're ready to have the destination take
-over, you have to remove the iface-id from the source and add it at
-the destination and i think it'd typically be configured on both
-ends, since it's a clone of the source VM (and it's config)."
-
-* VLAN trunk ports.
-
-Russell Bryant: "Today that would require creating 4096 ports for
-the VM and attach to 4096 OVN networks, so doable, but not quite
-ideal."
-
-* Native DNS support
-
-Russell Bryant: "This is an OpenStack requirement to fully eliminate
-the DHCP agent."
-
-* Service function chaining.
-
-* MAC learning.
-
-Han Zhou: "To support VMs that hosts workloads with their own macs,
-e.g. containers, if not using OVN native container support."
-
-* Finish up ARP/ND support: re-checking bindings, expiring bindings.
-
-* Hitless upgrade, especially for data plane.
-
-* Use OpenFlow "bundles" for transactional data plane updates.
-
-* L3 support
-
-** Logical routers should send RST replies to TCP packets.
-
-** IPv6 router ports should periodically send ND Router Advertisements.
-
-* Dynamic IP to MAC binding enhancements.
-
-OVN has basic support for establishing IP to MAC bindings dynamically,
-using ARP.
-
-** Ratelimiting.
-
-From casual observation, Linux appears to generate at most one ARP per
-second per destination.
-
-This might be supported by adding a new OVN logical action for
-rate-limiting.
-
-** Tracking queries
-
-It's probably best to only record in the database responses to queries
-actually issued by an L3 logical router, so somehow they have to be
-tracked, probably by putting a tentative binding without a MAC address
-into the database.
-
-** Renewal and expiration.
-
-Something needs to make sure that bindings remain valid and expire
-those that become stale.
-
-One way to do this might be to add some support for time to the
-database server itself.
-
-** Table size limiting.
-
-The table of MAC bindings must not be allowed to grow unreasonably
-large.
-
-** MTU handling (fragmentation on output)
-
-* Security
-
-** Limiting the impact of a compromised chassis.
-
-Every instance of ovn-controller has the same full access to the central
-OVN_Southbound database.  This means that a compromised chassis can
-interfere with the normal operation of the rest of the deployment.  Some
-specific examples include writing to the logical flow table to alter
-traffic handling or updating the port binding table to claim ports that are
-actually present on a different chassis.  In practice, the compromised host
-would be fighting against ovn-northd and other instances of ovn-controller
-that would be trying to restore the correct state.  The impact could 
include
-at least temporarily redirecting traffic (so the compromised host could
-receive traffic that it shouldn't) and potentially a more general denial of
-service.
-
-There are different potential improvements to this area.  The first would 
be
-to add some sort of ACL scheme to ovsdb-server.  A proposal for this should
-first include an ACL scheme for ovn-controller.  An example policy would
-be to make Logical_Flow read-only.  Table-level control is needed, but is
-not enough.  For example, ovn-controller must be able to update the Chassis
-and Encap tables, but should only be able to modify the rows associated 
with
-that chassis and no others.
-
-A more complex example is the Port_Binding table.  Currently, 
ovn-controller
-is the source of truth of where a port is located.  There seems to be  no
-policy that can prevent malicious behavior of a compromised host with this
-table.
-
-An alternative scheme for 

[ovs-dev] [PATCH 0/4] Convert remaining docs to rST

[Stephen Finucane]

This is the fourth and final conversion series. This was kept separate
due to the size and complexity of the tutorial guides. There are also
ancillary changes to a previously unformatted TODO file (missed
previously due to the lack of an extension) and the AUTHORS file.

Stephen Finucane (4):
  doc: Convert tutorial/Tutorial to rST
  doc: Convert tutorial/OVN-Tutorial to rST
  doc: Convert ovn/TODO to rST
  AUTHORS: Add Stephen Finucane

 AUTHORS|   1 +
 FAQ.rst|   2 +-
 README.rst |   2 +-
 ovn/TODO   | 213 --
 ovn/TODO.rst   | 233 +++
 tutorial/Tutorial.md   | 859 
 tutorial/automake.mk   |   4 +-
 tutorial/{OVN-Tutorial.md => ovn-tutorial.rst} | 721 ++--
 tutorial/ovn/env1/setup.sh |   2 +-
 tutorial/ovn/env6/setup.sh |   2 +-
 tutorial/tutorial.rst  | 870 +
 11 files changed, 1440 insertions(+), 1469 deletions(-)
 delete mode 100644 ovn/TODO
 create mode 100644 ovn/TODO.rst
 delete mode 100644 tutorial/Tutorial.md
 rename tutorial/{OVN-Tutorial.md => ovn-tutorial.rst} (59%)
 create mode 100644 tutorial/tutorial.rst

-- 
2.7.4

___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH 2/4] doc: Convert tutorial/OVN-Tutorial to rST

[Stephen Finucane]

There's a mismash of absolute and relative URLs, but these will be
resolved by the move to Sphinx.

In addition, the URLs pointing to the test scripts are removed as they
will break when we move to Sphinx.  This is because they won't be
published with the Sphinx docs, ruling out relative links, and OVS
evolves too fast to rely on non-breaking links to GitHub. Better to
rely on shell examples like we do elsewhere and let the user figure it
out.

Signed-off-by: Stephen Finucane 
---
 tutorial/automake.mk   |   2 +-
 tutorial/{OVN-Tutorial.md => ovn-tutorial.rst} | 721 +++--
 tutorial/ovn/env1/setup.sh |   2 +-
 tutorial/ovn/env6/setup.sh |   2 +-
 4 files changed, 333 insertions(+), 394 deletions(-)
 rename tutorial/{OVN-Tutorial.md => ovn-tutorial.rst} (59%)

diff --git a/tutorial/automake.mk b/tutorial/automake.mk
index cd7baec..79f9b68 100644
--- a/tutorial/automake.mk
+++ b/tutorial/automake.mk
@@ -1,6 +1,6 @@
 docs += \
tutorial/tutorial.rst \
-   tutorial/OVN-Tutorial.md
+   tutorial/ovn-tutorial.rst
 EXTRA_DIST += \
tutorial/ovs-sandbox \
tutorial/t-setup \
diff --git a/tutorial/OVN-Tutorial.md b/tutorial/ovn-tutorial.rst
similarity index 59%
rename from tutorial/OVN-Tutorial.md
rename to tutorial/ovn-tutorial.rst
index a9f591f..8d9fc1a 100644
--- a/tutorial/OVN-Tutorial.md
+++ b/tutorial/ovn-tutorial.rst
@@ -1,42 +1,65 @@
+..
+  Licensed under the Apache License, Version 2.0 (the "License"); you may
+  not use this file except in compliance with the License. You may obtain
+  a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+  WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+  License for the specific language governing permissions and limitations
+  under the License.
+
+  Convention for heading levels in Open vSwitch documentation:
+
+  ===  Heading 0 (reserved for the title in a document)
+  ---  Heading 1
+  ~~~  Heading 2
+  +++  Heading 3
+  '''  Heading 4
+
+  Avoid deeper levels because they do not render well.
+
+
 OVN Tutorial
 
 
 This tutorial is intended to give you a tour of the basic OVN features using
-`ovs-sandbox` as a simulated test environment.  It’s assumed that you have an
+``ovs-sandbox`` as a simulated test environment.  It's assumed that you have an
 understanding of OVS before going through this tutorial. Detail about OVN is
-covered in [ovn-architecture(7)], but this tutorial lets you quickly see it in
+covered in ovn-architecture_, but this tutorial lets you quickly see it in
 action.
 
 Getting Started
 ---
 
-For some general information about `ovs-sandbox`, see the “Getting Started”
-section of [Tutorial.md].
+For some general information about ``ovs-sandbox``, see the "Getting Started"
+section of the tutorial_.
 
-`ovs-sandbox` does not include OVN support by default.  To enable OVN, you must
-pass the `--ovn` flag.  For example, if running it straight from the ovs git
-tree you would run:
+``ovs-sandbox`` does not include OVN support by default.  To enable OVN, you
+must pass the ``--ovn`` flag.  For example, if running it straight from the ovs
+git tree you would run::
 
 $ make sandbox SANDBOXFLAGS="--ovn"
 
 Running the sandbox with OVN enabled does the following additional steps to the
 environment:
 
-  1. Creates the `OVN_Northbound` and `OVN_Southbound` databases as described 
in
- [ovn-nb(5)] and [ovn-sb(5)].
+1. Creates the ``OVN_Northbound`` and ``OVN_Southbound`` databases as 
described in
+   `ovn-nb(5)`_ and `ovn-sb(5)`_.
 
-  2. Creates a backup server for `OVN_Southbond` database. Sandbox launch
- screen provides the instructions on accessing the backup database.
- However access to the backup server is not required to go through the
- tutorial.
+2. Creates a backup server for ``OVN_Southbond`` database. Sandbox launch
+   screen provides the instructions on accessing the backup database.  However
+   access to the backup server is not required to go through the tutorial.
 
-  3. Creates the `hardware_vtep` database as described in [vtep(5)].
+3. Creates the ``hardware_vtep`` database as described in `vtep(5)`_.
 
-  4. Runs the [ovn-northd(8)], [ovn-controller(8)], and 
[ovn-controller-vtep(8)]
- daemons.
+4. Runs the `ovn-northd(8)`_, `ovn-controller(8)`_, and
+   `ovn-controller-vtep(8)`_ daemons.
 
-  5. Makes OVN and VTEP utilities available for use in the environment,
- including [vtep-ctl(8)], [ovn-nbctl(8)], and [ovn-sbctl(8)].
+5. Makes OVN and VTEP utilities available for use in the environment, including
+   `vtep-ctl(8)`_, `ovn-nbctl(8)`_, and `ovn-sbctl(8)`_.
 
 

Re: [ovs-dev] [PATCH 23/23] doc: Convert vswitchd/INTERNALS to rST

[Stephen Finucane]

On 2016-11-04 00:43, Russell Bryant wrote:

On Sun, Oct 30, 2016 at 2:30 PM, Stephen Finucane 
wrote:


Signed-off-by: Stephen Finucane 
---
lib/mac-learning.c |   3 +-
lib/mac-learning.h |   2 +-
vswitchd/INTERNALS | 239

vswitchd/INTERNALS.rst | 244
+
vswitchd/automake.mk [1]   |   2 +-
5 files changed, 248 insertions(+), 242 deletions(-)
delete mode 100644 vswitchd/INTERNALS
create mode 100644 vswitchd/INTERNALS.rst


This whole series has been applied to master.  Thanks!


That was fast. Thanks :) Tutorial docs incoming, followed by the first 
pass at the Sphinx integration.


Stephen
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

[ovs-dev] [PATCH] ovn: Fix url in OVN-Tutorial.md.

[nickcooper-zhangtonghao]

Signed-off-by: nickcooper-zhangtonghao 
---
 tutorial/OVN-Tutorial.md | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/tutorial/OVN-Tutorial.md b/tutorial/OVN-Tutorial.md
index 129e918..3779558 100644
--- a/tutorial/OVN-Tutorial.md
+++ b/tutorial/OVN-Tutorial.md
@@ -1005,10 +1005,10 @@ and `lport2`.
 
[env1packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/packet1.sh
 
[env1packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/packet2.sh
 
[env1thirdport]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/add-third-port.sh
-[env1unknownports]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env1/add-unknown-ports.sh
-[env1securityport]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env1/add-security-ip-ports.sh
-[env1packet3]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env1/packet3.sh
-[env1packet4]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env1/packet4.sh
+[env1unknownports]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/add-unknown-ports.sh
+[env1securityport]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/add-security-ip-ports.sh
+[env1packet3]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/packet3.sh
+[env1packet4]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env1/packet4.sh
 
[env2setup]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env2/setup.sh
 
[env2packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env2/packet1.sh
 
[env2packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env2/packet2.sh
@@ -1029,8 +1029,8 @@ and `lport2`.
 
[env7contports]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env7/add-container-ports.sh
 
[env7packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env7/packet1.sh
 
[env7packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env7/packet2.sh
-[env8setup]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env8/setup.sh
-[env8packet1]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env8/packet1.sh
-[env8packet2]:https://github.com/nickcooper-zhangtonghao/ovs/blob/master/tutorial/ovn/env8/packet2.sh
+[env8setup]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env8/setup.sh
+[env8packet1]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env8/packet1.sh
+[env8packet2]:https://github.com/openvswitch/ovs/blob/master/tutorial/ovn/env8/packet2.sh
 
[openstack-ovn-acl-blog]:http://blog.russellbryant.net/2015/10/22/openstack-security-groups-using-ovn-acls/
 
[openvswitch-docker]:http://openvswitch.org/support/dist-docs/INSTALL.Docker.rst.txt
-- 
1.8.3.1



___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev