60 likes | 192 Views
Strawman Proposal: On tenants, virtual networks and AAA. June-2-2014 Colin Dixon, Dave Lenrow, Liem Nguyen. Base Assumptions. Open DayLight Should Present a Tenant aware NBI All Access to controller resources protected by a tenant-aware AAA system
E N D
Strawman Proposal: On tenants, virtual networks and AAA June-2-2014 Colin Dixon, Dave Lenrow, Liem Nguyen
Base Assumptions • Open DayLight Should Present a Tenant aware NBI • All Access to controller resources protected by a tenant-aware AAA system • Open DayLight Should provide Network virtualization as a service (NVaaS) • Consistent API for consuming virtual networks regardless of underlying implementation. • OpenDovevs VTN vs NSX vsMidokuravsNuage is not visible outside of the controller NBI.
Tenants and Virtual Networks are Orthogonal • Is a virtual network a tenant? No. Is a tenant a virtual network? No. • There is no simple answer to the question “what is the relationship between a tenant and a virtual network?” • It is possible for any tenant to “own” any number of virtual networks. They are an ODL resource like any other. • Whether a given tenant is allowed to CRUD a virtual network, and which resources can be attached to the VN is governed by the AAA overlay.
Tenancy is an overlay • The AAA system creates a “fiction” of tenants with various privileges defined per tenant. • AAA controls the rights/privileges associated with “state regulation” per-tenant • It is proposed that this overlay support a tree of tenants, where each node’s permission to modify resources is controlled by their parent node • Apply “Parental Controls” model for enabling/disabling resource access by children. • Users and Roles for a given tenant are yet another overlay, providing access controls to the aggregate capabilities that a given tenant inherited from it’s parent. • Tenancy is state manipulation (the state regarding who can do what).
Proposed ODL Startup in a GBP System • Controller discovers all devices and sets up initial state. • Controller builds master policy rendering catalog based on loaded renderers, etc. • External system (orchestration, automation) does capabilities exchange with controller to decide what kind of policy elements to offer, and then starts pushing GBP to enable network transactions as needed. • Root tenant (facilities based operator) would define physical network properties first. • Child tenants would then proceed to allocate resources via policy/intent as restricted by their parents. • Child permissions determine leaf use of network create, etc.