Hello Anil,
My inputs inline below
Thanks,
Prasanna
From: Anil Vishnoi [mailto:[email protected]]
Sent: 02 March 2017 13:22
To: Abhijit Kumbhare <[email protected]>
Cc: Prasanna Huddar <[email protected]>;
[email protected]; Kanagasundaram K
<[email protected]>
Subject: Re: [openflowplugin-dev] Proposed Reconciliation framework
Hi Prasanna,
I liked the idea of notifying the applications once the node is reconciled and
ready for further configuration. I have few questions about the proposed
framework in the context of single node + current master-slave implementation:
(1) I think following is not the case, for sure not for FRM, and i believe for
FRM-Sync as well
Slide-4:
"If Reconciliation fails the ODL disconnects the switch, and the whole process
is repeated by Re-sync and application
Applications start acting on OF switch which is in “unknown” state, which
should be avoided."
[Prasanna]: Ok, Will reword/ update. If Re-sync fails only options is
reconnect the switch.
(2) Slide-8:
"Application(s) registering with Reconciliation module is encouraged since:
Applications would know the right Flows and group which needs to be replayed
with write operation(Add / delete / update).
FRM / FRS would not have application view of flows / group, it would blindly
replay the flows / groups.
Also flows having idle / hard timeout can be gracefully handled by application
rather than FRM / FRS."
Are we assuming the application won't maintain the correct configuration in the
data store ?
[Prasanna]:
No, FRM / FRS would have the right information in data-store, but FRM / FRS
will push all the flows blindly, whereas application can push optimized set of
flows, as covered in couple of points below.
I believe meter and group always need to be programmed before flow, so is there
any other variance of ordering where we want application to do the
reconciliation ?
[Prasanna]:
Yes, once FRM / FRS or application registers with Reconciliation module,
the algorithm implemented by application can handle all these variances,
algorithm related info are just reccomendations.
If the flows are installed with idle/hard timeout, we should expect application
to remove it from data store. Unfortunately data store can't help much here, so
application will have to take this burden.
[Prasanna]:
Agree, but some flow timeouts can happen when Switch is Disconnected from
switch, timeout information is available only in application, using this info
application can re-program the flows as part of re-sync or exclude it.
So we really keep the clear contract with respect to data store, i don't really
see any reason, why we should leave the node reconciliation to application.
Plugin should do the reconciliation based on the config state in the data store
and once it's done with that reconciliation, it can notify application to
reconcile it's business logic.
Also in case of controller restart, the only state application will have is in
config data store, and until and unless they run their business logic they
can't figure out the correct ordering. And they can't run the business logic
because there is no node advertized to them yet.
[Prasanna]:
Regarding Plugin implementing the Reconciliation;
Agree, but plugin should run it as separate bundle, which would be enabled
/ disabled through flag.
1. Since, OVS might support Bundles , but community plugin cannot accept
all other users to use OVS.
a. So, we need to give them option to use their own algorithm(separate
bundle)
b. If future a better algorithm comes up user should be able to move to it
without dependencies.
c. Reconciliation framework infra should work irrespective of
Reconciliation algorithm.
Regarding node advertisement:
1. Agree, node is not advertised to application.
2. But as part of Reconciliation call-back / notification, reconciliation
framework calls the call back function or notification with switch information.
a. This switch information can be used by application to decide which
flows has to be re-programmed.
i. Timer is
one option to filter out flows.
(3) If we leave the reconciliation to the applications, and assume that two
applications are using the same node, do we expect that both the application
will have to use the similar kind of reconciliation mechanism? Assuming one
wants to use bundle or one want to use the vanilla reconciliation mechanism
that we have? If not, who will win? If yes, how we will implement it at the
plugin level, because bundle's like features are provided at the plugin level.
So basically i don't see how you can implement different reconciliation methods
without depending on the plugin. I can see that you can use one method for
reconciling specific node, but then all the application using that node need to
use the same method. By doing that we are basically pushing switch specific
reconciliation to the application level, and in my opinion that's not a good
idea.
[Prasanna]:
We are completely dependent on plugin for all the contracts to
push the flows(meter/flows/groups/etc) down to the switch.
That is why we say Plugin registers with RPC than invokes Reconciliation
framework.
We do not accept the application to use the same method, but
anything related to algorithm are just recommendation by this framework.
Scenario;
1. Consider App1 and App2 have registered to Reconciliation framework.
2. Plugin gives different contracts to program
flows(flows/group/meter/etc).
a. General flows.
b. Flows with barrier message.
c. Flows using bundles.
3. App1 and App2 can use any construct of plugin to program the flows.
We can discuss this more if needed in one of the upcoming calls.
(4) slide-9
"Check if Reconciliation is needed, if yes, update the DS status of the Switch
and go to Step 6"
Given that switch is not yet in data store, what really we want to update in
the data store? Also i didn't find the step 6 in the slides.
[Prasanna]
“ Given that switch is not yet in data store, what really we want to update in
the data store? Also i didn't find the step 6 in the slides.”
Typo will be corrected, no DS reference is needed
Sorry, Updated the slide just check, no idea with gdrive conversions.
(5) slide-10
"9.Application(s) would also wait for error from switch, for pre-defined time."
Why do we need to wait for pre-define time?, given that the current API-s do
return the future and future will fail if the configuration on switch fails.
[Prasanna]:
Ah, than not needed.
(6) slide -10
"10.Application(s) would inform the Reconciliation status to Reconciliation
module."
How long does plugin wait on the application to notify?
[Prasanna]:
We can make it configurable.
(7) Proposal says that if any of the application is not able to reconcile
successfully, it should disconnect the device. Assume out of 2 application, one
application is able to reconcile and other one failed, how do disconnecting the
switch will help here ? is there any scenario where we expect different outcome
once switch re-connect?
[Prasanna]:
Are you suggesting:
When Reconciliation fails, whether to disconnect or not should be left to
solution?
- Is yes, agree.
(8) If we push the node reconciliation to applications, are we assuming that
they will use the RPC for flow installation during the reconciliation ?
[Prasanna]:
Yes, we are registering the RPC methods with before invoking the
Reconciliation framework.
But this is not hard requirement, again this is just framework, which should be
flexible for future needs.
We can discuss further in one of the calls after Carbon release(or separate
call early, since Carbon is on priority), which is round the corner.
Thanks
Anil
On Wed, Feb 22, 2017 at 9:34 AM, Abhijit Kumbhare
<[email protected]<mailto:[email protected]>> wrote:
Just to clarify - this reconciliation workflow as well as bundles based
reconciliation being discussed is for the next release (Nitrogen) and not part
of Carbon. The basic bundles support can be code reviewed & merged as it is a
stretch goal item in the Carbon release plan - however it will not be used by
reconciliation or any other application in Carbon.
On Wed, Feb 22, 2017 at 4:35 AM, Prasanna Huddar
<[email protected]<mailto:[email protected]>> wrote:
Hello All,
Please review the proposed new Reconciliation workflow and provide your
inputs.
Link to the document(1st draft):
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Reconciliation#Future_Enhancements
Thanks,
Prasanna
_______________________________________________
openflowplugin-dev mailing list
[email protected]<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________
openflowplugin-dev mailing list
[email protected]<mailto:[email protected]>
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
--
Thanks
Anil
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
