From: Reinaldo Penno rapenno@gmail.com
Sent: Tuesday, October 20, 2015 2:47 PM
To: Guo, Ruijing; Keith Burns
Cc: Brady Allen Johnson; sfc-dev@lists.opendaylight.org
Subject: Re: [sfc-dev] Classifier/RSP dependency
Okay, I took some time looking around the code.
If the change is limited to removing the classifier from RSP then it seems to me it is not risky. You just stop configuring it and remove it from RSP yang model.
But you need a way to attach an ACL to the actual classifier device. Today it is done through the classifier model since it points to a SFF that exists. I would suggest this stays the same since there are two listeners that depend on it.
Later we can do more deep changes if needed.
From: "Guo, Ruijing" <ruijing.guo@intel.com>
Date: Monday, October 19, 2015 at 10:32 PM
To: Reinaldo Penno <rapenno@gmail.com>, Keith Burns <alagalah@gmail.com>
Cc: Brady Allen Johnson <brady.allen.johnson@ericsson.com>, "sfc-dev@lists.opendaylight.org" <sfc-dev@lists.opendaylight.org>
Subject: RE: [sfc-dev] Classifier/RSP dependency
I agree with your suggestion and plan to remove classifier in RSP.
Do you have concern about Configuration data store depends on Operation data store between classifier/RSP?
Thanks,
-Ruijing
From: Reinaldo Penno rapenno@gmail.com
Sent: Tuesday, October 20, 2015 12:48 PM
To: Keith Burns; Guo, Ruijing
Cc: Brady Allen Johnson; sfc-dev@lists.opendaylight.org
Subject: Re: [sfc-dev] Classifier/RSP dependency
This is probably the best way to go and the perfect time to patch given all the work that is going on.
Paul and I had this grand master plan where a user could only configure a ACL and point to a RSP if the RSP was already created, and then if the RSP was deleted we could notify the user, etc.
But the notification does not really need the RSP to the tied to ACL at the config level, we just need the right oper/state Yang models in place (which we have).
In summary, this is a good time to really clean this up.
1 - ACL action points to RSP (exists)
2 – No configuration of classifier or ACL in RSP
3 – Maybe we can completely remove classifier Yang since it seems it will have no purpose
4 – We store the relationship between ACL<->RSP. If RSP is deleted (or ACL points to nothing) we say “Traffic is probably going to be blackholed”, but that’s about it as far we should go.
-RP
From: Keith Burns <alagalah@gmail.com>
Date: Monday, October 19, 2015 at 9:25 PM
To: "Guo, Ruijing" <ruijing.guo@intel.com>
Cc: Reinaldo Penno <rapenno@gmail.com>, Brady Allen Johnson <brady.allen.johnson@ericsson.com>, "sfc-dev@lists.opendaylight.org" <sfc-dev@lists.opendaylight.org>
Subject: Re: [sfc-dev] Classifier/RSP dependency
RSP should have no "direct" relationship to classifier.
I've just finised a patch to introduce type safety (ie convert all the Strings into things like RspName, SfcName etc).
Once it's tested and gone through review/discussion, I think we need to have a serious look at all the models.
I don't think the RSP model should contain ANY reference to the Classifier at all.
What RSPs a classifier is using is interesting for one functionality (ie potentially some notification) and what classifiers are using an RSP may also be interesting for path-selection (Scheduler) optimisation. But these things shouldn't be baked into the model at all.
On Mon, Oct 19, 2015 at 7:50 PM, Guo, Ruijing <ruijing.guo@intel.com> wrote:
Hi, All,
1. Recursive dependency between classifier/RSP.
I think only classifier can refer to RSP and RSP cannot refer to classifier. What do you think?
In rendered-service-path.yang:
rpc create-rendered-path {
leaf classifier {
}
leaf symmetric-classifier {
}
In service-function-classifier.yang & service-function-acl.yang
container service-function-classifiers
{
leaf access-list {
choice sfc-action {
leaf rendered-service-path
}
2. Configuration data store depends on Operation data store between classifier/RSP
Classifier is configuration data store and RSP is operation data store. Is it an issue?
If controller reboot, operation data store is missing and configuration data store exists?
Thanks,
-Ruijing
_______________________________________________
sfc-dev mailing list
sfc-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/sfc-dev