[openstack-dev] [networking-sfc] What resources can and can't be reused
Duarte Cardoso, Igor
igor.duarte.cardoso at intel.com
Mon Feb 13 19:11:49 UTC 2017
Hi networking-sfc,
As part of my work regarding SFC Encapsulation and SFC Graphs, I exercised the API to understand exactly what resources can be reused, to possibly relax a few of the constraints when a chain is encapsulated end-to-end.
I'm requesting that the leaders and cores take a look at the list below, and reply if you see something that doesn't look quite right (or have any other comment/question). Thanks!
1. Every flow-classifier must have a logical source port.
2. The flow-classifier must be unique in its (full) definition.
3. A port-chain can have multiple flow-classifiers associated with exactly the same definition BUT different logical source ports.
4. The port-chains can be ambiguous, i.e. match on the same classification criteria, if and only if there are 0 flow classifiers associated.
5. The flow classifiers can only be used once, by a single port-chain.
6. Different port-chains cannot be associated to different flow classifiers that specify the same classification criteria BUT different logical source ports (this is https://bugs.launchpad.net/networking-sfc/+bug/1638421).
7. A port-pair's ingress cannot be in use by another port-pair's ingress.
8. A port-pair's egress cannot be in use by another port-pair's egress.
9. A port-pair can be associated to another port-pair's ingress and egress ports BUT swapped (i1=e2, e1=i2).
10. The port-pairs become "in use" when a port-pair-group associates them, so they can't be reused across port-pair-groups.
11. A port-chain can include port-pair-groups already associated to other port-chains, as long as not the exact same sequence as another port-chain (e.g. pc1: [ppg1,ppg2]; pc2: [ppg1] - is fine).
Best regards,
Igor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170213/c9e0ca0a/attachment.html>
More information about the OpenStack-dev
mailing list