Adding missing references pages to docs navigation

mkdocs.yml

@@ -62,7 +62,9 @@ nav:
           GatewayClass: v1alpha2/api-types/gatewayclass.md
           Gateway: v1alpha2/api-types/gateway.md
           HTTPRoute: v1alpha2/api-types/httproute.md
-      - API specification: v1alpha2/references/spec.md    
+      - API specification: v1alpha2/references/spec.md
+      - Cross Namespace References: v1alpha2/references/cross-namespace-references.md
+      - Policy Attachment: v1alpha2/references/policy-attachment.md
     - Release policy: references/releases.md
   - Contributing:
     - Developer guide: contributing/devguide.md

site-src/v1alpha2/references/cross-namespace-references.md

@@ -34,7 +34,7 @@ we need to enforce a handshake mechanism that requires resources in both
 namespaces to agree to this reference. To accomplish that, a ReferencePolicy
 resource has been introduced.
 
-![Reference Policy](images/referencepolicy.png)
+![Reference Policy](/v1alpha2/references/images/referencepolicy.png)
 
 With this model, Routes are able to directly reference Services in other namespaces.
 These references are only considered valid if a ReferencePolicy in the target

site-src/v1alpha2/references/policy-attachment.md

@@ -28,23 +28,23 @@ Access is granted with RBAC - for example, anyone that has access to create a
 RetryPolicy in a given namespace can attach it to any resource within that
 namespace.
 
-![Simple Ingress Example](/images/policy/ingress-simple.png)
+![Simple Ingress Example](/v1alpha2/references/images/policy/ingress-simple.png)
 
 To build on that example, it’s possible to attach policies to more resources.
 Each policy applies to the referenced resource and everything below it in terms
 of hierarchy. Although this example is likely more complex than many real world
 use cases, it helps demonstrate how policy attachment can work across
 namespaces.
 
-![Complex Ingress Example](/images/policy/ingress-complex.png)
+![Complex Ingress Example](/v1alpha2/references/images/policy/ingress-complex.png)
 
 ## Policy Attachment for Mesh
 Although there is a great deal of overlap between ingress and mesh use cases,
 mesh enables more complex policy attachment scenarios. For example, users may
 want to apply policy to requests from a specific namespace to a backend in
 another namespace.
 
-![Simple Mesh Example](/images/policy/mesh-simple.png)
+![Simple Mesh Example](/v1alpha2/references/images/policy/mesh-simple.png)
 
 Policy attachment can be quite simple with mesh. Policy can be applied to any
 resource in any namespace but it can only apply to requests from the same
@@ -55,7 +55,7 @@ workload to a backend in another namespace. A route can be used to intercept
 these requests and split them between different backends (foo-a and foo-b in
 this case).
 
-![Complex Mesh Example](/images/policy/mesh-complex.png)
+![Complex Mesh Example](/v1alpha2/references/images/policy/mesh-complex.png)
 
 ## Target Reference API
 
@@ -124,7 +124,7 @@ Each policy MAY include default or override values. Overrides enable admins to
 enforce policy from the top down. Defaults enable app owners to provide default
 values from the bottom up for each individual application.
 
-![Policy Hierarchy](/images/policy/hierarchy.png)
+![Policy Hierarchy](/v1alpha2/references/images/policy/hierarchy.png)
 
 To illustrate this, consider 3 resources with the following hierarchy: A
 (highest) > B > C. When attaching the concept of defaults and overrides to that,
@@ -179,7 +179,7 @@ precedence over the default drainTimeout value attached to the Route. At the
 same time, we can see that the default connectionTimeout attached to the Route
 has precedence over the default attached to the Gateway.
 
-![Hierarchical Policy Example](/images/policy/policy-hierarchy.png)
+![Hierarchical Policy Example](/v1alpha2/references/images/policy/policy-hierarchy.png)
 
 #### Attaching Policy to GatewayClass
 GatewayClass may be the trickiest resource to attach policy to. Policy