Hi all,
@Arun, @Gobi, please feel free to add anything which I might have missed out
from our discussions
Context :
=======
During last OFPlugin weekly call, we were discussing about how bundle-based
resync flow would behave in upgrade context. In normal resync scenarios - ie.
a) switch reconnecting and/or b) controller reboots (and subsequent switch
reconnects), flows and groups which can be dispatched via resync bundle is
sourced from the inventory Config DS. In case of upgrade, inventory Config DS
would be completely nuked and hence a different handling is required. During
this discussion, a concern was raised as to why OFPlugin should become
extensively cognizant of "upgrade" as a special case. The thought process was
more to expose the bundle service generically from OFPlugin's end so that
upgrade-orchestration becomes a higher level functionality without switching
behaviors from with OFP
So, following this mail boostraps the discussions with following approaches and
choosing an approach which is less invasive. We can continue to discuss the
merits, demerits and fine-tune the approach to arrive at an agreeable mechanism.
Premises :
=======
1) Bundle construct is currently used in Reconciliation and Resync context
2) The objective is to expose bundle as a generic construct for applications to
use whenever a set of flows and/groups have to be provisioned to the switch in
"atomic" manner
3) Usage scenarios
a) Common bundle shared across applications - usage example - coordinated
resync
b) Enabling applications to use bundles with specific set of constraints
if the merit of atomicity provided by bundles offsets the constraints (see
approach 2)
Bundle lifecycle :
===========
Approach 1 :
========
Tying up bundle permanently with a flow/group at DS level optionally. In other
words, a given flow is always associated with a fixed bundle-id. This can
tantamount to adding non-persistable (config = false) bundle-id attribute to
flow and group models. This appears to be a very rigid approach which would not
be flexible to associate flows and groups with different bundles for different
scenarios (normal operations and resync - to be specific)
Approach 2 :
========
Allowing applications to create and close the bundle with not more than one
bundle active per switch.
All groups and flows provisioned during the window of create and close of the
bundle by a given application can be pushed in context of the current-active
bundle. This approach has a benefit that flow / group object in DS need not
explicitly refer the bundle. But separate flavor of flow and group add/mod/del
API
needs to be invoked by apps to indicate that corresponding flows and group
actions have to be encapsulated within a bundle. It would be the responsibility
of
the application to close the bundle explictly
Approach 3 :
========
Keeping bundle(s) as floating, leasable, non-persistent resouce(s) which can be
associated with one or more flows/groups combination. Application functionality
- resync being one of them, can lease one or more bundle(s) as required from a
pool of bundles, associate the same with a switch and start using the same.
Some involved yang-modeling and service-logic would be required for providing
such leasing service and corresponding validation logic (eg. handling normal
releasing and abnormal releasing - lease-onwer node dies etc.) would require a
non-trivial service implementation and testing for various failure scenarios.
But this approach would be provide more flexibility from usage perspective.
Approach 2 appears to be less invasive and is nothing but a special case of
Approach 3 (of course we can discuss on any other approaches and agree upon a
more acceptable way forward)
Common model change across these approaches is following (assuming we choose
Approach 2)
=============================================================
1) A separate bunde-list to be added as child to flowcapablenode - to represent
generic 1:MANY relationship between switch and bundle for future extensions
2) Each element of bundle-list shall be a bundle object which has attributes -
bundle-id, bundle-status (OPEN|CLOSE), bundle-type (REGULAR for now and can
be added with additional enum values to provide one more level of
indirection in future if we want to add types like RESYNC - for example in
future)
3) Especially for supporting approach-2, there must not be more than 1 bundle
active for a DPN at any point in time. This should be imposed as a constraint in
the bundle-list. If we have more than 1 bundle active, then there must be
explicit mapping of flow and group entities to respective bundles
CRUD Handling of new bundle in bundle-list (assuming we choose Approach 2)
==================================================
1) Applications create a common shared bundle
(bundle-id=<bundle-id;bundle-status=OPEN;bundle-type=REGULAR> under bundle-list
and subsequently invoke special flowmod and groupmod APIs (to indicate that
corresponding flow-mods and group-mods are to be added in context of OPEN'ed
bundle)
2) Bundle created under bundle-list can be disposed as part of nodal reboot
(since the bundle-list is operational in nature)
3) Bundle gets updated only for close status. ie. when applications decide to
close bundle which they have opened
4) Bundle is read mainly by OFPlugin via DTCN to get update events on bundle
OPENing and CLOSing (for initial case, this would be mainly for triggering
resync)
E2E flow (assuming Approach 2) :
======================
The proposal is to use
a) Reconciliation API which is present in OFPlugin to announce the
available of switch to apps
b) In reaction, apps OPEN a bundle using the approach 2 and push flows
and/or groups
c) When completed, application can CLOSE
Please see "app" referred above as normal resync or upgrade-specific resync
functionality and not in general notion of visualizing apps as ITM, IFM or
L3VPN service
Let us continue the discussion during next week's call as well as over this
mail chain
Regards
Muthu
_______________________________________________
openflowplugin-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
