Networking use cases and user stories

[taylor]

What are some networking use cases which can be used for context and assessment?

As part of any proposed best practices it is requested to provide 1 or more use cases showing where the best practice could be used.

Goal:

• Relating best practices to real world use cases.
• Discussion of core features and functionality from use cases and their NFs.
• Examination of existing use cases to discussion of kubenative implementations which provide the core features and functionality.

When adding a use case to the list please provide some context on the following attributes/properties if known:

• Complexity: simple to very complex
• Domain: telco specific, mobile core, mobile edge
• Open source example(s): list if available
• What OSI layer(s)?
• Common/standard protocols used: eg. DOCSIS, GRPC, SNMP
• Proprietary protocols used?
• Links to external material on the use case, including presentation, code, etc.

Please feel free to add any other context with the use case that helps with a better shared understanding.

[taylor]

Bump in the wire / transparent firewall. No IP address on data/user plane. In-line filtering

• Complexity: simple
• Domain: general networking, security

---

suggested by @fkautz

[iawells]

Worth noting the distinctive bits:

• per-packet handling of traffic
• 'leave my addressing alone' - only needs a unique MAC
• interfaces to the CNF: 'in', 'out', something for management
• No obvious persistent storage requirements
• May require hardware LB for scale, and if it's unaddressed L2 that LB is not straightforward

[taylor]

Something using a BGP Speaker

Refs:

• https://osrg.github.io/gobgp/ - https://github.com/osrg/gobgp
• https://github.com/cloudnativelabs/kube-router
• https://github.com/cloudnativelabs/kube-router/blob/master/docs/bgp.md

---

suggested by @iawells

[taylor]

VoWifi with ePDG

Subset of evolved mobile core

[iawells]

So this is a good diagram but it's hard to see the implications here because the architecture choices determine certain things. The behaviour of certain components that can be in the cloud can be determined, but not the implications of the whole system.

• Which of these components virtualise?
• How many VRFs are there?
• How do these components locate each other? (There's probably more than one way for them to do that). Does location need assistance? Today it would be done by top-down orchestration of config, that's a well tolerated model.
• In general, we would configure things like SGWs with their addresses and routes (think routers - you tell them their address, they don't get them from the environment like more conventional workloads do). Is that the right thing to do? Is that something we might want to do, but only in some circumstances? Would a CNF go to the platform for that help, or a management service? (We don't need to build or architect the service, only describe the interface to it, to make this possible.) Again, this is typically a top-down problem today.

[iawells]

VoWiFI, and other 3GPP-akin standards, are going to have a lot of (perhaps optional) aspects to attack like 'how do I find this CNF running somewhere else', but others would be really low level like 'how do I ensure I'm using redundant uplinks from this pod' that many actual use cases would want to consume, and there's a middle ground of 'here is one CNF and its generalised requirements'. Not quite sure how we want to attack that.

[sronanrh]

Virtual CU / Virtual DU

Domain: Telco RAN

[rmerz]

I can think a "simple" UPF local-breakout scenario.

I need a bit of guidance for enhancing it

• Complexity: probably complex
• Domain: mobile edge e.g. one UPF running Kubernetes
• Open source example(s): please help me out here
• What OSI layer(s)? from link to transport
• Common/standard protocols used: definitely 3GPP protocol (how much to go into detail here)?
• Proprietary protocols used? n/a
• Links to external material on the use case, including presentation, code, etc: n/a

[taylor]

Recommendation: CNF services work as expected after being rescheduled to a new node