Igor, For #6, the requirement on source-port for a flow-classifier is only for the OVS driver. This is not a restriction for other backend drivers. In the case where there is no need for a sfc proxy to re-classify traffic returned from the egress port of a SF, i.e., the SF is NSH-aware and it can receive, process and return the NSH, this restriction does not apply. - Louis
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Monday, February 13, 2017 12:27 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be reused Hi Cathy, Relax only a couple of them. For Ocata I'm looking at disabling #6 if the chain/graph doesn't include sfc proxies (#6 seems to only be necessary if there are sfc proxies [1]). For Pike it would be interesting to make port-pair-groups completely reusable, as long as the flow classifiers don't make the choice of chain ambiguous. [1] http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-01-12-17.14.log.html Best regards, Igor. From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com] Sent: Monday, February 13, 2017 7:50 PM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [networking-sfc] What resources can and can't be reused Hi Igor, Before we dive into evaluation of the rules you listed below, I would like to understand whether you are suggesting to enforce the rules or relax the rules/constraints you listed? Could you clarify it? Thanks, Cathy From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Monday, February 13, 2017 11:12 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [networking-sfc] What resources can and can't be reused 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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
