[OpenDaylight Discuss] On multi-tenancy support


Colin Dixon <colin@...>
 

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.

--Colin


On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Rob Adams <readams@...>
 

Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.


On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:
I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.

--Colin


On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



Lenrow, Dave <david.lenrow@...>
 

Hi Luis,

I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.

 

Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.

 

In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.

 

Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.

 

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 

 

It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.

 

 

 

Below is pasted an email from the discuss list discussing this as well

 

Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.

This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.

We presented this and got some good feedback from the TWS call on June 2.

 

What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:

 

The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.

The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.

The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.

The parent child relationship can be extended recursively to an arbitrary depth.

Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.

 

 

Email included below describes the vision of how this would work in general.

The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.

 

Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  

 

Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?

 

I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 

 

Bring it on!

-drl

 

 

 

From: Lenrow, Dave
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy

 

Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that

 

One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.

 

 

Facitlities Based Provider – Owns switches, servers, fibre, etc.

    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent

        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent

            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent

                Admin in business Unit – provides on-demand, self-service access to subset of BU resources

                    BU developer – consumes on-demand, self-service subset of BU resources

                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.

                            Application module – can do stuff within envelope of BUA parent.

                                Etc.

 

In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.

I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.

 

 

FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.

VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.

LargeCo can define which virtual networks are accessible to the Finance BU

FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet

BU dev can contain the number of instances of paystubprinter allowed on-demand.

PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface

App module can stream log data within storage contstraints from FinBU (great-grand-parent)

Etc.

 

Above is kind of goofy contrived example, so please send nit picking to /dev/null.

 

Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.

 

Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.

 

 

Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).

 

Do others feel that this vision is sensible and needs to get reflected in our requirements?

 

It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).

 

If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.

 

I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.

 

 

 

-drl

 

Dave Lenrow

Distinguished Architect

Advanced Technology Group - HP Networking

Hewlett-Packard, Littleton MA

+1 (617)-329-1861 (mobile)

david.lenrow@...

@dlenrow

 

 

 

 

 

From: Rob Adams [mailto:readams@...]
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support

 

Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.

 

On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.

 

--Colin

 

On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:

Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 


Luis Gomez
 

Hi Dave,

Thanks for this detailed information. I will ask more in case of questions.

BR/Luis


On Aug 4, 2014, at 8:40 AM, Lenrow, Dave <david.lenrow@...> wrote:

Hi Luis,
I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.
 
Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.
 
In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.
 
Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.
 

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.
 
 
 
Below is pasted an email from the discuss list discussing this as well
 
Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.
This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.
We presented this and got some good feedback from the TWS call on June 2.
 
What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:
 
The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.
The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.
The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.
The parent child relationship can be extended recursively to an arbitrary depth.
Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.
 
 
Email included below describes the vision of how this would work in general.
The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.
 
Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  
 
Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?
 
I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
Bring it on!
-drl
 
 
 
From: Lenrow, Dave 
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy
 
Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that
 
One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.
 
 
Facitlities Based Provider – Owns switches, servers, fibre, etc.
    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent
        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent
            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent
                Admin in business Unit – provides on-demand, self-service access to subset of BU resources
                    BU developer – consumes on-demand, self-service subset of BU resources
                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.
                            Application module – can do stuff within envelope of BUA parent.
                                Etc.
 
In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.
I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.
 
 
FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.
VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.
LargeCo can define which virtual networks are accessible to the Finance BU
FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet
BU dev can contain the number of instances of paystubprinter allowed on-demand.
PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface
App module can stream log data within storage contstraints from FinBU (great-grand-parent)
Etc.
 
Above is kind of goofy contrived example, so please send nit picking to /dev/null.
 
Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.
 
Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.
 
 
Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).
 
Do others feel that this vision is sensible and needs to get reflected in our requirements?
 
It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).
 
If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.
 
I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.
 
 
 
-drl
 
Dave Lenrow
Distinguished Architect
Advanced Technology Group - HP Networking
Hewlett-Packard, Littleton MA
+1 (617)-329-1861 (mobile)
@dlenrow
 
 
 
 
 
From: Rob Adams [mailto:readams@...] 
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support
 
Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.

 

On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.
 
--Colin

 

On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
 


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



Wojciech Dec
 

Hi Luis,

