Nephio - Network Architecture - Principles (initial sketch)

[Bernar...@telekom.de]

Hi,

 

I have started to sketch some initial principles/guidelines for the Nephio project (written from a CSP perspective) – if you have the time please have a look and comment.

Any kind of feedback is highly welcome.

 

https://docs.google.com/document/d/1xvuQTAO0n4ggvOaX6s8Y4vxqp_2h8xjB_JJetjlikN0/edit?usp=sharing

 

(Attached you will also find a copy of the document (for those who do not have access to Google drive.)

 

BR Bernard

 

From: 'John Belamaric' via SIG Network Architecture <sig-network-...@nephio.org>
Sent: Montag, 29. August 2022 17:48
To: Eric Debeau <eric....@gmail.com>
Cc: Kaushik Bhandankar <kaush...@google.com>; SIG Network Architecture <sig-network-...@nephio.org>
Subject: Re: [nephio-sig-netarch] Action Items from today's SIG-arch meeting

 

I didn’t see any invitation or video conference info. Hopefully I was not the one that was supposed to send it out. If so, I am sorry about that. 

 

Given this, I think it’s best to reschedule. I can take a look at Wednesday morning and send an invitation. 

 

On Mon, Aug 29, 2022 at 8:16 AM Eric Debeau <eric....@gmail.com> wrote:

Hello

 

Is there a meeting planned today for the core-DNS use-case ?

 

Best Regards

 

Eric

 

On Tue, Aug 23, 2022 at 12:03 AM 'Kaushik Bhandankar' via SIG Network Architecture <sig-network-...@nephio.org> wrote:

Hello team,

 

Please find below the high-level Action Items from today's SIG-arch meeting (these Action Items are also listed in the meeting minutes doc). If there were any AIs that I missed, please update them in this document.

 

Action Items

• [Telcos] Self-nominate yourself on the Wiki for the Chair election. Self-nomination ends Aug 23, 2022 (end-of-day, Pacific time)
• [Community] Document the key Nephio principles and articulate their importance
• [Google] Share the 5GC-based use-cases with the community.
• [Telcos / Google] Self-organize to prioritize the Nephio v1 use-cases, with the objective to scope/minimize the work while ensuring the Nephio principles are applied / validated.

• [Google] Schedule a 30-min session on Aug 29, 2022 9am PT to follow-up on the Core-DNS demo use-case.

• Prerequisite to participants: Please read up Nephio Simple Scenario [Public] and listen to the Video recording

 

Thank you!

Kaushik

 

 

PS: We are moving to the Linux Foundation data-sharing tools as we speak.

 

 

--
You received this message because you are subscribed to the Google Groups "SIG Network Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-network-archit...@nephio.org.
To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/CAOAguQmh4vPygBi6hf8w6HAPOppmZCn8p8BV4wUs_DeMBxeaHw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "SIG Network Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-network-archit...@nephio.org.
To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/CAHwh%2BPOF9yL0Gm%3DjumcMJdW6E4KKNN%2Bb5krzm0XxayVRV8qDtQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "SIG Network Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-network-archit...@nephio.org.
To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/CAC_RkjyZ8X3uAq1zW487uFz9Xd1JXeDsMmxW-6KEgEe528bQLw%40mail.gmail.com.

[Tom Nolle (Public)]

Hi, Bernard, and thanks for taking the time to put this together!  Your summary of principles raises a question for me based on my interaction with operators over the last decade.  That question relates to the relationship between network functions Nephio deploys and legacy network infrastructure like rotuers, switches, and appliances.

Nephio is clearly capable of lifecycle management for hosted elements of a service, which would mean either elements that were connected to a legacy network (as CPE, for example) or elements that made up a complete collection of features that could be considered "connected".  What is less clear is how Nephio would play in the lifecycle management of a hybrid infrastructure made up of a mixture of hosted elements and legacy elements.

It would seem to me that there are three models that might apply:

1. Nephio sees the legacy elements of the network as its own "virtual network" infrastructure, which it is aware of and relies upon but which is independently configured and managed.
2. Nephio has some means of managing the the legacy elements, perhaps through a set of APIs.
3. Nephio and the legacy elements are part of a lifecycle management framework that lives above Nephio and is aware of and in control of all the elements, legacy and hosted.

My question is what CSPs like yourself would see as the value ranking of these models, and what issues you might see with each.

Thanks in advance,

Tom Nolle, CIMI Corp.

To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/FR0P281MB21237983E737E95CBD8A61CBE9769%40FR0P281MB2123.DEUP281.PROD.OUTLOOK.COM.

[Bernar...@telekom.de]

Hi Tom,

 

that is an excellent question but I unfortunately do not have a simple answer. So here are a couple of thoughts in that direction:

 

• Ideal World: in an ideal world every resource/service be it a CNF or a physical appliance would be easily integrable and manageable by the same procedures and mechanisms (the tools in order to achieve that would differ but basically from a CSP point would allow to install, configure, activate, deactivate and determine the status of each resource/service – implying a similar lifecycle-state-transition model) – here we believe that the model-based closed-loop lifecycle automation approach of k8s is best practice. If the management tools would make use of the same technologies (e.g. k8s operators) even better. Only thing which we would need to consider is how to address dependency management between different resources/services, i.e. how to propagate changes along dependent solution elements. For that purpose we would like to categorize dependencies and establish common policies for reacting on change events.
• Real World: CSPs and solution providers have invested in a lot of legacy solution elements and will not be able to phase out these elements in a short time frame. We will have to live in a mixed world with different management approaches e.g. ETSI Mano, k8s CRDs, … .We have decided to separate the legacy & VNF world from the CNF world in order to be able to later more easily decouple the different management approaches. Nevertheless dependencies exist between these worlds and are currently accounted for either by design of static decoupled solution architectures or semi-automated/automated orchestration processes on-top.
• Nephio vs. k8s operators:  with k8s operators I would imagine we could potentially do anything, but that alone would not simplify the lives of CSPs because we would still have the integration problem for the management solutions. The main reason why we are participating in Nephio is because we hope we can establish a common understanding of how these management systems should work and interact in the future

 

So coming back to your question:

 

• Case 1 sounds to me a bit like ideal world
• Case 2 is what we already have now as soon as a vendor decides to package a management system as a k8s operator
• Case 3 sound to me like a current real world setup

 

In general we believe that even in an ideal world we will need a service orchestrator on top of Nephio to address complex service related dependencies and constraints e.g. traffic migration, complex upgrades, …

 

Sorry for the long answer but I hope it gives a first impression which direction we are aiming for.

 

BR Bernard

[Tom Nolle (Public)]

Thank you, Bernard.  I agree it's not an easy question to answer, and I agree in particular with your comment about the need to somehow preserve current management systems for current infrastructure.  Given that, I wonder whether there is value or complexity (your choice 😁) associated with the fact that the general model of VNF deployment in play today manages the deployment and configuration of a VNF through one model (Nephio, I think, is such an approach) but the functional behavior through the EMS that would have managed the PNF from which the VNF was derived.  The value is that it preserves legacy EMS/NMS/SMS structures at the service function level, and the complexity is that the same software element is really living in two different management worlds.

Tom

[Tal Liron]

For what it's worth, I think it is possible to unify management under Kubernetes, even for so-called "legacy" environments. The idea is that PNFs and non-Kubernetes VNFs will get a representation as a custom resource in Kubernetes, which contains IDs and connectivity details. At the end of the day, what does it matter if the workload is a local Pod+Service or an external device? And since much of the existing management software (S-VNFMs) can run on Kubernetes (even if it's not particularly cloud-native), it could just run on what we've been calling the "management cluster" in Nephio (see my Bifurcated Orchestration presentation). So, it's not that we've moved everything to Kubernetes, just that we've consolidated the management plane somewhat.

