Merge pull request #2019 from weaveworks/1-5-edit3

cleaned up product names
2016-03-08 12:29:18 -06:00
commit 66cd178308
@@ -5,11 +5,11 @@ layout: default



-Weave can be configured to encrypt both the data passing over the TCP
+Weave Net can be configured to encrypt both the data passing over the TCP
 connections and the payloads of UDP packets sent between peers. This
 is accomplished using the [NaCl](http://nacl.cr.yp.to/) crypto
 libraries, employing Curve25519, XSalsa20 and Poly1305 to encrypt and
-authenticate messages. Weave protects against injection and replay
+authenticate messages. Weave Net protects against injection and replay
 attacks for traffic forwarded between peers.

 NaCl was selected because of its good reputation both in terms of
@@ -20,17 +20,17 @@ quite difficult to use NaCl incorrectly. Contrast this with libraries
 such as OpenSSL where the library and its APIs are vast in size,
 poorly documented, and easily used wrongly.

-There are some similarities between Weave's crypto and
-[TLS](https://tools.ietf.org/html/rfc4346). Weave does not need to cater
+There are some similarities between Weave Net's crypto and
+[TLS](https://tools.ietf.org/html/rfc4346). Weave Net does not need to cater
 for multiple cipher suites, certificate exchange and other
 requirements emanating from X509, and a number of other features. This
 simplifies the protocol and implementation considerably. On the other
-hand, Weave needs to support UDP transports, and while there are
+hand, Weave Net needs to support UDP transports, and while there are
 extensions to TLS such as [DTLS](https://tools.ietf.org/html/rfc4347)
 which can operate over UDP, these are not widely implemented and
 deployed.

 **See Also**

- * [How Weave Implements Encryption](/site/encryption/ephemeral-key.md)
+ * [How Weave Implements Encryption](/site/encryption/implementation.md)
 * [Securing Containers Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md)
@@ -1,5 +1,5 @@
 ---
-title: How Weave Implements Encryption
+title: How Weave Net Implements Encryption
 layout: default
 ---

@@ -27,7 +27,7 @@ When a peer has received a public key from the remote peer, it uses
 this to form the ephemeral session key for this connection. The public
 key from the remote peer is combined with the private key for the
 local peer in the usual [Diffie-Hellman way](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), 
-resulting in both peersarriving at the same shared key. To this is appended the supplied
+resulting in both peers arriving at the same shared key. To this is appended the supplied
 password, and the result is hashed through SHA256, to form the final
 ephemeral session key. 

@@ -53,7 +53,7 @@ between two peers.
 Generating fresh keys for every connection
 provides forward secrecy at the cost of placing a demand on the Linux
 CSPRNG (accessed by `GenerateKey` via `/dev/urandom`) proportional to
-the number of inbound connection attempts. Weave has accept throttling
+the number of inbound connection attempts. Weave Net has accept throttling
 to mitigate against denial of service attacks that seek to deplete the
 CSPRNG entropy pool, however even at the lower bound of ten requests
 per second, there may not be enough entropy gathered on a headless
@@ -71,7 +71,7 @@ entirely safe for use as key material.

 By way of comparison, this is exactly how OpenSSL works - it reads 256
 bits of entropy at startup, and uses that to seed an internal CSPRNG,
-which is used to generate keys. While Weave could have taken
+which is used to generate keys. While Weave Net could have taken
 the same approach and built a custom CSPRNG to work around the
 potential `/dev/random` blocking issue, the decision was made to rely
 on the [heavily scrutinised](http://eprint.iacr.org/2012/251.pdf) Linux random number
@@ -80,7 +80,7 @@ here](http://cr.yp.to/highspeed/coolnacl-20120725.pdf) (page 10,
 'Centralizing randomness'). 

 >>**Note:**The aforementioned notwithstanding, if
-Weave's demand on `/dev/urandom` is causing you problems with blocking
+Weave Net's demand on `/dev/urandom` is causing you problems with blocking
 `/dev/random` reads, please get in touch with us - we'd love to hear
 about your use case.

@@ -4,12 +4,12 @@ layout: default
 ---


-Weave implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed.  The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel:
+Weave Net implements an overlay network between Docker hosts. Without fast datapath enabled, each packet is encapsulated in a tunnel protocol header and sent to the destination host, where the header is removed.  The Weave router is a user space process, which means that the packet follows a winding path in and out of the Linux kernel:

 ![Weave Net Encapsulation](/images/weave-net-encap1-1024x459.png)


-The fast datapath in Weave uses the Linux kernel's [Open vSwitch datapath module](https://www.kernel.org/doc/Documentation/networking/openvswitch.txt). This module enables the Weave router to tell the kernel how to process packets:
+The fast datapath in Weave Net uses the Linux kernel's [Open vSwitch datapath module](https://www.kernel.org/doc/Documentation/networking/openvswitch.txt). This module enables the Weave Net router to tell the kernel how to process packets:

 ![Weave Net Encapsulation](/images/weave-net-fdp1-1024x454.png)

@@ -19,7 +19,7 @@ Because Weave Net issues instructions directly to the kernel, context switches a

 Prior to version 1.2, Weave Net used a custom encapsulation format. Fast data path uses VXLAN, and like Weave Net's custom encapsulation format, VXLAN is UDP-based, and therefore needs no special configuration with network infrastructure. 

->>Note:The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path.
+>>**Note:** The required open vSwitch datapath (ODP) and VXLAN features are present in Linux kernel versions 3.12 and greater. If your kernel was built without the necessary modules Weave Net will fall back to the "user mode" packet path.


 **See Also**
@@ -20,19 +20,19 @@ $ WEAVE_NO_FASTDP=true weave launch

 ###Fast Datapath and Encryption

-Encryption does not work with fast datapath. If you enable encryption using the `--password` option to launch weave (or you use the `WEAVE_PASSWORD` environment variable), fast data path will by default be disabled. 
+Encryption does not work with fast datapath. If you enable encryption using the `--password` option to launch weave (or you use the `WEAVE_PASSWORD` environment variable), fast datapath will by default be disabled. 

-When encryption is not in use there may be other conditions in which the fastdp will revert back to `sleeve mode`. Once these conditions pass, weave will revert back to using fastdp. To view which mode Weave is using, run `weave status connections`.
+When encryption is not in use there may be other conditions in which the fast datapath reverts to `sleeve mode`. Once these conditions pass, Weave Net reverts back to using fastdp. To view which mode Weave Net is using, run `weave status connections`.

 ###Viewing Connection Mode Fastdp or Sleeve

-Weave automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave can use the fast data path:
+Weave Net automatically uses the fastest datapath for every connection unless it encounters a situation that prevents it from working. To ensure that Weave Net can use the fast datapath:

 * Avoid Network Address Translation (NAT) devices
 * Open UDP port 6784 (This is the port used by the Weave routers)
 * Ensure that `WEAVE_MTU` fits with the `MTU` of the intermediate network (see below)

-The use of fast datapath is an automated connection-by-connection decision made by Weave, and because of this, you may end up with a mixture of connection tunnel types. If fast data path cannot be used for a connection, Weave falls back to the "user space" packet path. 
+The use of fast datapath is an automated connection-by-connection decision made by Weave Net, and because of this, you may end up with a mixture of connection tunnel types. If fast datapath cannot be used for a connection, Weave Net falls back to the "user space" packet path. 

 Once a Weave network is set up, you can query the connections using the `weave status connections` command:

@@ -41,7 +41,7 @@ $ weave status connections
 <-192.168.122.25:43889  established fastdp a6:66:4f:a5:8a:11(ubuntu1204)
 ~~~

-Where fastdp indicates that fast data path is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method:
+Where fastdp indicates that fast datapath is being used on a connection. If fastdp is not shown, the field displays `sleeve` indicating Weave Net's fall-back encapsulation method:

 ~~~bash
 $ weave status connections
@@ -37,7 +37,7 @@ To application containers, the network established by Weave
 resembles a giant Ethernet switch, where all containers are 
 connected and can easily access services from one another. 

-Because Weave uses standard protocols, your favorite network 
+Because Weave Net uses standard protocols, your favorite network 
 tools and applications, developed over decades, can still 
 be used to configure, secure, monitor, and troubleshoot 
 a container network. 
@@ -50,7 +50,7 @@ and [Deploying Applications to Weave Net](/site/using-weave/deploying-applicatio

 ###<a name="fast-data-path"></a>Fast Datapath

-Weave automatically chooses the fastest available method to 
+Weave Net automatically chooses the fastest available method to 
 transport data between peers. The best performing of these 
 (the 'fast datapath') offers near-native throughput and latency.

@@ -63,7 +63,7 @@ See [Using Fast Datapath](/site/fastdp/using-fastdp.md) and

 ###<a name="docker"></a>Seamless Docker Integration (Weave Docker API Proxy)

-Weave includes a [Docker API Proxy](/site/weave-docker-api/set-up-proxy.md), which can be 
+Weave Net includes a [Docker API Proxy](/site/weave-docker-api/set-up-proxy.md), which can be 
 used to launch containers to the Weave network using the Docker [command-line interface](https://docs.docker.com/reference/commandline/cli/) or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/). 

 To use the proxy run: 
@@ -82,7 +82,7 @@ See [Using the Weave Docker API](/site/weave-docker-api/using-proxy.md)

 ###<a name="plugin"></a>Weave Network Docker Plugin

-Weave can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
+Weave Net can also be used as a [Docker plugin](https://docs.docker.com/engine/extend/plugins_network/).  A Docker network 
 named `weave` is created by `weave launch`, which is used as follows:

    $ docker run --net=weave -ti ubuntu 
@@ -107,7 +107,7 @@ Containers are automatically allocated a unique IP address. To view the addresse
 Instead of allowing Weave to automatically allocate addresses, an IP address and a network can be explicitly 
 specified. See [How to Manually Specify IP Addresses and Subnets(/site/using-weave/manual-ip-address.md) for instructions. 

-For a discussion on how Weave uses IPAM, see [Automatic IP Address Management](/site/ipam/overview-init-ipam.md). And also review the 
+For a discussion on how Weave Net uses IPAM, see [Automatic IP Address Management](/site/ipam/overview-init-ipam.md). And also review the 
 [the basics of IP addressing](/site/ip-addresses/ip-addresses.md) for an explanation of addressing and private networks. 


@@ -128,7 +128,7 @@ See [Naming and discovery with Weavedns](/site/weavedns/how-works-weavedns.md).
 
 ###<a name="application-isolation"></a>Application Isolation

-A single weave network can host multiple, isolated 
+A single Weave network can host multiple, isolated 
 applications, with each application's containers being able 
 to communicate with each other but not with the containers 
 of other applications.
@@ -158,13 +158,13 @@ for details.
 ###<a name="security"></a>Security

 In keeping with our ease-of-use philosophy, the cryptography 
-in Weave is intended to satisfy a particular user requirement: 
+in Weave Net is intended to satisfy a particular user requirement: 
 strong, out-of-the-box security without a complex setup or 
 the need to wade your way through the configuration of cipher 
 suite negotiation, certificate generation or any of the 
 other things needed to properly secure an IPsec or TLS installation.

-Weave communicates via TCP and UDP on a well-known port, so 
+Weave Net communicates via TCP and UDP on a well-known port, so 
 you can adapt whatever is appropriate to your requirements - for 
 example an IPsec VPN for inter-DC traffic, or VPC/private network 
 inside a data-center. 
@@ -175,7 +175,7 @@ mechanism which you can use in conjunction with or as an
 alternative to any other security technologies you have 
 running alongside Weave. 

-Weave implements encryption and security using [Daniel J. Bernstein's NaCl library](http://nacl.cr.yp.to/index.html).
+Weave Net implements encryption and security using [Daniel J. Bernstein's NaCl library](http://nacl.cr.yp.to/index.html).

 For information on how to secure your Docker network connections,
 see [Securing Connections Across Untrusted Networks](/site/using-weave/security-untrusted-networks.md)
@@ -184,7 +184,7 @@ and for a more technical discussion on how Weave implements encryption see, [Usi

 ###<a name="host-network-integration"></a>Host Network Integration

-Weave application networks can be integrated with a host's 
+Weave Net application networks can be integrated with a host's 
 network, and establish connectivity between the host and 
 application containers anywhere.

@@ -213,7 +213,7 @@ See [Enabling Multi-Cloud networking and Muti-hop Routing](/site/using-weave/mul
 ###<a name="multi-hop-routing"></a>Multi-Hop Routing

 A network of containers across more than two hosts can be established 
-even when there is only partial connectivity between the hosts. Weave 
+even when there is only partial connectivity between the hosts. Weave Net
 routes traffic between containers as long as there is at least one *path* 
 of connected hosts between them.

@@ -239,17 +239,17 @@ See [Managing Services in Weave: Exporting, Importing, Binding and Routing](/sit

 ###<a name="fault-tolerance"></a>Fault Tolerance

-Weave peers continually exchange topology information, and 
+Weave Net peers continually exchange topology information, and 
 monitor and (re)establish network connections to other peers. 
 So if hosts or networks fail, Weave can "route around" the problem. 
 This includes network partitions, where containers on either side 
 of a partition can continue to communicate, with full connectivity 
 being restored when the partition heals.

-The Weave Router container is very lightweight, fast and and disposable. 
-For example, should Weave ever run into difficulty, one can 
+The Weave Net Router container is very lightweight, fast and and disposable. 
+For example, should Weave Net ever run into difficulty, one can 
 simply stop it (with `weave stop`) and restart it. Application 
 containers do *not* have to be restarted in that event, and 
-if the Weave container is restarted quickly enough, 
+if the Weave Net container is restarted quickly enough, 
 may not experience a temporary connectivity failure.

@@ -15,12 +15,12 @@ Install Weave Net by running the following:
 If you are on OSX and are using Docker Machine) you need to make sure
 that a VM is running and configured before getting Weave Net. Setting up a VM is shown in [the Docker Machine
 documentation](https://docs.docker.com/installation/mac/#from-your-shell).
-After the VM is configured with Docker Machine, Weave can be launched directly from the OSX host.
+After the VM is configured with Docker Machine, Weave Net can be launched directly from the OSX host.

-Weave respects the environment variable `DOCKER_HOST`, so that you can run
+Weave Net respects the environment variable `DOCKER_HOST`, so that you can run
 and control a Weave Network locally on a remote host. See [Using The Weave Docker API Proxy](/site/weave-docker-api/using-proxy.md)

-With Weave downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Deploying Applications to Weave](/site/using-weave/deploying-applications.md#launching)
+With Weave Net downloaded onto your VMs or hosts, you are ready to launch a Weave network and deploy apps onto it. See [Deploying Applications to Weave](/site/using-weave/deploying-applications.md#launching)

 CoreOS users see [here](https://github.com/fintanr/weave-gs/blob/master/coreos-simple/user-data) for an example of installing Weave using cloud-config.

@@ -4,11 +4,7 @@ layout: default
 ---


-##What is Weave Net?
-
-Weave creates a virtual network that connects Docker containers deployed across multiple hosts and enables their automatic discovery. With Weave Net, portable microservices-based applications consisting of multiple containers can run anywhere: on one host, multiple hosts or even across cloud providers and data centers. 
-Applications use the network just as if the containers were all plugged into the same network switch, without having to configure port mappings, or ambassador links. 
-
+Weave Net creates a virtual network that connects Docker containers deployed across multiple hosts and enables their automatic discovery. With Weave Net, portable microservices-based applications consisting of multiple containers can run anywhere: on one host, multiple hosts or even across cloud providers and data centers. Applications use the network just as if the containers were all plugged into the same network switch, without having to configure port mappings, or ambassador links. 

 Services provided by application containers on the weave network can be exposed to the outside world, regardless of where they are running. Similarly, existing internal systems can be opened to accept connections from application containers irrespective of their location.

@@ -17,13 +13,13 @@ Services provided by application containers on the weave network can be exposed

 ###Hassle Free Configuration

-Weave simplifies setting up a container network. Because containers on a Weave network use standard port numbers, (for example MySQL’s default is port 3306), managing microservices is straightforward. Every container can find the IP of any other container using a simple DNS query on the container's name, and it can also communicate directly without NAT, without using port mappings or complicated ambassador linking.  And best of all deploying a Weave container network requires zero changes to your application’s code. 
+Weave Net simplifies setting up a container network. Because containers on a Weave network use standard port numbers, (for example MySQL’s default is port 3306), managing microservices is straightforward. Every container can find the IP of any other container using a simple DNS query on the container's name, and it can also communicate directly without NAT, without using port mappings or complicated ambassador linking.  And best of all deploying a Weave container network requires zero changes to your application’s code. 

 ![Weave Net Encapsulation](/images/weave-net-overview.png)

 ###Service Discovery

-Weave implements service discovery by providing a fast "micro DNS" server at each node. You simply name containers and everything 'just works', including load balancing across multiple containers with the same name.  
+Weave Net implements service discovery by providing a fast "micro DNS" server at each node. You simply name containers and everything 'just works', including load balancing across multiple containers with the same name.  

 ###No External Cluster Store Required

@@ -34,7 +30,7 @@ For information about the Weave Docker Plugin, see “Using the Weave Network Do

 ###Operates in Partially Connected Networks

-Weave can forward traffic between nodes, and it works even if the mesh network is only partially connected.  This means that you can have a mix of legacy systems and containerized apps and still use Weave Net to keep everything in communication. 
+Weave Net can forward traffic between nodes, and it works even if the mesh network is only partially connected.  This means that you can have a mix of legacy systems and containerized apps and still use Weave Net to keep everything in communication. 

 ###Weave Net is Fast

@@ -4,7 +4,7 @@ layout: default
 ---


-IP subnets are used to define or restrict routing. By default, Weave
+IP subnets are used to define or restrict routing. By default, Weave Net
 puts all containers into a subnet that spans the entire allocation
 range, so that every Weave-attached container can communicate with every other
 Weave-attached container.
@@ -4,11 +4,11 @@ layout: default
 ---


-Weave automatically assigns containers a unique IP address
+Weave Net automatically assigns containers a unique IP address
 across the network, and also releases that address when the container
 exits. Unless you explicitly specify an address, this occurs for all 
 invocations of the `run`, `start`,
-`attach`, `detach`, `expose`, and `hide` commands. Weave can also assign
+`attach`, `detach`, `expose`, and `hide` commands. Weave Net can also assign
 addresses in multiple subnets.

 The following automatic IP address managment topics are discussed: 
@@ -23,8 +23,8 @@ The following automatic IP address managment topics are discussed:
 ### <a name="initialization"></a>Initializing Peers on a Weave Network

 Just once, when the first automatic IP address allocation is requested
-in the whole network, Weave needs a majority of peers to be present in
-order to avoid formation of isolated groups, which could lead to
+in the whole network, Weave Net needs a majority of peers to be present in
+order to avoid formation of isolated groups, which can lead to
 inconsistency, for example, the same IP address being allocated to two
 different containers. 

@@ -32,7 +32,7 @@ Therefore, you must either supply the list of all peers in the network at `weave
 `--init-peer-count` flag to specify how many peers there will be.

 To illustrate, suppose you have three hosts, accessible to each other
-as `$HOST1`, `$HOST2` and `$HOST3`. You can start weave on those three
+as `$HOST1`, `$HOST2` and `$HOST3`. You can start Weave Net on those three
 hosts using these three commands:

    host1$ weave launch $HOST2 $HOST3
@@ -61,7 +61,7 @@ through three states: 'deferred', 'waiting' and 'achieved':
  themselves successfully
 * 'achieved' - consensus achieved; allocations proceed normally

-Finally, you may launch some peers as election observers using the
+Finally, some peers can be launched as election observers using the
 `--observer` option:

    host4$ weave launch --observer $HOST3
@@ -77,7 +77,7 @@ initial peer counts accordingly.
 Normally it isn't a problem to over-estimate `--init-peer-count`, but if you supply
 a number that is too small, then multiple independent groups may form.

-Weave uses the estimate of the number of peers at initialization to
+Weave Net uses the estimate of the number of peers at initialization to
 compute a majority or quorum number - specifically floor(n/2) + 1. 

 If the actual number of peers is less than half the number stated, then
@@ -101,7 +101,7 @@ that was correct when they first started, then they could form an
 independent set again.

 To illustrate this last point, the following sequence of operations
-is safe with respect to Weave's startup quorum:
+is safe with respect to Weave Net's startup quorum:

    host1$ weave launch
    ...time passes...
@@ -127,8 +127,8 @@ successfully.

 ### <a name="range"></a>Choosing an Allocation Range

-By default, Weave allocates IP addresses in the 10.32.0.0/12
-range. This can be overridden with the `--ipalloc-range` option, e.g.
+By default, Weave Net allocates IP addresses in the 10.32.0.0/12
+range. This can be overridden with the `--ipalloc-range` option:

    host1$ weave launch --ipalloc-range 10.2.0.0/16

@@ -5,29 +5,30 @@ layout: default


 You may wish to `weave stop` and re-launch to change some config or to
-upgrade to a new version; provided the underlying protocol hasn't
-changed it will pick up where it left off and learn from peers in the
-network which address ranges it was previously using. If, however, you
-run `weave reset` this will remove the peer from the network so
-if Weave is run again on that node it will start from scratch.
+upgrade to a new version. Provided that the underlying protocol hasn't
+changed, Weave Net picks up where it left off and learns from peers in the
+network which address ranges it was previously using. 
+
+If, however, you run `weave reset` this removes the peer from the network so
+if Weave Net is run again on that node it will start from scratch.

 For failed peers, the `weave rmpeer` command can be used to
-permanently remove the ranges allocated to said peer.  This will allow
-other peers to allocate IPs in the ranges previously owner by the rm'd
-peer, and as such should be used with extreme caution - if the rm'd
+permanently remove the ranges allocated to said peer.  This allows
+other peers to allocate IPs in the ranges previously owned by the removed peer, 
+and as such should be used with extreme caution - if the removed
 peer had transferred some range of IP addresses to another peer but
 this is not known to the whole network, or if it later rejoins
 the Weave network, the same IP address may be allocated twice.

-Assuming we had started the three peers in the example earlier, and
-host3 has caught fire, we can go to one of the other hosts and run:
+Assume you had started the three peers in the example earlier, and
+then host3 caught fire, you can go to one of the other hosts and run:

    host1$ weave rmpeer host3

-Weave will take all the IP address ranges owned by host3 and transfer
+Weave Net takes all the IP address ranges owned by host3 and transfers
 them to be owned by host1. The name "host3" is resolved via the
-'nickname' feature of weave, which defaults to the local host
-name. Alternatively, one can supply a peer name as shown in `weave
+'nickname' feature of Weave Net, which defaults to the local host
+name. Alternatively, you can supply a peer name as shown in `weave
 status`.

 **See Also**
@@ -8,7 +8,7 @@ The command

    weave status

-reports on the current status of the weave router and IP allocator:
+reports on the current status of the Weave Net router and IP allocator:

 ````
 ...
@@ -21,8 +21,8 @@ reports on the current status of the weave router and IP allocator:
 ...
 ````

-The first section covers the router; see the [troubleshooting
-guide](/site/troubleshooting.md#weave-status) for full details.
+The first section covers the router; see the [Troubleshooting
+Guide](/site/troubleshooting.md#weave-status) for full details.

 The 'Service: ipam' section displays the consensus state as well as
 the total allocation range and default subnet.
@@ -1,16 +1,16 @@
 ---
-title: How the Weave Docker Network Plugin Works
+title: How the Weave Net Docker Network Plugin Works
 layout: default
 ---


-The Weave plugin actually provides *two* network drivers to Docker - one named `weavemesh` that can operate without a cluster store and another one named `weave` that can only work with one (like Docker's overlay driver).
+The Weave Net plugin actually provides *two* network drivers to Docker - one named `weavemesh` that can operate without a cluster store and another one named `weave` that can only work with one (like Docker's overlay driver).

 ### `weavemesh` driver

-* Weave handles all co-ordination between hosts (referred to by Docker as a "local scope" driver)
+* Weave Net handles all co-ordination between hosts (referred to by Docker as a "local scope" driver)
 * Supports a single network only. A network named `weave` is automatically created for you.
-* Uses Weave's partition tolerant IPAM
+* Uses Weave Net's partition tolerant IPAM

 If you do create additional networks using the `weavemesh` driver, containers attached to them will be able to communicate with containers attached to `weave`. There is no isolation between those networks.

@@ -5,16 +5,16 @@ layout: default


 Docker versions 1.9 and later have a plugin mechanism for adding
-different network providers. Weave installs itself as a network plugin
+different network providers. Weave Net installs itself as a network plugin
 when you start it with `weave launch`. The Weave Docker Networking plugin is fast and easy to use and 
 best of all doesn't require an external cluster store in order to use it.  

-To create a network which can span multiple Docker hosts, the Weave peers must be connected to each other, by specifying the other hosts during `weave launch` or via
+To create a network which can span multiple Docker hosts, Weave Net peers must be connected to each other, by specifying the other hosts during `weave launch` or via
 [`weave connect`](/site/using-weave/finding-adding-hosts-dynamically.md).

 See [Deploying Applications to Weave Net](/site/using-weave/deploying-applications.md#peer-connections) for a discussion on peer connections. 

-After you've launched Weave and peered your hosts,  you can start containers using the following, for example:
+After you've launched Weave Net and peered your hosts,  you can start containers using the following, for example:

    $ docker run --net=weave -ti ubuntu

@@ -22,7 +22,7 @@ on any of the hosts, and they can all communicate with each other.

 >>**Warning!** It is inadvisable to attach containers to the Weave network using the Weave Docker Networking Plugin and Weave Docker API Proxy simultaneously. Such containers will end up with two Weave network interfaces and two IP addresses, which is rarely desirable. To ensure that the proxy is not being used, do not run eval $(weave env), or docker $(weave config).

-In order to use Weave's [Service Discovery](/site/weavedns/overview-using-weavedns.md) you
+In order to use Weave Net's [Service Discovery](/site/weavedns/overview-using-weavedns.md) you
 must pass the additional arguments `--dns` and `-dns-search`, for
 which a helper is provided in the Weave script:

@@ -32,7 +32,7 @@ which a helper is provided in the Weave script:



-###Launching Weave and Running Containers Using the Plugin
+###Launching Weave Net and Running Containers Using the Plugin

 Just launch the Weave Net router onto each host and make a peer connection with the other hosts:

@@ -1,5 +1,5 @@
 ---
-title: How Weave Inteprets Network Topology
+title: How Weave Net Inteprets Network Topology
 layout: default
 ---

@@ -144,7 +144,7 @@ which time the topology should have updated.

 **See Also**

- * [Weave Router Encapsulation](/site/router-topology/router-encapsulation.md)
+ * [Weave Net Router Encapsulation](/site/router-topology/router-encapsulation.md)
 
 
 
@@ -5,14 +5,14 @@ layout: default



-A Weave network consists of a number of 'peers' - Weave routers
+A Weave network consists of a number of 'peers' - Weave Net routers
 residing on different hosts. Each peer has a name, which tends to
 remain the same over restarts, a human friendly nickname for use in
 status and logging output and a unique identifier (UID) that is
 different each time it is run.  These are opaque identifiers as far as
 the router is concerned, although the name defaults to a MAC address.

-Weave routers establish TCP connections with each other, over which they
+Weave Net routers establish TCP connections with each other, over which they
 perform a protocol handshake and subsequently exchange
 [topology](/site/router-topology/network-topology.md) information. 
 These connections are encrypted if
@@ -20,13 +20,13 @@ so configured. Peers also establish UDP "connections", possibly
 encrypted, which carry encapsulated network packets. These
 "connections" are duplex and can traverse firewalls.

-Weave creates a network bridge on the host. Each container is
+Weave Net creates a network bridge on the host. Each container is
 connected to that bridge via a veth pair, the container side of which
 is given an IP address and netmask supplied either by the user or
-by Weave's IP address allocator. Also connected to the bridge is the
-Weave router container.
+by Weave Net's IP address allocator. Also connected to the bridge is the
+Weave Net router container.

-A Weave router captures Ethernet packets from its bridge-connected
+A Weave Net router captures Ethernet packets from its bridge-connected
 interface in promiscuous mode, using 'pcap'. This typically excludes
 traffic between local containers, and between the host and local
 containers, all of which is routed straight over the bridge by the
@@ -35,15 +35,15 @@ running on other hosts. On receipt of such a packet, a router injects
 the packet on its bridge interface using 'pcap' and/or forwards the
 packet to peers.

-Weave routers learn which peer host a particular MAC address resides
+Weave Net routers learn which peer host a particular MAC address resides
 on. They combine this knowledge with topology information in order to
 make routing decisions and thus avoid forwarding every packet to every
-peer. Weave can route packets in partially connected networks with
+peer. Weave Net can route packets in partially connected networks with
 changing topology. For example, in this network, peer 1 is connected
 directly to 2 and 3, but if 1 needs to send a packet to 4 or 5 it must
 first send it to peer 3:

-![Partially connected Weave Network](images/top-diag1.png "Partially connected Weave Network")
+![A Partially Connected Weave Network](images/top-diag1.png "Partially connected Weave Network")

 **See Also**

@@ -1,10 +1,10 @@
 ---
-title: Weave Router Encapsulation
+title: Weave Net Router Encapsulation
 layout: default
 ---


-When the Weave router forwards packets, the encapsulation looks
+When the Weave Net router forwards packets, the encapsulation looks
 something like this:

    +-----------------------------------+
@@ -61,4 +61,4 @@ MAC discovery.

 **See Also**

- * [How Weave Inteprets Network Topology](/site/router-topology/network-topology.md)
+ * [How Weave Net Inteprets Network Topology](/site/router-topology/network-topology.md)
@@ -1,9 +1,8 @@
 ---
-title: Troubleshooting Weave
+title: Troubleshooting Weave Net
 layout: default
 ---

-# Troubleshooting Weave

 * [Basic Diagnostics](#diagnostics)
 * [Status Reporting](#weave-status)
@@ -18,7 +17,7 @@ layout: default

 ## <a name="diagnostics"></a>Basic Diagnostics

-Check the version of Weave you are running using:
+Check the version of Weave Net you are running using:

    weave version

@@ -27,7 +26,7 @@ If it is not the latest version, as shown in the list of
 recommended you upgrade using the
 [installation instructions](https://github.com/weaveworks/weave#installation).

-To check the Weave container logs:
+To check the Weave Net container logs:

    docker logs weave

@@ -82,7 +81,7 @@ $ weave status
 The terms used here are explained further at
 [How Weave Net Works](/site/router-topology/overview.md).

-  * **Version** - shows the Weave version.
+  * **Version** - shows the Weave Net version.

  * **Protocol**- indicates the Weave Router inter-peer
 communication protocol name and supported versions (min..max).
@@ -120,14 +119,14 @@ available with [`weave status peers`](#weave-status-peers).

 ### <a name="weave-status-connections"></a>List Connections

-Connections between Weave peers carry control traffic over TCP and
+Connections between Weave Net peers carry control traffic over TCP and
 data traffic over UDP. For a connection to be fully established, the
 TCP connection and UDP datapath must be able to transmit information
-in both directions. Weave routers check this regularly with
+in both directions. Weave Net routers check this regularly with
 heartbeats. Failed connections are automatically retried, with an
 exponential back-off.

-Detailed information on the local Weave router's connections can be
+Detailed information on the local Weave Net router's connections can be
 obtained using `weave status connections`:

 ````
@@ -219,7 +218,7 @@ inspect`:
    $ weave report -f {% raw %}'{{.DNS.Domain}}'{% endraw %}
    weave.local.

-Weave adds a template function, `json`, which can be applied to get
+Weave Net adds a template function, `json`, which can be applied to get
 results in JSON format.

    $ weave report -f {% raw %}'{{json .DNS}}'{% endraw %}
@@ -251,11 +250,11 @@ You can also supply a list of container IDs/names to `weave ps`, like this:
    able ce:15:34:a9:b5:6d 10.2.5.1/24
    baker 7a:61:a2:49:4b:91 10.2.8.3/24

-## <a name="stop"></a>Stopping Weave
+## <a name="stop"></a>Stopping Weave Net

-To stop Weave, if you have configured your environment to use the
+To stop Weave Net, if you have configured your environment to use the
 Weave Docker API Proxy, e.g. by running `eval $(weave env)` in your
-shell, you must first restore the environment with
+shell, you must first restore the environment using:

    eval $(weave env --restore)

@@ -268,8 +267,8 @@ Containers on the local host can continue to communicate, whereas
 communication with containers on different hosts, as well as service
 export/import, is disrupted but resumes once Weave is relaunched.

-To stop Weave and to completely remove all traces of the Weave network on
-the local host, run
+To stop Weave Net and to completely remove all traces of the Weave network on
+the local host, run:

    weave reset

@@ -289,7 +288,7 @@ Weave and run application containers from
 If you are shutting down or restarting a host deliberately, run `weave
 reset` to clear everything down.

-The Weave Docker plugin does restart automatically because it must
+The Weave Net Docker plugin does restart automatically because it must
 always start with Docker, as described in
 [its documentation](/site/weave-docker-api/using-proxy.md).

@@ -7,11 +7,11 @@ A single Weave network can host multiple, isolated applications where each appli
 to communicate with each other, but not with the containers of other applications.

 To isolate applications, you can make use of `isolation-through-subnets` technique.
- This common strategy is an example of how with Weave many of your `on metal` 
- techniques can still be used to deploy applications to a container network.
+This common strategy is an example of how with Weave Net many of your `on metal` 
+techniques can still be used to deploy applications to a container network.
 
 To begin isolating an application (or parts of an application),  
-configure Weave's IP allocator to manage multiple subnets. 
+configure Weave Net's IP allocator to manage multiple subnets. 

 Using [the netcat example](/site/using-weave/deploying-applications.md), configure multiple subsets:

@@ -22,7 +22,7 @@ Using [the netcat example](/site/using-weave/deploying-applications.md), configu
    host2$ eval $(weave env)
 ~~~

-This delegates the entire 10.2.0.0/16 subnet to Weave, and instructs
+This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs
 it to allocate from 10.2.1.0/24 within that, if a specific subnet is not
 specified. 

@@ -79,7 +79,7 @@ isolation between application containers, that feature needs to be disabled by [

 **See Also** 

- * [Managing Services in Weave: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md)
+ * [Managing Services in Weave Net: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md)
 * [Exposing Services to the Outside World] (/site/using-weave/service-export.md)
 
 
@@ -13,7 +13,7 @@ This section contains the following topics:

 ###<a name="launching"></a>Launching Weave Net

-Before launching Weave and deploying your apps, ensure that Docker is [installed]( https://docs.docker.com/engine/installation/) on both hosts. 
+Before launching Weave Net and deploying your apps, ensure that Docker is [installed]( https://docs.docker.com/engine/installation/) on both hosts. 

 On `$HOST1` run:

@@ -23,8 +23,8 @@ On `$HOST1` run:

 Where, 

- * The first line runs Weave. 
- * The second line configures the Weave environment, so that containers launched via the Docker command line are automatically attached to the Weave network, and, 
+ * The first line runs Weave Net. 
+ * The second line configures the Weave Net environment, so that containers launched via the Docker command line are automatically attached to the Weave network, and, 
 * The third line runs the application container using [Docker commands]( https://docs.Docker.com/engine/reference/commandline/daemon/). 

 >>**Note:** If the first command results in an error like
@@ -33,7 +33,7 @@ Where,

 >>**Important!** if you are running the Weave Docker Network Plugin do not run `eval $(weave env)`. See [Using the Weave Net Docker Network Plugin](/site/pluing/weave-plugin-how-to.md) for more information.

-Weave must be launched once per host. The relevant container images will be pulled down from Docker Hub on demand during `weave launch`. 
+Weave Net must be launched once per host. The relevant container images will be pulled down from Docker Hub on demand during `weave launch`. 

 You can also preload the images by running `weave setup`. Preloaded images are useful for automated deployments, and ensure there are no delays during later operations.

@@ -42,19 +42,19 @@ If you are deploying an application that consists of more than one container to

 ###<a name="peer-connections"></a>Creating Peer Connections Between Hosts

-To launch Weave on an additional host and create a peer connection, run the following:
+To launch Weave Net on an additional host and create a peer connection, run the following:

    host2$ weave launch $HOST1
    host2$ eval $(weave env)
    host2$ docker run --name a2 -ti ubuntu

-As noted above, the same steps are repeated for `$HOST2`. The only difference, besides the application container’s name, is that `$HOST2` is told to peer with Weave on `$HOST1` during launch. 
+As noted above, the same steps are repeated for `$HOST2`. The only difference, besides the application container’s name, is that `$HOST2` is told to peer with Weave Net on `$HOST1` during launch. 

 You can also peer with other hosts by specifying the IP address, and a `:port` by which `$HOST2` can reach `$HOST1`. 

 >>**Note:** If there is a firewall between `$HOST1` and `$HOST2`,  you must permit traffic to flow through TCP 6783 and UDP 6783/6798, which are Weave’s control nd data ports.

-There are a number of different ways that you can specify peers on a Weave network. You can launch Weave on `$HOST1` and then peer with `$HOST2`, or you can launch on `$HOST2` and peer with `$HOST1` or you can tell both hosts about each other at launch. The order in which peers are specified is not important. Weave automatically (re)connects to peers when they become available. 
+There are a number of different ways that you can specify peers on a Weave network. You can launch Weave Net on `$HOST1` and then peer with `$HOST2`, or you can launch on `$HOST2` and peer with `$HOST1` or you can tell both hosts about each other at launch. The order in which peers are specified is not important. Weave Net automatically (re)connects to peers when they become available. 

 ####Specifying Multiple Peers at Launch

@@ -102,7 +102,7 @@ and then connected to from the another container on `$HOST2` using:
    root@a2:/# echo 'Hello, world.' | nc a1 4422
 ~~~

-Weave supports *any* protocol, and it doesn't have to be over TCP/IP. For example, a netcat UDP service can also be run by using the following:
+Weave Net supports *any* protocol, and it doesn't have to be over TCP/IP. For example, a netcat UDP service can also be run by using the following:

 ~~~bash
    root@a1:/# nc -lu -p 5533
@@ -113,5 +113,5 @@ Weave supports *any* protocol, and it doesn't have to be over TCP/IP. For exampl
 **See Also** 

 * [Installing Weave Net](/site/installing-weave.md)
- * [Using Fastdp With Weave](/site/fastdp/using-fastdp.md)
+ * [Using Fastdp With Weave Net](/site/fastdp/using-fastdp.md)
 * [Using the Weave Net Docker Network Plugin](/site/plugin/weave-plugin-how-to.md)
@@ -4,7 +4,7 @@ layout: default
 ---


-When containers may not know the network to which they will be attached, Weave enables you to dynamically attach and detach containers to and from a given network, even when a container is already running. 
+When containers may not know the network to which they will be attached, Weave Net enables you to dynamically attach and detach containers to and from a given network, even when a container is already running. 

 To illustrate these scenarios, imagine a netcat service running in a container on $host1 and you need to attach it to another subnet. To attach the netcat service container to a given subnet run: 

@@ -15,7 +15,7 @@ To illustrate these scenarios, imagine a netcat service running in a container o
 Where, 

 *  `C=$(Docker run -e WEAVE_CIDR=none -dti ubuntu)` is a variable for the subnet on which to attach
- *  `weave attach` – the Weave command to attach to the specified subnet, which takes the variable for the subnet
+ *  `weave attach` – the Weave Net command to attach to the specified subnet, which takes the variable for the subnet
 *  `10.2.1.3` - the allocated IP address output by `weave attach` and in this case, represents the default subnet

 >>Note If you are using the Weave Docker API proxy, it will have modified `DOCKER_HOST` to point to the proxy and therefore you will have to pass `-e WEAVE_CIDR=none` to start a container that _doesn't_ get automatically attached to the weave network for the purposes of this example.
@@ -5,24 +5,24 @@ layout: default


 To add a host to an existing Weave network, simply launch 
-Weave on the host, and then supply the address of at least 
-one host. Weave automatically discovers any other hosts in 
-the network and  establishes connections with them if it 
+Weave Net on the host, and then supply the address of at least 
+one host. Weave Net automatically discovers any other hosts in 
+the network and establishes connections with them if it 
 can (in order to avoid unnecessary multi-hop routing).

-In some situations all existing Weave hosts may be 
+In some situations all existing Weave Net hosts may be 
 unreachable from the new host due to firewalls, etc. 
 However, it is still possible to add the new host, 
 provided that inverse connections, for example, 
 from existing hosts to the new hosts, are available. 

-To accomplish this, launch Weave onto the new host 
+To accomplish this, launch Weave Net onto the new host 
 without supplying any additional addresses.  And then, from one 
 of the existing hosts run:

    host# weave connect $NEW_HOST

-Other hosts in the Weave network will automatically attempt
+Other hosts on the Weave network will automatically attempt
 to establish connections to the new host as well. 

 Alternatively, you can also instruct a peer to forget a 
@@ -45,7 +45,7 @@ For complete control over the peer topology, automatic
 discovery can be disabled using the `--no-discovery` 
 option with `weave launch`. 

-If discovery if disabled, Weave only connects to the 
+If discovery if disabled, Weave Net only connects to the 
 addresses specified at launch time and with `weave connect`.

 A list of all hosts that a peer has been asked to connect 
@@ -1,5 +1,5 @@
 ---
-title: Integrating a Host Network with Weave
+title: Integrating a Host Network with Weave Net
 layout: default
 ---

@@ -12,7 +12,7 @@ On `$HOST2` run:
    host2$ weave expose
    10.2.1.132

-This command grants the host access to all of the application containers in the default subnet. An IP address is allocated by Weave especially for that purpose, and is returned after running `weave expose`. 
+This command grants the host access to all of the application containers in the default subnet. An IP address is allocated by Weave Net especially for that purpose, and is returned after running `weave expose`. 

 Now you are able to ping the host:

@@ -25,7 +25,7 @@ And you can also ping the `a1` netcat application container residing on `$HOST1`

 ###Exposing Multiple Subnets

-Multiple subnet addresses can be exposed or hidden with a single command:
+Multiple subnet addresses can be exposed or hidden using a single command:

    host2$ weave expose net:default net:10.2.2.0/24
    10.2.1.132 10.2.2.130
@@ -14,7 +14,7 @@ To do this, you need to configure Weave's IP allocator to manage multiple subnet
    host2$ eval $(weave env)
 ~~~

-This delegates the entire 10.2.0.0/16 subnet to Weave, and instructs it to allocate from 10.2.1.0/24 within that if no specific subnet is specified. 
+This delegates the entire 10.2.0.0/16 subnet to Weave Net, and instructs it to allocate from 10.2.1.0/24 within that if no specific subnet is specified. 

 Now you can launch two containers onto the default subnet:

@@ -8,11 +8,11 @@ Containers are automatically allocated an IP address that is unique across the W
    host1$ weave ps a1
    a7aee7233393 7a:44:d3:11:10:70 10.32.0.2/12

-Weave detects when a container has exited and releases its allocated addresses so they can be re-used by the network.
+Weave Net detects when a container has exited and releases its allocated addresses so they can be re-used by the network.

 See the [Automatic IP Address Management](/site/ipam/overview-init-ipam.md) and also an explanation of [the basics of IP addressing](/site/ip-addresses/ip-addresses.md) for further details.

-Instead of allowing Weave to allocate IP addresses automatically (using IPAM), there may be instances where you need to control a particular container or a cluster by setting an IP address for it.  
+Instead of allowing Weave Net to allocate IP addresses automatically (using IPAM), there may be instances where you need to control a particular container or a cluster by setting an IP address for it.  

 You can specify an IP address and a network explicitly, using Classless Inter-Domain Routing or [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing).

@@ -6,13 +6,12 @@ layout: default

 ###Enabling Multi-Cloud Networking

-Before multi-cloud networking can be enabled, you must c
-onfigure the network to allow connections through Weave's 
-control and data ports on the Docker hosts. By default, the 
+Before multi-cloud networking can be enabled, you must configure the network to allow 
+connections through Weave Net's control and data ports on the Docker hosts. By default, the 
 control port defaults to TCP 6783, and the data ports to 
 UDP 6783/6784. 

-To override Weave’s default ports specify a port using 
+To override Weave Net’s default ports, specify a port using 
 the `WEAVE_PORT` setting. For example, if WEAVE_PORT is 
 set to `9000`, then Weave uses TCP 9000 for its control 
 port and UDP 9000/9001 for its data port. 
@@ -27,14 +26,14 @@ A network of containers across more than two hosts can be
 established even when there is only partial connectivity 
 between the hosts. 

-Weave routes traffic between containers as long as 
+Weave Net routes traffic between containers as long as 
 there is at least one *path* of connected hosts 
 between them.

 For example, if a Docker host in a local data center can 
 connect to hosts in GCE and EC2, but the latter two cannot 
 connect to each other, containers in the latter two can 
-still communicate and Weave in this instance will route the 
+still communicate and Weave Net in this instance will route the 
 traffic via the local data center.

 **See Also** 
@@ -4,7 +4,7 @@ layout: default
 ---


-To connect containers across untrusted networks, Weave peers can be instructed to encrypt traffic by supplying a `--password` option or by using the `WEAVE_PASSWORD` environment variable during `weave launch`. 
+To connect containers across untrusted networks, Weave Net peers can be instructed to encrypt traffic by supplying a `--password` option or by using the `WEAVE_PASSWORD` environment variable during `weave launch`. 

 For example:

@@ -26,7 +26,7 @@ To guard against dictionary attacks, the password needs to be reasonably strong

    < /dev/urandom tr -dc A-Za-z0-9 | head -c9 ; echo

-The same password must be specified for all Weave peers, by default both control and data plane traffic will then use authenticated encryption. 
+The same password must be specified for all Weave Net peers, by default both control and data plane traffic will then use authenticated encryption. 

 Fast datapath does not support encryption. If you supply a
 password at `weave launch` the router falls back to a slower
@@ -34,7 +34,7 @@ password at `weave launch` the router falls back to a slower

 If some of your peers are co-located in a trusted network (for example within the boundary of your own datacenter) you can use the `--trusted-subnets` argument to `weave launch` to selectively disable data plane encryption as an optimization. 

-Both peers must consider the other to be in a trusted subnet for this to take place - if they do not agree, Weave [falls back to a slower method]( /site/fastdp/using-fastdp.md) for transporting data between peers, since fast datapath does not support encryption.
+>>**Note:** Both peers must consider the other to be in a trusted subnet for this to take place - if they do not agree, Weave Net [falls back to a slower method]( /site/fastdp/using-fastdp.md) for transporting data between peers, since fast datapath does not support encryption.

 Be aware that:

@@ -45,4 +45,5 @@ Be aware that:

 **See Also**

- * [Using Encryption With Weave](/site/encryption/crypto-overview.md)
+ * [Using Encryption With Weave Net](/site/encryption/crypto-overview.md)
+ * [Using Fast Datapath](/site/using-weave/using-fastdap.md)
@@ -5,13 +5,13 @@ layout: default

 Services running in containers on a Weave network can be made
 accessible to the outside world (and, more generally, to other networks)
-from any Weave host, irrespective of where the service containers are
+from any Weave Net host, irrespective of where the service containers are
 located.

 Returning to the netcat example service, described in [Deploying Applications]( /site/using-weave/deploying-applications.md), 
 you can expose the netcat service running on `HOST1` and make it accessible to the outside world via `$HOST2`. 

-First, expose the application network to `$HOST2`, as explained in [Integrating a Host Network with a Weave](/site/using-weave/host-network-integration.md):
+First, expose the application network to `$HOST2`, as explained in [Integrating a Host Network with a Weave Net](/site/using-weave/host-network-integration.md):

    host2$ weave expose
    10.2.1.132
@@ -36,4 +36,4 @@ Similar NAT rules to the above can be used to expose services not just to the ou
 **See Also**

 * [Using Weave Net](/site/using-weave/intro-example.md)
- * [Managing Services in Weave: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md)
+ * [Managing Services in Weave Net: Exporting, Importing, Binding and Routing](/site/using-weave/service-management.md)
@@ -1,5 +1,5 @@
 ---
-title: Managing Services in Weave - Exporting, Importing, Binding and Routing
+title: Managing Services in Weave Net - Exporting, Importing, Binding and Routing
 layout: default
 ---

@@ -83,16 +83,16 @@ You can point application containers to another service location by changing the

 You can combine the service export and service import features to establish connectivity between applications and services residing on disjointed networks, even if those networks are separated by firewalls and have overlapping IP ranges. 

-Each network imports its services into Weave, while at the same time, exports from Weave any services that are required by its applications. In this scenario, there are no application containers (although, there could be). Weave is acting as an address translation and routing facility, and uses the Weave container network as an intermediary.
+Each network imports its services into Weave Net, while at the same time, exports from Weave Net any services that are required by its applications. In this scenario, there are no application containers (although, there could be). Weave Net is acting as an address translation and routing facility, and uses the Weave container network as an intermediary.

-Expanding on the [netcat example](/site/using-weave/deploying-applications.md), you can also import an additional netcat service running on `$HOST3` into Weave via `$HOST1`. 
+Expanding on the [netcat example](/site/using-weave/deploying-applications.md), you can also import an additional netcat service running on `$HOST3` into Weave Net via `$HOST1`. 

 Begin importing the service onto `$HOST2` by first exposing the application network:

    host2$ weave expose
    10.2.1.3

-Then add a NAT rule which routes traffic from the `$HOST2` network (i.e. anything which can connect to `$HOST2`) to the service endpoint on the Weave network:
+Then add a NAT rule which routes traffic from the `$HOST2` network (for example, anything that can connect to `$HOST2`) to the service endpoint on the Weave network:

    host2$ iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 4433 \
           -j DNAT --to-destination 10.2.1.3:3322
@@ -1,5 +1,5 @@
 ---
-title: Using Automatic Discovery With the Weave Proxy
+title: Using Automatic Discovery With the Weave Net Proxy
 layout: default
 ---

@@ -35,8 +35,7 @@ For example, you can launch the proxy using all three flags, as follows:
 (for example, `$1`). For further details on the regular expression syntax see
 [Google's re2 documentation](https://github.com/google/re2/wiki/Syntax).

-After launching the Weave proxy with these flags, running a container named `aws-12798186823-foo` without labels results in
-weavedns registering the hostname `my-app-foo` and not `aws-12798186823-foo`.
+After launching the Weave Net proxy with these flags, running a container named `aws-12798186823-foo` without labels results in weavedns registering the hostname `my-app-foo` and not `aws-12798186823-foo`.

    host1$ docker run -ti --name=aws-12798186823-foo ubuntu ping my-app-foo
    PING my-app-foo.weave.local (10.32.0.2) 56(84) bytes of data.
@@ -4,13 +4,13 @@ layout: default
 ---


-If [automatic IP address allocation](/site/ipam/overview-init-ipam.md) is enabled in Weave (by default IPAM is enabled),
+If [automatic IP address allocation](/site/ipam/overview-init-ipam.md) is enabled in Weave Net (by default IPAM is enabled),
 then containers started via the proxy are automatically assigned an IP address, *without having to specify any
 special environment variables or any other options*.

    host1$ docker run -ti ubuntu

-To use a specific subnet, we pass a `WEAVE_CIDR` to the container, e.g.
+To use a specific subnet, you can pass a `WEAVE_CIDR` to the container, for example:

    host1$ docker run -ti -e WEAVE_CIDR=net:10.32.2.0/24 ubuntu

@@ -27,7 +27,7 @@ be passed the `--no-default-ipalloc` flag, for example:

    host1$ weave launch-proxy --no-default-ipalloc

-In this configuration, containers with no `WEAVE_CIDR` environment
+In this configuration, containers using no `WEAVE_CIDR` environment
 variable are not connected to the Weave network. 

 Containers started with a `WEAVE_CIDR` environment variable are handled as before. 
@@ -4,19 +4,19 @@ layout: default
 ---


-When starting Weave-enabled containers, the proxy automatically
+When starting Weave Net enabled containers, the proxy automatically
 replaces the container's `/etc/hosts` file, and disables Docker's control
 over it. The new file contains an entry for the container's hostname
-and Weave IP address, as well as additional entries that have been
+and Weave Net IP address, as well as additional entries that have been
 specified using the `--add-host` parameters. 

 This ensures that:

 - name resolution of the container's hostname, for example, via `hostname -i`,
-returns the Weave IP address. This is required for many cluster-aware
+returns the Weave Net IP address. This is required for many cluster-aware
 applications to work.
 - unqualified names get resolved via DNS, for example typically via weavedns
-to Weave IP addresses. This is required so that in a typical setup
+to Weave Net IP addresses. This is required so that in a typical setup
 one can simply "ping <container-name>", i.e. without having to
 specify a `.weave.local` suffix.

@@ -1,5 +1,5 @@
 ---
-title: Setting Up The Weave Docker API Proxy
+title: Setting Up The Weave Net Docker API Proxy
 layout: default
 ---

@@ -11,7 +11,7 @@ or the [remote API](https://docs.docker.com/reference/api/docker_remote_api/),
 instead of `weave run`.

 
-###Setting Up The Weave Docker API Proxy
+###Setting Up The Weave Net Docker API Proxy

 The proxy sits between the Docker client (command line or API) and the
 Docker daemon, and intercepts the communication between the two. You can
@@ -44,7 +44,7 @@ remote docker daemon, then any firewalls inbetween need to be
 configured to permit access to the proxy port.

 All docker commands can be run via the proxy, so it is safe to adjust
-your `DOCKER_HOST` to point at the proxy. Weave provides a convenient
+your `DOCKER_HOST` to point at the proxy. Weave Net provides a convenient
 command for this:

    host1$ eval $(weave env)
@@ -7,7 +7,7 @@ The command

    weave status

-reports on the current status of various weave components, including
+reports on the current status of various Weave Net components, including
 the proxy, if it is running:

 ````
@@ -4,17 +4,17 @@ layout: default
 ---


-When containers are created via the Weave proxy, their entrypoint is 
+When containers are created via the Weave Net proxy, their entrypoint is 
 modified to wait for the Weave network interface to become
 available. 

-When they are started via the Weave proxy, containers are 
+When they are started via the Weave Net proxy, containers are 
 [automatically assigned IP addresses](/site/ipam/overview-init-ipam.md) and connected to the
 Weave network.  

-###Creating and Starting Containers with the Weave Proxy
+###Creating and Starting Containers with the Weave Net Proxy

-To create and start a container via the Weave proxy run:
+To create and start a container via the Weave Net proxy run:

    host1$ docker run -ti ubuntu

@@ -41,8 +41,8 @@ IPPrefixLen), are still returned when `docker inspect` is run. If you want
 `docker inspect` to return the Weave NetworkSettings instead, then the
 proxy must be launched using the `--rewrite-inspect` flag. 

-This command substitutes the Weave Network settings when the container has a
-Weave IP. If a container has more than one Weave IP, then the inspect call
+This command substitutes the Weave network settings when the container has a
+Weave Net IP. If a container has more than one Weave Net IP, then the inspect call
 only includes one of them.

    host1$ weave launch-router && weave launch-proxy --rewrite-inspect
@@ -51,7 +51,7 @@ only includes one of them.
 ###Multicast Traffic and Launching the Weave Proxy

 By default, multicast traffic is routed over the Weave network.
-To turn this off, e.g. because you want to configure your own multicast
+To turn this off, for example, because you want to configure your own multicast
 route, add the `--no-multicast-route` flag to `weave launch-proxy`.


@@ -9,8 +9,8 @@ containers on that host. It learns about hostnames for local containers
 from the proxy and from the `weave run` command.  

 If a hostname is in the `.weave.local` domain, then weavedns records the association of that
-name with the container's Weave IP address(es) in its in-memory
-database, and then broadcasts the association to other Weave peers in the
+name with the container's Weave Net IP address(es) in its in-memory
+database, and then broadcasts the association to other Weave Net peers in the
 cluster.

 When weavedns is queried for a name in the `.weave.local` domain, it
@@ -12,7 +12,7 @@ The command:

    weave status

-reports on the current status of various Weave components, including
+reports on the current status of various Weave Net components, including
 DNS:

 ````