Enhance network peering by exposing only specified Prefixes of peered network

[kasabe28]

Summary

Enhance network peering by exposing only specified Prefixes of peered network. Prefixes is a list of CIDRs that we want only to be exposed to the peered network, if no prefixes are specified no filtering will be done and entire network will be peered.

Basic example

apiVersion: networking.ironcore.dev/v1alpha1
kind: Network
metadata:
  name: my-network-1
  namespace: my-namespace-1
  uid: 2020dcf9-e030-427e-b0fc-4fec2016e73a
spec:
  peerings:
  - name: my-network-peering
    prefixes:
    - 10.10.0.0/24
    - 10.20.0.0/24
    networkRef:
      name: my-network-2
      namespace: my-namespace-2
  incomingPeerings:
  - name: my-network-2
    namespace: my-namespace-2
    uid: 3030dcf9-f031-801b-f0f0-4fec2016e73a
status:
  state: Available
  peerings:
  - name: my-network-peering
    prefixes:
    - 10.30.0.0/24
    - 10.40.0.0/24
    state: Applied
---
apiVersion: networking.ironcore.dev/v1alpha1
kind: Network
metadata:
  name: my-network-2
  namespace: my-namespace-2
  uid: 3030dcf9-f031-801b-f0f0-4fec2016e73a
spec:
  peerings:
  - name: my-network-peering
    prefixes:
    - 10.30.0.0/24
    - 10.40.0.0/24
    networkRef:
      name: my-network-1
      namespace: my-namespace-1
  incomingPeerings:
  - name: my-network-1
    namespace: my-namespace-1
    uid: 2020dcf9-e030-427e-b0fc-4fec2016e73a
status:
  state: Available
  peerings:
  - name: my-network-peering
    prefixes:
    - 10.10.0.0/24
    - 10.20.0.0/24
    state: Applied

[balpert89]

I can remember we have briefly discussed this in one of the alignments. Summarized, the addition would be necessary and is similar to approaches other cloudproviders use (GCP: https://cloud.google.com/vpc/docs/routes?hl=de#peering-subnet-routes Openstack: https://docs.openstack.org/neutron/train/admin/config-address-scopes.html). However, these cloudproviders have a concept of a Subnet which is not available in ironcore.

My suggestion would be to leverage the given Prefix resource to use as a reference which routes should be actually exposed to the peering partner. With this, explicit network implementations can decide how they are announcing hops / endpoints, e.g. ironcore-net adds this explicit CIDR then to its Network resource based on the referenced ironcore Prefix.

As an example, instead of doing this

spec:
  peerings:
  - name: my-network-peering
    prefixes:
    - 10.30.0.0/24
    - 10.40.0.0/24

You would do something along this:

spec:
  peerings:
  - name: my-network-peering
    prefixes:
    - prefixRef:
         name: prefix-name
         namespace: prefix-namespace
         uid: xyz-prefix-uid

[afritzler]

How about using this format:

spec:
  peerings:
  - name: my-network-peering
    prefixes:
       - name: foo-static
          prefix: 10.0.0.0/24
       - name: foo-dynamic
          prefixRef:
              name: foo
status:
  state: Available
  peerings:
  - name: my-network-peering
    prefixes:
    - name: foo-static
       prefix: 10.10.0.0/24
    - name: foo-dynamic:
       prefix: 10.20.0.0/24
    state: Applied