anchor.diff:  properties: {...}
   ```
   
  -Note that the `secondary_db` link has been marked as optional, to indicate that the "web" job will work correctly, even if the operator does not provide a "secondary_db" link. Providing the `secondary_db` link may enable some additional functionality.
  +Note that the `secondary_db` link has been marked as optional, to indicate that the `web` job will work correctly, even if the operator does not provide a `secondary_db` link. Providing the `secondary_db` link may enable some additional functionality.
   
   Here is an example Postgres job that provides a `conn` link of type `db`.
   
  
positive.code: 
  <p class="note">Note: This feature is available with bosh-release v255.5+.</p>
  
  Previously, if network communication was required between jobs, release authors had to add job properties to accept other job's network addresses (e.g. a "db_ips" property). Operators then had to explicitly assign static IPs or DNS names for each instance group and fill out network address properties. Such configuration typically relied on some helper tool like spiff or careful manual configuration. It also led to inconsistent network configuration as different jobs named their properties differently. All of that did not make it easy to automate and operate multiple environments.
  
  Links provide a solution to the above problem by making the Director responsible for the IP management. Release authors get a consistent way of retrieving networking (and topology) configuration, and operators have a way to consistently connect components.
  
  
negative.code: 
  By default, links include network addresses on the producer's default link network. The default link network is a network marked with `default: [gateway]`. A release job can also consume a link over a different network.
  
  For example, this `web` job will receive `data_db`'s network addresses on its `vip` network, instead of receiving network addresses from the `private` network.
  
  ```yaml
  instance_groups:
  