the currently proposed AuthZ service data-model + API factor in a multi-tenancy aspect by allowing authorization policies for resources to be nested covering multiple domains.
You can find this described in https://lists.opendaylight.org/pipermail/aaa-dev/2014-July/000036.html

Welcome all feedback on the matter.

Regards,
Wojciech.


On 4 August 2014 18:51, Luis Gomez <ecelgp@...> wrote:
Hi Dave,

Thanks for this detailed information. I will ask more in case of questions.

BR/Luis

On Aug 4, 2014, at 8:40 AM, Lenrow, Dave <david.lenrow@...> wrote:

Hi Luis,
I have worked with some other members of the community to map a proposal that would define the relationships in ODL among AAA, tenants, virtual networks, and group based policy. It has generally been well received when socialized, but we’ve not yet figured out how to translate this concept into cooperation and code within all the projects that would need to participate.
 
Clearly not happening for Helium and possibly a great thing to work on when broad community membership is face-to-face at September developer event.
 
In todays GBP requirements call we will discuss plans to align GBP and AAA with this proposed approach.
 
Below are links to some documents from the discussion to date. They may help you understand the direction we’re proposing, however they may require some narration by the authors. We’ve presented some of this on TWS previously and could do an update to TWS if that is of interest.
 

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
It’s not yet  clear to me  how we staff the developers to implement long term architectural vision across projects in ODL. Folks with interest/availability to participate should raise their hands as we begin to think about long term improvements outside of the helium timeline.
 
 
 
Below is pasted an email from the discuss list discussing this as well
 
Since the first ODL Hackfest, we’ve been trying to figure out how to get on the same page about terminology and how we can use it to talk about what we’re building.
This spring, Colin Dixon, Liem Nguyen, and I took an action to propose a way to map AAA tools to some well defined entities and in the process to resolve ongoing confusion around what we mean by tenants, users, and virtual networks, in particular.
We presented this and got some good feedback from the TWS call on June 2.
 
What we proposed was a model with an entity called a domain (chosen by poll) that works as follows:
 
The “root” domain is created when the GBP system starts and it inherits access to  all of the physical and virtual network resources discovered by the startup process.
The root domain can include various users and roles with AAA support. Within the root domain an admin can be created and can then subsequently define which resources and actions the various root domain users are allowed to access.
The root domain can create one or more children, and for each can specify what resources and actions are available in the childrens “view” of the overall resource and policy world.
The parent child relationship can be extended recursively to an arbitrary depth.
Each child  domain also has a set of users and roles supported by AAA that are local to that domain. These define what various users are allowed to do withing the resource/policy view they inherit.
 
 
Email included below describes the vision of how this would work in general.
The OpenStack project, which will often sit atop ODL (and GBP) does not support arbitrarily deep recursion of “tenant like” entities. It is basically a one-deep hierarchy. Enclosed slides show how multiple instances of OpenStack provider/tenants could map onto a single instance of the recursive ODL network infrastructure model.
 
Within Group Based Policy it would be fantastic if we could figure out how to make GBP the policy language for describing the concentric circles of  ever-more restrictive “parental controls” as one marches down the ODL domain stack.  
 
Suggest we discuss this in a GBP arch meeting at a minimum. May touch enough areas that we want to discuss on TWS again?
 
I’ve uploaded some slides that help explain the thinking on the GBP Wiki

https://wiki.opendaylight.org/images/e/e3/OS-ODL_Mapping.pdf

https://wiki.opendaylight.org/images/a/a0/TWS-ODL-tenancy-preso-2014-06-02.pdf

 
 
Bring it on!
-drl
 
 
 
From: Lenrow, Dave 
Sent: Friday, May 23, 2014 9:20 AM
To: discuss@...; controller-dev@...
Subject: Expanding on N-deep tenant hierarchy
 
Some folks have asked me to restate my vision for how/why we need a flexible tenant concept. Please note that
 
