New approach to peer config

[henderiw]

Make peer config independent of the network instance as it might be that the peer is not configured on the NF.
In this proposal the peerconfig is a list of peers:

• the name represent the name of the peer
• the labels can be used as metadata for additional information on the peer, like NF, location, etc
• The network Instance is still there if this information is relevant for the peer.

[gvbalaji]

/approve

[nephio-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: gvbalaji, henderiw

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [henderiw]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[henderiw]

@s3wong could you have a look at this?

[s3wong]

@henderiw

@s3wong could you have a look at this?

I still have question on how do we get to the N3 IP address from SMF controller?

So SMF controller is supposed to get a list of PeerConfig --- each of them representing a UPF?

And the attachment is N4, so the Peers[i].IPv4 will contain to N4 IP address

How do we get to the N3 on this peer UPF? I noticed you added Labels and NetworkInstance, not sure if either is useful. What is your plan on how we (operator team) can use these fields?

[henderiw]

@s3wong
So the way this is supposed to work is this.

Lets assume we have 2 upf(s) : 1 on edge1 and 1 on edge2.

The smf package is augmented with the UPF with the additional IPAllocation objects:

• important is the query annotation

UPF-edge1: this info should be available in the topology + fanout -> sites info you get from topology, network-instance from top and kind you could get from interface (I can provide the logic for that as this is also used in if-fn).

IPAllocation query for UPF on edge1

apiVersion: ipam.alloc.nephio.org/v1alpha1
kind: IPAllocation
metadata:
name: n3
annotations:
specializer.nephio.org/query: true
spec:
kind: network
selector:
matchLabels:
nephio.org/site: edge1
networkInstance:
name: vpc-ran

apiVersion: ipam.alloc.nephio.org/v1alpha1
kind: IPAllocation
metadata:
name: n4
annotations:
specializer.nephio.org/query: true
spec:
kind: network
selector:
matchLabels:
nephio.org/site: edge1
networkInstance:
name: vpc-internal

Same for UPF on edge2
IPAllocation query for UPF on edge1

apiVersion: ipam.alloc.nephio.org/v1alpha1
kind: IPAllocation
metadata:
name: n3
annotations:
specializer.nephio.org/query: true
spec:
kind: network
selector:
matchLabels:
nephio.org/site: edge2
networkInstance:
name: vpc-ran

apiVersion: ipam.alloc.nephio.org/v1alpha1
kind: IPAllocation
metadata:
name: n4
annotations:
specializer.nephio.org/query: true
spec:
kind: network
selector:
matchLabels:
nephio.org/site: edge2
networkInstance:
name: vpc-internal

During specialization we use this information to resolve the IP(s) that were allocated to these UPFs.

The nf-deploy function add this information in the SMFdeployment.

peers:

• name: n3
  labels:
  nephio.org/site: edge1
  network-instance:
  name: vpc-ran
  ipv4:
  address: 10.1.0.3/24
  gateway: 10.1.0.1
• name: n4
  labels:
  nephio.org/site: edge1
  network-instance:
  name: vpc-internal
  ipv4:
  address: 10.2.0.3/24
  gateway: 10.2.0.1
• name: n3
  labels:
  nephio.org/site: edge2
  network-instance:
  name: vpc-ran
  ipv4:
  address: 10.1.1.3/24
  gateway: 10.1.1.1
• name: n4
  labels:
  nephio.org/site: edge2
  network-instance:
  name: vpc-internal
  ipv4:
  address: 10.2.1.3/24
  gateway: 10.2.1.1

[vireshnavalli]

@s3wong @tliron could you please check if this is OK to be merged so that I can use it for SMF CRDs generation
cc// @henderiw

[s3wong]

To understand the (free5gc) SMF config for this, the layout is:

---

  userplaneInformation: # list of userplane information
    upNodes: # information of userplane node (AN or UPF)
      UPF:  # the name of the node
        type: UPF # the type of the node (AN or UPF)
        nodeID: 10.100.50.241 # the IP/FQDN of N4 interface on this UPF (PFCP).  <---- N4 IP for UPF
       interfaces: # Interface list for this UPF
              - interfaceType: N3 # the type of the interface (N3 or N9).   
                endpoints: # the IP address of this N3/N9 interface on this UPF
                  - 10.100.50.233                                                       <---- N3 IP for UPF

---

So, logically, we group by peer NF, and identify the connected point (N4 IP on the connected UPF in this case), and N3 and N9 IP addresses under that one UPF.

Even ignoring free5gc's needs, the structure of "peer" is the peer NF connected, or even pointed to via "n4", but SMF has NO "n3", "n9"...etc, and the logical structure should be "name of my neighbor NF", then "the IP we are connected", and "all the other interfaces and IPs on this peer". This is much more structural than what is proposed here. If the SMF is connected to a bunch of UPFs, and all of them reports "n3", then on the operator side we are extracting all the "n3"s first and THEN internally grouping them under a peer? This seems to make parsing a lot more convoluted.

Package specialization modules get topology information from NFTopology, and NFTopology also starts from NFInstance before browsing through the attachments... so I am not sure this way to organize peers would help even at that level.

[henderiw]

in specialisation we do not get topology, since a package it per NF. What we agreed is we get a request for an IP. So what is proposed here is a list with the info. The receiving end just have to go through it to provide the structure. I believe not everyone need this structure and seems specific to the free5gc. I don't want to build just for free5gc.

So here we just need to run through the list and get the info but the structure how you consume it is the job of the receiver