This is not always a good idea because it means further investment in integrating systems that already work and perhaps are best left to continue working as they are. It might make better sense to spend capital in overhauling those systems instead of integrating them. All I mean to say here is that unification is technically viable, and there have indeed been many PoCs of this from various players.

To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/FR0P281MB21233923FCC5BB45CFE41F41E9769%40FR0P281MB2123.DEUP281.PROD.OUTLOOK.COM.

[Tom Nolle (Public)]

That could be interesting for two reasons.  First, it could allow us to optimize deployment decisions where both legacy service components and hosted service components (and their infrastructures) were factors in meeting an SLA.  Second, if we had a failure of a service component of either type, the optimum recovery configuration might involve reconfiguring legacy elements and moving/scaling hosted elements in a different topology.  That would likely be easier if one system understood the service structure/topology overall.

Tom

[Wim Henderickx]

I agree with Tal that we could manage and integrate legacy infrastructure under K8s. Now there is a lifecycle cost we need to consider:

 

If you look at an operator it is a declarative/intent way of operating a system/element/etc. It does not matter if it is a CNF/VNF/PNF (Let’s call it xNF). Now, to do so you want to have a set of capabilities in the xNF that make this easier to maintain such operator and automate its lifecycle.

If we do this right, we can auto-generate these operators and have them available the day the xNF release comes out.

 

Now the scope of Nephio in my view is to come up with an architecture to consume these xNF/its operators in harmony with the infrastructure.

 

For those interested here is a talk I did on this.

https://www.youtube.com/watch?v=d7t3rmTYHX4&t=6s

 

