Closed kasabe28 closed 2 months ago
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
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
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