├── CONTRIBUTING.md ├── LICENSE ├── README.md ├── adjacent-communities.md └── whitepaper ├── CNCF _TUG_Cloud Native Thinking for Telecommunications.pdf ├── cloud_native_thinking_for_telecommunications.md └── readme.md /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | ## Table of Contents 4 | * [Issues](#issues) 5 | * [Pull Requests](#prs) 6 | * [Pull Requests Approval Process](#approvals) 7 | * [Idle Pull Requests Policy](#idle) 8 | * [Unresolved Pull Requests Policy](#unresolved) 9 | 10 | 11 | 12 | ### Issues 13 | 14 | - **Anyone** can create an issue here: [TUG Issues](https://github.com/cncf/telecom-user-group/issues) 15 | - Issues can include bugs to be fixed or topics to be agreed 16 | - The document owners can label issues and assign them to other contributors, or to return it to the originator for more information 17 | - All issues must be clearly titled and described 18 | 19 | 22 | 23 | 24 | ### Pull Requests 25 | 26 | - *Anyone* can create a Pull Request (PR) here: [TUG Pull Requests](https://github.com/cncf/telecom-user-group/pulls) 27 | > Note, using one of the [GitHub keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) will automatically close the issue which the PR is resolving when it is merged 28 | - A PR *should* be modified be just one person unless permission is given to other contributors by the original PR author 29 | - A PR *should* only create/modify content within the scope of a single document 30 | - A PR *should* only add/change content related to the issue associated with the PR 31 | - Comments/Conversations within a PR may only be marked Resolved by: 32 | - The originator of the sub-conversation, or 33 | - The overall document or repository owner, or 34 | - An automated timeout of 48hrs when there has been no additional comments after an update is posted to resolve the sub-thread 35 | - **The person responding to a sub-conversation shall not mark it as Resolved** 36 | - All changes to existing PRs *shall* be made through subsequent commits 37 | - **Do not modify an existing commit, create separate commits under the same PR** 38 | - PRs will be merged using "Squash and Merge" to enforce a linear commit history 39 | - Break up changes into smaller chunks when possible so the PR review and acceptance is likely to occur sooner 40 | - If you think there is unlikely to be consensus on a point then feel free to create an issue to discuss further 41 | - If an existing PR is blocked because a change can't come to consensus open an issue to continue the discussion and see if the other parts of the PR can be accepted. 42 | - If you want to brainstorm / spec out and idea create an issue 43 | - If there is an existing issue when a PR is created then reference the issue 44 | 45 | For those familiar with Git: 46 | - Create a local fork 47 | - Commit your changes to your local fork 48 | - When ready, create a PR to merge those change to the `telecom-user-group/master` branch, following the guidelines above 49 | 50 | For those new to Git: 51 | - Browse to the document you wish to modify 52 | - Click edit pencil 53 | - Modify the document in the browser 54 | - When ready, use one of the [GitHub keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) to reference the Issue you are resolving in the "Add an optional extended description..." box 55 | - Click "Propose file change" 56 | - This will create a PR from a local fork back to the `telecom-user-group/master` branch 57 | 58 | 59 | 60 | ### Pull Requests Approval Process 61 | 62 | - Once a PR is created, it needs to get the following approvals before it is merged into master 63 | - Active contributors to that document 64 | - Document / repository owners 65 | - 2 business days cool off period should be applied before Final approval 66 | - Final Approval by an Editor (e.g. @ASalkever) 67 | - Only one approval will be counted per each organization for a given PR 68 | - The selection of which contributor to approve a PR is made by the document owner and should take those factors into consideration: 69 | - Contributor needs to be actively discussing the PR to be selected for approval 70 | - PRs will be merged automatically online by an Editor (e.g. @ASalkever) once consensus is reached and all approvals are receive 71 | 72 | 73 | ### Idle Pull Requests Policy 74 | 75 | Pull Requests will be automatically labelled as "**Idle**" when: 76 | - No engagement/activity (content, reviews, conversations) from author, reviewers and other contributors on non-merge ready PRs for 7 calendar days 77 | - Personal holidays or public holidays will not be counted 78 | - One or more identified Reviewers are not providing feedback/resolutions or approving the Pull Request for more than 7 calendar days 79 | 80 | Any Pull Requests that are labeled as "Idle" will be discussed during TUG meetings to take a decision on, such as: 81 | - Close the PR and label it as "**Returned**". 82 | - "**Force**" Merging of the PR without having full reviewers approvals due to their inactivity. 83 | 84 | 85 | ### Unresolved Pull Requests Policy 86 | 87 | Pull Requests will be labelled as "**Unresolved**" when no consensus is reached during approval process. 88 | 89 | Any Pull Requests that are labeled as "**Unresolved**" will be discussed during TUG meetings to take a decision on it by: 90 | - Finding Common Grounds to come to consensus 91 | - Follow Governance Procedures to get consensus via voting mechanisms 92 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Telecom User Group 2 | 📞📱☎️Public info for the CNCF Telecom User Group 3 | 4 | _Note:_
5 | Activities have moved to the [CNF Certification Program](https://github.com/cncf/cnf-certification/#cnf-certification---v11-beta), [CNF Working Group (WG)](https://github.com/cncf/cnf-wg#cloud-native-network-function-working-group-cnf-wg) and [CNF Test Suite](https://github.com/cncf/cnf-testsuite#cnf-test-suite). The CNF WG is focused on documenting use cases, user stories, and best practices. The CNF Test Suite provides a framework and a suite of tests for validating best practices of workloads running on K8s. 6 | 7 | ## Meeting Time 8 | 9 | Meetings are currently in hiatus. Please see the [CNF WG](https://github.com/cncf/cnf-wg#cloud-native-network-function-working-group-cnf-wg) and [CNF Test Suite](https://github.com/cncf/cnf-testsuite#cnf-test-suite) for active CNCF telecom meetings. 10 | 11 | 30 | 31 | ## Meeting Minutes 32 | Upcoming and past meeting agenda/notes are [available](https://docs.google.com/document/d/1yhtI7aiwpdAiRBKyUX6mOJDHAbjOog2mI4Ur2k27D7s/edit#) 33 | 34 | ## Recordings 35 | TUG meeting recordings are available on [CNCF's YouTube Channel](https://www.youtube.com/playlist?list=PLj6h78yzYM2MHITsQll62n8gj8mtxXbTq) 36 | 37 | ## Mailing list 38 | [Request to join](https://lists.cncf.io/g/telecom-user-group/join) - note that work email addresses are required. 39 | 40 | ## Slack 41 | [https://slack.cncf.io/](https://slack.cncf.io/) - #tug 42 | 43 | ## Upcoming Events: 44 | - TBA 45 | 46 | 47 | ## Past Events: 48 | ### [TUG + CNFs At KubeCon + CloudNativeCon NA 2021 Virtual/Los Angeles](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) 49 | 50 | [Intro & Deep Dive to the CNF WG](https://kccncna2021.sched.com/event/lV9e) 51 | * Friday, October 15 • 5:25pm - 6:00pm PDT 52 | 53 | 54 | ### [TUG + CNFs At Open Networking and Edge Summit NA 2021 Virtual](https://events.linuxfoundation.org/open-networking-edge-summit-north-america/program/schedule/) 55 | 56 | [CNF WG BoF: Bring Your Networking Challenge, We’ll Find a Cloud Native Best Practice](https://sched.co/og1s) 57 | * Tuesday, October 12 • 12:00pm - 12:30pm PDT 58 | 59 | 60 | ### [TUG + CNFs At KubeCon + CloudNativeCon EU 2021 Virtual](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) 61 | 62 | [CNF WG: K8s Best Practices for Telco Apps](https://sched.co/iE74) 63 | - Thursday, May 6 at 11:30 - 12:05 UTC 64 | - [Recording](https://youtu.be/ZF5UJD7YJIw) 65 | 66 | 67 | ### [TUG + CNFs At KubeCon + CloudNativeCon NA 2020](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) 68 | 69 | [Intro to CNCF’s Telecom Initiatives](https://sched.co/ekG9) 70 | - Wednesday, November 18 at 4:55pm - 5:30pm EST 71 | - [Recording](https://youtu.be/IEmzRqqNWCs) 72 | 73 | 74 | ### [TUG + CNFs At Open Networking & Edge Summit NA 2020](https://events.linuxfoundation.org/open-networking-edge-summit-north-america/) 75 | 76 | Monday, September 28 • 18:00 - 21:00 UTC - [Tutorial: Cloud Native for Edge and Service Providers - Sponsored by Cloud Native Computing Foundation (Pre-registration Required)](https://sched.co/bWhI) 77 | 78 | Wednesday, September 30 • 17:45 - 18:15 UTC - [Birds of a Feather: CNCF Telecom User Group](https://sched.co/bWQV) 79 | 80 | Wednesday, September 30 • 17:45 - 18:15 UTC - [Panel Discussion: Cloud Native Thinking for Telecommunications Chapter 1](https://sched.co/bWQh) 81 | 82 | ### [TUG + CNFs At KubeCon + CloudNativeCon EU 2020](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2020/) 83 | 84 | Wednesday, August 19 • 14:55 - 15:30 UTC - [Birds of a Feather: Telecom User Group](https://sched.co/Zevr) 85 | 86 | ### [TUG + CNFs At Cloud Native + Open Source Virtual Summit China 2020](https://cncf.lfasiallc.cn/) 87 | 88 | Saturday, August 1 • 12:10 - 12:40 UTC - [Intro: Birds of a Feather: Telecom User Group](https://sched.co/cpAM) 89 | 90 | ### [CNTT April 2020 Virtual Technical Event](https://wiki.lfnetworking.org/display/LN/2020+April+Virtual+Technical+Event) 91 | 92 | LFN Technical Meetings Spring 2020, April 21-23 93 | 94 | ### TUG + CNFs At KubeCon + CloudNativeCon NA 2019 95 | 96 | Monday, November 18 • 4:30pm - 6:30pm - [CNCF TUG & CNTT: Part 1](https://wiki.lfnetworking.org/display/LN/CNTT+-+CNCF+TUG+F2F+workshop+in+KubeCon+NA+2019#CNTT-CNCFTUGF2FworkshopinKubeConNA2019-Brainstormingagendaitems) 97 | - Location: Meeting room 17B, Mezzanine level, San Diego Convention Center 98 | - Details: AV in the room, set theater, capacity 100 99 | - [Agenda](https://wiki.lfnetworking.org/display/LN/CNTT+-+CNCF+TUG+F2F+workshop+in+KubeCon+NA+2019#CNTT-CNCFTUGF2FworkshopinKubeConNA2019-Brainstormingagendaitems) 100 | - [RSVP, space is limited](https://forms.gle/VahVc9WVPNGMdk9p9) 101 | 102 | Wednesday, November 20 • 3:20pm - 3:55pm - [Birds of a Feather: Telecom User Group - Cheryl Hung, Dan Kohn, Cloud Native Computing Foundation; & Taylor Carpenter, Vulk Coop](https://sched.co/Uakt) 103 | 104 | Wednesday, November 20 • 4pm - 6pm - [CNCF TUG & CNTT: Part 2](https://wiki.lfnetworking.org/display/LN/CNTT+-+CNCF+TUG+F2F+workshop+in+KubeCon+NA+2019#CNTT-CNCFTUGF2FworkshopinKubeConNA2019-Brainstormingagendaitems) 105 | - Location: Meeting room 2, Upper level, SDCC 106 | - Details: AV in the room, set round tables, capacity 160 107 | - [Agenda](https://wiki.lfnetworking.org/display/LN/CNTT+-+CNCF+TUG+F2F+workshop+in+KubeCon+NA+2019#CNTT-CNCFTUGF2FworkshopinKubeConNA2019-Brainstormingagendaitems) 108 | - [RSVP, space is limited](https://forms.gle/VahVc9WVPNGMdk9p9) 109 | 110 | Thursday, November 21 • 4:25pm - 5:55pm - [Intro + Deep Dive: Cloud Native Network Function (CNF) Testbed](https://sched.co/UakA) 111 | 112 | ### TUG + CNFs At Open Networking Summit EU 2019 113 | 114 | Monday, September 23 • 08:45 - 10:15 - [Tutorial: Take a Test Drive with the Cloud Native Network Function (CNF) Testbed - Sponsored by Cloud Native Computing Foundation (Pre-registration required)](https://sched.co/ScCA) 115 | 116 | Monday, September 23 • 10:45 - 12:15 - [CNCF Telecom User Group Meeting](https://sched.co/Saoc) 117 | 118 | Wednesday, September 25 • 16:15 - 16:45 - [Panel Discussion: Embracing Cloud Native on the Path to 5G - Heather Kirksey, The Linux Foundation; Rabi Abdel, Vodafone; Lincoln Lavoie, UNH Interoperability Lab; Frederick Kautz, doc.ai; Taylor Carpenter, Vulk Coop](https://sched.co/SYwo) 119 | 120 | ### CNFs At KubeCon + CloudNativeCon China 2019 121 | 122 | Tuesday, June 25 • 11:20 - 11:55am - [Intro + Deep Dive BoF: Telecom User Group and Cloud Native Network Functions (CNF) Testbed - Cheryl Hung, Dan Kohn, CNCF & Taylor Carpenter, Vulk Coop](https://sched.co/OBhN) 123 | 124 | **Kickoff meeting at KubeCon EU on Thursday, May 23 • 11:05am - 12:30pm** - [Intro + Deep Dive BoF: Telecom User Group and Cloud Native Network Functions (CNF) Testbed - Cheryl Hung, Dan Kohn, CNCF & Taylor Carpenter, Vulk Coop](https://sched.co/MSzj) 125 | - [Video](https://www.youtube.com/watch?v=zEIr1mq-81E) 126 | - [Slides](https://docs.google.com/presentation/d/1iAgzRp5eFv7LWmpR2u1Wy0LdhvB85SkKJBxXFSNH8XE/) 127 | 128 | ## Adjacent communities 129 | 130 | CNCF TUG works together with lots of other communities. [This](adjacent-communities.md) page lists these communities and ways how to reach them. 131 | 132 | 133 | ## License 134 | 135 | The content in this repository including documentation is available under the Apache License, Version 2.0. The documentation is alternatively available under the Creative Commons Attribution 4.0 license. 136 | -------------------------------------------------------------------------------- /adjacent-communities.md: -------------------------------------------------------------------------------- 1 | # Adjacent Communities 2 | 3 | This page collects the communities working together with the CNCF TUG. 4 | 5 | ## Common NFVI Telco Task Force (CNTT) 6 | 7 | The main motivation of CNTT is to reduce the time and cost for VNF Certifications. The current bottleneck is that there is no limit on the number of VIM/NFVIs on which the VNF certifications to be performed and the base VIM services. This needs a standardization of VIM/NFVI. 8 | 9 | CNTT was started by telecom operators and they are engaged for the standardization. Vendors are also participating. The result standardized VIM/NFVI still should be able to serve as a basis for telco workloads. 10 | 11 | - [Homepage](https://github.com/cntt-n/CNTT) 12 | - [List of online meetings](https://github.com/cntt-n/CNTT/wiki/Meetings) 13 | - [Mailing lists](https://github.com/cntt-n/CNTT/wiki/Mailing-Lists) 14 | - Next face to face meetings 15 | - CNTT Technical F2F Work Shop 16 | - Dates not known yet 17 | - Los Angeles CA 18 | - [Details](https://wiki.lfnetworking.org/display/LN/CNTT+Technical+F2F+Work+Shop%2C+Los+Angeles+CA) 19 | 20 | -------------------------------------------------------------------------------- /whitepaper/CNCF _TUG_Cloud Native Thinking for Telecommunications.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cncf/telecom-user-group/288cf52cc714c65ac9a0b36f83ecd4710f3b9002/whitepaper/CNCF _TUG_Cloud Native Thinking for Telecommunications.pdf -------------------------------------------------------------------------------- /whitepaper/cloud_native_thinking_for_telecommunications.md: -------------------------------------------------------------------------------- 1 | # Cloud Native Thinking for Telecommunications 2 | 3 | Basic tenets and end users' suggestions on how cloud native design and principles can be applied to mission critical telecommunications functions. 4 | 5 | ## Table of Contents 6 | * [1.1 Introduction](#1.1) 7 | * [1.2 What is Cloud Native?](#1.2) 8 | * [1.3 Defining Cloud Native Systems](#1.3) 9 | * [1.3.1 What "loosely coupled" means in cloud native systems](#1.3.1) 10 | * [1.3.2 Cloud native applications require orchestration](#1.3.2) 11 | * [1.3.3 Infrastructure, Deployment and Configuration of Cloud Native Systems](#1.3.3) 12 | * [1.4 Cloud Native Network Functions](#1.4) 13 | * [1.5 Cloud Native for Telcos](#1.5) 14 | * [1.5.1 A Brief History of Virtualisation for Telcos](#1.5.1) 15 | * [1.5.2 Software Defined Networking And The Emergence of VNFs](#1.5.2) 16 | * [1.5.3 Principles for Cloud Native Telco Infrastructure and Applications](#1.5.3) 17 | * [1.5.4 Evolving the Stack From VNFs to CNFs](#1.5.4) 18 | * [1.6 Cloud Native for Telcos in Practice](#1.6) 19 | * [1.7 Conclusion](#1.7) 20 | 21 | 22 | ## 1.1 Introduction 23 | 24 | Enterprises, governments, and other organizations are rapidly adopting cloud native technologies to build infrastructure and run workloads that are more resilient, higher performance, and more economical. As cloud native is becoming the de facto choice for enterprise and IT, the telecommunications industry will also benefit from deploying cloud native architectures to its platforms, networks, and telephony applications. 25 | 26 | This journey to cloud native telecom environments has already begun. In fact, if you use voicemail on a wireless network powered by Bell Canada, your message queue is officially cloud native. In 2019, Bell Canada ported its voicemail network functions over to a container-based architecture running on top of a Kubernetes orchestration layer alongside its production instance of the ONAP architecture. Voicemail is one of a number of functions that Bell Canada has or will be migrating to Cloud Native Network Functions (CNFs). “The main driver behind cloud native for Bell Canada is service availability, namely, how can we leverage cloud native principles to make sure our services are more agile, more flexible, and more resilient?,” explains Daniel Bernier, a Senior Technical Architect at Bell Canada and a member of Cloud Native Computing Foundation’s (CNCF) Telecom User Group (TUG). 27 | 28 | Telecommunications companies provide some of the most critical services in the world. From emergency 911 services to air traffic control to buy-sell signals that move billions of dollars worth of bonds, telecommunications networks impact our safety, social stability, and economic prosperity. Because the stakes are so high, telecommunications infrastructure has been designed, maintained, and upgraded to minimize risks and maximize reliability and uptime. 29 | 30 | Operators like Bell Canada intend to move more of their functionality to cloud native architectures as the telecommunications community further evolves standards and practices around deployment of mission critical applications and services over CNFs. The goal of this whitepaper is to help companies like telecom operators, as well as enterprises running internal telecommunications-like infrastructure, to better understand what cloud native means for telcos and help build consensus around industry adoption of cloud native technologies. 31 | 32 | 33 | ## 1.2 What is Cloud Native? 34 | 35 | After a collaborative discussion, the CNCF published the following [definition](../../../../toc/blob/master/DEFINITION.md) of cloud native: 36 | 37 | “Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.” 38 | 39 | 40 | ## 1.3 Defining Cloud Native Systems 41 | 42 | There are some additional key principles to cloud native that are important to grasp in order to think more broadly about architecting cloud native technologies for complex systems. A fundamental principle of cloud native for telco applications is that their underlying telco systems conform to the core precepts of cloud native architecture. The lack of exceptions makes the rule; the entire advantage of cloud native is driven by decomposability and abstraction from physical infrastructure. By deviating even slightly from these core principles, the service provider stands to lose the workload portability and minimal toil that drew them to cloud native approaches in the first place. 43 | 44 | 45 | ### 1.3.1 What "loosely coupled" means in cloud native systems 46 | 47 | Cloud native systems have a clear separation between the microservices. The separation is based on technology, like containers, which allows independent life cycle management of each microservice. Cloud native applications (which are built on these microservices) and cloud native systems more generally benefit from design considerations that segregate services based on the business capabilities being delivered and the organization that owns said delivery. By leveraging technology such as containers, it is possible for individual business units to own the development of their specific microservice independent of collaborative development teams. Additional benefits of cloud native architectures include scalability on a per microservice basis. This simplifies deployment in a wide variety of infrastructure environments, ranging from an endpoint device to edge stations to large data centers. Adopting cloud native architectures also allows service providers to deploy resources in the most efficient manner possible while maintaining necessary and optimal service levels for regulated and unregulated service types. 48 | 49 | The delivery of software as microservices harnesses the existing group boundaries within an organization and works with, not against, the different rates of change and business capabilities residing within those boundaries. This enables effective parallel development and communication across an organization, which allows events such as security patches to be rolled out more quickly and easily because deployment need not be executed in lock-step with other parts of the application. 50 | 51 | While one microservice per container is the ideal state for cloud native applications, the reality is not always so clean and simple. It is entirely possible and sometimes required to run multiple microservices in a single container, and even to deploy very large containers for aggregations of services that are difficult or impossible to decouple due to software or network limitations. However, the general idea behind cloud native is to decompose microservices into the smallest possible infrastructure unit allowable. This causes a shift in where the burden of orchestration lies and pushes it solely (ideally) into the orchestration layer. 52 | 53 | Cloud native applications also are packaged with all of their runtime dependencies during the build phase. The build is then used for deployment. This allows for individual business units and operations teams to care and maintain for their software with less risk of other stakeholders disrupting their service’s “uptime”. In practice, this allows for scenarios such as the owner of service “X” being able to theoretically scale their chosen software independent of service “Y”. 54 | 55 | These clear lines of demarcation provide a paradigm that makes sense to legacy operations groups who are being forced to rapidly assess how they’ve delegated roles and responsibilities. For example, a network focused operations group could do upgrades and updates to a microservice hosting routing protocol services, such as ISIS or BGP, without impacting the development or operations of the security team managing the microservices hosting AAA or Access List functionality. 56 | 57 | 58 | ### 1.3.2 Cloud native applications require orchestration 59 | 60 | Because they are loosely coupled, cloud native services are always managed by an application orchestrator, such as Kubernetes. As cloud native applications are built from a loosely coupled collection of services that are delivered via an API, this coordination function is paramount, not only for reliability but also for performance and resilience. From an operational standpoint, an orchestrator is necessary to manage and deploy these services; manual deployment and meshing of these services and applications would be complex, error-prone, and resource intensive. 61 | 62 | The orchestration layer is tasked with composing, decomposing, and reshaping or resizing the resources assigned to specific applications provided by the infrastructure. It does this based on assessments and monitoring of performance and availability of the actual infrastructure used by the application. In that manner, the applications are the “brains”, directing the orchestration layer towards functional goals and outcomes (for example, low latency or specific uptime and resiliency metrics). The objective of orchestration is to create an entity that aggregates the microservices into services that can be easily mapped to network functions. 63 | 64 | Kubernetes is unique in that it provides an example of both a declarative orchestration model as well as an application that can be deployed and consumed in a cloud native manner. From an orchestration standpoint, Kubernetes presents a declarative API and works off an assumption of immutability. Conversely, Kubernetes is an application that is comprised of a decoupled system of microservices deployed via orchestration. Given these design implementations, Kubernetes itself is often deployed via Kubernetes and treated the same as any other cloud native application. The expectations, set forth by this example, would be that a CNF would behave in a similar manner, with its core componentry being immutable and its method of configuration being declarative. 65 | 66 | 67 | ### 1.3.3 Infrastructure, Deployment, and Configuration of Cloud Native Systems 68 | 69 | [Immutable infrastructure](https://docs.google.com/document/d/1fwV3vZB5IgHb6uUgQpHts9mFR0HheYbIrlg9hGfWYfA) (the orchestrator and all of the software and hardware that it depends on) is provisioned using baked and versioned templates (e.g. server images) or a combination of templates and bootstrapping (some repeatable and versioned process that is applied to the template e.g. kubeadm). The underlying infrastructure is not changed after it is made ready for use. New changes to the infrastructure are rolled out as new instances of infrastructure. By separating the application layer from the infrastructure layer, it is possible to iterate faster with minimal dependency risk. Additionally, this separation enables the vision of a programmable and software defined infrastructure, allowing end-to-end lifecycle management of the entire stack from the hardware up. 70 | 71 | In cloud native systems, the atomic unit of deployment can come in many forms. A container, a physical appliance, a virtual machine or even future looking runtime methodologies such as unikernels and serverless. What truly makes an artifact cloud native is the philosophy employed when developing and deploying it. Container runtimes brought about a paradigm shift to the industry at large by commoditizing the complicated process of separating application dependencies from the infrastructure. A container, deployed upon an immutable and decoupled compute environment, attempts to abstract function from the underlying physical infrastructure and network architecture completely. At present, the most commonly used container environment is an OCI-compliant implementation. 72 | 73 | A container is different than a Virtual Machine (VM), which was the initial base unit of cloud computing, in several key ways. A VM hosts a Guest OS capable of delivering a service's required compute and networking. This guest runs on top of a hypervisor consuming the virtual infrastructure and orchestration provided to it. It is also infinitely mutable, and continuously modified in real time making it unique and oftentimes no longer disposable. In contrast, containers run on top of a shared Host OS (a shared kernel) and leverages native Linux tooling to logically partition resources within said host. An application's desired runtime dependencies and metadata can be easily packaged within a container. As containers are agnostic to the type of Host OS they are running on, assuming basic kernel and libraries version requirements are met, the underlying infrastructure becomes transparent to the hosted application. 74 | 75 | For Kubernetes specifically, the atomic unit of management is a Pod. A Pod is a set of application containers which are 76 | co-located and co-scheduled on the same machine (Node in Kubernetes terms) which run with a shared context and the same Linux networking namespace. For telco (and other) cloud native applications, the Pod is the basic building block of deployment, scaling operations and upgrades. 77 | 78 | Cloud native applications consist of sets of cloud native microservices. The configuration of these microservices is not changed after deployment (note, this does allow for changes in application data such as "add a new user"). New features for a cloud native application and the underlying Pods are rolled out as new artifacts and new configuration. Cloud native systems are configured declaratively. This means that the system configuration describes “what” a loosely coupled system should look like, not ”how” the system should be created. The “how” of the application is determined by the tooling (e.g. the orchestrator, operators, and CRDs). 79 | 80 | 81 | ## 1.4 Cloud Native Network Functions 82 | 83 | A cloud native network function (CNF) is a cloud native application that implements network functionality. A CNF consists of one or more microservices and has been developed using Cloud Native Principles including immutable infrastructure, declarative APIs, and a “repeatable deployment process”. 84 | 85 | An example of a simple CNF is a packet filter that implements a single piece of network functionality as a microservice. A firewall is an example of a CNF which may be composed of more than one microservice (i.e. encryption, decryption, access lists, packet inspection, etc.). 86 | 87 | The CNFs themselves, by nature of following cloud native principles, are also composable and can implement and facilitate more complex network functionality if needed. 88 | 89 | CNFs and cloud native principles can be used when implementing applications and network infrastructure which needs to meet standards such as [3GPP](https://en.wikipedia.org/wiki/3GPP). For example, an [Evolved Packet Core's (EPC)](https://en.wikipedia.org/wiki/System_Architecture_Evolution#Evolved_Packet_Core_(EPC)) [Serving Gateway](https://en.wikipedia.org/wiki/System_Architecture_Evolution#SGW_(Serving_Gateway)) could be implemented as a CNF and support all 3GPP requirements (eg. S1 protocol stack) allowing integration with other [EPC services](https://en.wikipedia.org/wiki/System_Architecture_Evolution#Evolved_Packet_Core_(EPC)). 90 | 91 | 92 | ## 1.5 Cloud Native for Telcos 93 | 94 | 95 | ### 1.5.1 A Brief History of Virtualisation for Telcos 96 | 97 | Until the 1990s, most functionality and applications for telecommunications resided primarily in physical hardware (aka ‘boxes’). While software powered these systems, the software functioned more like firmware and was not easy to abstract and run on multiple platforms in virtual environments. 98 | 99 | This fostered a “top-down” approach to telecommunications systems that was imperative rather than declarative. This approach was resource intensive and expensive; redundancy meant acquiring multiple physical instances of required systems. This guiding architectural decision encouraged the tight bundling of numerous services and capabilities into individual physical systems. The result was not only high infrastructure and provisioning costs but also inefficient hyper-redundancy in system engineering for overlapping capabilities. 100 | 101 | 102 | ### 1.5.2 Software Defined Networking And The Emergence of VNFs 103 | 104 | In the late 1990s, the concept of virtualization for enterprise computing garnered interest as enterprises tired of spending large sums of money on high-powered servers. Simultaneously, we saw a rapid rise in the popularity of the commodity Open Source Linux Operating System. In 1999, VMware released its first virtualization product for x86 devices. In the early 2010s, the concept of Network Functions Virtualisation (NFV) emerged as telcos and other users of big networking gear sought to virtualize their networking functionality, enhance resiliency, and take advantage of commodity hardware. With constructs such as NFV-encapsulated Virtual Network Functions (VNFs), Network Function Infrastructure (NFVI), and an orchestration component (MANO), the entire NFV hardware and software stack could be integrated and distributed across geographically dispersed data centers. In 2017, Open Networking Automation Platform (ONAP) emerged as the open source standard platform for orchestrating and automating physical and virtual network elements with full lifecycle management. NFV and ONAP primarily focused on creating and orchestrating virtual analogs for physical equipment - virtual boxes. 105 | 106 | This was the same pattern followed during server virtualization when initial efforts focused on replicating physical servers as virtual entities. Cloud native, however, requires a more fundamental rethink and redesign of how telco and backbone/core network systems function. This paradigm shift impacts both the software architectures being proposed and how the telco operator structures and organizes its staff. 107 | 108 | In a sense, cloud native for telcos will require a transformation that is actually not dissimilar from the era of forklifting over monolithic legacy applications into virtual environments. This next evolution will require the decoupling of tightly bundled functions and processes to create a more resilient, manageable, and performant infrastructure that derives immutability precisely from its ephemerality. For these considerations to successfully achieve widespread adoption, CNFs will have to first be introduced alongside VNFs and PNFs (physical network functions) and will need to fit into operational models that govern those earlier types of network functions. Finding sensible integration points between emerging greenfields and legacy brownfields will be crucial to the success and adoption of cloud native practices at larger telcos. CTO offices and architecture groups must find ways to stitch CNFs into existing layer 2 and 3 domains, integrate CNFs into existing management systems currently present in the service providers' networks, and find ways to introduce some of modern DevOps practices, such as continuous integration (CI) and continous deployment/delivery (CD), to the PNF/VNF world. These achievable objectives are crucial as they provide executives both a means of capturing a return on investment with their existing infrastructure and a realistic path forward in adopting a more holistic cloud native approach. 109 | 110 | 111 | ### 1.5.3 Principles for Cloud Native Telco Infrastructure and Applications 112 | 113 | At its core, the evolution from box-centric to process and function-centric requires an evaluation of the OSI Layers through a cloud native lens. The best general practices of cloud native infrastructure deployment and application design should also be applied to networking infrastructure. Two key shifts required for CNFs to function well are deployment pipelines and the use of declarative programming and scripts for configuration. By pipelines, we mean the use of CI and CD platforms. This is fundamental because it allows for rapid iteration, granular versioning, easier rollbacks, canary testing, and many other capabilities that are presently complex and often not possible when deploying VNFs. By declarative language, we mean a shift to intelligent orchestration that is better able to maintain required service levels and maximize efficiencies based on available resources. This will ultimately mean a transition of network intelligence and design - function, description, and configuration - into other parts of Kubernetes (Helm Charts, CRDs, and Operators). 114 | 115 | 116 | ### 1.5.4 Evolving the Stack From VNFs to CNFs 117 | 118 | The emergence of Kubernetes as the most widely used container orchestration layer allows telecommunications operators to shift their infrastructure over from more bespoke, expensive, and higher friction stacks to a de facto standard platform while also improving performance and resiliency. The extensibility of Kubernetes should allow a gradual transition from legacy VNFs built on OpenStack or VMWare VMs over to a Kubernetes telco stack that accommodates all aspects of their business - including legacy VNFs, which can be easily managed via an abstraction layer on top of Kubernetes (KubeVirt/Virtlet/Openstack). 119 | 120 | Back-office applications, such as BSS and OSS functions, can run directly on Kubernetes and will enjoy all the same benefits that enterprise applications derive from Kubernetes. Operators should also be able to run real-time, critical functions on Kubernetes. CNFs must be able to run on Kubernetes and benefit directly and strongly from cloud native principles. It is important to note that, in theory, Kubernetes and containerization should allow for true infrastructure-agnostic immutability and portability. This will only be true if conforming Kubernetes versions and configurations are used and supported by operators. That said, creating a Kubernetes conformance model for telecommunications is non-trivial, requiring validation and certification of key elements such as network software (CNI plug-in, network service mesh, etc.) and other aspects. 121 | 122 | 123 | ## 1.6 Cloud Native For Telcos In Practice 124 | Likely deployment patterns for cloud native applications into telcos will move from functions that are more fault intolerant or not as latency sensitive (voicemail, OSS/BSS, etc.) to more critical functions such as the backbone cores. Telcos will gain on multiple fronts by deploying cloud native systems. Those benefits include operational consistency, application resilience, simplified and responsive scaling at the microservice level, simplified integration with enterprise-facing cloud native applications, and improved portability between public, private, and hybrid cloud environments. Another key improvement would be transparency, observability, and control, all of which would be increased by operating network functions under a Kubernetes umbrella as opposed to operating purpose-built boxes. Telco operators should also benefit from built-in or natively integrated tools and metrics, such as Prometheus, Jaeger, and OpenTracing because they are simpler to instrument and observe at the service level in Kubernetes running microservices. 125 | 126 | As cloud native involves decomposing tightly coupled processes into loosely coupled microservices, rearchitecting applications as CNFs often will entail decomposing functional aspects into services running in discrete containers or as separate microservices. For an example of how cloud native telecommunications principles might work in practice, consider a UTM (universal threat management) firewall. These are generally large physical or virtual appliances that encompass multiple functions including DDoS protection, IP filtering, VPN provisioning and termination, stateful packet inspection, and anti-virus / spam filtering. They are complicated to troubleshoot and a clear single point of failure for multiple critical functions. UTMs are also by design imperative. This makes them brittle and poor handlers of edge cases. UTMs cannot be easily managed via CI/CD and standard DevOps practices. 127 | 128 | Through a cloud native lens, all of the functions of the UTM could be decomposed as microservices, each functioning as its own application running in it is own container (or containers). These services could be controlled and monitored from a single management plane, giving the operator the same visibility into what is happening and the same ability to manage the composed whole, but offering additional granularity on service performance. This should also allow for easier bursting to handle outlier events (usage/traffic spikes) and for running security infrastructure as an agile pipeline rather than a cumbersome snake. Additionally, if one microservice fails, other services in the meshed CNFs would remain functional, resulting in improved overall resiliency and failure tolerance. For example, a failing DDoS microservice would not impact IP filtering, anti-virus, or other functionality in the UTM application bundle. Similarly, this architecture will support the cloud native vision of network services running on common infrastructure that can scale and enhance performance and reliability in the most optimal manner while enabling an operational environment to address DevOps models in the most adequate manner. 129 | 130 | The manipulation of namespaces and multi-tenancy within the orchestration layer will be crucial for operators if they are to deploy these examples at scale. For there to be any hope of gaining a return on investment, smarter deployments of the infrastructure will be as important as the deployment of the CNF itself. Building upon the UTM example, if it and subsequent CNFs adhere to the cloud native design philosophies, then it should be feasible to deploy them into a single Kubernetes cluster, leveraging the available tooling to ensure logical isolation/segmentation. 131 | 132 | If the CNF has strong opinions on what the infrastructure must provide (i.e. “CNF-X will only run in a 3rd-party-provided Kubernetes deployment”), then the economies of scale in both infrastructure costs and operational simplicity are reduced. For example, if an operator must run multiple types of Kubernetes for different CNFs, then the infrastructure and required orchestration software is no longer a commodity. In this scenario, each CNF suite may require more masters and instances of the etcd key-value datastore than is economical, to name one example. Additionally, the different flavors of Kubernetes will require different operational playbooks and potentially will inject more complexity into analytics, application performance monitoring, and infrastructure management. Looking at a service provider’s far edge, it is not feasible to assume that a cupboard-sized data center will be cost effective if the expectation is for that miniature data-center to host an instance of Kubernetes per application. A conforming “Plain Vanilla” flavor of Kubernetes for telcos would ideally run on all different infrastructure components, including X86, ARM, and RISC, due to the different infrastructure composition of centralized data centers and edge data centers. 133 | 134 | 135 | ## 1.7 Conclusion 136 | Telecommunications services demand a higher bar for resiliency, security, and performance than nearly any other set of services. Our society increasingly relies on our telecommunications infrastructure for critical capabilities that keep us safe and allow us to conduct research, commerce, and our daily lives. 137 | 138 | This high bar was attained at a high price. Traditionally, telecommunications infrastructure and applications have been designed in tightly composed physical or virtual units in order to better control the software stack and with a model of redundancy and resiliency derived from ready overcapacity. This has also ensured that deployment of new applications is complicated and often slow; tightly-bundled applications are not easy to modify and cannot be provisioned or versioned with modern DevOps tools. As a result, telecommunications progress was usually quite expensive, both in implementation and physical infrastructure. The reliance on custom-made telecommunications platforms meant it was necessary to retain and rely on architects and consultants with arcane expertise in those bespoke platforms. 139 | 140 | The great promise of cloud native for telecommunications is to turbocharge the development and improvement of telecommunications applications by finally allowing these critical services to run on largely commodity physical infrastructure, and to finally decouple them from purpose-built boxes. In addition, customized, tightly-coupled, and hardware-bound telecommunications platforms can give way to Kubernetes, enhancing modularity, scalability, observability, and interoperability. This transition will enable the telecommunications industry to benefit from the dynamic and vigorous community of software development and innovation rapidly growing around Kubernetes. In general, adopting cloud-native ways should help telecommunications operators become more agile, responsive, and adaptive both internally and externally. These are already key goals for the telecommunications industry. Moreover, the telecommunications industry stands to benefit even more than enterprises because the implications for reducing CapEx and improving the speed of application development (and by extension, service improvement) are profound. 141 | 142 | Telcos have traditionally struggled to keep pace with startup technology companies in deploying newer software-driven technologies because they played by a different set of rules - the “Rules of the Boxes” and strict regulatory rules - defining service delivery and reliability. In the cloud native realm, boxes can be broken up into distributed CNFs composed of microservices that follow cloud native principles. 143 | 144 | As a result, telcos will be able to freely test, design, deploy, provision, revise, and ultimately innovate at a far faster pace. With process and organization adaptations to cloud native thinking and design, telcos will be able to leverage this new freedom to build more resilient infrastructure and applications and to accelerate the roll out of new features and new capabilities more quickly, with less risk and less fear of disrupting critical regulated systems and functions. 145 | 146 | Work is ongoing to bring the most demanding and mission critical telecommunications systems to cloud native, including those that must fulfill regulatory requirements (such as emergency call handling). However, in theory, CNFs running on Kubernetes should provide equivalent regulatory compliance for the same reasons that cloud native applications for enterprises tend to be more fault-tolerant, more responsive, and more resilient; because loosely coupled immutable systems are inherently better at handling highly complex applications with strict SLAs and multiple dependent and interactive functions. This is the significant promise of cloud native for telecommunications applications and functions. 147 | 148 | Contributors: [Ahmed ElSawaf](https://github.com/ASawwaf), [Bill Mulligan](https://github.com/xmulligan), [Dan Kohn](https://github.com/dankohn), [Daniel Bernier](https://github.com/dabernie), [Dave Cremins](https://github.com/davecremins), Ervins Kampans, [Frederick Kautz](https://github.com/fkautz), [Gergely Csatari](https://github.com/CsatariGergely), Henrik Saveedra Persson, [Herbert Damker](https://github.com/hdamker), [Ildiko Vancsa](https://github.com/ildikov), [Jeff Saelens](https://github.com/jeffsaelens), Khawaja Daniyal, Lei Wang, [Rabi Abdel](https://github.com/rabiabdel), Saad Sheikh, [Tamas Zsiros](https://github.com/TamasZsiros), [Taylor Carpenter](https://github.com/taylor), [Tom Kivlin](https://github.com/tomkivlin), [W. Watson](https://github.com/wavell), [Petar Torre](https://github.com/petorre). 149 | Editors: [Alex Salkever](https://github.com/ASalkever) 150 | -------------------------------------------------------------------------------- /whitepaper/readme.md: -------------------------------------------------------------------------------- 1 | # Telecom User Group White Paper 2 | 3 | All essential information on the ongoing work for the Telco User Group White Paper. 4 | 5 | 6 | # Documents 7 | 8 | A prologue whitepaper, [Cloud Native Thinking for Telecommunications](https://github.com/cncf/telecom-user-group/blob/master/whitepaper/cloud_native_thinking_for_telecommunications.md), is available in this repo [based on an older Google Doc version](https://docs.google.com/document/d/1LO6G4sWHJKKW77z7gj2Aqt3IF3dRJL5q6Q1wXI4Kj8g/edit?pli=1#heading=h.mk8qm2iyy17n) 9 | 10 | Another (to be named) whitepaper is available as a [WIP Google Doc](https://docs.google.com/document/d/1-zqxz5bdCLTuOEvi2ybADR3PcmzbBhNt6YkNnvx-KoA/edit?usp=sharing), which has intended scope summarized, many comments and some contributed content in different sections. 11 | 12 | # Contributing and commenting 13 | Please see the [contribution guidelines](../CONTRIBUTING.md). 14 | 15 | # Meetings and review procedures 16 | The official meeting to discuss everything around the WP is the [regular Zoom call for the Telecom User Group](https://github.com/cncf/telecom-user-group). 17 | 18 | Please see the [contribution guidelines](../CONTRIBUTING.md) for details on the review/approvals process. 19 | 20 | # License 21 | The whitepapers in this repository is available under the Apache License, Version 2.0. The whitepapers are alternatively available under the Creative Commons Attribution 4.0 license. 22 | 23 | # Questions 24 | 25 | --------------------------------------------------------------------------------