Wim

To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/4e3d858c-36e2-928c-efb3-eb1d030b9743%40cimicorp.com.

[Vance Shipley]

On Tue, Aug 30, 2022 at 3:10 AM <Bernar...@telekom.de> wrote: 

Ideal World: in an ideal world every resource/service be it a CNF or a physical appliance would be easily integrable and manageable by the same procedures and mechanisms (the tools in order to achieve that would differ but basically from a CSP point would allow to install, configure, activate, deactivate and determine the status of each resource/service – implying a similar lifecycle-state-transition model)

Yes, this should not be part of our requirements. It's not just about PNF or VNF integration but multi-cloud federation, including different Nephio domains, and E2E orchestration and assurance.

 

 Only thing which we would need to consider is how to address dependency management between different resources/services, i.e. how to propagate changes along dependent solution elements. For that purpose we would like to categorize dependencies and establish common policies for reacting on change events.

Yes, and this is the important point.  A bag of technology/vendor specific CRDs, which do not cohere, will not change anything.  In SIG NA we should analyze the landscape (TMF, ONF, 3GPP, ETSI, MEF, O-RAN) and develop a coherence model which makes the Ideal World achievable.

I often get negative reactions, with arguments about "legacy" and "declarative", however I see no reason we can not make Objects in Nepio manageable without compromising the principles of Intent. The landscape was developed by stakeholders with varied concerns and we should not assume those are made redundant by new technology. Some are of course, and we should look to ETSI Zero Touch network and Service Management (ZSM) and 3GPP's Service Based Management Architecture (SBMA) for their current  best practice.  What is legacy is static hierarchical EMS/DMS/NMS, with opaque proprietary (vendor) domains. In  SBMA Management Services (MnS) are exposed and consumed by Management Functions (MnF) directly, with MnS-MnF relationships dynamically instantiated. Trust issues aside, Objects should be openly manageable in a manner which is consistent with the requirements of E2E orchestration and assurance.

 

--

Vance Shipley

CEO, SigScale

[Vance Shipley]

On Tue, Aug 30, 2022 at 12:35 PM Vance Shipley <van...@sigscale.com> wrote:

Yes, this should not be part of our requirements.

Oops! That was an edit error.  "should be part of our requirements".

[Tal Liron]

On Mon, Aug 29, 2022 at 11:38 PM Vance Shipley <van...@sigscale.com> wrote:

On Tue, Aug 30, 2022 at 12:35 PM Vance Shipley <van...@sigscale.com> wrote:

Yes, this should not be part of our requirements.

Oops! That was an edit error.  "should be part of our requirements".

LOL, that does change everything. :)

It's good to see some of us here agreeing about this direction, i.e. using Kubernetes to manage "external" devices. I call these "representational operators", because they work on representations of devices rather than on the devices themselves.

Small addendum -- DPUs and GPUs and smart NICs might be productively treated in the same way as these "external" devices (even as entire PNFs in some cases!). Yes, they are on the host, but they behave in many ways (management) as if they were independent.

I think we can work on this in parallel in Nephio. SIG Architecture can conceptualize a design through collaborative iteration. Meanwhile, SIG Machinery can develop PoCs to see just how feasible the idea is and how far we can take it. Yes, I know some of us have built similar things internally, and that experience will help, but we need something the community can see together, using open source. I can refer you back to Jose Nunez's presentation in which he showed that an end-to-end RAN solution can be created using open source components and off-the-shelf(-ish) hardware devices. If we can manage the whole narrative on K8s (Day 1, Day 2), well, that would be an impressive PoC.

[Bernard Tsai]

I believe the existing DNS use-case partially already addresses the Software Lifecycle Management principle.

My question would be: are there any ideas floating around which would detail how Nephio use-cases could demonstrate the other principles mentioned in the document?
In addition: would it be useful to write down corresponding CSP use cases / journeys for that purpose?

[John Belamaric]

Great discussion, everyone. I agree with the use of K8s to manage legacy things as well. It sounds like we're pretty well aligned on the idea of using KRM / K8s API server as the source of truth for intent, and then realizing that via other actuation mechanisms. I haven't had a chance to watch last week's call yet but hope to tomorrow; I'll try to watch Wim's video above too. Unfortunately I won't get to it before tomorrow's meeting.

Bernard, I added a few comments in your doc, thanks for getting this going. And yes, more use cases and journeys are very very helpful. 

--

You received this message because you are subscribed to the Google Groups "SIG Network Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-network-archit...@nephio.org.

To view this discussion on the web visit https://groups.google.com/a/nephio.org/d/msgid/sig-network-architecture/2d40d934-1cb6-41cf-bb7b-e72439dc5d66n%40nephio.org.