One could imagine a strict hierarchy of control as follows in which each subsequent tenant entity has authority/scope/role defined and limited by it’s parent/child relationship through which it inherits a constrained view of the total resource pool.
 
 
Facitlities Based Provider – Owns switches, servers, fibre, etc.
    Virtual Cloud Provider – Sells access to a subset of the resources offered by FBP parent
        Corporate Customer – provides corporate wide access to subset of  resources offered by VCP parent
            Business unit of Corporation – provides on-demand self-service access to subset of resources offered by CC parent
                Admin in business Unit – provides on-demand, self-service access to subset of BU resources
                    BU developer – consumes on-demand, self-service subset of BU resources
                        BU production application – consumes resources as defined by developer with elastics scaleout-based on load.
                            Application module – can do stuff within envelope of BUA parent.
                                Etc.
 
In this case N=8, but the instant we decide that is the right constant, somebody will come up with a good reason for 9. If we decide N=25 to have lot’s of headroom we will feel dumb some day.
I claim we need an architecture that allows for a hierarchy that is arbitrarily deep.
 
 
FBP can decide that VCP 1 gets 80 of the bandwidth in the physical fabric and VCP 2 gets 20%, but with special express links between metro hubs.
VCP one can sell  LargeCo access to some dedicated resources and an ability to burst on-demand up to a limit X in a shared pool.
LargeCo can define which virtual networks are accessible to the Finance BU
FinBU can allow admin to choose developers who are allowed to request Gold QoS on their diffserv vnet
BU dev can contain the number of instances of paystubprinter allowed on-demand.
PayStubPrinter FinBU app can decide how/when to load balance across multi-link border interface
App module can stream log data within storage contstraints from FinBU (great-grand-parent)
Etc.
 
Above is kind of goofy contrived example, so please send nit picking to /dev/null.
 
Point is Tenancy cannot be flat, or shallow, but must be supported for potential complex hierarchy of control.
 
Within the hierarchy, the limits of what a child can do are always defined buy inheritance from their parent.
 
 
Authentication at any level of the hierarchy could be to a common, multi-tenant aware auth server or to an instance of auth-server with constrained/local context (e.g. FinBU auth server for FinBU and children).
 
Do others feel that this vision is sensible and needs to get reflected in our requirements?
 
It won’t surprise anyone that I think we need to build the enforcement of the rules of such a hierarchy into a controller based declarative intent NBI. I would suggest that the single writer of policy be the only trusted client of a completely trusted NBI and that the entire hierarchy of control and enforcement be built above that trusted interface.  As others have recommended, the controller would have no native sense of tenancy in the management/control plane (there are clearly requirements, e.g. overlapping tenant IP address spaces that need to be handled in tenant context in the data plane). The intent NBI would become the single-sign-on interface for AAA for non-infrastructure entities (e.g. securing controller-native bunldles and interfaces needs it’s own secure plumbing solution).
 
If folks want to talk me out of a single policy writer completely trusted, I won’t be surprised (and I’m sure the reasons will be compelling), but  the top of the plumbing AAA/policy stack needs to connect to the bottom of the intent based NBI stack cleanly with no AAA ambiguity.
 
I’m donning my flame retardant suit as I hit send and await our communities diverse views on my wacky vision of the future. Be gentle friends.
 
 
 
-drl
 
Dave Lenrow
Distinguished Architect
Advanced Technology Group - HP Networking
Hewlett-Packard, Littleton MA
@dlenrow
 
 
 
 
 
From: Rob Adams [mailto:readams@...] 
Sent: Monday, August 04, 2014 1:06 AM
To: Colin Dixon
Cc: Luis Gomez; <discuss@...>; Lenrow, Dave; groupbasedpolicy-dev@...; aaa-dev@...
Subject: Re: [OpenDaylight Discuss] On multi-tenancy support
 
Tenants are in the group-based policy model but group-based policy does not implement any sort of access control at the moment; we've been assuming that AAA would be provided by the restconf layer and we could plug into that.  So we should be ready to tie into whatever mechanism exists.

 

On Sun, Aug 3, 2014 at 8:05 PM, Colin Dixon <colin@...> wrote:

I know that there has be some discussion of this in the group-based policy project and in particular from Dave Lenrow. I think AAA was also thinking along these lines.

I'm cc'ing both those dev lists.
 
--Colin

 

On Mon, Jul 28, 2014 at 8:37 PM, Luis Gomez <ecelgp@...> wrote:
Hi all,

I would like to know if there is any plan to develop new multi-tenancy feature in ODL other than the existing mechanisms. If so which project will implement this and by which release?

Thanks/Luis

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
 


_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss



_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss