Fix some typos

Change-Id: I5317006ca91c76833f54fd23a5742b42780b3022
Bernard Cafarelli 7 years ago
parent 7a9153cff7
commit deee2d348f

@ -1,2 +1,2 @@
Networking API referennce is maintained in the neutron-lib repo.
Networking API reference is maintained in the neutron-lib repo.
See api-ref in the neutron-lib repository.

@ -151,7 +151,7 @@ taken into account:
platform's point of view discerning which tagged packets are meant
to be treated 'transparently' and which ones are meant to be used
for demultiplexing (in order to reach the right destination).
The outcome might only be predicatble if two layers of vlan tags
The outcome might only be predictable if two layers of vlan tags
are stacked up together, making guest support even more crucial
for the combined use case.
@ -233,7 +233,7 @@ are:
and ports participating a trunk with no ability to convert
from one to the other (and vice versa), no migration is
required. This is done at a cost of some loss of flexibility
and maintainance complexity.
and maintenance complexity.
* Design reusability: a solution to support vlan trunking for
the Linux Bridge mech driver will still be required to avoid
widening the gap with Open vSwitch (e.g. OVS has DVR but
@ -254,7 +254,7 @@ are:
To summarize:
* VLAN interfaces (A) are compelling because will lead to a relatively
contained engineering cost at the expenses of performance. The Open
contained engineering cost at the expense of performance. The Open
vSwitch community will need to be involved in order to deliver vlan
transparency. Irrespective of whether this strategy is chosen for
Open vSwitch or not, this is still the only viable approach for Linux
@ -263,7 +263,7 @@ To summarize:
strategy for OVS deployments that are unable to adopt DPDK.
* Open Flow (B) is compelling because it will allow Neutron to unlock
the full potential of Open vSwitch, at the expenses of development
the full potential of Open vSwitch, at the expense of development
and operations effort. The development is confined within the
boundaries of the Neutron community in order to address vlan awareness
and transparency (as two distinct use cases, ie. to be adopted
@ -275,7 +275,7 @@ To summarize:
* Trunk Bridges (C) tries to bring the best of option A and B together
as far as OVS development and performance are concerned, but it
comes at the expenses of maintainance complexity and loss of flexibility.
comes at the expense of maintenance complexity and loss of flexibility.
A Linux Bridge solution would still be required and, QinQ support will
still be needed to address vlan transparency.
@ -295,7 +295,7 @@ plane performance improvement is hindered by the extra use of kernel resources,
this option is not at all appealing in the long term.
Embracing option (B) in the long run may be complicated by the adoption of
option (C). The development and maintainance complexity involved in Option
option (C). The development and maintenance complexity involved in Option
(C) and (B) respectively poses the existential question as to whether
investing in the agent-based architecture is an effective strategy,
especially if the end result would look a lot like other maturing

@ -362,7 +362,7 @@ The Linux bridge implementation relies on the new tc_lib functions:
The ingress bandwidth limit is configured on the tap port by setting a simple
`tc-tbf <>`_ queueing discipline (qdisc) on the
port. It requires a value of HZ parameter configured in kernel on the host.
This value is neccessary to calculate the minimal burst value which is set in
This value is necessary to calculate the minimal burst value which is set in
tc. Details about how it is calculated can be found in
`here <>`_. This solution is similar to Open
vSwitch implementation.