© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
Since #1583299 is now marked as a duplicate of this bug, please ignore post #23.
I'm moving the proposed model here:
The Common Classifier model should be both explicit and extensible.
This figure shows the model proposed: [1].
Separating the traffic classification in individual types will allow future types to be added and agreed in the future, while keeping the remaining ones intact. Existing types can of course be updated and properly versioned. Looking at the neutron-classifier project, I already see hints of an architecture like this one, as can be seen in [2], so maybe there's already some interest in this approach.
So, how to define this model and how can it be used?
- The Common Classifier allows Classification Rules to be defined and used by an OpenStack service.
- 1 Classification Rule is of a single type, e.g. either Ethernet, IP, or HTTP, and contains a definition that depends on the type.
- The definition contains the fields that the type supports.
- Not all supported fields need to be defined - only the ones required by the consuming service.
- The consuming service should contain any additional logic, such as:
- AND/ORing many Classification Rules (CRs), if needed;
- Setting directionality constraints on the CRs, if needed;
- Scoping the CRs to local resources (e.g. Neutron ports), if needed;
- Other logic or local constraints.
[1] http://
[2] https:/