On Tue, Oct 18, 2016 at 4:03 PM, Stephen Finucane <step...@that.guru> wrote:

> Signed-off-by: Stephen Finucane <step...@that.guru>
> ---
>  FAQ.md                          |   4 +-
>  Makefile.am                     |   2 +-
>  WHY-OVS.md                      | 106 ---------------------------------
>  WHY-OVS.rst                     | 128 ++++++++++++++++++++++++++++++
> ++++++++++
>  rhel/openvswitch-fedora.spec.in |   2 +-
>  rhel/openvswitch.spec.in        |   2 +-
>  tests/run-oftest                |   2 +-
>  tests/run-ryu                   |   2 +-
>  tutorial/ovs-sandbox            |   2 +-
>  utilities/ovs-dev.py            |   2 +-
>  utilities/ovs-sim.in            |   4 +-
>  11 files changed, 139 insertions(+), 117 deletions(-)
>  delete mode 100644 WHY-OVS.md
>  create mode 100644 WHY-OVS.rst
>
> diff --git a/FAQ.md b/FAQ.md
> index 9ab5210..420e40e 100644
> --- a/FAQ.md
> +++ b/FAQ.md
> @@ -83,7 +83,7 @@ A: The [PORTING.rst] document describes how one would go
> about
>  A: Open vSwitch is specially designed to make it easier to manage VM
>     network configuration and monitor state spread across many physical
>     hosts in dynamic virtualized environments.  Please see
> -   [WHY-OVS.md] for a more detailed description of how Open vSwitch
> +   [WHY-OVS.rst] for a more detailed description of how Open vSwitch
>     relates to the Linux Bridge.
>
>  ### Q: How is Open vSwitch related to distributed virtual switches like
> the VMware vNetwork distributed switch or the Cisco Nexus 1000V?
> @@ -2150,7 +2150,7 @@ b...@openvswitch.org
>  http://openvswitch.org/
>
>  [PORTING.rst]:PORTING.rst
> -[WHY-OVS.md]:WHY-OVS.md
> +[WHY-OVS.rst]:WHY-OVS.rst
>  [INSTALL.rst]:INSTALL.rst
>  [OPENFLOW-1.1+.md]:OPENFLOW-1.1+.md
>  [INSTALL.DPDK.rst]:INSTALL.DPDK.rst
> diff --git a/Makefile.am b/Makefile.am
> index dc92b71..9373a04 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -94,7 +94,7 @@ docs = \
>         README-native-tunneling.md \
>         REPORTING-BUGS.rst \
>         SECURITY.md \
> -       WHY-OVS.md
> +       WHY-OVS.rst
>  EXTRA_DIST = \
>         $(docs) \
>         NOTICE \
> diff --git a/WHY-OVS.md b/WHY-OVS.md
> deleted file mode 100644
> index d31e69e..0000000
> --- a/WHY-OVS.md
> +++ /dev/null
> @@ -1,106 +0,0 @@
> -Why Open vSwitch?
> -=================
> -
> -Hypervisors need the ability to bridge traffic between VMs and with the
> -outside world.  On Linux-based hypervisors, this used to mean using the
> -built-in L2 switch (the Linux bridge), which is fast and reliable.  So,
> -it is reasonable to ask why Open vSwitch is used.
> -
> -The answer is that Open vSwitch is targeted at multi-server
> -virtualization deployments, a landscape for which the previous stack is
> -not well suited.  These environments are often characterized by highly
> -dynamic end-points, the maintenance of logical abstractions, and
> -(sometimes) integration with or offloading to special purpose switching
> -hardware.
> -
> -The following characteristics and design considerations help Open
> -vSwitch cope with the above requirements.
> -
> -* The mobility of state: All network state associated with a network
> -  entity (say a virtual machine) should be easily identifiable and
> -  migratable between different hosts.  This may include traditional
> -  "soft state" (such as an entry in an L2 learning table), L3 forwarding
> -  state, policy routing state, ACLs, QoS policy, monitoring
> -  configuration (e.g. NetFlow, IPFIX, sFlow), etc.
> -
> -  Open vSwitch has support for both configuring and migrating both slow
> -  (configuration) and fast network state between instances.  For
> -  example, if a VM migrates between end-hosts, it is possible to not
> -  only migrate associated configuration (SPAN rules, ACLs, QoS) but any
> -  live network state (including, for example, existing state which
> -  may be difficult to reconstruct).  Further, Open vSwitch state is
> -  typed and backed by a real data-model allowing for the development of
> -  structured automation systems.
> -
> -* Responding to network dynamics: Virtual environments are often
> -  characterized by high-rates of change.  VMs coming and going, VMs
> -  moving backwards and forwards in time, changes to the logical network
> -  environments, and so forth.
> -
> -  Open vSwitch supports a number of features that allow a network
> -  control system to respond and adapt as the environment changes.
> -  This includes simple accounting and visibility support such as
> -  NetFlow, IPFIX, and sFlow.  But perhaps more useful, Open vSwitch
> -  supports a network state database (OVSDB) that supports remote
> -  triggers.  Therefore, a piece of orchestration software can "watch"
> -  various aspects of the network and respond if/when they change.
> -  This is used heavily today, for example, to respond to and track VM
> -  migrations.
> -
> -  Open vSwitch also supports OpenFlow as a method of exporting remote
> -  access to control traffic.  There are a number of uses for this
> -  including global network discovery through inspection of discovery
> -  or link-state traffic (e.g. LLDP, CDP, OSPF, etc.).
> -
> -* Maintenance of logical tags: Distributed virtual switches (such as
> -  VMware vDS and Cisco's Nexus 1000V) often maintain logical context
> -  within the network through appending or manipulating tags in network
> -  packets.  This can be used to uniquely identify a VM (in a manner
> -  resistant to hardware spoofing), or to hold some other context that
> -  is only relevant in the logical domain.  Much of the problem of
> -  building a distributed virtual switch is to efficiently and correctly
> -  manage these tags.
> -
> -  Open vSwitch includes multiple methods for specifying and maintaining
> -  tagging rules, all of which are accessible to a remote process for
> -  orchestration.  Further, in many cases these tagging rules are stored
> -  in an optimized form so they don't have to be coupled with a
> -  heavyweight network device.  This allows, for example, thousands of
> -  tagging or address remapping rules to be configured, changed, and
> -  migrated.
> -
> -  In a similar vein, Open vSwitch supports a GRE implementation that can
> -  handle thousands of simultaneous GRE tunnels and supports remote
> -  configuration for tunnel creation, configuration, and tear-down.
> -  This, for example, can be used to connect private VM networks in
> -  different data centers.
> -
> -* Hardware integration: Open vSwitch's forwarding path (the in-kernel
> -  datapath) is designed to be amenable to "offloading" packet processing
> -  to hardware chipsets, whether housed in a classic hardware switch
> -  chassis or in an end-host NIC.  This allows for the Open vSwitch
> -  control path to be able to both control a pure software
> -  implementation or a hardware switch.
> -
> -  There are many ongoing efforts to port Open vSwitch to hardware
> -  chipsets.  These include multiple merchant silicon chipsets (Broadcom
> -  and Marvell), as well as a number of vendor-specific platforms.  (The
> -  PORTING file discusses how one would go about making such a port.)
> -
> -  The advantage of hardware integration is not only performance within
> -  virtualized environments.  If physical switches also expose the Open
> -  vSwitch control abstractions, both bare-metal and virtualized hosting
> -  environments can be managed using the same mechanism for automated
> -  network control.
> -
> -In many ways, Open vSwitch targets a different point in the design space
> -than previous hypervisor networking stacks, focusing on the need for
> -automated and dynamic network control in large-scale Linux-based
> -virtualization environments.
> -
> -The goal with Open vSwitch is to keep the in-kernel code as small as
> -possible (as is necessary for performance) and to re-use existing
> -subsystems when applicable (for example Open vSwitch uses the existing
> -QoS stack).  As of Linux 3.3, Open vSwitch is included as a part of the
> -kernel and packaging for the userspace utilities are available on most
> -popular distributions.
> diff --git a/WHY-OVS.rst b/WHY-OVS.rst
> new file mode 100644
> index 0000000..161889d
> --- /dev/null
> +++ b/WHY-OVS.rst
> @@ -0,0 +1,128 @@
> +..
> +      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.
> +
> +=================
> +Why Open vSwitch?
> +=================
> +
> +Hypervisors need the ability to bridge traffic between VMs and with the
> outside
> +world. On Linux-based hypervisors, this used to mean using the built-in L2
> +switch (the Linux bridge), which is fast and reliable. So, it is
> reasonable to
> +ask why Open vSwitch is used.
> +
> +The answer is that Open vSwitch is targeted at multi-server virtualization
> +deployments, a landscape for which the previous stack is not well suited.
> These
> +environments are often characterized by highly dynamic end-points, the
> +maintenance of logical abstractions, and (sometimes) integration with or
> +offloading to special purpose switching hardware.
> +
> +The following characteristics and design considerations help Open vSwitch
> cope
> +with the above requirements.
> +
> +The mobility of state
> +---------------------
> +
> +All network state associated with a network entity (say a virtual machine)
> +should be easily identifiable and migratable between different hosts.
> This may
> +include traditional "soft state" (such as an entry in an L2 learning
> table), L3
> +forwarding state, policy routing state, ACLs, QoS policy, monitoring
> +configuration (e.g. NetFlow, IPFIX, sFlow), etc.
> +
> +Open vSwitch has support for both configuring and migrating both slow
> +(configuration) and fast network state between instances. For example, if
> a VM
> +migrates between end-hosts, it is possible to not only migrate associated
> +configuration (SPAN rules, ACLs, QoS) but any live network state
> (including,
> +for example, existing state which may be difficult to reconstruct).
> Further,
> +Open vSwitch state is typed and backed by a real data-model allowing for
> the
> +development of structured automation systems.
> +
> +Responding to network dynamics
> +------------------------------
> +
> +Virtual environments are often characterized by high-rates of change. VMs
> +coming and going, VMs moving backwards and forwards in time, changes to
> the
> +logical network environments, and so forth.
> +
> +Open vSwitch supports a number of features that allow a network control
> system
> +to respond and adapt as the environment changes. This includes simple
> +accounting and visibility support such as NetFlow, IPFIX, and sFlow. But
> +perhaps more useful, Open vSwitch supports a network state database
> (OVSDB)
> +that supports remote triggers. Therefore, a piece of orchestration
> software can
> +"watch" various aspects of the network and respond if/when they change.
> This is
> +used heavily today, for example, to respond to and track VM migrations.
> +
> +Open vSwitch also supports OpenFlow as a method of exporting remote
> access to
> +control traffic. There are a number of uses for this including global
> network
> +discovery through inspection of discovery or link-state traffic (e.g.
> LLDP,
> +CDP, OSPF, etc.).
> +
> +Maintenance of logical tags
> +----------------------------
> +
> +Distributed virtual switches (such as VMware vDS and Cisco's Nexus 1000V)
> often
> +maintain logical context within the network through appending or
> manipulating
> +tags in network packets. This can be used to uniquely identify a VM (in a
> +manner resistant to hardware spoofing), or to hold some other context
> that is
> +only relevant in the logical domain. Much of the problem of building a
> +distributed virtual switch is to efficiently and correctly manage these
> tags.
> +
> +Open vSwitch includes multiple methods for specifying and maintaining
> tagging
> +rules, all of which are accessible to a remote process for orchestration.
> +Further, in many cases these tagging rules are stored in an optimized
> form so
> +they don't have to be coupled with a heavyweight network device. This
> allows,
> +for example, thousands of tagging or address remapping rules to be
> configured,
> +changed, and migrated.
> +
> +In a similar vein, Open vSwitch supports a GRE implementation that can
> handle
> +thousands of simultaneous GRE tunnels and supports remote configuration
> for
> +tunnel creation, configuration, and tear-down. This, for example, can be
> used
> +to connect private VM networks in different data centers.
> +
> +Hardware integration
> +--------------------
> +
> +Open vSwitch's forwarding path (the in-kernel datapath) is designed to be
> +amenable to "offloading" packet processing to hardware chipsets, whether
> housed
> +in a classic hardware switch chassis or in an end-host NIC. This allows
> for the
> +Open vSwitch control path to be able to both control a pure software
> +implementation or a hardware switch.
> +
> +There are many ongoing efforts to port Open vSwitch to hardware chipsets.
> These
> +include multiple merchant silicon chipsets (Broadcom and Marvell), as
> well as a
> +number of vendor-specific platforms. (The PORTING file discusses how one
> would
> +go about making such a port.)
> +
> +The advantage of hardware integration is not only performance within
> +virtualized environments. If physical switches also expose the Open
> vSwitch
> +control abstractions, both bare-metal and virtualized hosting
> environments can
> +be managed using the same mechanism for automated network control.
> +
> +In many ways, Open vSwitch targets a different point in the design space
> than
> +previous hypervisor networking stacks, focusing on the need for automated
> and
> +dynamic network control in large-scale Linux-based virtualization
> environments.
> +
> +The goal with Open vSwitch is to keep the in-kernel code as small as
> possible
> +(as is necessary for performance) and to re-use existing subsystems when
> +applicable (for example Open vSwitch uses the existing QoS stack). As of
> Linux
> +3.3, Open vSwitch is included as a part of the kernel and packaging for
> the
> +userspace utilities are available on most popular distributions.
>

These last two paragraphs were not part of the "hardware integration"
section in the original doc.  They were the closing paragraphs of the
document.  I haven't thought of a good heading for them, though.  Maybe
"design"?  Thoughts?

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

Reply via email to