Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

[Cathy Zhang]

Hi Rajeev,

There is no meter yet. I think it is a good idea to add it.
Would you like to share your thought in more detail?

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, June 26, 2017 2:37 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for 
Networking-SFC

Hi Rajeev, there are no meters as far as I know and I'm not aware of any plans 
at the moment.
What else do you have in mind in terms of monitoring?

Best regards,
Igor.

From: rajeev.satyanaray...@wipro.com 
[mailto:rajeev.satyanaray...@wipro.com]
Sent: Sunday, June 25, 2017 1:10 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ceilometer][networking-sfc] Meters/Statistics for 
Networking-SFC


Hi All,



I am interested to know if there are any meters available for monitoring SFC 
through ceilometer, like no.of flows associated with an SFC or packets in/out 
for an SFC etc?

If they are available, please let me know how to configure and use them. If 
not, are there any plans of providing support to them in coming releases?



Thanking you,



Regards,

Rajeev.
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
__
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

Re: [openstack-dev] [networking-sfc] About insertion modes and SFC Encapsulation

[Cathy Zhang]

Hi Igor,

Moving the correlation from port-pair to port-pair-group makes sense. In the 
future I think we should add all new attributes for a SF to 
port-pair-group-param.

But I think L2/L3 is different from encap type NSH or MPLS. An L3 type SF can 
support either NSH or MPLS. I would suggest the following:

port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
   Correlation:
- MPLS
- NSH
tap-enabled:
- False (default)
- True

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, March 20, 2017 8:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi networking-sfc,

At the latest IRC meeting [1] it was agreed to split TAP from the possible 
insertion modes (initial spec version [2]).

I took the ARs to propose coexistence of insertion modes, correlation and (now) 
a new tap-enabled attribute, and send this email about possible directions.

Here are my thoughts, let me know yours:


1.   My expectation for future PP and PPG if TAP+insertion modes go ahead 
and nothing else changes (only relevant details outlined):

port-pair (service-function-params):
correlation:
- MPLS
- None (default)
port-pair-group (port-pair-group-params):
insertion-mode:
- L2
- L3 (default)
tap-enabled:
- False (default)
- True


2.   What I propose for future PP and PPG (only relevant details outlined):

port-pair (service-function-params):

port-pair-group (port-pair-group-params):
mode:
- L2
- L3 (default)
- MPLS
- NSH
tap-enabled:
- False (default)
- True

With what's proposed in 2.:
- every combination will be possible with no clashes and no validation required.
- port-pair-groups will always group "homogeneous" sets of port-pairs, making 
load-balacing and next-hop processing simpler and consistent.
- the "forwarding" details of a Service Function are no longer dictated both by 
port-pair and port-pair-group, but rather only by port-pair-group.

Are there any use cases for having next-hop SF candidates (individual 
port-pairs) supporting different SFC Encapsulation protocols?
I understand, however, that removing correlation from port-pairs might not be 
ideal given that it's a subtractive API change.

[1] 
http://eavesdrop.openstack.org/meetings/service_chaining/2017/service_chaining.2017-03-16-17.02.html
[2] https://review.openstack.org/#/c/442195/
[3] 
https://github.com/openstack/networking-sfc/blob/17c537b35d41a3e1fd80da790ae668e52cea6b88/doc/source/system_design%20and_workflow.rst#usage

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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Cathy Zhang]

Just completed.

Cathy

From: Jeffrey Zhang [mailto:zhang.lei@gmail.com]
Sent: Friday, March 03, 2017 6:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

any update for releasing stable/ocata branch or tag? It is Mar already.

On Tue, Feb 21, 2017 at 1:23 AM, Henry Fourie 
> wrote:
Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary

__
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



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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

Re: [openstack-dev] [networking-sfc] PTG notes

[Cathy Zhang]

Hi Bernard,

Thanks for the notes! I just talked with Louis. We will pull the stable branch 
for networking-sfc today. 
I hope after the branch is pulled, everyone can help doing more testing on the 
stable branch to make it more stable:-)

Thanks,
Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, February 28, 2017 7:04 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] PTG notes

Hi,

I will miss the next two IRC meetings, so here is a quick summary email of PTG 
topics of interest for networking-sfc in the Pike cycle.

* Release, stable branching, stadium requirements For Ocata, neutron-lib 
patches are waiting for our stable branch creation (should be OK today?). The 
release itself is not as urgent, so we can still run some tests after merging 
the last open feature [0], and before tagging the release For Pike, stadium 
projects will synchronize releases with neutron [1] Except from more generic 
requirements, no new specific requirements to expect in this cycle

* Tempest tests
Two interesting items here:
 * Split tempest plugin repositories [2]: if agreed we will move the tempest 
plugin in a separate branchless repository (and proper configuration depending 
on features)
 * Refactor of tempest scenario base classes [3]: we will probably have to keep 
our copy of manager.py, and update to new API when it is ready

* Python 3.5 support
This is a project-wide goal for Pike, we have python3 unit tests already, but 
we should add a tempest/python3 check, and make it work (without forgetting the 
currently buggy multinode check)

* neutron-lib hacking checks
These are additional PEP8 checks we should enable as a neutron-lib consumer 
project. Some changes are underway [4], but we should enable these in 
networking-sfc

* API updates
Changes need to be advertised via a new extension (SFC graphs current review)

* Push notifications
This is in progress for Neutron [5], but can be nice for stadium projects too

* Common classifier
This probably deserves its separate topic, but we had an interesting session 
(possible consumers: networking-bpvpn, networking-sfc, FWaaS, QoS, 
Tap-as-a-Service, …) [6]


The completed neutron etherpad is at [7], with Kevin's nice summary at [8] I 
leave it to other PTG attendees to correct/extend this list!

[0] https://review.openstack.org/#/c/420339/
[1] https://review.openstack.org/#/c/437699/
[2] https://etherpad.openstack.org/p/qa-ptg-pike-tempest-plugins
[3] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112938.html
[4] http://lists.openstack.org/pipermail/openstack-dev/2017-February/112988.html
[5] https://blueprints.launchpad.net/neutron/+spec/push-notifications
[6] https://review.openstack.org/#/c/333993/
[7] https://etherpad.openstack.org/p/neutron-ptg-pike-final
[8] http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html

--
Bernard Cafarelli

__
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
__
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

Re: [openstack-dev] [networking-sfc] Stable/Ocata Version

[Cathy Zhang]

We have been preparing for the ocata release. We are currently working on 
getting some final patches reviewed and merged.
Once those are merged, we will pull a stable/ocata branch around end of Feb or 
early March the latest.

Thanks,
Cathy

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Sunday, February 19, 2017 4:29 AM
To: OpenStack List
Subject: [openstack-dev] [networking-sfc] Stable/Ocata Version

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary
__
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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Cathy Zhang]

Hi Igor,

The list of rules are correct.

Best regards,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, February 13, 2017 1: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 Louis,

Yes, that makes sense - thanks for the feedback and the responses on my points.

Best regards,
Igor.

From: Henry Fourie [mailto:louis.fou...@huawei.com]
Sent: Monday, February 13, 2017 9:15 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

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

Re: [openstack-dev] [networking-sfc] What resources can and can't be reused

[Cathy Zhang]

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

Re: [openstack-dev] [networking-sfc]

[Cathy Zhang]

There is a SFC Horizon code patch available. And our presentation video GUI is 
based on that. 

Louis/Vikram,

I am on business trip and have difficulty to access some openstack links. Could 
you share the link to our SFC Horizon work?

Thanks,
Cathy

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, January 24, 2017 9:31 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc]

On 20 January 2017 at 00:06, Michael Gale  wrote:
> Hello,
>
> Are there updated install docs for sfc? The only install steps for 
> a testbed I can find are here and they seem outdated:
> https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
There is also a SFC chapter in the networking guide:
http://docs.openstack.org/newton/networking-guide/config-sfc.html

Which parts do you find outdated? Some references to Ubuntu/OVS versions may 
need a cleanup, but the design and API parts should still be OK (OSC client, 
SFC graph API, symmetric ports and other goodies are still under review and not 
yed merged)

> Also from the conference videos there seems to be some Horizon menu / 
> screens that are available?
Not for networking-sfc directly, but there is a SFC tab in the tacker horizon 
plugin (or will be, someone from the tacker team can confirm
that)


--
Bernard Cafarelli

__
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

__
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

Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow classifiers

[Cathy Zhang]

This clash check was added on purpose to avoid the ambiguity of the following 
scenario (This is just one of many similar scenarios):

VM2, VM3 hosted on Int-Bridge1 of Server1
VM4 hosted on Int-Bridge2 of Server2
VM5 hosted on Int-Bridge3 of Server3

Chain1: VM1, VM2, VM4
Chain2: VM1, VM3, VM5

Suppose FC1 for Chain1 and FC2 for Chain2 are the same except logical source 
port(Igor's testing scenario). 
If we allow this, then when the Int-Bridge1 on Server1 receives the packet from 
VM2 or VM3, it can not distinguish 
which chain the packet is associated with and thus don't know whether to 
forward the packet to VM4 or VM5  
since the packet's n-tuple classification is the same (logical source port is 
not carried in the packet). 

If the SF2 on VM2 and the SF3 on VM3 are chain-ID aware (eg. Supports NSH), 
then the ambiguity can be resolved and we can remove this check. 
Another alternative is to support a chain-ID-correlation mechanism between the 
SF and the vSwitch. 

Thanks,
Cathy

 

-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Thursday, January 12, 2017 7:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc] Limitation on port chains + flow 
classifiers

On 10 January 2017 at 14:13, Duarte Cardoso, Igor 
 wrote:
> Hi networking-sfc,
>
>
>
> While working on the SFC Graphs patch, I observed the following 
> limitation when creating port-chains: http://paste.openstack.org/show/594387/.
>
>
>
> My objective was to have 2 port-chains acting on the same 
> classification of traffic but from different logical source ports – my 
> expectation was that there wouldn’t be any clash here.
>
>
>
> However, the flow-classifiers clash when they are associated to those 
> 2 different port-chains.
>
>
>
> The exception is raised in [1] and the attributes of the 
> flow-classifier being checked are in [2], where neither logical source 
> port or logical destination port are specified.
>
>
>
> Is there a specific reasoning behind this or can it be considered a 
> bug? For the SFC Graphs work, it’s important that this limitation be 
> lifted – I’m happy to submit a patch to correct it.
>
> Let me know your thoughts.
>
>
>
> [1]
> https://github.com/openstack/networking-sfc/blob/9b4a918177768a036c192
> a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
>
> [2]
> https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f
> 408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

This must be the theme for this week's networking-sfc topic then, I ended up 
hitting the same problem while anylyzing the tempest race condition failures 
[1].

Each test creates a new port to use for its port pair, and a new flow 
classifier. The flow classifier has the same parameters, except for the source 
logical port (the related port is used here).
Apparently the test failure (a PortChainFlowClassifierInConflict
exception) is caused by a flow classifier from a previous test conflicting with 
the new one.

My thoughts here: this should indeed be allowed, and I think this restriction 
comes from an incorrect use of the *_conflict() functions
[2]: we should use the full flowclassifier_conflict() instead of 
flowclassifier_basic_conflict(), as it adds logical port conflict check and is 
the "main" conflict check function.
That is in fact the fix I just sent for review [3], local tempest runs went 
fine here. Feedback welcome!


[1] https://bugs.launchpad.net/networking-sfc/+bug/1655618
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L191
[3] https://review.openstack.org/#/c/419525/

--
Bernard Cafarelli

__
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
__
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

Re: [openstack-dev] [networking-sfc] Intermittent database transaction issues, affecting the tempest gate

[Cathy Zhang]

Hi Bernard,

Thanks for the email. I will take a look at this. Xiaodong has been working on 
tempest test scripts. 
I will work with Xiaodong on this issue. 

Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, December 20, 2016 3:00 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] Intermittent database transaction 
issues, affecting the tempest gate

Hi everyone,

we have an open bug (thanks Igor for the report) on DB transaction issues:
https://bugs.launchpad.net/networking-sfc/+bug/1630503

The thing is, I am seeing  quite a few tempest gate failures that follow the 
same pattern: at some point in the test suite, the service gets warnings/errors 
from the DB layer (reentrant call, closed transaction, nested rollback, …), and 
all following tests fail.

This affects both master and stable/newton branches (not many changes for now 
in the DB parts between these branches)

Some examples:
* https://review.openstack.org/#/c/400396/ failed with console log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/console.html#_2016-12-16_12_44_47_564544
and service log
http://logs.openstack.org/96/400396/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/c27920b/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_12_44_32_301
* https://review.openstack.org/#/c/405391/ failed,
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/console.html.gz#_2016-12-16_13_05_17_384323
and 
http://logs.openstack.org/91/405391/2/check/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/7e2b1de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-16_13_04_11_840
* another on master branch: https://review.openstack.org/#/c/411194/
with 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/console.html.gz#_2016-12-15_22_36_15_216260
and 
http://logs.openstack.org/94/411194/1/gate/gate-tempest-dsvm-networking-sfc-ubuntu-xenial/90633de/logs/screen-q-svc.txt.gz?level=WARNING#_2016-12-15_22_35_53_310

I took a look at the errors, but only found old-and-apparently-fixed pymysql 
bugs, and suggestions like:
* 
http://docs.sqlalchemy.org/en/latest/faq/sessions.html#this-session-s-transaction-has-been-rolled-back-due-to-a-previous-exception-during-flush-or-similar
*  https://review.openstack.org/#/c/230481/
Not really my forte, so if someone could take a look at these logs and fix the 
problem, it would be great! Especially with the upcoming multinode tempest gate

Thanks,
--
Bernard Cafarelli

__
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
__
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

Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

[Cathy Zhang]

Hi Igor,

Good idea. I will get this #networking-sfc channel registered. 

Thanks,
Cathy

-Original Message-
From: Ravi Sekhar Reddy Konda [mailto:ravisekhar.ko...@oracle.com] 
Sent: Wednesday, November 23, 2016 7:37 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1


Thanks,
Ravi Sekhar
- Original Message -
From: bcafa...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Wednesday, November 23, 2016 7:18:53 PM GMT +05:30 Chennai, Kolkata, 
Mumbai, New Delhi
Subject: Re: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

+1, a specific channel would be nice!

On 23 November 2016 at 13:09, Mohan Kumar  wrote:
> Yes , It will be good
>
> Thanks.,
> Mohankumar.N
>
> On Wed, Nov 23, 2016 at 4:56 PM, Duarte Cardoso, Igor 
>  wrote:
>>
>> Hi networking-sfc’s leaders, devs and users,
>>
>>
>>
>> What do you think about having an IRC channel dedicated to 
>> networking-sfc’s discussions and sync?
>>
>>
>>
>> For the time being  I have joined #networking-sfc @ freenode, and 
>> will stay online to keep it open.
>>
>>
>>
>> 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
>>
>
>
> __
>  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
>



--
Bernard Cafarelli

__
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

__
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
__
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

[openstack-dev] [Neutron][networking-sfc] No networking-sfc meeting at 1700 UTC on 11/24/2016

[Cathy Zhang]

Hi Everyone,

No meeting on 11/24/2016.

Happy Thanksgiving Holiday!

Cathy
__
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

[openstack-dev] [Neutron][networking-sfc] We will have networking-sfc meeting at 1700 UTC on 11/17/2016

[Cathy Zhang]

Hi Everyone,

We will cover the following topics:

1.   Newton release which has been completed

2.   Big Stadium assessment walk through (I think we have got all items 
taken care of with a few pending for Neutron driver team approval)

3.   Ocata Release time line

4.   Ocata release preparation: New Features planned for Ocata release

5.   Review patches and bug scrub

Feel free to add the topic you would like to discuss. Please double check your 
local time for 1700 UTC. For pacific time zone, it is 9am instead of 10am now.

Thanks,
Cathy
__
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

Re: [openstack-dev] [networking-sfc][devstack][mitaka] Chain doesn't work

[Cathy Zhang]

Hi Alioune,

SFC is working fine. Your problem is with configuration of your specific 
Service Function.
AFAIK, Farhad has responded to your question before.
https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg95199.html

Thanks,
Cathy

From: Alioune [mailto:baliou...@gmail.com]
Sent: Wednesday, November 02, 2016 5:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Mohan Kumar
Subject: Re: [networking-sfc][devstack][mitaka] Chain doesn't work

Any suggestion ?

On Monday, 24 October 2016, Alioune 
<baliou...@gmail.com<mailto:baliou...@gmail.com>> wrote:
Hi all,
I'm trying to implement service chain in OpenStack using networking-sfc 
(stable/mitaka) and OVS 2.5.90

The following is the architecture I used :

SRC DST
  ||
  == br-int 
 |
   SF1
SF1: 55.55.55.3
SRC: 55.55.55.4
DST: 55.55.55.5

I can create port-pairs, port-pair-group, classifier and chain with these 
commands:

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix 
55.55.55.4/32<http://55.55.55.4/32>  --logical-source-port 
0009034f-4c39-4cbf-be7d-fcf82dad024c  --protocol icmp  FC1
neutron port-pair-create --ingress=p1 --egress=p1 PP1
neutron port-pair-group-create --port-pair PP1 PG1
neutron port-chain-create --port-pair-group PG1 --flow-classifier FC1 PC1
I could ping from SRC to DST before setting the chain, but after the chain 
creating ping doesn't work.
ICMP echo request packets arrive to SF1 port but it doesn't send back the 
packets in order to allow them to get their destination DST (see output below).
The Opendaylight/SFC project uses NSH aware service function (SF) that send 
back packets to the chains after analyzing them, I would like to know :
- How networking-sfc configures SF to send back packets to the chain as seem in 
some of your presentation ?
- What's wrong in my configurations (see commands and ovs-ofctl output below) ? 
I've followed the main steps described in your wiki page.
Best Regards,


vagrant@vagrant-ubuntu-trusty-64:~$ neutron port-list
+--+--+---+--+
| id   | name | mac_address   | fixed_ips   
 |
+--+--+---+--+
| 0009034f-4c39-4cbf-be7d-fcf82dad024c |  | fa:16:3e:dd:16:f7 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.4"}|
| 082e896d-5982-458c-96e7-0dd372d3d7d9 | p1   | fa:16:3e:90:b4:67 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.3"}|
| 2ad109e4-42a8-4554-b884-a32344e91036 |  | fa:16:3e:74:9a:fa | 
{"subnet_id": "3cf6eb27-7258-4252-8f3d-b6f9d27c948b", "ip_address": 
"192.168.105.2"} |
| 51f055c0-ff4d-47f4-9328-9a0d7ca204f3 |  | fa:16:3e:da:f9:93 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.1"}|
| 656ad901-2bc0-407a-a581-da955ecf3b59 |  | fa:16:3e:7f:44:01 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.2"}|
| b1d14a4f-cde6-4c44-b42e-0f0466dba32a |  | fa:16:3e:a6:c6:35 | 
{"subnet_id": "8bf8a2e1-ecad-4b4b-beb1-d760a16667bc", "ip_address": 
"55.55.55.5"}|
+--+--+---+--+

vagrant@vagrant-ubuntu-trusty-64:~$ ifconfig |grep 082e896d
qbr082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvb082e896d-59 Link encap:Ethernet  HWaddr b6:96:27:fa:ab:af
qvo082e896d-59 Link encap:Ethernet  HWaddr 7e:1a:7b:7d:09:df
tap082e896d-59 Link encap:Ethernet  HWaddr fe:16:3e:90:b4:67

vagrant@vagrant-ubuntu-trusty-64:~$ sudo tcpdump -i tap082e896d-59 icmp
tcpdump: WARNING: tap082e896d-59: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap082e896d-59, link-type EN10MB (Ethernet), capture size 65535 
bytes
10:51:10.229674 IP 55.55.55.4 > 55.55.55.5<http://55.55.55.5>: ICMP echo 
request, id 15617, seq 61, length 64
10:51:11.230318 IP 55.55.55.4 > 55.55.55.5<http://55.55.55.5>: ICMP echo 
request, id 15617, seq 62, length 64
10:51:12.233451 IP 55.55.55.4 > 55.55.55.5<http://55.55.55.5>: ICMP echo 
request, id 15617, seq 63, length 64
10:51:13.234496 IP 55.55.55.

[openstack-dev] [Neutron][networking-sfc] No networking-sfc meeting for 11/3/2016. We will resume our project meeting on 11/10/2016

[Cathy Zhang]

__
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

Re: [openstack-dev] [Neutron][networking-sfc] OpenStack Summit Barcelona: networking-sfc project team lunch meetup

[Cathy Zhang]

Hi Reedip,

I have two presentations today, one before lunch and another after lunch. Would 
you like to meet after my presentation (1:50pm~2:30pm) at room CCIB 212 ?

Thanks,
Cathy

From: reedip banerjee [mailto:reedi...@gmail.com]
Sent: Wednesday, October 26, 2016 4:51 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][networking-sfc] OpenStack Summit 
Barcelona: networking-sfc project team lunch meetup


Hi Cathy,
Sorry, we missed the discussion today.
TaaS team would also like to have a discussion for the SFC, and we are present 
here in Barcelona.
Can we meet up tomorrow in the AC hotel for Lunch?

On Oct 25, 2016 23:56, "Cathy Zhang" 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Stephen,

Sorry to miss you. It will be a social get together at lunch, no specific 
agenda, open topic. We can update you and others for any technical discussion 
if any in  the next IRC meeting.

Cathy

From: Stephen Wong 
[mailto:stephen.kf.w...@gmail.com<mailto:stephen.kf.w...@gmail.com>]
Sent: Tuesday, October 25, 2016 8:49 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron][networking-sfc] OpenStack Summit 
Barcelona: networking-sfc project team lunch meetup

Hi Cathy,

Sorry, I won't be attending the summit. Will there be an etherpad to 
capture what is going to be discussed regarding networking-sfc during the 
summit? If so, please post the link.

Thanks,
- Stephen

On Tue, Oct 25, 2016 at 6:38 AM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Let’s meet for lunch at the AC Buffet lunch room (not the CCIN buffet lunch 
area) at 1pm Wednesday.
Anyone interested in service function chaining solution is welcomed to join.

Thanks,
Cathy


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

Re: [openstack-dev] [Neutron][networking-sfc] OpenStack Summit Barcelona: networking-sfc project team lunch meetup

[Cathy Zhang]

Hi Stephen,

Sorry to miss you. It will be a social get together at lunch, no specific 
agenda, open topic. We can update you and others for any technical discussion 
if any in  the next IRC meeting.

Cathy

From: Stephen Wong [mailto:stephen.kf.w...@gmail.com]
Sent: Tuesday, October 25, 2016 8:49 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron][networking-sfc] OpenStack Summit 
Barcelona: networking-sfc project team lunch meetup

Hi Cathy,

Sorry, I won't be attending the summit. Will there be an etherpad to 
capture what is going to be discussed regarding networking-sfc during the 
summit? If so, please post the link.

Thanks,
- Stephen

On Tue, Oct 25, 2016 at 6:38 AM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Let’s meet for lunch at the AC Buffet lunch room (not the CCIN buffet lunch 
area) at 1pm Wednesday.
Anyone interested in service function chaining solution is welcomed to join.

Thanks,
Cathy

__
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

[openstack-dev] [Neutron][networking-sfc] OpenStack Summit Barcelona: networking-sfc project team lunch meetup

[Cathy Zhang]

Let's meet for lunch at the AC Buffet lunch room (not the CCIN buffet lunch 
area) at 1pm Wednesday.
Anyone interested in service function chaining solution is welcomed to join.

Thanks,
Cathy
__
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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Cathy Zhang]

+1

From: Miguel Lavalle [mailto:mig...@mlavalle.com]
Sent: Friday, October 14, 2016 11:31 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Dear Neutrinos,
I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm
It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.
Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel
__
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

Re: [openstack-dev] [ovs-discuss] [ovn][networking-sfc]

[Cathy Zhang]

The guide is the networking-ovn guide. Not sure what is meant by 
“port-security”. From networking-sfc point of view, security group is not 
needed.

Thanks,
Cathy

From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of Murali R
Sent: Monday, October 10, 2016 2:47 PM
To: discuss; OpenStack Development Mailing List (not for usage questions)
Subject: [ovs-discuss] [ovn][networking-sfc]

Networking-sfc and ovn install guide says "port_security" must be enabled when 
enabling networkin-sfc  (networking-ovn/doc/source/install.rst -- line 165)

In my use cases it gets too complicated if I use port-security, so was 
disabling it.

Please let me know if there is any hard requirement that this MUST be enabled 
in Neutron?

-Murali

__
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

Re: [openstack-dev] [networking-sfc][devstack][mitaka]

[Cathy Zhang]

Hi Navdeep,

Please see inline.

Cathy

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Tuesday, October 11, 2016 5:42 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi all,

I have been trying out networking-sfc to create service function chain in 
Openstack. I could create all the port pairs, port-pair-groups, flow classifier 
and the chain but I could not see the packets on the desired hops.
I am trying to create a simple sfc with 3 VMs(vm1 to vm3) in the setup. I just 
want to check how it works. In my setup, vm1 is the Traffic generator(iperf) 
and vm3 is the traffic receiver(iperf server). Now, the  2 vms (vm2 and 3) are 
in the same network with vm1 and I want to move the iperf traffic from 
vm1->vm2->vm3. In order to achieve this, I have created 2 port pairs of vm2  
and vm3 and both pairs are in separate port pair groups (PG1 and PG2), also 
created a Flow classifier FC1 and finally chain with PG1, PG2 and FC1.  Now my 
question is, is my setup correct in order to achieve the sfc result as I stated 
above? Do I need to include the vm1 in the port pair group?

Cathy> You only need to include VM2 in a port pair group. Traffic source and 
traffic destination do not need to be included in the chain's port pair group, 
instead their IP addresses should be included in the flow classifier so that 
the system knows which flow needs to go through the chain. Here is a link to 
thw wiki.
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Cathy




Below is the flow classifier:

++--+
| Field  | Value
|
++--+
| description  |
  |
| destination_ip_prefix   |  |
| destination_port_range_max |  |
| destination_port_range_min |  |
| ethertype| IPv4   
  |
| id | 
e5000ade-50ad-41ed-a159-b89c4blp97ec |
| l7_parameters  | {}   
|
| logical_destination_port   |  |
| logical_source_port   | 63cdf664-dd67-455c-8345-f01ef58c23e5 |
| name| FC1 
 |
| project_id   | 
6b90cd3356144681b44274d4881c5fc7 |
| protocol  | tcp   
   |
| source_ip_prefix  | 10.0.0.18/32  
   |
| source_port_range_max  |  |
| source_port_range_min  |  |
| tenant_id | 
6b90cd3310104681b44274d4881c5fc7 |
++--+



Is there any wiki with some example case explained with testing scenario?


Best Regards,
Navdeep Uniyal
Email: navdeep.uni...@neclab.eu
-
Software Engineer
NEC Europe Ltd.
NEC Laboratories Europe
Kurfürstenanlage 36, D-69115 Heidelberg,

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, HA4 6QE, GB | Registered in England 2832014
__
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

Re: [openstack-dev] Removing required port-id from classifier

[Cathy Zhang]

Hi Anil,

Could you check the /etc/neutron/neutron.conf to make sure you are not using 
flow classifiers drivers=ovs? You can also check your DB schema to make sure it 
is not old and does not have the check for source port. 
Another alternative is to use the latest code and also make sure your DB is 
migrated to the latest DB. If you still see the problem, could you send out the 
log?  

Thanks,
Cathy

-Original Message-
From: Anil Vishnoi [mailto:avish...@brocade.com] 
Sent: Tuesday, October 04, 2016 3:08 PM
To: Cathy Zhang; Tim Rozet
Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam
Subject: Re: Removing required port-id from classifier

Hi Cathy,

I am using the networking-odl sfc driver in my setup and that does require the 
logical_port for the classifier, although i am using around one month old 
networking-sfc master branch code. Is this something recently changed ?

Thanks
Anil 

From: Cathy Zhang <cathy.h.zh...@huawei.com>
Sent: Tuesday, October 4, 2016 2:36 PM
To: Tim Rozet; Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam; Anil Vishnoi
Subject: RE: Removing required port-id from classifier

Hi Tim,



Please see inline.



Cathy



-Original Message-

From: Tim Rozet [mailto:tro...@redhat.com]

Sent: Tuesday, October 04, 2016 1:29 PM

To: Cathy Zhang

Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam; Anil Vishnoi

Subject: Re: Removing required port-id from classifier



Responses inline.



Thanks,



Tim Rozet

Red Hat SDN Team



- Original Message -

From: "Cathy Zhang" <cathy.h.zh...@huawei.com>

To: "Tim Rozet" <tro...@redhat.com>, "OpenStack Development Mailing List (not 
for usage questions)" <openstack-dev@lists.openstack.org>

Cc: "Sridhar Ramaswamy" <sric...@gmail.com>, "Sripriya Seetharam" 
<ssee...@brocade.com>

Sent: Tuesday, October 4, 2016 1:54:04 PM

Subject: RE: Removing required port-id from classifier



Hi Tim,



Please see inline.



Thanks,

Cathy



-Original Message-

From: Tim Rozet [mailto:tro...@redhat.com]

Sent: Tuesday, October 04, 2016 10:07 AM

To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang

Cc: Sridhar Ramaswamy; Sripriya Seetharam

Subject: [tacker] [networking-sfc] Removing required port-id from classifier



Hi Cathy,

I recall a while back discussing removing the required neutron port-id from the 
classifier.



Cathy> Do you mean logical source port here?

trozet> yeah the neutron_source_port seems required.



Cathy> This is only required if the backend is OVS SFC driver (not required if 
it is ODL SFC driver or other drivers). There are several reasons for this. For 
example, without neutron source port being specified, we have to install flow 
classification rules on every compute node to catch the traffic flow from the 
source and scalability will be a big issue if there are thousands of compute 
nodes. Another example is that if two tenants use a shared network and each has 
its flow originating from different source VMs and going through its own SFC in 
the shared network, OVS needs different logical source ports to distinguish 
different tenants' traffic flow. Is there any reason why you can not specify a 
neutron source port?





We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?



Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.

trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl driver 
for networking-sfc that supports NSH.

Can you link the patches or point me to who is working on the NSH support for 
the API/plugin DB layer?



Cathy> Here is the patch link 
https://urldefense.proofpoint.com/v2/url?u=https-3A__review.openstack.org_-23_c_373465_=DQIGaQ=IL_XqQWOjubgfqINi2jTzg=nNx-ccom3k8BhfkcqdGNBnq-5rteGW1CENWnxJvQP1M=UQNNvtujvkLCQr8XWkfqD3vDLIHnXj6PNYlMzCPvL2o=hm29JgqSH_6ZsobVL9vy5m5jEt7Q8laFNP2FmtCdo6c=









Thanks,



Tim Rozet

Red Hat SDN Team


__
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

Re: [openstack-dev] Removing required port-id from classifier

[Cathy Zhang]

Hi Tim,

Please see inline. 

Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 1:29 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam; Anil Vishnoi
Subject: Re: Removing required port-id from classifier

Responses inline.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Cathy Zhang" <cathy.h.zh...@huawei.com>
To: "Tim Rozet" <tro...@redhat.com>, "OpenStack Development Mailing List (not 
for usage questions)" <openstack-dev@lists.openstack.org>
Cc: "Sridhar Ramaswamy" <sric...@gmail.com>, "Sripriya Seetharam" 
<ssee...@brocade.com>
Sent: Tuesday, October 4, 2016 1:54:04 PM
Subject: RE: Removing required port-id from classifier

Hi Tim,

Please see inline.

Thanks,
Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 10:07 AM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Cc: Sridhar Ramaswamy; Sripriya Seetharam
Subject: [tacker] [networking-sfc] Removing required port-id from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  

Cathy> Do you mean logical source port here?
trozet> yeah the neutron_source_port seems required.

Cathy> This is only required if the backend is OVS SFC driver (not required if 
it is ODL SFC driver or other drivers). There are several reasons for this. For 
example, without neutron source port being specified, we have to install flow 
classification rules on every compute node to catch the traffic flow from the 
source and scalability will be a big issue if there are thousands of compute 
nodes. Another example is that if two tenants use a shared network and each has 
its flow originating from different source VMs and going through its own SFC in 
the shared network, OVS needs different logical source ports to distinguish 
different tenants' traffic flow. Is there any reason why you can not specify a 
neutron source port? 


We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?  

Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.  
trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl driver 
for networking-sfc that supports NSH.  
Can you link the patches or point me to who is working on the NSH support for 
the API/plugin DB layer?

Cathy> Here is the patch link https://review.openstack.org/#/c/373465/




Thanks,

Tim Rozet
Red Hat SDN Team
__
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

Re: [openstack-dev] Removing required port-id from classifier

[Cathy Zhang]

Hi Tim,

Please see inline.

Thanks,
Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 10:07 AM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Cc: Sridhar Ramaswamy; Sripriya Seetharam
Subject: [tacker] [networking-sfc] Removing required port-id from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  

Cathy> Do you mean logical source port here?


We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?  

Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.  




Thanks,

Tim Rozet
Red Hat SDN Team
__
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

Re: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS agent

[Cathy Zhang]

Hi Bernard,

Networking-sfc currently uses OF1.3. Although OF1.3 dumps all groups, 
networking-sfc has follow-on filter code to select the info associated with the 
specific group ID from the dump. So we are fine and let's keep it as OF1.3. 

We can upgrade to OF1.5 when Neutron uses OF1.5. 

Thanks,
Cathy


-Original Message-
From: Bernard Cafarelli [mailto:bcafa...@redhat.com] 
Sent: Tuesday, September 20, 2016 7:16 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [networking-sfc] OpenFlow version to use in the OVS 
agent

In the OVSSfcAgent migration to a L2 agent extension review[1], Igor Duarte 
Cardoso noticed a difference on the OpenFlow versions between a comment and 
actual code.
In current code [2], we have:
# We need to dump-groups according to group Id, # which is a feature of 
OpenFlow1.5 full_args = ["ovs-ofctl", "-O openflow13", cmd, self.br_name

Indeed, only OpenFlow 1.5 and later support dumping a specific group [3]. 
Earlier versions of OpenFlow always dump all groups.
So current code will return all groups:
$ sudo ovs-ofctl -O OpenFlow13 dump-groups br-int 1 OFPST_GROUP_DESC reply 
(OF1.3) (xid=0x2):
 
group_id=1,type=select,bucket=actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)
 
group_id=2,type=select,bucket=actions=set_field:fa:16:3e:2d:f3:28->eth_dst,resubmit(,5)
$ sudo ovs-ofctl -O OpenFlow15 dump-groups br-int 1 OFPST_GROUP_DESC reply 
(OF1.5) (xid=0x2):
 
group_id=1,type=select,bucket=bucket_id:0,actions=set_field:fa:16:3e:05:46:69->eth_dst,resubmit(,5),bucket=bucket_id:1,actions=set_field:fa:16:3e:cd:b7:7e->eth_dst,resubmit(,5)

This code behavior will not change in my extension rewrite, so this will still 
have to be fixed. though I am not sure on the solution:
* We can use Openflow 1.5, but its support looks experimental? And Neutron 
apparently only uses up to 1.4 (for OVS firewall extension)
* Method to dump a group can "grep" the group ID in the complete dump.
Not as efficient but works with OpenFlow 1.1+
* Use another system to load balance across the port pairs?

Thoughts?
In gerrit, I kept it set to 1.5 (no impact for now as this is still marked as 
WIP)

[1]: https://review.openstack.org/#/c/351789
[2]: 
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/common/ovs_ext_lib.py
[3]: http://openvswitch.org/support/dist-docs/ovs-ofctl.8.txt

--
Bernard Cafarelli

__
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

__
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

Re: [openstack-dev] [neutron][networking-sfc] TAP functionality

[Cathy Zhang]

Hi Subrahmanyam,

Yes, we can add this support. Would you like to join next project IRC meeting 
to discuss and sync up with the team on the requirement and the tapaas 
integration with networking-sfc?

Thanks,
Cathy
From: Subrahmanyam Ongole [mailto:song...@oneconvergence.com]
Sent: Wednesday, September 14, 2016 4:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][networking-sfc] TAP functionality

Hi Cathy

Is sfc project going to address TAP/Monitor type of packet redirection, where a 
copy of the packet is made and sent to the specified port? Is it targeted for 
any specific release - N, O etc?

If it is not available in sfc, does tapaas solution work with sfc? Any thoughts 
you could share? Thanks

--

Thanks
(Subrahmanyam Ongole)
__
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

Re: [openstack-dev] [neutron] Is OVS implementation for supporting VLAN-Aware-VM compeleted?

[Cathy Zhang]

Ryan,

Thanks!

Cathy

From: Tidwell, Ryan [mailto:ryan.tidw...@hpe.com]
Sent: Tuesday, September 13, 2016 1:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Is OVS implementation for supporting 
VLAN-Aware-VM compeleted?

Cathy,

There are a few outstanding reviews to be wrapped up, including docs. However, 
this is mostly complete and the bulk of the functionality has merged and you 
can try it out.

Code Reviews: 
https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/vlan-aware-vms
Docs: https://review.openstack.org/#/c/361776/

-Ryan

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Tuesday, September 13, 2016 11:25 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] Is OVS implementation for supporting 
VLAN-Aware-VM compeleted?

Hi All,

Sorry I lost track of this work. Is the implementation completed? Can we start 
using the OVS version of VLAN-Aware VMs ?

Thanks,
Cathy
__
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

[openstack-dev] [neutron] Is OVS implementation for supporting VLAN-Aware-VM compeleted?

[Cathy Zhang]

Hi All,

Sorry I lost track of this work. Is the implementation completed? Can we start 
using the OVS version of VLAN-Aware VMs ?

Thanks,
Cathy
__
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

Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

[Cathy Zhang]

Hi Tim,

Thank you for your response! From the statement, it does not seem to refer to a 
merged commit, which does not apply to our case. But you could be right. 

Anyway we will upload a patch for the release request and put down the git hash 
of the last commit which should be included in this Mitaka release. 
The Neutron release team will review it and let us know if there is more we 
need to do. 

Thanks,
Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Thursday, September 01, 2016 2:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Ihar Hrachyshka; Armando M.; Cathy Zhang
Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting 
release for networking-sfc

Hi Cathy,
I haven't done this in openstack before, but what I believe the statement is 
referring to is that you need to make sure you tag a merged commit, if the 
topic branch had diverged from master and had to be merged into your master 
trunk.  

For example:
commit f01595f801e1d78f84b43c111f2955f67573e263
Merge: 04a7bf2 4b84887
Author: Tim Rozet <tro...@redhat.com>
Date:   Wed Aug 31 01:40:12 2016 +

Merge "Adds ability to power off nodes in clean"

commit 4b84887ed2322db6b04924bdee7b44d3dcf7c32d
Author: Tim Rozet <tro...@redhat.com>
Date:   Tue Aug 30 13:06:33 2016 -0400

Adds ability to power off nodes in clean

Now if an inventory file is provided to clean, those nodes will be
powered off.

JIRA: APEX-250

Change-Id: I2d78285717726c3d1c9d7d88c38e706d4617e337
Signed-off-by: Tim Rozet <tro...@redhat.com>


In this situation I want to tag f01595f801e, because it is the merged commit 
(and not 4b84887).  To create a tag you can do this:

git checkout 
git tag -am ""  git push origin 

Hope that helps,

Tim Rozet
Red Hat SDN Team

----- Original Message -
From: "Cathy Zhang" <cathy.h.zh...@huawei.com>
To: "Ihar Hrachyshka" <ihrac...@redhat.com>, "Armando M." <arma...@gmail.com>, 
"Cathy Zhang" <cathy.h.zh...@huawei.com>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Sent: Thursday, September 1, 2016 3:03:13 PM
Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting 
release for networking-sfc

Thanks for all your response. 

We would like to have the stable branch pulled from a git commit. 
Shall we use the git hash of that commit for the intended git hash in the 
release request? 

I am confused about the following statement in the release guide. 
"You need to be careful when picking a git commit to base new releases on. In 
most cases, you’ll want to tag the merge commit that merges your last commit in 
to the branch. This bug shows an instance where this mistake was caught. Notice 
the difference between the incorrect commit and the correct one which is the 
merge commit. git log 6191994..22dd683 --oneline shows that the first one 
misses a handful of important commits that the second one catches. This is the 
nature of merging to master."

What is meant by " tag the merge commit"? How do we tag a git commit on our 
master branch? 

Thanks,
Cathy

-----Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, September 01, 2016 4:22 AM
To: Armando M.
Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting 
release for networking-sfc

Armando M. <arma...@gmail.com> wrote:

>
>
> On 31 August 2016 at 17:31, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> CC OpenStack alias.
>
>
>
> From: Cathy Zhang
> Sent: Wednesday, August 31, 2016 5:19 PM
> To: Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang
> Subject: need help on requesting release for networking-sfc
>
>
>
> Hi Armando/Ihar,
>
>
>
> I would like to submit a request for a networking-sfc release. I did 
> this for previous branch release by submitting a bug request in 
> launchpad before. I see that other subproject, such as L2GW, did this 
> in Launchpad for mitaka release too.
>
> But the Neutron stadium link
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidel
> ines.html#sub-project-release-process
> states that “A sub-project owner proposes a patch to 
> openstack/releases repository with the intended git hash. The Neutron 
> release liaison should be added in Gerrit to the list of reviewers for the 
> patch”.
>
>
>
> Could you advise which way I should go or should I do both?
>
>
> Consider the developer documentation the most up to date process, so 
> please go ahead with a patch against the openstack/releases repo.

Right. There was a recent

Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

[Cathy Zhang]

Hi Mooney,

Thank you for your response! I am still not quite sure about this. 

Anyway we will upload a patch for the release request and put down the git hash 
of the last commit which should be included in this Mitaka release. 
The Neutron release team will review it and let us know if there is more we 
need to do. 

Thanks,
Cathy

-Original Message-
From: Mooney, Sean K [mailto:sean.k.moo...@intel.com] 
Sent: Thursday, September 01, 2016 12:26 PM
To: OpenStack Development Mailing List (not for usage questions); Ihar 
Hrachyshka; Armando M.
Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting 
release for networking-sfc



> -Original Message-
> From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
> Sent: Thursday, September 1, 2016 8:03 PM
> To: Ihar Hrachyshka <ihrac...@redhat.com>; Armando M.
> <arma...@gmail.com>; Cathy Zhang <cathy.h.zh...@huawei.com>
> Cc: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on 
> requesting release for networking-sfc
> 
> Thanks for all your response.
> 
> We would like to have the stable branch pulled from a git commit.
> Shall we use the git hash of that commit for the intended git hash in 
> the release request?
> 
> I am confused about the following statement in the release guide.
> "You need to be careful when picking a git commit to base new releases 
> on. In most cases, you’ll want to tag the merge commit that merges 
> your last commit in to the branch. This bug shows an instance where 
> this mistake was caught. Notice the difference between the incorrect 
> commit and the correct one which is the merge commit. git log 
> 6191994..22dd683 --oneline shows that the first one misses a handful 
> of important commits that the second one catches. This is the nature 
> of merging to master."
> 
> What is meant by " tag the merge commit"? How do we tag a git commit 
> on our master branch?
[Mooney, Sean K] cathy if networking-sfc is setup the way I setup 
networking-ovs-dpdk e.g. following the old infra new projects guide the Core 
team has the right to push signed tags.
In this case you would checkout the commit you want To tag.
Then you would tag it with "git tag -s x.y.z" I think its -s to sign the tag 
but its been a While since I did it  last then you do "git push --tags gerrit" 
to push the tag to the repo.
Becareful to include at least 3 section in the version for it to be a valid tag 
for pypi packaging.

That said I don’t know if you have to tag the repo manually if you are using 
the openstack/release repo.

> 
> Thanks,
> Cathy
> 
> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Thursday, September 01, 2016 4:22 AM
> To: Armando M.
> Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on 
> requesting release for networking-sfc
> 
> Armando M. <arma...@gmail.com> wrote:
> 
> >
> >
> > On 31 August 2016 at 17:31, Cathy Zhang <cathy.h.zh...@huawei.com>
> wrote:
> > CC OpenStack alias.
> >
> >
> >
> > From: Cathy Zhang
> > Sent: Wednesday, August 31, 2016 5:19 PM
> > To: Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang
> > Subject: need help on requesting release for networking-sfc
> >
> >
> >
> > Hi Armando/Ihar,
> >
> >
> >
> > I would like to submit a request for a networking-sfc release. I did 
> > this for previous branch release by submitting a bug request in 
> > launchpad before. I see that other subproject, such as L2GW, did 
> > this in Launchpad for mitaka release too.
> >
> > But the Neutron stadium link
> >
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidel
> > ines.html#sub-project-release-process
> > states that “A sub-project owner proposes a patch to 
> > openstack/releases repository with the intended git hash. The 
> > Neutron release liaison should be added in Gerrit to the list of 
> > reviewers
> for the patch”.
> >
> >
> >
> > Could you advise which way I should go or should I do both?
> >
> >
> > Consider the developer documentation the most up to date process, so 
> > please go ahead with a patch against the openstack/releases repo.
> 
> Right. There was a recent change to the process that streamlined 
> release requests and hopefully made them a tad easier for both 
> subproject owners as well as release liaison. Please stick to the 
> latest version of the process as 

Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

[Cathy Zhang]

Thanks for all your response. 

We would like to have the stable branch pulled from a git commit. 
Shall we use the git hash of that commit for the intended git hash in the 
release request? 

I am confused about the following statement in the release guide. 
"You need to be careful when picking a git commit to base new releases on. In 
most cases, you’ll want to tag the merge commit that merges your last commit in 
to the branch. This bug shows an instance where this mistake was caught. Notice 
the difference between the incorrect commit and the correct one which is the 
merge commit. git log 6191994..22dd683 --oneline shows that the first one 
misses a handful of important commits that the second one catches. This is the 
nature of merging to master."

What is meant by " tag the merge commit"? How do we tag a git commit on our 
master branch? 

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, September 01, 2016 4:22 AM
To: Armando M.
Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting 
release for networking-sfc

Armando M. <arma...@gmail.com> wrote:

>
>
> On 31 August 2016 at 17:31, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> CC OpenStack alias.
>
>
>
> From: Cathy Zhang
> Sent: Wednesday, August 31, 2016 5:19 PM
> To: Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang
> Subject: need help on requesting release for networking-sfc
>
>
>
> Hi Armando/Ihar,
>
>
>
> I would like to submit a request for a networking-sfc release. I did 
> this for previous branch release by submitting a bug request in 
> launchpad before. I see that other subproject, such as L2GW, did this 
> in Launchpad for mitaka release too.
>
> But the Neutron stadium link
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidel
> ines.html#sub-project-release-process
> states that “A sub-project owner proposes a patch to 
> openstack/releases repository with the intended git hash. The Neutron 
> release liaison should be added in Gerrit to the list of reviewers for the 
> patch”.
>
>
>
> Could you advise which way I should go or should I do both?
>
>
> Consider the developer documentation the most up to date process, so 
> please go ahead with a patch against the openstack/releases repo.

Right. There was a recent change to the process that streamlined release 
requests and hopefully made them a tad easier for both subproject owners as 
well as release liaison. Please stick to the latest version of the process as 
described in devref in master branch of neutron repo.

Ihar
__
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

Re: [openstack-dev] [neutron][networking-sfc] Unable to create openstack SFC

[Cathy Zhang]

Hi Vincent,

Yes, there have been some code optimization and bug fixes going into the master 
branch.
I am going to request the Mitaka release today after the patch for fixing the 
tempest version mismatch issue is merged. I would suggest that you use the 
Mitaka release.

Thanks,
Cathy

From: Vincent.Chao [mailto:vincentcha...@gmail.com]
Sent: Wednesday, August 31, 2016 7:43 PM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Cc: Alioune
Subject: Re: [openstack-dev] [neutron][networking-sfc] Unable to create 
openstack SFC

Hi Neutrons,

I met this situation once in the release Liberty.
Here is the thing.
When the create_port_chain() is called, 
(@networking-sfc/networking_sfc/services/sfc/drivers/ovs/driver.py)
it goes the following code path
   -> _thread_update_path_nodes()
   ->_update_path_node_flowrules()
   ->_update_path_node_port_flowrules()
   ->_build_portchain_flowrule_body()
   ->_update_path_node_next_hops()
   ->_get_port_subnet_gw_info_by_port_id
   ->_get_port_subnet_gw_info()raise exc.SfcNoSubnetGateway
if you didn't give the network a router, it raises SfcNoSubnetGateway .
And then back to the plugin.py: create_port_chain(), cache the exception 
sfc_exc.SfcDriverError as e
In this exception, there is a delete_port_chain() method.
But due to the synchronization problem between DB and ovs-bridge, it will 
delete failure.
I hope this info. could help anyone who uses a liberty version.
Next time, don't forget giving a router before creating a port chain.

I don't see this code path in the master branch.
It may be better in mitaka.

Thanks
Vincent



2016-08-31 2:19 GMT+08:00 Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>:
Hi Alioune,

It is weird that when you create a port chain, you get a “chain delete failed” 
error message.
We never had this problem. Chain deletion is only involved when you do “delete 
chain” or “update chain”.
Not sure which networking code file combination you are using or whether it is 
because your system is not properly cleaned up or not properly installed.
We are going to release the networking-sfc mitaka version soon.
I would suggest that you wait a little bit and then use the official released 
mitaka version and reinstall the feature on your system.

Thanks,
Cathy

From: Alioune [mailto:baliou...@gmail.com<mailto:baliou...@gmail.com>]
Sent: Tuesday, August 30, 2016 8:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Mohan Kumar; Henry Fourie
Subject: Re: [openstack-dev][neutron][networking-sfc] Unable to create 
openstack SFC

Hi,
Have you received my previous email ?

Regards,

On 15 August 2016 at 13:39, Alioune 
<baliou...@gmail.com<mailto:baliou...@gmail.com>> wrote:
Hi all,
I'm trying to launch Openstack SFC as explained in[1] by creating 2 SFs, 1 Web 
Server (DST) and the DHCP namespace as the SRC.
I've installed OVS (Open vSwitch) 2.3.90 with Linux kernel 3.13.0-62 and the 
neutron L2-agent runs correctly.
I followed the process by creating classifier, port pairs and port_group but I 
got a wrong message "delete_port_chain failed." when creating port_chain [2]
I tried to create the neutron ports with and without the option 
"--no-security-groups" then tcpdpump on SFs tap interfaces but the ICMP packets 
don't go through the SFs.

Can anyone advice to fix? that ?
What's your channel on IRC ?

Regards,


[1] https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
[2]
vagrant@ubuntu:~/openstack_sfc$ ./08-os_create_port_chain.sh
delete_port_chain failed.
vagrant@ubuntu:~/openstack_sfc$ cat 08-os_create_port_chain.sh
#!/bin/bash

neutron port-chain-create --port-pair-group PG1 --port-pair-group PG2 
--flow-classifier FC1 PC1

[3] Output OVS Flows

vagrant@ubuntu:~$ sudo ovs-ofctl dump-flows br-tun -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0xbc2e9105125301dc, duration=9615.385s, table=0, n_packets=146, 
n_bytes=11534, priority=1,in_port=1 actions=resubmit(,2)
 cookie=0xbc2e9105125301dc, duration=9615.382s, table=0, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=9615.382s, table=2, n_packets=5, 
n_bytes=490, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 
actions=resubmit(,20)
 cookie=0xbc2e9105125301dc, duration=9615.381s, table=2, n_packets=141, 
n_bytes=11044, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 
actions=resubmit(,22)
 cookie=0xbc2e9105125301dc, duration=9615.380s, table=3, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=9615.380s, table=4, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=8617.106s, table=4, n_packets=0, 
n_bytes=0, priority=1,tun_id=0x40e 
actions=push_vlan:0x8100,set_field:4097->vlan_vid,resubmit(,10)
 cookie=0xbc2e9105125301dc, duration=9615.379s, table=6, n_packets=0, 
n_bytes=0, priority=0 actions=

[openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

[Cathy Zhang]

CC OpenStack alias.

From: Cathy Zhang
Sent: Wednesday, August 31, 2016 5:19 PM
To: Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang
Subject: need help on requesting release for networking-sfc

Hi Armando/Ihar,

I would like to submit a request for a networking-sfc release. I did this for 
previous branch release by submitting a bug request in launchpad before. I see 
that other subproject, such as L2GW, did this in Launchpad for mitaka release 
too.
But the Neutron stadium link 
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
 states that "A sub-project owner proposes a patch to openstack/releases 
repository with the intended git hash. The Neutron release liaison should be 
added in Gerrit to the list of reviewers for the patch".

Could you advise which way I should go or should I do both?

Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron][networking-sfc] Unable to create openstack SFC

[Cathy Zhang]

Hi Alioune,

It is weird that when you create a port chain, you get a “chain delete failed” 
error message.
We never had this problem. Chain deletion is only involved when you do “delete 
chain” or “update chain”.
Not sure which networking code file combination you are using or whether it is 
because your system is not properly cleaned up or not properly installed.
We are going to release the networking-sfc mitaka version soon.
I would suggest that you wait a little bit and then use the official released 
mitaka version and reinstall the feature on your system.

Thanks,
Cathy

From: Alioune [mailto:baliou...@gmail.com]
Sent: Tuesday, August 30, 2016 8:03 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Mohan Kumar; Henry Fourie
Subject: Re: [openstack-dev][neutron][networking-sfc] Unable to create 
openstack SFC

Hi,
Have you received my previous email ?

Regards,

On 15 August 2016 at 13:39, Alioune 
<baliou...@gmail.com<mailto:baliou...@gmail.com>> wrote:
Hi all,
I'm trying to launch Openstack SFC as explained in[1] by creating 2 SFs, 1 Web 
Server (DST) and the DHCP namespace as the SRC.
I've installed OVS (Open vSwitch) 2.3.90 with Linux kernel 3.13.0-62 and the 
neutron L2-agent runs correctly.
I followed the process by creating classifier, port pairs and port_group but I 
got a wrong message "delete_port_chain failed." when creating port_chain [2]
I tried to create the neutron ports with and without the option 
"--no-security-groups" then tcpdpump on SFs tap interfaces but the ICMP packets 
don't go through the SFs.

Can anyone advice to fix? that ?
What's your channel on IRC ?

Regards,


[1] https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
[2]
vagrant@ubuntu:~/openstack_sfc$ ./08-os_create_port_chain.sh
delete_port_chain failed.
vagrant@ubuntu:~/openstack_sfc$ cat 08-os_create_port_chain.sh
#!/bin/bash

neutron port-chain-create --port-pair-group PG1 --port-pair-group PG2 
--flow-classifier FC1 PC1

[3] Output OVS Flows

vagrant@ubuntu:~$ sudo ovs-ofctl dump-flows br-tun -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0xbc2e9105125301dc, duration=9615.385s, table=0, n_packets=146, 
n_bytes=11534, priority=1,in_port=1 actions=resubmit(,2)
 cookie=0xbc2e9105125301dc, duration=9615.382s, table=0, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=9615.382s, table=2, n_packets=5, 
n_bytes=490, priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 
actions=resubmit(,20)
 cookie=0xbc2e9105125301dc, duration=9615.381s, table=2, n_packets=141, 
n_bytes=11044, priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 
actions=resubmit(,22)
 cookie=0xbc2e9105125301dc, duration=9615.380s, table=3, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=9615.380s, table=4, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=8617.106s, table=4, n_packets=0, 
n_bytes=0, priority=1,tun_id=0x40e 
actions=push_vlan:0x8100,set_field:4097->vlan_vid,resubmit(,10)
 cookie=0xbc2e9105125301dc, duration=9615.379s, table=6, n_packets=0, 
n_bytes=0, priority=0 actions=drop
 cookie=0xbc2e9105125301dc, duration=9615.379s, table=10, n_packets=0, 
n_bytes=0, priority=1 
actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xbc2e9105125301dc,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
 cookie=0xbc2e9105125301dc, duration=9615.378s, table=20, n_packets=5, 
n_bytes=490, priority=0 actions=resubmit(,22)
 cookie=0xbc2e9105125301dc, duration=9615.342s, table=22, n_packets=146, 
n_bytes=11534, priority=0 actions=drop
vagrant@ubuntu:~$ sudo ovs-ofctl dump-flows br-int -O OpenFlow13
OFPST_FLOW reply (OF1.3) (xid=0x2):
 cookie=0xbc2e9105125301dc, duration=6712.090s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=7,icmp_type=136 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6709.623s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=8,icmp_type=136 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6555.755s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=10,icmp_type=136 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6559.596s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=9,icmp_type=136 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6461.028s, table=0, n_packets=0, 
n_bytes=0, priority=10,icmp6,in_port=11,icmp_type=136 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6712.071s, table=0, n_packets=13, 
n_bytes=546, priority=10,arp,in_port=7 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6709.602s, table=0, n_packets=0, 
n_bytes=0, priority=10,arp,in_port=8 actions=resubmit(,24)
 cookie=0xbc2e9105125301dc, duration=6555.727s, table=0, n_packets=0, 
n_bytes=0, priority=10,arp,in_port=10 actions=resubmit(

Re: [openstack-dev] [networking-sfc] Newton release plans?

[Cathy Zhang]

Hi James,

Networking-sfc will release Newton version after Neutron pull the stable/Newton 
branch (around late Oct. and Early Nov time frame).
Basically after the branch is pulled, we will make sure all unit, functional, 
tempest tests including multi-node end-to-end tests against stable/Newton 
branch are passed, and then will do the release.

Thanks,
Cathy

From: James Page [mailto:james.p...@canonical.com]
Sent: Monday, August 08, 2016 2:08 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] Newton release plans?

Hi Networking SFC team

I'm trying to get a view on a few Neutron related projects with the objective 
of lining up a release in Ubuntu and Debian alongside OpenStack Newton of 
vmware-nsx, networking-l2gw, networking-sfc and tap-as-a-service.

What are your plans for Newton? I can push snapshots into Debian/Ubuntu during 
development, but it would be nice to know at what point in time networking-sfc 
will release a version for Newton so we don't end up with a dangling snapshot 
of networking-sfc after the release of Ubuntu 16.10 and OpenStack Newton.

Cheers

James
__
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

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

[Cathy Zhang]

Hi Assaf,

Yes, that makes sense. 

Thanks,
Cathy

-Original Message-
From: Assaf Muller [mailto:as...@redhat.com] 
Sent: Thursday, July 28, 2016 1:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

On Thu, Jul 28, 2016 at 3:02 PM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi Ihar and all,
>
> Yes, we have been preparing for such a release. We will do one more round of 
> testing to make sure everything works fine, and then I will submit the 
> release request.
> There is a new patch on "stadium: adopt openstack/releases in subproject 
> release process" which is not Merged yet.
> Shall I follow this 
> http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
>  to submit the request?
> Do you have a good bug example for Neutron sub-project release request?
>
> BTW, a functional and tempest patch for networking-sfc has been uploaded and 
> it might take some time for the team to complete the review. The test is 
> non-voting. Do you think we should wait until this patch is merged or release 
> can be done without it?

The ideal is that any testing you're doing downstream or manually should be 
happening upstream and via CI. If you feel the need to run things one more time 
then that means that the upstream CI that is running for SFC is insufficient. A 
secondary incentive is to boost adoption - People tend to be attracted to 
stable projects with higher quality testing. I would advise accelerating the 
functional and tempest tests patches and releasing when your CI is in a better 
state.

>
> Thanks,
> Cathy
>
> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Wednesday, July 27, 2016 1:24 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version
>
> Tony Breeds <t...@bakeyournoodle.com> wrote:
>
>> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>>> Hi,
>>> Is anyone looking at creating a stable/mitaka version? What if 
>>> someone want to use this for stable/mitaka?
>>
>> If that's a thing you need it's a matter of Armando asking the 
>> release managers to create it.
>
> I only suggest Armando is not dragged into it, the release liaison (currently 
> me) should be able to handle the request if it comes from the core team for 
> the subproject.
>
> Ihar
>
> __
>  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

__
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

__
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

Re: [openstack-dev] [Neutron] SFC stable/mitaka version

[Cathy Zhang]

Hi Ihar and all,

Yes, we have been preparing for such a release. We will do one more round of 
testing to make sure everything works fine, and then I will submit the release 
request. 
There is a new patch on "stadium: adopt openstack/releases in subproject 
release process" which is not Merged yet. 
Shall I follow this 
http://docs.openstack.org/developer/neutron/stadium/sub_project_guidelines.html#sub-project-release-process
 to submit the request? 
Do you have a good bug example for Neutron sub-project release request?  

BTW, a functional and tempest patch for networking-sfc has been uploaded and it 
might take some time for the team to complete the review. The test is 
non-voting. Do you think we should wait until this patch is merged or release 
can be done without it? 

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Wednesday, July 27, 2016 1:24 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] SFC stable/mitaka version

Tony Breeds  wrote:

> On Wed, Jul 06, 2016 at 12:40:48PM +, Gary Kotton wrote:
>> Hi,
>> Is anyone looking at creating a stable/mitaka version? What if 
>> someone want to use this for stable/mitaka?
>
> If that's a thing you need it's a matter of Armando asking the release 
> managers to create it.

I only suggest Armando is not dragged into it, the release liaison (currently 
me) should be able to handle the request if it comes from the core team for the 
subproject.

Ihar

__
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

Re: [openstack-dev] [ovs-dev] SFC-Summary: MultiTenant

[Cathy Zhang]

Hi Russell,

Please see inline.

Thanks,
Cathy

From: Russell Bryant [mailto:russ...@ovn.org]
Sent: Tuesday, July 19, 2016 6:51 AM
To: Cathy Zhang
Cc: Farhad Sunavala; d...@openvswitch.org; Russell Bryant; Kyle Mestery
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

Even putting the multi-tenant considerations aside, I think sub-ports (tagging 
or encapsulation) are valuable as a mechanism to differentiate between 
different chains (traffic matched with different classifiers).
Cathy> Definitely. Using virtual sub-ports to differentiate different chains 
will greatly improve the OVS performance since this eliminates the need for 
re-classification at each hop. It also solves the problem caused by “some 
SF/VNF could change the 5-tuple or n-tuple fields of the packets that are used 
for chain flow classification”.  Based on info from John of Palo Alto networks, 
their VNF is alreadt using different virtual ports to differentiate different 
chains.

I agree that it's also complex that it requires coordination with the VNF - 
both with the vendors and a mechanism to coordinate with VNFs at runtime.

Cathy> The correlation between the sub-port and the chain needs to be 
communicated to the OVS as well as to the VNF. Networking-sfc’s chain API 
already has this info and passes this info down to the driver and OVS. The same 
information can be passed to VNF Manager which in turn passes to VNF. But as 
you said, we need coordination with the VNF manager. Different vendors could 
have different VNF managers. We need some agreement there.

I'd really like to understand better what people building VNFs are doing and 
what they want.  So many SFC conversations feel like vendors trying to guess.  
I haven't actually talked to any users myself.  I just want to build what 
people will actually use.  :-)

Cathy> There are many different types of VNFs. Some VNFs could have a need for 
passing of some metadata to the next hop VNF. I would also like to hear more 
use cases☺

On Wed, Jul 13, 2016 at 6:18 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Russell,

To add on Farhad's point, with current neutron and nova, we cannot create a 
multi-tenant  VNF.
Currently, nova checks whether the neutron port belongs to the same tenant as 
the VM itself.
You attach a network interface (neutron port) to a VM using nova 
interface-attach, if the port and the VM are in different tenants, an error is 
given.

As to the sub-ports feature of Neutron, although it allows the sub-ports to 
associate with different networks, it seems these networks need to all belong 
to the same tenant according to vlan-aware-vms spec 
http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html.

It is not clear whether it can work properly if these networks belong to 
different tenants.
DO you know this? We may need to send an email to Neutron team for 
clarification on this.

Thanks,
Cathy

-Original Message-
From: dev 
[mailto:dev-boun...@openvswitch.org<mailto:dev-boun...@openvswitch.org>] On 
Behalf Of Farhad Sunavala
Sent: Tuesday, July 12, 2016 7:59 PM
To: d...@openvswitch.org<mailto:d...@openvswitch.org>
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

>I was thinking this could be handled with child / sub-ports.  We do
>this today for containers in VMs.  We can have a single VIF for a VM
>that is connected to multiple networks that are owned by separate
>tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>would be used to differentiate the traffic for each networking in/out
>of that VIF.  I had started adding the ability to use MPLS for this in
>my prototype for this reason, as that was what networking-sfc had defined.
I have a quick question on the above. (multi-tenancy).Yes, I know the 
containers can be in different networks of the same tenant.How does it work 
when the containers are in different tenants ?
Below is the latest spec for vlan-aware-vms 
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

The trick is to create neutron ports (for the subports) and then link them to 
the trunk port using neutron trunk-subport-add TRUNK \   
PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]

In the above command all the neutron ports (trunk  ports and subports) must be 
in the same tenant.As far as I know, a tenant will not see neutron ports from 
another tenant.Or will this command allow neutron ports from different 
tenants to be attached ?
E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1 
(network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The 
trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The 
above command will be neutron trunk-subport-add T1 \   A  vlan 1 \   B 
vlan 2 Is my understanding correct? thanks,Farhad.
_

[openstack-dev] [Neutron][networking-sfc] meeting topics for 7/14/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
The following link shows the topics I have for this week's project meeting 
discussion. Feel free to add more.
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
Thanks,
Cathy
__
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

[openstack-dev] [Neutron] MultiTenant support for VLAN-Aware-VM

[Cathy Zhang]

Hi Everyone,

We have been discussing on multi-tenant VNF for service chain on the OVN 
mailing alias. 
We are thinking about leveraging the vlan-aware-VM for supporting this. 

AFAIK, with current nova, we cannot create a multi-tenant  VNF.
Currently, nova checks whether the neutron port belongs to the same tenant as 
the VM itself.  
You attach a network interface (neutron port) to a VM using nova 
interface-attach, if the port and the VM are in different tenants, an error is 
given.

With the introduction of the trunk-port/sub-port feature of Neutron, the 
sub-ports of a VM are allowed to associate with different networks. But it 
seems these networks need to all belong to the same tenant if we read the 
vlan-aware-vm spec correctly 
(http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html).
 

Is our understanding correct? Does it work properly if these networks belong to 
different tenants? 

Thanks,
Cathy

-Original Message-
From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad Sunavala
Sent: Tuesday, July 12, 2016 7:59 PM
To: d...@openvswitch.org
Subject: Re: [ovs-dev] SFC-Summary: MultiTenant

>I was thinking this could be handled with child / sub-ports.  We do 
>this today for containers in VMs.  We can have a single VIF for a VM 
>that is connected to multiple networks that are owned by separate 
>tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever) 
>would be used to differentiate the traffic for each networking in/out 
>of that VIF.  I had started adding the ability to use MPLS for this in 
>my prototype for this reason, as that was what networking-sfc had defined.
I have a quick question on the above. (multi-tenancy).Yes, I know the 
containers can be in different networks of the same tenant.How does it work 
when the containers are in different tenants ?
Below is the latest spec for vlan-aware-vms 
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html

The trick is to create neutron ports (for the subports) and then link them to 
the trunk port using neutron trunk-subport-add TRUNK \   
PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]

In the above command all the neutron ports (trunk  ports and subports) must be 
in the same tenant.As far as I know, a tenant will not see neutron ports from 
another tenant.    Or will this command allow neutron ports from different 
tenants to be attached ?
E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1 
(network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The 
trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The 
above command will be neutron trunk-subport-add T1 \   A  vlan 1 \   B 
vlan 2 Is my understanding correct? thanks,Farhad.
___
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
__
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

[openstack-dev] [Neutron][networking-sfc] meeting topics for 7/7/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
The following link shows the topics I have for this week's project meeting 
discussion. Feel free to add more.
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
Thanks,
Cathy
__
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

Re: [openstack-dev] [Neutron][networking-sfc] NO networking-sfc project IRC meetings on 6/23/2016 and 6/30/2016

[Cathy Zhang]

FYI. No networking-sfc project meeting this week due to some project members 
being either in Summit/Conference or on vacation,. We will resume our meeting 
next Thursday 7/7/2016.
I have updated the meeting page for discussion topics. Feel free to add more if 
you have any.

Thanks,
Cathy

From: Cathy Zhang
Sent: Tuesday, June 21, 2016 3:55 PM
To: 'Cathy Zhang'; 'OpenStack Development Mailing List (not for usage 
questions)'
Subject: [openstack-dev] [Neutron][networking-sfc] NO networking-sfc project 
IRC meetings on 6/23/2016 and 6/30/2016

Hi everyone,
Since some of the project members are either in Summit/Conference or on 
vacation, we will not have project meetings on 6/23/2016 and 6/30/2016.
Thanks,
Cathy
__
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

Re: [openstack-dev] Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

[Cathy Zhang]

Please see inline.

Cathy

From: Na Zhu [mailto:na...@cn.ibm.com]
Sent: Monday, June 27, 2016 9:56 PM
To: Cathy Zhang
Cc: Farhad Sunavala; John McDowall; Henry Fourie; Kyle Mestery; OpenStack 
Development Mailing List (not for usage questions); Russell Bryant; Ryan Moats; 
Richard Theis; Stephen Wong; Vikram Choudhary
Subject: RE: Change in openstack/networking-sfc[master]: Networking-sfc / OVN 
Driver

Hi Cathy,

Thanks your response.
Another question, how to create different port-chains for different tenants, 
and these chains consist of the same port pair group. In my test scenario, 
port-pair-group created by tenant A is not visible for tenant B.

Cathy> Each port pair group has an associated tenant ID, so it belongs to a 
tenant, that is why it is not visible. The same tenant can have multiple 
chains, eg. One for voice, one for video, one for data, and these chains can 
share the port pair group. But different tenants can not share the port pair 
group.





Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: na...@cn.ibm.com<mailto:na...@cn.ibm.com>
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New District, 
Shanghai, China (201203)



From:    Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>
To:Na Zhu/China/IBM@IBMCN, Henry Fourie 
<louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>>, "OpenStack 
Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc:Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>>, Kyle 
Mestery <mest...@mestery.com<mailto:mest...@mestery.com>>, Russell Bryant 
<rbry...@redhat.com<mailto:rbry...@redhat.com>>, Richard Theis 
<rth...@us.ibm.com<mailto:rth...@us.ibm.com>>, Stephen Wong 
<stephen.kf.w...@gmail.com<mailto:stephen.kf.w...@gmail.com>>, Vikram Choudhary 
<vikram.choudh...@huawei.com<mailto:vikram.choudh...@huawei.com>>, Farhad 
Sunavala <fs...@yahoo.com<mailto:fs...@yahoo.com>>, "John McDowall" 
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
Date:2016/06/28 12:29
Subject:RE: Change in openstack/networking-sfc[master]: Networking-sfc 
/ OVN Driver




Hi Na,

Please see inline for my reply.

Cathy

-Original Message-
From: Na Zhu (Code Review) [mailto:rev...@openstack.org]
Sent: Monday, June 27, 2016 8:08 PM
To: Henry Fourie
Cc: Ryan Moats; Na Zhu; Kyle Mestery; Russell Bryant; Richard Theis; Stephen 
Wong; Cathy Zhang; Vikram Choudhary; Farhad Sunavala; John McDowall
Subject: Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

Na Zhu has posted comments on this change.

Change subject: Networking-sfc / OVN Driver 
..


Patch Set 1:

(1 comment)

https://review.openstack.org/#/c/333172/1/doc/source/sfc_ovn_driver.rst
File doc/source/sfc_ovn_driver.rst:

Line 88: +-+   +-+ outport +===+
> Agree that it is better to clarify these points.
Hi Cathy,
I try to create multiple port-chains with the same port-pair-group, it failed. 
I think it is not allowed to do what you said, right?
(neutron) port-chain-create --flow-classifier fc --port-pair-group pg1 pc1 Port 
Pair Group(s) [u'17c9a0a5-a38f-4a75-834e-9aa213cd431f'] in use by Port Chain 
f3af530f-210a-4c51-9a02-f1835d5b1d85.
Neutron server returns request_ids: ['req-47e6a39b-677a-4ce3-9976-5dfcee0ac47f']
(neutron)

Cathy> when a port pair group is shared by multiple chains, these chains should 
be different, which means these chains should consist of different sequences of 
port pair groups. For example, chain 1 consists of <port-pair-group1, 
port-pair-group2> and chain 2 consists of "port-pair-group1, port-pair-group3, 
port-pair-group4>. But if the two chains are the same, i.e. they consist of the 
same sequence of port-pair-groups (e.g. the two chains both consist of 
), then it is not allowed since it does not make sense to 
create the same chain twice. Maybe your test scenario falls into the second 
case?



--
To view, visit https://review.openstack.org/333172
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I5c1827dcc81e48983a41120ec08983c571c5b2e9
Gerrit-PatchSet: 1
Gerrit-Project: openstack/networking-sfc
Gerrit-Branch: master
Gerrit-Owner: Louis Fourie 
<louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>>
Gerrit-Reviewer: Farhad Sunavala <fs...@yahoo.com<mailto:fs...@yahoo.com>>
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: John McDowall 
<jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>
Gerrit-Reviewer: Kyle Mestery <mest...@mestery.com&l

Re: [openstack-dev] Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

[Cathy Zhang]

Hi Na,

Please see inline for my reply.

Cathy

-Original Message-
From: Na Zhu (Code Review) [mailto:rev...@openstack.org] 
Sent: Monday, June 27, 2016 8:08 PM
To: Henry Fourie
Cc: Ryan Moats; Na Zhu; Kyle Mestery; Russell Bryant; Richard Theis; Stephen 
Wong; Cathy Zhang; Vikram Choudhary; Farhad Sunavala; John McDowall
Subject: Change in openstack/networking-sfc[master]: Networking-sfc / OVN Driver

Na Zhu has posted comments on this change.

Change subject: Networking-sfc / OVN Driver 
..


Patch Set 1:

(1 comment)

https://review.openstack.org/#/c/333172/1/doc/source/sfc_ovn_driver.rst
File doc/source/sfc_ovn_driver.rst:

Line 88: +-+   +-+ outport +===+
> Agree that it is better to clarify these points. 
Hi Cathy,
I try to create multiple port-chains with the same port-pair-group, it failed. 
I think it is not allowed to do what you said, right?
(neutron) port-chain-create --flow-classifier fc --port-pair-group pg1 pc1 Port 
Pair Group(s) [u'17c9a0a5-a38f-4a75-834e-9aa213cd431f'] in use by Port Chain 
f3af530f-210a-4c51-9a02-f1835d5b1d85.
Neutron server returns request_ids: ['req-47e6a39b-677a-4ce3-9976-5dfcee0ac47f']
(neutron)

Cathy> when a port pair group is shared by multiple chains, these chains should 
be different, which means these chains should consist of different sequences of 
port pair groups. For example, chain 1 consists of <port-pair-group1, 
port-pair-group2> and chain 2 consists of "port-pair-group1, port-pair-group3, 
port-pair-group4>. But if the two chains are the same, i.e. they consist of the 
same sequence of port-pair-groups (e.g. the two chains both consist of 
), then it is not allowed since it does not make sense to 
create the same chain twice. Maybe your test scenario falls into the second 
case?



-- 
To view, visit https://review.openstack.org/333172
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I5c1827dcc81e48983a41120ec08983c571c5b2e9
Gerrit-PatchSet: 1
Gerrit-Project: openstack/networking-sfc
Gerrit-Branch: master
Gerrit-Owner: Louis Fourie <louis.fou...@huawei.com>
Gerrit-Reviewer: Farhad Sunavala <fs...@yahoo.com>
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: John McDowall <jmcdow...@paloaltonetworks.com>
Gerrit-Reviewer: Kyle Mestery <mest...@mestery.com>
Gerrit-Reviewer: Louis Fourie <louis.fou...@huawei.com>
Gerrit-Reviewer: Na Zhu <na...@cn.ibm.com>
Gerrit-Reviewer: Richard Theis <rth...@us.ibm.com>
Gerrit-Reviewer: Russell Bryant <rbry...@redhat.com>
Gerrit-Reviewer: Ryan Moats <rmo...@us.ibm.com>
Gerrit-Reviewer: Stephen Wong <stephen.kf.w...@gmail.com>
Gerrit-Reviewer: cathy <cathy.h.zh...@huawei.com>
Gerrit-Reviewer: vikram.choudhary <vikram.choudh...@huawei.com>
Gerrit-HasComments: Yes
__
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

[openstack-dev] [Neutron][networking-sfc] NO networking-sfc project IRC meetings on 6/23/2016 and 6/30/2016

[Cathy Zhang]

Hi everyone,
Since some of the project members are either in Summit/Conference or on 
vacation, we will not have project meetings on 6/23/2016 and 6/30/2016.
Thanks,
Cathy
__
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

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Cathy Zhang]

Hi MartinX,

I sent you a reply on 6/14. 

Cathy

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Thursday, June 16, 2016 4:49 AM
To: 'openstack-dev@lists.openstack.org'
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a use case 
I am trying to implement requires that every instance has it's separated 
network and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group and 
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded back 
through the p3 port to the ROUTER.  The router finds out that there are packets 
with source address 1.1.1.1 coming from port where is should not (the router 
expects those packets from the net1 interface), they don't pass the reverse 
path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the sfc to 
work without such changes.

Is such topology supported? What should the topology look like?

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and 
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly 
and don't connect them anyhow to the ROUTER nor the rest of the topology, the 
OVS is able to send the traffic to the p2 port on the ingress side. However, on 
the egress side the packet is routed to the ROUTER3 which drops it as it 
doesn't have any route for it.

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


__
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
--- Begin Message ---
Hi Banszel,

Please see inline. 

Thanks,
Cathy 

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a 

[openstack-dev] [neutron] No Neutron Common Flow Classifier meeting on 6/21 UTC 1700

[Cathy Zhang]

Hi everyone,

Since we have had the meeting discussion on Common Flow classifier on 
6/14/2016, we will not have another meeting on 6/21/2016. 
We will have our next meeting on 7/5/2016 and then have one every odd week. 

Here is the link to the feature wiki page. 
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier

Thanks,
Cathy 
__
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

Re: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

[Cathy Zhang]

Hi Banszel,

Please see inline. 

Thanks,
Cathy 

-Original Message-
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with 
multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated 
from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 
(one for ingress port, one for egress port) are connected to the tenants 
networks. I know that all three instances can share one network but a use case 
I am trying to implement requires that every instance has it's separated 
network and there is a different network for ingress and egress port of the SF.

 +---+ +-+ +---+
 | VMSRC | |  VMSFC  | | VMDST |
 +---+---+ +--+---+--+ +---+---+
 | p1 (1.1.1.1) p2|   |p3  |p4 (4.4.4.4)
 ||   ||
-++--- net1   |   |  --+---+- net4
  |   |   ||
  |  ---+-+---) net2   |
  |  ---)--+--+ net3   |
  | |  |   |
  |  +--+--+--+|
  +--+ ROUTER ++
 ++


All networks are connected to a single router ROUTER. I created a flow 
classifier that matches all traffic going from VMSRC to VMDST 
(--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 
--destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group 
containing this port pair and a port chain containing this port pair group and 
flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered 
through the VMSFC (where just the ip_forwarding is set to 1) and forwarded back 
through the p3 port to the ROUTER.  The router finds out that there are packets 
with source address 1.1.1.1 coming from port where is should not (the router 
expects those packets from the net1 interface), they don't pass the reverse 
path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router 
namespace on the controller. But I don't want to do this -- I expect the sfc to 
work without such changes.

Is such topology supported? What should the topology look like?

Cathy> No, current networking-sfc does not support this topology. 

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and 
add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly 
and don't connect them anyhow to the ROUTER nor the rest of the topology, the 
OVS is able to send the traffic to the p2 port on the ingress side. However, on 
the egress side the packet is routed to the ROUTER3 which drops it as it 
doesn't have any route for it.
Cathy> Router3 will not have any rule to forward the packet since 
networking-sfc does not install any new forwarding rules into a Router, that is 
why it is dropped. Anyway the current implementation does not have proper 
support for chain across multiple subnets. If you put VMSRC and VMSFC in the 
same subnet and VMDST in another subnet, it should work. 

Thanks for any hints!

Best regards
Martin Banszel
--
Intel Research and Development Ireland Limited Registered in Ireland Registered 
Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 
308263


This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.


__
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

__
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

[openstack-dev] [neutron] Neutron Common Flow Classifier meeting 6/14 UTC 1700

[Cathy Zhang]

Hi everyone,

We will have the second meeting discussion on Common Flow classifier at 1700 
UTC on openstack-meeting channel 6/14/2016. 
Please refer to the wiki page for more meeting information. 

https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier

Thanks,
Cathy 
__
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

[openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for networking-sfc core

[Cathy Zhang]

Mohan has been working on networking-sfc project for over one year. He is a key 
contributor to the design/coding/testing of SFC CLI,  SFC Horizon, as well as 
ONOS controller support for SFC functionality. He has been great at helping out 
with bug fixes, testing, and reviews of all components of networking-sfc. He is 
also actively providing guidance to the users on their SFC setup, testing, and 
usage. Mohan showed a very good understanding of the networking-sfc design, 
code base, and its usage scenarios. Networking-sfc could use more cores as our 
user base and features have grown and I think he'd be a valuable addition.


Please respond with your +1 votes to approve this change or -1 votes to oppose.

Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron][SFC]

[Cathy Zhang]

Hi Alioune,

Which OVS version are you using?
Try openvswitch version 2.4.0 and restart the openvswitch-server before 
installing the devstack.

Cathy

From: Alioune [mailto:baliou...@gmail.com]
Sent: Friday, June 03, 2016 9:07 AM
To: openstack-dev@lists.openstack.org
Cc: Cathy Zhang
Subject: [openstack-dev][neutron][SFC]

Probleme with OpenStack SFC
Hi all,
I've installed Openstack SFC with devstack and all module are corretly running 
except the neutron L2-agent

After a "screen -rd", it seems that there is a conflict between l2-agent and 
SFC (see trace bellow).
I solved the issue with "sudo ovs-vsctl set bridge br 
protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13" on all openvswitch 
bridge (br-int, br-ex, br-tun and br-mgmt0).
I would like to know:
  - If someone knows why this error arrises ?
 - is there another way to solve it ?

Regards,

2016-06-03 12:51:56.323 WARNING 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] OVS is dead. 
OVSNeutronAgent will keep running and checking OVS status periodically.
2016-06-03 12:51:56.330 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4722 completed. Processed ports statistics: {'regular': {'updated': 
0, 'added': 0, 'removed': 0}}. Elapsed:0.086 from (pid=12775) 
loop_count_and_wait 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1680
2016-06-03 12:51:58.256 DEBUG 
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Agent rpc_loop - 
iteration:4723 started from (pid=12775) rpc_loop 
/opt/stack/neutron/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py:1732
2016-06-03 12:51:58.258 DEBUG neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Running command (rootwrap 
daemon): ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23'] 
from (pid=12775) execute_rootwrap_daemon 
/opt/stack/neutron/neutron/agent/linux/utils.py:101
2016-06-03 12:51:58.311 ERROR neutron.agent.linux.utils 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 12:51:58.323 ERROR networking_sfc.services.sfc.common.ovs_ext_lib 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None]
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
Exit code: 1
Stdin:
Stdout:
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)

2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Traceback (most recent call last):
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File 
"/opt/stack/networking-sfc/networking_sfc/services/sfc/common/ovs_ext_lib.py", 
line 125, in run_ofctl
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 process_input=process_input)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib   
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
 raise RuntimeError(m)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
RuntimeError:
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Command: ['ovs-ofctl', '-O openflow13', 'dump-flows', 'br-int', 'table=23']
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Exit code: 1
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdin:
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stdout:
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
Stderr: 
2016-06-03T12:51:58Z|1|vconn|WARN|unix:/var/run/openvswitch/br-int.mgmt: 
version negotiation failed (we support version 0x04, peer supports version 0x01)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib 
ovs-ofctl: br-int: failed to connect to socket (Broken pipe)
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-03 12:51:58.323 TRACE networking_sfc.services.sfc.common.ovs_ext_lib
2016-06-03 12:51:58.335 ERROR networking_sfc.services.sfc.common.ovs_ext_lib 
[req-1258bbbc-7211-4cfd-ab7c-8b856604f768 None None] Unable to execute 
['ovs-ofctl', '-O openflow13', '

[openstack-dev] [Neutron][networking-sfc] meeting topics for 6/1/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
The following link shows the topics I have for this week's project meeting 
discussion(The meeting time is not changed, still UTC 1700 Thursday). Feel free 
to add more.
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
Thanks,
Cathy
__
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

Re: [openstack-dev] support of NSH in networking-SFC

[Cathy Zhang]

Igor and Tim,

+1 on your suggestion. 

Thanks,
Cathy

-Original Message-
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] 
Sent: Tuesday, May 31, 2016 8:48 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] support of NSH in networking-SFC

Hi Tim,

+1
Focus on the plugin and API while improving the n-sfc<->ODL interaction to 
match that.

In parallel, early (non-merged) support in OVS driver itself could be 
attempted, based on the unofficial April 2016's NSH patches for OVS [1]. After 
official supports gets merged, it would be less troublesome to adapt since the 
big hurdles of mapping the abstraction to OVS would have been mostly overcome.

[1] 
https://github.com/yyang13/ovs_nsh_patches/tree/98e1d3d6b1ed49d902edaede11820853b0ad5037
 
Best regards,
Igor.


-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, May 31, 2016 4:21 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hey Paul,
ODL uses OVS as its dataplane (but is also not limited to just OVS), and ODL 
already supports IETF SFC today in the ODL SFC project.  My point was Neutron 
is no longer in scope of managing OVS, since it is managed by ODL.  I think 
your comments echo the 2 sides of this discussion - whether or not OVS is in 
scope of a protocol implementation in Neutron networking-sfc.  In my opinon it 
is if you consider OVS driver support, but it is not if you consider a 
different networking-sfc driver.

You can implement IETF NSH in the networking-sfc API/DB Model, without caring 
if it is actually supported in OVS (when using ODL as a driver) because all 
networking-sfc cares about should be if it's driver correctly supports SFC.  To 
that end, if you are using ODL as your SFC driver, then absolutely you should 
verify it is an IETF SFC compliant API/model.  However, outside of that scope, 
it is not networking-sfc's responsibility to care what ODL is using as it's 
dataplane backend or for that matter it's version of OVS.  It is now up to ODL 
to manage that for networking-sfc, and networking-sfc just needs to ensure it 
can talk to ODL.  

I think this is a pragmatic way to go, since networking-sfc doesn't yet support 
an ODL driver and we are in the process of adding one.  We could leave the 
networking-sfc OVS driver alone, add support for NSH to the networking-sfc 
plugin, and then only allow API calls that use NSH to work if ODL networking 
driver is the backend.  That way we allow for some experimental NSH support in 
networking-sfc without officially supporting it in the OVS driver until it is 
officially supported in OVS.

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Paul Carver" 
To: "OpenStack Development Mailing List (not for usage questions)" 

Sent: Monday, May 30, 2016 10:12:34 PM
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On 5/25/2016 13:24, Tim Rozet wrote:
> In my opinion, it is a better approach to break this down into plugin vs 
> driver support.  There should be no problem adding support into 
> networking-sfc plugin for NSH today.  The OVS driver however, depends on OVS 
> as the dataplane - which I can see a solid argument for only supporting an 
> official version with a non-NSH solution.  The plugin side should have no 
> dependency on OVS.  Therefore if we add NSH SFC support to an ODL driver in 
> networking-odl, and use that as our networking-sfc driver, the argument about 
> OVS goes away (since neutron/networking-sfc is totally unaware of the 
> dataplane at this point).  We would just need to ensure that API calls to 
> networking-sfc specifying NSH port pairs returned error if the enabled driver 
> was OVS (until official OVS with NSH support is released).
>

Does ODL have a dataplane? I thought it used OvS. Is the ODL project supporting 
its own fork of OvS that has NSH support or is ODL expecting that the user will 
patch OvS themself?

I don't know the details of why OvS hasn't added NSH support so I can't judge 
the validity of the concerns, but one way or another there has to be a 
production-quality dataplane for networking-sfc to front-end.

If ODL has forked OvS or in some other manner is supporting its own NSH capable 
dataplane then it's reasonable to consider that the ODL driver could be the 
first networking-sfc driver to support NSH. However, we still need to make sure 
that the API is an abstraction, not implementation specific.

But if ODL is not supporting its own NSH capable dataplane, instead expecting 
the user to run a patched OvS that doesn't have upstream acceptance then I 
think we would be building a rickety tower by piling networking-sfc on top of 
that unstable base.

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Cathy Zhang]

Looks like the work of removing the mandatory L3 requirement associated with 
decapsulated VxLAN-gpe packet also involves OVS kernel change, which is 
difficult. Furthermore, even this blocking issue is resolved and eventually OVS 
accepts the VLAN-gpe+NSH encapsulation, there is still another issue. 
Current Neutron only supports VXLAN, not VXLAN-gpe, and adopting VXLAN-gpe 
involves consideration of backward compatibility with existing VXLAN VTEP and 
VXLAN Gateway. 

An alternative and maybe easier/faster path could be to push a patch of " VxLAN 
+ Eth + NSH + Original frame" into OVS kernel. This is also IETF compliant 
encapsulation for SFC and does not have the L3 requirement issue and Neutron 
VXLAN-gpe support issue. 

We can probably take this discussion to the OVS mailing alias. 

Thanks,
Cathy

-Original Message-
From: Ben Pfaff [mailto:b...@ovn.org] 
Sent: Tuesday, May 31, 2016 9:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Wed, Jun 01, 2016 at 12:08:23AM +, Yang, Yi Y wrote:
> Ben, yes, we submitted nsh support patch set last year, but ovs 
> community told me we have to push kernel part into Linux kernel tree, 
> we're struggling to do this, but something blocked us from doing this.

It's quite difficult to get patches for a new protocol into the kernel.
You have my sympathy.

> Recently, ovs did some changes in tunnel protocols which requires the 
> packet decapsulated by a tunnel must be a Ethernet packet, but Linux 
> kernel (net-next) tree accepted VxLAN-gpe patch set from Redhat guy 
> (Jiri Benc) which requires the packet decapsulated by VxLAN-gpe port 
> must be L3 packet but not L2 Ethernet packet, this blocked us from 
> progressing better.
> 
> Simon Horman (Netronome guy) has posted a series of patches to remove 
> the mandatory requirement from ovs in order that the packet from a 
> tunnel can be any packet, but so far we didn't see they are merged.

These are slowly working their way through OVS review, but these also have a 
prerequisite on kernel patches, so it's not easy to get them in either.

> I heard ovs community looks forward to getting nsh patches merged, it 
> will be great if ovs guys can help progress this.

I do plan to do my part in review (but much of this is kernel review, which I'm 
not really involved in anymore).

__
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

__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier

[Cathy Zhang]

Hi everyone,

Thanks YAMAMOTO Takashi for reserving a new meeting channel 
"openstack-meeting", for the discussion.
We will have biweekly-odd meetings on this channel at UTC 1700 on Tuesday. Due 
to this long weekend in US and some people taking extra days off, let's start 
the meeting on this new channel on June 14. 

Thanks,
Cathy

-Original Message-----
From: Cathy Zhang 
Sent: Thursday, May 05, 2016 3:35 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent 
extension for Newton cycle

Hi everyone,

We had a discussion on the two topics during the summit. Here is the etherpad 
link for the discussion. 
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

We agreed to continue the discussion on Neutron channel on a weekly basis. It 
seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. 
Another option is UTC 1700 ~ UTC 1800 Friday. 

I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
this time is good for all people who have interest and like to contribute to 
this work. We plan to start the first meeting on May 17. 

Thanks,
Cathy


-Original Message-----
From: Cathy Zhang
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-----
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

&g

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Haim,

Thanks for taking care of this. I see that Miguel has started working on the 
new L2 extension for Flow management。

https://bugs.launchpad.net/neutron/+bug/1563967
https://review.openstack.org/#/c/320439/

We may need to sync up the change with this new work too.

Thanks,
Cathy

From: Haim Daniel [mailto:hdan...@redhat.com]
Sent: Thursday, May 26, 2016 5:42 AM
To: Ihar Hrachyshka
Cc: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Vikram Choudhary; Sean M. Collins; Mathieu Rohon; Shaughnessy, David; 
Eichberger, German; Henry Fourie; Armando M.
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi all,

sorry for digging up this thread. I took a liberty to submitt an RFE per Ihar's 
suggestion for the first step (switching to l2 agent extensions):
https://bugs.launchpad.net/networking-sfc/+bug/1586024

As a followup on that - hoping to send some wip patches in the near time.

Hope to hear your thoughts/suggestions on the $subj.

On Fri, Apr 15, 2016 at 2:44 AM, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:

I think there is no formal spec or anything, just some emails around there.

That said, I don’t follow why it’s a requirement for SFC to switch to l2 agent 
extension mechanism. Even today, with SFC maintaining its own agent, there are 
no clear guarantees for flow priorities that would avoid all possible conflicts.

Cathy> There is no requirement for SFC to switch. My understanding is that 
current L2 agent extension does not solve the conflicting entry issue if two 
features inject the same priority table entry. I think this new L2 agent effort 
is try to come up with a mechanism to resolve this issue. Of course if each 
feature( SFC or Qos) uses its own agent, then there is no coordination and no 
way to avoid conflicts.

Sorry, I probably used misleading wording. I meant, why do we consider the 
semantic flow management support in l2 agent extension framework a 
*prerequisite* for SFC to switch to l2 agent extensions? The existing framework 
should already allow SFC to achieve what you have in the subproject tree 
implemented as a separate agent (essentially a fork of OVS agent). It will also 
set SFC to use standard extension mechanisms instead of hacky inheritance from 
OVS agent classes. So even without the strict semantic flow management, there 
is benefit for the subproject.

With that in mind, I would split this job into 3 pieces:
* first, adopt l2 agent extension mechanism for SFC functionality (dropping 
custom agent);
* then, work on semantic flow management support in OVS agent API class [1];
* once the feature emerges, switch SFC l2 agent extension to the new framework 
to manage SFC flows.

I would at least prioritize the first point and target it to Newton-1. Other 
bullet points may take significant time to bake.

[1] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py

Ihar

__
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

[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension

[Cathy Zhang]

Hi everyone,

We will have the first meeting discussion on Common Flow classifier at 1700 UTC 
on openstack-neutron channel 5/17/2016. 
Based on our etherpad action item in the Austin Summit meeting, Louis and I 
have created a wiki page for this work, describing the work overview and API 
design guideline we have discussed in the summit. I have also uploaded a table 
comparing the FC rules used in security group and networking-sfc. 

https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier

Let's discuss them in tomorrow's meeting. 

Thanks,
Cathy 
__
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

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Cathy Zhang]

Hi Uri,

I hope all the replies have helped answer your question. 

To echo what Paul said, the networking-sfc approach is to separate the API from 
the backend drivers. The actual data plane forwarder is not part of 
networking-sfc. We aren't going to maintain the out-of-tree OVS NSH code. When 
OVS accepts the NSH functionality, our network-sfc OVS driver will be updated 
to support "push NSH" and "pop NSH" etc. to make use of the NSH encapsulation 
available in the data plane forwarder. 
If you know any other open source vSwitch/vRouter that already supports NSH and 
if someone wants to write a networking-sfc driver for it, that code would be 
welcomed. 

Thanks,
Cathy

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Saturday, May 14, 2016 7:25 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

On Fri, 13 May 2016 17:13:59 -0700
"Armando M."  wrote:

> On 13 May 2016 at 16:10, Elzur, Uri  wrote:
> 
> > Hi Cathy
> >
> >
> >
> > Thank you for the quick response. This is the essence of my question 
> > – does Neutron keep OvS as a gold standard and why
> >  
> 
> Not at all true. Neutron, the open source implementation, uses a 
> variety of open components, OVS being one of them. If you know of any 
> open component that supports NSH readily available today, I'd be happy 
> to hear about it.

I agree with Armando and Cathy. There's nothing "gold standard" about OvS. The 
networking-sfc approach is to separate the API from the backend drivers and the 
OvS driver is only one of several. We have a place in the API where we expect 
to capture the tenant's intent to use NSH.

What we don't currently have is a backend, OvS or other, that supports NSH. The 
actual dataplane forwarder is not part of networking-sfc. We aren't going to 
maintain the out-of-tree OvS NSH code or depend on it.
When OvS accepts the NSH functionality upstream then our network-sfc driver 
will be able to make use of it.

If any other vSwitch/vRouter that already supports NSH and if someone wants to 
write a networking-sfc driver for, that code would be welcome.

We've also started discussing how to implement a capabilities discovery API so 
that if some backends support a capability (e.g. NSH) and other backends don't 
support it, we will provide the tenant with an abstract way to query the 
networking-sfc API in order to determine whether a particular capability can be 
provided by the current backend.

The thing networking-sfc won't take on is ownership of the upstream dataplane 
forwarder projects. We'll simply provide an abstraction so that a common API 
can invoke SFC across pre-existing SFC-capable dataplanes.

__
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
__
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

Re: [openstack-dev] [Neutron] support of NSH in networking-SFC

[Cathy Zhang]

Hi Uri,

Current networking-sfc API allows the user to specify the data path SFC 
encapsulation mechanism and NSH could be one of the encapsulation options.
But since OVS release has not supported the NSH yet, we have to wait until  NSH 
is added into OVS and then start to support the NSH encapsulation mechanism in 
the data path.

AFAIK, it is the position of Neutron to have any OVS related new features 
developed inside the OVS community.

Thanks,
Cathy

From: Elzur, Uri [mailto:uri.el...@intel.com]
Sent: Friday, May 13, 2016 3:02 PM
To: OpenStack Development Mailing List (not for usage questions); Armando M
Subject: [openstack-dev] [Neutron] support of NSH in networking-SFC

Hi Armando

As an industry we are working on SFC for 3 years or so (more?). Still to date, 
we are told we can’t get Neutron or even a Stadium project e.g. networking-SFC 
to support NSH (in IETF LC phase) because OvS has not supported NSH. Is this an 
official position of Neutron that OvS is the gold standard to support any new 
feature?

We have seen OvS support other overlays that are not ahead of VXLAN-gpe in the 
IETF.

Thx

Uri (“Oo-Ree”)
C: 949-378-7568

__
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

[openstack-dev] [Neutron][networking-sfc] meeting topics for 5/12/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
Here are some topics I have for this week's project meeting discussion(The 
meeting time is not changed, still UTC 1700 Thursday). Feel free to add more.
You can also find the meeting topics in the project wiki page.  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
* Status update:
   *Add support for Querying Driver capability for SFC functionality support
   *Networking-sfc SFC driver for OVN
   *Networking-sfc SFC driver for ODL
   *Networking-sfc integration with ONOS completion status update
   *Tacker Driver for networking-sfc
* Use case documentation
* new field "priority" in flow-classifier
* Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component
* Add VNF type (l2 or l3) param in service-function-param
* Add "NSH" encap param in service-chain-param
* Functional Test script
* Tempest Test suite
* Dynamic service chain update without service interruption


Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

It is always hard to find a day and time that is good for everyone around the 
globe:-)
The first meeting will still be UTC 1700 ~ UTC 1800 May 17 on Neutron channel. 
In the meeting, we can see if we can reach consensus on a new meeting time. 

Cathy

-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com] 
Sent: Tuesday, May 10, 2016 12:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

On Tue, May 10, 2016 at 12:41 AM,  <thomas.mo...@orange.com> wrote:
> Hi Cathy,
>
> Cathy Zhang:
>>
>> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday.
>> Hope this time is good for all people who have interest and like to 
>> contribute to this work. We plan to start the first meeting on May 17.
>
>
> I would be happy to participate, but I'm unlikely to be able to attend 
> at that time.
> Might 15:00 UTC work for others ?

+1 for earlier

> If not, well, I'll make do with log/emails/pads/gerrit interactions.
>
> -Thomas
>
>
>
>
>> -Original Message-----
>> From: Cathy Zhang
>> Sent: Thursday, April 21, 2016 11:43 AM
>> To: Cathy Zhang; OpenStack Development Mailing List (not for usage 
>> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim 
>> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry 
>> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
>> Cc: Cathy Zhang
>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
>> and OVS Agent extension for Newton cycle
>>
>> Hi everyone,
>>
>> We have room 400 at 3:10pm on Thursday available for discussion of 
>> the two topics.
>> Another option is to use the common room with roundtables in "Salon C"
>> during Monday or Wednesday lunch time.
>>
>> Room 400 at 3:10pm is a closed room while the Salon C is a big open 
>> room which can host 500 people.
>>
>> I am Ok with either option. Let me know if anyone has a strong preference.
>>
>> Thanks,
>> Cathy
>>
>>
>> -Original Message-
>> From: Cathy Zhang
>> Sent: Thursday, April 14, 2016 1:23 PM
>> To: OpenStack Development Mailing List (not for usage questions); 
>> 'Ihar Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim 
>> Daniel'; 'Mathieu Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; 
>> Cathy Zhang; Henry Fourie; 'arma...@gmail.com'
>> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
>> and OVS Agent extension for Newton cycle
>>
>> Thanks for everyone's reply!
>>
>> Here is the summary based on the replies I received:
>>
>> 1.  We should have a meet-up for these two topics. The "to" list are 
>> the people who have interest in these topics.
>>  I am thinking about around lunch time on Tuesday or Wednesday 
>> since some of us will fly back on Friday morning/noon.
>>  If this time is OK with everyone, I will find a place and let 
>> you know where and what time to meet.
>>
>> 2.  There is a bug opened for the QoS Flow Classifier
>> https://bugs.launchpad.net/neutron/+bug/1527671
>> We can either change the bug title and modify the bug details or 
>> start with a new one for the common FC which provides info on all 
>> requirements needed by all relevant use cases. There is a bug opened 
>> for OVS agent extension 
>> https://bugs.launchpad.net/neutron/+bug/1517903
>>
>> 3.  There are some very rough, ugly as Sean put it:-), and 
>> preliminary work on common FC 
>> https://github.com/openstack/neutron-classifier which we can see how 
>> to leverage. There is also a SFC API spec which covers the FC API for 
>> SFC usage 
>> https://github.com/openstack/networking-sfc/blob/master/doc/source/ap
>> i.rst, the following is the CLI version of the Flow Classifier for 
>> your
>> reference:
>>
>> neutron flow-classifier-create [-h]
>>  [--description ]
>>  [--protocol ]
>>  [--ethertype ]
>>  [--source-port :> source protocol port>]
>>  [--destination-port > port>:]
>>  [--source-ip-prefix ]
>>  [--destination-ip-prefix ]
>>  [--logical-source-port ]
>>  [--logical-destination-port ]
>>  [--l7-parameters ] FLOW-CLASSIFIER-NAME
>>
>> The corresponding code is here
>> https://github.com/openstack/networking-sfc/tree/master/networking_sf
>> c/extensions
>>
>> 

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Thank you!

Cathy

-Original Message-
From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com] 
Sent: Friday, May 06, 2016 12:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Sounds good,

   I started by opening a tiny RFE, that may help in the organization of flows 
inside OVS agent, for inter operability of features (SFC, TaaS, ovs fw, and 
even port trunking with just openflow). [1] [2]


[1] https://bugs.launchpad.net/neutron/+bug/1577791
[2] http://paste.openstack.org/show/495967/


On Fri, May 6, 2016 at 12:35 AM, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
> Hi everyone,
>
> We had a discussion on the two topics during the summit. Here is the etherpad 
> link for the discussion.
> https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit
>
> We agreed to continue the discussion on Neutron channel on a weekly basis. It 
> seems UTC 1700 ~ UTC 1800 Tuesday is good for most people.
> Another option is UTC 1700 ~ UTC 1800 Friday.
>
> I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
> this time is good for all people who have interest and like to contribute to 
> this work. We plan to start the first meeting on May 17.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Cathy Zhang
> Sent: Thursday, April 21, 2016 11:43 AM
> To: Cathy Zhang; OpenStack Development Mailing List (not for usage 
> questions); Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim 
> Daniel; Mathieu Rohon; Shaughnessy, David; Eichberger, German; Henry 
> Fourie; arma...@gmail.com; Miguel Angel Ajo; Reedip; Thierry Carrez
> Cc: Cathy Zhang
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
> and OVS Agent extension for Newton cycle
>
> Hi everyone,
>
> We have room 400 at 3:10pm on Thursday available for discussion of the two 
> topics.
> Another option is to use the common room with roundtables in "Salon C" during 
> Monday or Wednesday lunch time.
>
> Room 400 at 3:10pm is a closed room while the Salon C is a big open room 
> which can host 500 people.
>
> I am Ok with either option. Let me know if anyone has a strong preference.
>
> Thanks,
> Cathy
>
>
> -Original Message-
> From: Cathy Zhang
> Sent: Thursday, April 14, 2016 1:23 PM
> To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
> Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
> Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry 
> Fourie; 'arma...@gmail.com'
> Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier 
> and OVS Agent extension for Newton cycle
>
> Thanks for everyone's reply!
>
> Here is the summary based on the replies I received:
>
> 1.  We should have a meet-up for these two topics. The "to" list are the 
> people who have interest in these topics.
> I am thinking about around lunch time on Tuesday or Wednesday since some 
> of us will fly back on Friday morning/noon.
> If this time is OK with everyone, I will find a place and let you know 
> where and what time to meet.
>
> 2.  There is a bug opened for the QoS Flow Classifier 
> https://bugs.launchpad.net/neutron/+bug/1527671
> We can either change the bug title and modify the bug details or start 
> with a new one for the common FC which provides info on all 
> requirements needed by all relevant use cases. There is a bug opened 
> for OVS agent extension 
> https://bugs.launchpad.net/neutron/+bug/1517903
>
> 3.  There are some very rough, ugly as Sean put it:-), and preliminary 
> work on common FC https://github.com/openstack/neutron-classifier 
> which we can see how to leverage. There is also a SFC API spec which 
> covers the FC API for SFC usage 
> https://github.com/openstack/networking-sfc/blob/master/doc/source/api
> .rst, the following is the CLI version of the Flow Classifier for your 
> reference:
>
> neutron flow-classifier-create [-h]
> [--description ]
> [--protocol ]
> [--ethertype ]
> [--source-port : protocol port>]
> [--destination-port : destination protocol port>]
> [--source-ip-prefix ]
> [--destination-ip-prefix ]
> [--logical-source-port ]
> [--logical-destination-port ]
> [--l7-parameters ] FLOW-CLASSIFIER-NAME
>
> The corresponding code is here 
> https://github.com/openstack/networking-sfc/tree/master/networking_sfc
> /extensions
>
> 4.  We should come up with a formal Neutron spec for FC and another 
> one for OVS Agent extension an

[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi everyone,

We had a discussion on the two topics during the summit. Here is the etherpad 
link for the discussion. 
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

We agreed to continue the discussion on Neutron channel on a weekly basis. It 
seems UTC 1700 ~ UTC 1800 Tuesday is good for most people. 
Another option is UTC 1700 ~ UTC 1800 Friday. 

I will tentatively set the meeting time to UTC 1700 ~ UTC 1800 Tuesday. Hope 
this time is good for all people who have interest and like to contribute to 
this work. We plan to start the first meeting on May 17. 

Thanks,
Cathy


-Original Message-
From: Cathy Zhang 
Sent: Thursday, April 21, 2016 11:43 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions); 
Ihar Hrachyshka; Vikram Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; 
Shaughnessy, David; Eichberger, German; Henry Fourie; arma...@gmail.com; Miguel 
Angel Ajo; Reedip; Thierry Carrez
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-----
From: Cathy Zhang
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to t

[openstack-dev] [Neutron] meeting topics for 5/5/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
Here are some topics I have for this week's project meeting discussion(The 
meeting time is not changed, still UTC 1700 Thursday). Feel free to add more.
You can also find the meeting topics in the project wiki page.  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
* Confirm the CI maintenance ownership
* Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
* Requirement for reference Implementation on OVS driver and OVS Agent 
path for any API extension
* Add support for Querying Driver capability for SFC functionality 
support
* Use case documentation
* new field "priority" in flow-classifier
* Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component
* Define VNF type (l2 or l3) param in service-function-param
* Add "NSH" encap param in service-chain-param
* Networking-sfc SFC driver for OVN
* Networking-sfc SFC driver for ODL
* Networking-sfc integration with ONOS completion status update
* Tacker Driver for networking-sfc
* Dynamic service chain update without service interruption


Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Miguel,

No worry. Today is just a meeting for lunch to get to know each other although 
we touched some technical points.
We will recap and do the technical discussion at Room 400 at 3:10pm Thursday.

Cathy

From: Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
Sent: Wednesday, April 27, 2016 10:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle


Trying to find you folks. I was late
El 27/4/2016 12:04, "Paul Carver" 
<pcar...@paulcarver.us<mailto:pcar...@paulcarver.us>> escribió:
SFC team and anybody else dealing with flow selection/classification (e.g. QoS),

I just wanted to confirm that we're planning to meet in salon C today 
(Wednesday) to get lunch but then possibly move to a quieter location to 
discuss the common flow classifier ideas.

On 4/21/2016 19:42, Cathy Zhang wrote:
I like Malini’s suggestion on meeting for a lunch to get to know each
other, then continue on Thursday.

So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday
and then continue the discussion at Room 400 at 3:10pm Thursday.

Since Salon C is a big room, I will put a sign “Common Flow Classifier
and OVS Agent Extension” on the table.

I have created an etherpad for the discussion.
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

We will have a technical discussion tomorrow and record our meeting minutes in 
the etherpad. 
Tuesday is more a f2f social meet-up. 

Thanks,
Cathy

-Original Message-
From: Elzur, Uri [mailto:uri.el...@intel.com] 
Sent: Wednesday, April 27, 2016 12:42 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

Can you pls add more detailed minutes as to emerging agreements/understandings?

Thx

Uri ("Oo-Ree")
C: 949-378-7568


-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com]
Sent: Tuesday, April 26, 2016 11:50 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

2016-04-26 12:31 GMT-05:00 Henry Fourie :
> All,
>Please use the networking-sfc etherpad to record discussions at the
> meetups:
>
> https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting
>
>  - Louis
>
> -Original Message-
> From: Paul Carver [mailto:pcar...@paulcarver.us]
> Sent: Tuesday, April 26, 2016 10:20 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc 
> project f2f2 meet-up place and time
>
> On 4/26/2016 00:35, Akihiro Motoki wrote:
>> Hi Cathy and folks interested in SFC and classifers!
>>
>> Can't we use a different room like Salon D?
>> Salon C is a lunch room and at that time there are no sessions in other 
>> rooms.
>> It would be great if we can use Salon D or E (after looking at the 
>> first day's session) I think we can gather more easily and 
>> concentrate the discussion if we use some different space.
>> Thought?
>>
>
> Akihiro,
>
> Unless I've misunderstood the emails, the plan for Tuesday is a social lunch 
> for the SFC team to get together. The plan for Wednesday is a working lunch 
> to discuss flow classifiers in various projects and figure out how to 
> converge on a single flow classifier API/model that can be shared by 
> everything that needs to specify flows.
>
> If that's correct, then meeting in Salon C for lunch on Tuesday makes sense. 
> For Wednesday we probably ought to grab boxed lunches and find a quiet room.

I was confused with networking-sfc f2f meeting and flow classifier one.
My previous mail is a suggestion for wednesday flow classifier meeting.
Thanks for point it out.

Akihiro


>
>
> __
>  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
>
> __
>  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

__
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

__
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

__
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

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

Hi Anil,

Sorry just checked the email. We ended it around 1:45pm.
It is mostly a get-to-know each other f2f meet-up lunch. Not much technical 
discussion. You can refer to the etherpad on the discussion notes.

Thanks,
Cathy

From: Anil Vishnoi [mailto:vishnoia...@gmail.com]
Sent: Tuesday, April 26, 2016 11:13 AM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

cathy, you guys are still there? I got stuck in some other meeting.

On Fri, Apr 22, 2016 at 5:03 PM, Anil Vishnoi 
<vishnoia...@gmail.com<mailto:vishnoia...@gmail.com>> wrote:
Sounds good. Thanks Cathy.

Anil

On Fri, Apr 22, 2016 at 3:30 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Everyone,

As we discussed in our project meeting, we should have a f2f meeting during the 
summit.
let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
Since Salon C is a big room, I will put a sign “Networking-SFC Project Meet-Up” 
on the table.

Thanks,
Cathy




--
Thanks
Anil



--
Thanks
Anil
__
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

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

Hi Akihiro,

We are at Salon C now. Could you come here to have lunch together and then we 
can move to Salon D after lunch if needed. 

Thanks,
Cathy

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, April 25, 2016 10:36 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

Hi Cathy and folks interested in SFC and classifers!

Can't we use a different room like Salon D?
Salon C is a lunch room and at that time there are no sessions in other rooms.
It would be great if we can use Salon D or E (after looking at the first day's 
session) I think we can gather more easily and concentrate the discussion if we 
use some different space.
Thought?

Akihiro

2016-04-22 17:30 GMT-05:00 Cathy Zhang <cathy.h.zh...@huawei.com>:
> Hi Everyone,
>
>
>
> As we discussed in our project meeting, we should have a f2f meeting 
> during the summit.
>
> let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
>
> Since Salon C is a big room, I will put a sign “Networking-SFC Project 
> Meet-Up” on the table.
>
>
>
> Thanks,
>
> Cathy
>
>
__
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

Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

Hi Stephen,

Yes, I will take notes on the etherpad.

Thanks,
Cathy

From: Stephen Wong [mailto:stephen.kf.w...@gmail.com]
Sent: Monday, April 25, 2016 3:05 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

Hi,

Unfortunately I will miss this f2f meeting since I won't arrive until late 
evening on Tuesday. But I did update the etherpad LouisF posted [1] (during the 
last IRC meeting) with some topics of interest. If any of them happens to be 
discussed during Tuesday's meetup, please update the etherpad accordingly. 
Thanks!

Actually, in general, please take notes in the etherpad so we can review as 
topics of interest (and corresponding discussion points) for development 
planning for the next cycle.

Thanks,
- Stephen

[1]  https://etherpad.openstack.org/p/networking-sfc-austin-summit-meeting

On Fri, Apr 22, 2016 at 3:30 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi Everyone,

As we discussed in our project meeting, we should have a f2f meeting during the 
summit.
let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
Since Salon C is a big room, I will put a sign “Networking-SFC Project Meet-Up” 
on the table.

Thanks,
Cathy


__
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

Re: [openstack-dev] [neutron] Social at the summit

[Cathy Zhang]

Hi Kyle,

Thanks for this. Count me in. 

Cathy

-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: Monday, April 25, 2016 11:07 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Social at the summit

OK, there is enough interest, I'll find a place on 6th Street for us and get a 
reservation for Thursday around 7 or so.

Thanks folks!

On Mon, Apr 25, 2016 at 12:30 PM, Zhou, Han  wrote:
> +1 :)
>
> Han Zhou
> Irc: zhouhan
>
>
> On Monday, April 25, 2016, Korzeniewski, Artur 
>  wrote:
>>
>> Sign me up :)
>>
>> Artur
>> IRC: korzen
>>
>> -Original Message-
>> From: Darek Smigiel [mailto:smigiel.dari...@gmail.com]
>> Sent: Monday, April 25, 2016 7:19 PM
>> To: OpenStack Development Mailing List (not for usage questions) 
>> 
>> Subject: Re: [openstack-dev] [neutron] Social at the summit
>>
>> Count me in!
>> Will be good to meet all you guys!
>>
>> Darek (dasm) Smigiel
>>
>> > On Apr 25, 2016, at 12:13 PM, Doug Wiegley 
>> >  wrote:
>> >
>> >
>> >> On Apr 25, 2016, at 12:01 PM, Ihar Hrachyshka 
>> >> 
>> >> wrote:
>> >>
>> >> WAT???
>> >>
>> >> It was never supposed to be core only. Everyone is welcome!
>> >
>> > +2
>> >
>> > irony intended.
>> >
>> > Socials are not controlled by gerrit ACLs.  :-)
>> >
>> > doug
>> >
>> >>
>> >> Sent from my iPhone
>> >>
>> >>> On 25 Apr 2016, at 11:56, Edgar Magana 
>> >>> wrote:
>> >>>
>> >>> Would you extend it to ex-cores?
>> >>>
>> >>> Edgar
>> >>>
>> >>>
>> >>>
>> >>>
>>  On 4/25/16, 10:55 AM, "Kyle Mestery"  wrote:
>> 
>>  Ihar, Henry and I were talking and we thought Thursday night 
>>  makes sense for a Neutron social in Austin. If others agree, 
>>  reply on this thread and we'll find a place.
>> 
>>  Thanks!
>>  Kyle
>> 
>>  
>>  ___ ___ 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-de
>>  v
>> >>> _
>> >>> ___ __ 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
>> >>
>> >> __
>> >> ___ _ 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
>> >
>> >
>> > ___
>> > ___  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
>>
>>
>> _
>> _ 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
>>
>> _
>> _ 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
>
>
> __
>  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
>

__
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

__
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

[openstack-dev] [neutron] [networking-sfc] Network-sfc project f2f2 meet-up place and time

[Cathy Zhang]

Hi Everyone,

As we discussed in our project meeting, we should have a f2f meeting during the 
summit.
let's meet at "Salon C" for lunch from 12:30pm~1:50pm on Tuesday.
Since Salon C is a big room, I will put a sign "Networking-SFC Project Meet-Up" 
on the table.

Thanks,
Cathy

__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

I like Malini’s suggestion on meeting for a lunch to get to know each other, 
then continue on Thursday.
So let’s meet at "Salon C" for lunch from 12:30pm~1:50pm on Wednesday and then 
continue the discussion at Room 400 at 3:10pm Thursday.
Since Salon C is a big room, I will put a sign “Common Flow Classifier and OVS 
Agent Extension” on the table.

I have created an etherpad for the discussion. 
https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

Thanks,
Cathy


From: Stephen Wong [mailto:stephen.kf.w...@gmail.com]
Sent: Thursday, April 21, 2016 1:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Cathy Zhang; Miguel Angel Ajo; Reedip
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

+1 on Wednesday lunch

On Thu, Apr 21, 2016 at 12:02 PM, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics.
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference.

On Monday, I have two talks to do. First one is 2:50-3:30pm, second one is 
4:40-5:20pm. But lunch time should probably be fine if it leaves time for the 
actual lunch...

Thursday at 3:10pm also works for me.


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi everyone,

We have room 400 at 3:10pm on Thursday available for discussion of the two 
topics. 
Another option is to use the common room with roundtables in "Salon C" during 
Monday or Wednesday lunch time.

Room 400 at 3:10pm is a closed room while the Salon C is a big open room which 
can host 500 people.

I am Ok with either option. Let me know if anyone has a strong preference. 

Thanks,
Cathy


-Original Message-----
From: Cathy Zhang 
Sent: Thursday, April 14, 2016 1:23 PM
To: OpenStack Development Mailing List (not for usage questions); 'Ihar 
Hrachyshka'; Vikram Choudhary; 'Sean M. Collins'; 'Haim Daniel'; 'Mathieu 
Rohon'; 'Shaughnessy, David'; 'Eichberger, German'; Cathy Zhang; Henry Fourie; 
'arma...@gmail.com'
Subject: RE: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before) 
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.

> Different features may extend OVS agent and add different new OVS flow 
> tables to support their new functionality. A mechanism is needed to 
> ensure consistent OVS flow table modification when multiple features 
> co-exist. AFAIK, there is some preliminary work on this, but it is not 
> a complete solution yet.

I think there is no formal spec or anything, just some emails around there.

That said, I don’t follow why it’s a requirement for SFC to switch to l2 agent 
extension mechanism. Even today, with SFC maintaining its own agent, there are 
no clear guarantees for flow priorities that would avoid all possible conflicts.

Cathy> There is no requirement for SFC to switch. My understanding is that 
current L2 agent extension does not solve the conflicting entry issue if two 
features inject the same priority table entry. I think this new L2 agent effort 
is try to come up with a mechanism to reso

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Sure, good suggestion!  I am thinking we can have a lunch/dinner together. I 
will put this in Thursday's meeting agenda and let you and others know the f2f 
meeting time and place. Any specific date that is not good for you?

Thanks,
Cathy


From: John McDowall [mailto:jmcdow...@paloaltonetworks.com]
Sent: Tuesday, April 19, 2016 5:27 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 
networking-sfc project IRC meeting

Cathy,

Thanks - is it worth while to have a f2f meeting with everyone at the summit?

Regards

John

Sent from my iPhone

On Apr 19, 2016, at 5:25 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
Hi John,

Thanks for the note. Great that you already have a skeleton OVN driver for 
networking-sfc.
The next step is to contribute to the detail driver specification and then work 
out the edges and details on the coding side as well as unit test and 
integration test (still a lot of work down the road:)). We can either sync up 
in the next project meeting (5/5 meeting) or sync up offline after you come 
back from the travel.

We will cancel the 4/28 project meeting since it is the OpenStack Summit week.

Thanks,
Cathy

From: John McDowall [mailto:jmcdow...@paloaltonetworks.com]
Sent: Tuesday, April 19, 2016 2:38 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 
networking-sfc project IRC meeting

Cathy,

I will not make the meeting on Thursday (traveling), but I have a skeleton OVN 
Driver in progress and should have it working by the end of the week with OVN 
and the current networking-sfc API. Lots of edge conditions and details to be 
worked out but the driver model make it pretty easy. Not sure of the next steps 
- contribute to the blueprint?

Regards

John

From: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>
Date: Tuesday, April 19, 2016 at 11:28 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>
Subject: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc 
project IRC meeting

Hi everyone,
Here are some topics I have for this week's project meeting discussion(The 
meeting time is not changed, still UTC 1700 Thursday). Feel free to add more.
You can also find the meeting topics in the project wiki page.  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Meetings_ServiceFunctionChainingMeeting=CwMFAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=vMgCMsjn906ziN6T3iPlpzfMXRm17lPMgzesF0adY6U=AUSU1HCezI2Us9EVSu7uUxv5O8QANpGdBLLCnMJ5Bfc=>
 Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
* Meeting time change from Thursday 1700 UTC to Friday 1700 UTC since 
no open channel for Wednesday 1700 UTC?
* Maintain the CI seriously and ensure the code in the repo pass all 
the basic static checks (needs ownership)
* Code Patches scrub
* Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
* new field "priority" in flow-classifier
* Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component
* Define VNF type (l2 or l3) param in service-function-param
* Networking-sfc SFC driver for OVN
* Networking-sfc SFC driver for ODL
* Networking-sfc integration with ONOS completion status update
* Tacker Driver for networking-sfc
* Dynamic service chain update without service interruption


Thanks,
Cathy
__
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

Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi John,

Thanks for the note. Great that you already have a skeleton OVN driver for 
networking-sfc.
The next step is to contribute to the detail driver specification and then work 
out the edges and details on the coding side as well as unit test and 
integration test (still a lot of work down the road:)). We can either sync up 
in the next project meeting (5/5 meeting) or sync up offline after you come 
back from the travel.

We will cancel the 4/28 project meeting since it is the OpenStack Summit week.

Thanks,
Cathy

From: John McDowall [mailto:jmcdow...@paloaltonetworks.com]
Sent: Tuesday, April 19, 2016 2:38 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] meeting topics for 4/21/2016 
networking-sfc project IRC meeting

Cathy,

I will not make the meeting on Thursday (traveling), but I have a skeleton OVN 
Driver in progress and should have it working by the end of the week with OVN 
and the current networking-sfc API. Lots of edge conditions and details to be 
worked out but the driver model make it pretty easy. Not sure of the next steps 
- contribute to the blueprint?

Regards

John

From: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>
Date: Tuesday, April 19, 2016 at 11:28 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Cc: Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>
Subject: [openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc 
project IRC meeting

Hi everyone,
Here are some topics I have for this week's project meeting discussion(The 
meeting time is not changed, still UTC 1700 Thursday). Feel free to add more.
You can also find the meeting topics in the project wiki page.  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.openstack.org_wiki_Meetings_ServiceFunctionChainingMeeting=CwMFAg=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ=vMgCMsjn906ziN6T3iPlpzfMXRm17lPMgzesF0adY6U=AUSU1HCezI2Us9EVSu7uUxv5O8QANpGdBLLCnMJ5Bfc=>
 Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
* Meeting time change from Thursday 1700 UTC to Friday 1700 UTC since 
no open channel for Wednesday 1700 UTC?
* Maintain the CI seriously and ensure the code in the repo pass all 
the basic static checks (needs ownership)
* Code Patches scrub
* Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
* new field "priority" in flow-classifier
* Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component
* Define VNF type (l2 or l3) param in service-function-param
* Networking-sfc SFC driver for OVN
* Networking-sfc SFC driver for ODL
* Networking-sfc integration with ONOS completion status update
* Tacker Driver for networking-sfc
* Dynamic service chain update without service interruption


Thanks,
Cathy
__
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

[openstack-dev] [Neutron] meeting topics for 4/21/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
Here are some topics I have for this week's project meeting discussion(The 
meeting time is not changed, still UTC 1700 Thursday). Feel free to add more.
You can also find the meeting topics in the project wiki page.  
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
 Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4
* Meeting time change from Thursday 1700 UTC to Friday 1700 UTC since 
no open channel for Wednesday 1700 UTC?
* Maintain the CI seriously and ensure the code in the repo pass all 
the basic static checks (needs ownership)
* Code Patches scrub
* Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver
* new field "priority" in flow-classifier
* Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component
* Define VNF type (l2 or l3) param in service-function-param
* Networking-sfc SFC driver for OVN
* Networking-sfc SFC driver for ODL
* Networking-sfc integration with ONOS completion status update
* Tacker Driver for networking-sfc
* Dynamic service chain update without service interruption


Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Reedip,

Sure will include you in the discussion. Let me know if there are other 
Tap-as-a-Service members who would like to join this initiative.

Cathy

From: reedip banerjee [mailto:reedi...@gmail.com]
Sent: Thursday, April 14, 2016 7:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Speaking on behalf of Tap-as-a-Service members, we would also be very much 
interested in the following initiative :)

On Fri, Apr 15, 2016 at 5:14 AM, Ihar Hrachyshka 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:

I think there is no formal spec or anything, just some emails around there.

That said, I don’t follow why it’s a requirement for SFC to switch to l2 agent 
extension mechanism. Even today, with SFC maintaining its own agent, there are 
no clear guarantees for flow priorities that would avoid all possible conflicts.

Cathy> There is no requirement for SFC to switch. My understanding is that 
current L2 agent extension does not solve the conflicting entry issue if two 
features inject the same priority table entry. I think this new L2 agent effort 
is try to come up with a mechanism to resolve this issue. Of course if each 
feature( SFC or Qos) uses its own agent, then there is no coordination and no 
way to avoid conflicts.

Sorry, I probably used misleading wording. I meant, why do we consider the 
semantic flow management support in l2 agent extension framework a 
*prerequisite* for SFC to switch to l2 agent extensions? The existing framework 
should already allow SFC to achieve what you have in the subproject tree 
implemented as a separate agent (essentially a fork of OVS agent). It will also 
set SFC to use standard extension mechanisms instead of hacky inheritance from 
OVS agent classes. So even without the strict semantic flow management, there 
is benefit for the subproject.

With that in mind, I would split this job into 3 pieces:
* first, adopt l2 agent extension mechanism for SFC functionality (dropping 
custom agent);
* then, work on semantic flow management support in OVS agent API class [1];
* once the feature emerges, switch SFC l2 agent extension to the new framework 
to manage SFC flows.

I would at least prioritize the first point and target it to Newton-1. Other 
bullet points may take significant time to bake.

[1] 
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py


Ihar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Thanks and Regards,
Reedip Banerjee
IRC: reedip



__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi Ihar,

My replies are inline.

Thanks,
Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, April 14, 2016 4:45 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions); Vikram 
Choudhary; Sean M. Collins; Haim Daniel; Mathieu Rohon; Shaughnessy, David; 
Eichberger, German; Henry Fourie; Armando M.
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

>
> I think there is no formal spec or anything, just some emails around there.
>
> That said, I don’t follow why it’s a requirement for SFC to switch to 
> l2 agent extension mechanism. Even today, with SFC maintaining its own 
> agent, there are no clear guarantees for flow priorities that would 
> avoid all possible conflicts.
>
> Cathy> There is no requirement for SFC to switch. My understanding is
> that current L2 agent extension does not solve the conflicting entry 
> issue if two features inject the same priority table entry. I think 
> this new L2 agent effort is try to come up with a mechanism to resolve 
> this issue. Of course if each feature( SFC or Qos) uses its own agent, 
> then there is no coordination and no way to avoid conflicts.

Sorry, I probably used misleading wording. I meant, why do we consider the 
semantic flow management support in l2 agent extension framework a
*prerequisite* for SFC to switch to l2 agent extensions? The existing framework 
should already allow SFC to achieve what you have in the subproject tree 
implemented as a separate agent (essentially a fork of OVS agent). It will also 
set SFC to use standard extension mechanisms instead of hacky inheritance from 
OVS agent classes. So even without the strict semantic flow management, there 
is benefit for the subproject.

Cathy> Yes, the existing extension mechanism with Bridge wrapper and cookie is 
a step forward for subprojects.  

With that in mind, I would split this job into 3 pieces:
* first, adopt l2 agent extension mechanism for SFC functionality (dropping 
custom agent);
* then, work on semantic flow management support in OVS agent API class [1];
* once the feature emerges, switch SFC l2 agent extension to the new framework 
to manage SFC flows.

I would at least prioritize the first point and target it to Newton-1.  
Other bullet points may take significant time to bake.

Cathy> Good suggestion. We can do this in steps. Previously we were thinking 
about waiting until strict flow management is supported in the extension. 

Thanks,
Cathy

[1]
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py

Ihar
__
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

Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Thanks for everyone's reply! 

Here is the summary based on the replies I received: 

1.  We should have a meet-up for these two topics. The "to" list are the people 
who have interest in these topics. 
I am thinking about around lunch time on Tuesday or Wednesday since some of 
us will fly back on Friday morning/noon. 
If this time is OK with everyone, I will find a place and let you know 
where and what time to meet. 

2.  There is a bug opened for the QoS Flow Classifier 
https://bugs.launchpad.net/neutron/+bug/1527671
We can either change the bug title and modify the bug details or start with a 
new one for the common FC which provides info on all requirements needed by all 
relevant use cases. There is a bug opened for OVS agent extension 
https://bugs.launchpad.net/neutron/+bug/1517903

3.  There are some very rough, ugly as Sean put it:-), and preliminary work on 
common FC https://github.com/openstack/neutron-classifier which we can see how 
to leverage. There is also a SFC API spec which covers the FC API for SFC usage 
https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst,
the following is the CLI version of the Flow Classifier for your reference:

neutron flow-classifier-create [-h]
[--description ]
[--protocol ]
[--ethertype ]
[--source-port :]
[--destination-port :]
[--source-ip-prefix ]
[--destination-ip-prefix ]
[--logical-source-port ]
[--logical-destination-port ]
[--l7-parameters ] FLOW-CLASSIFIER-NAME

The corresponding code is here 
https://github.com/openstack/networking-sfc/tree/master/networking_sfc/extensions

4.  We should come up with a formal Neutron spec for FC and another one for OVS 
Agent extension and get everyone's review and approval. Here is the etherpad 
catching our previous requirement discussion on OVS agent (Thanks David for the 
link! I remember we had this discussion before)
https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion


More inline. 

Thanks,
Cathy


-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Thursday, April 14, 2016 3:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] work on Common Flow Classifier and OVS 
Agent extension for Newton cycle

Cathy Zhang <cathy.h.zh...@huawei.com> wrote:

> Hi everyone,
> Per Armando’s request, Louis and I are looking into the following 
> features for Newton cycle.
> · Neutron Common FC used for SFC, QoS, Tap as a service etc.,
> · OVS Agent extension
> Some of you might know that we already developed a FC in 
> networking-sfc project and QoS also has a FC. It makes sense that we 
> have one common FC in Neutron that could be shared by SFC, QoS, Tap as a 
> service etc.
> features in Neutron.

I don’t actually know of any classifier in QoS. It’s only planned to emerge, 
but there are no specs or anything specific to the feature.

Anyway, I agree that classifier API belongs to core neutron and should be 
reused by all interested subprojects from there.

> Different features may extend OVS agent and add different new OVS flow 
> tables to support their new functionality. A mechanism is needed to 
> ensure consistent OVS flow table modification when multiple features 
> co-exist. AFAIK, there is some preliminary work on this, but it is not 
> a complete solution yet.

I think there is no formal spec or anything, just some emails around there.

That said, I don’t follow why it’s a requirement for SFC to switch to l2 agent 
extension mechanism. Even today, with SFC maintaining its own agent, there are 
no clear guarantees for flow priorities that would avoid all possible conflicts.

Cathy> There is no requirement for SFC to switch. My understanding is that 
current L2 agent extension does not solve the conflicting entry issue if two 
features inject the same priority table entry. I think this new L2 agent effort 
is try to come up with a mechanism to resolve this issue. Of course if each 
feature( SFC or Qos) uses its own agent, then there is no coordination and no 
way to avoid conflicts. 

> We will like to start these effort by collecting requirements and then 
> posting specifications for review. If any of you would like to join 
> this effort, please chime in. We can set up a meet-up session in the 
> Summit to discuss this face-in-face.

Great. Let’s have a meetup for this topic.

Ihar

__
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
__
OpenStack Development Mailing List (not for usage questions)
Uns

[openstack-dev] [neutron] work on Common Flow Classifier and OVS Agent extension for Newton cycle

[Cathy Zhang]

Hi everyone,
Per Armando's request, Louis and I are looking into the following features for 
Newton cycle.

* Neutron Common FC used for SFC, QoS, Tap as a service etc.,
* OVS Agent extension
Some of you might know that we already developed a FC in networking-sfc project 
and QoS also has a FC. It makes sense that we have one common FC in Neutron 
that could be shared by SFC, QoS, Tap as a service etc. features in Neutron.
Different features may extend OVS agent and add different new OVS flow tables 
to support their new functionality. A mechanism is needed to ensure consistent 
OVS flow table modification when multiple features co-exist. AFAIK, there is 
some preliminary work on this, but it is not a complete solution yet.
We will like to start these effort by collecting requirements and then posting 
specifications for review. If any of you would like to join this effort, please 
chime in. We can set up a meet-up session in the Summit to discuss this 
face-in-face.
Thanks,
Cathy
__
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

[openstack-dev] meeting topics for 4/14/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,
 Here are some topics I have in mind for tomorrow's meeting discussion. Feel 
free to add more.
 Meeting Info: Every Thursday 1700 UTC on #openstack-meeting-4

1. Meeting time change from Thursday 1700 UTC to Wednesday 1700 UTC?

2. Launch pad bug scrub

3. Launch pad Blueprint update

4. Remove Source port "mandatory" requirement in the FC API

5. Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver

6. new field "priority"  in flow-classifier

7. Move the generation of the data path chain path ID from the Driver 
component to the networking-sfc plugin component

8. Define VNF type (l2 or l3) param in service-function-param

9. Networking-sfc SFC driver for OVN

10.   Networking-sfc SFC driver for ODL

11.   Networking-sfc integration with ONOS completion status update

12.   Tacker Driver for networking-sfc

13.   Dynamic service chain update without service interruption


Thanks,
Cathy
__
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

[openstack-dev] meeting topics for 4/7/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,

Here are some topics I have in mind for tomorrow's meeting discussion. Feel 
free to add more.


1.   Source port specification in the FC

2.   Networking-sfc SFC driver for OVN

3.   Networking-sfc SFC driver for ODL

4.   Networking-sfc integration with ONOS completion status update

5.   Tacker Driver for networking-sfc

6.   Consistent Repository rule for networking-sfc related drivers: 
Northbound Tacker driver and Southbound ONOS driver, ODL driver, OVD driver

7.   Generate the Data path chain path ID

8.   Dynamic service chain update without service interruption

9.   Existing Bug scrub

Thanks,
Cathy

__
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

[openstack-dev] meeting topics for 3/31/2016 networking-sfc project IRC meeting

[Cathy Zhang]

Hi everyone,

First thanks to Louis Fourie and Paul Carver for chairing the project IRC 
meetings while I was on business trip.
Here are some topics I have in mind for tomorrow's meeting discussion. Feel 
free to add more.


1.   ODL SFC Driver to networking-sfc

2.   Networking-sfc driver to Tacker

3."Symmetric" parameter in the chain_param and let the underlying 
driver handle creating a reverse chain

4."SFC path-ID" parameter in the chain_param for supporting the 
wireless Gi-Lan scenario

5.   Source port specification in the FC

Thanks,
Cathy
__
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

[openstack-dev] [neutron] [networking-sfc] networking-sfc project IRC meeting

[Cathy Zhang]

Hi,

I am in a container conference and won't be able to chair this week's IRC 
meeting.
Paul Carver has volunteered to chair this week's meeting. Thanks Paul!
If there are any topics you would like to discuss, you can post them on the 
meeting wiki page

https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting

Thanks,
Cathy
__
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

[openstack-dev] [Neutron][networking-sfc] - No service chaining project IRC Meeting on 12/24 and 12/31

[Cathy Zhang]

Hi everyone,

We will cancel 12/24 and 12/31 1700 UTC IRC meetings for service chaining 
project since quite some people will be on vacation.
We will resume the project meeting on 1/7/2016.

Happy Holiday!

Cathy
__
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

Re: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

[Cathy Zhang]

Here it is (I posted this in today's IRC meeting too).

https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Thursday, December 03, 2015 10:34 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

Hi networking-sfc,

What is the recommended place to host the temporary installation instructions?

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

Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

[Cathy Zhang]

 I have some questions on option (c) and would like to make sure we are on the 
same page.

Thanks,
Cathy


(c) neutron sub-project repo
- [+] Each sub-project can develop a dashboard fast.
- [-] It is doable, but the directory tree can be complicated.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.
If we work in the same mode as we do DevStack plugins today, that is inside the 
sub-projects repo, the number of repos should be equal to the number of 
sub-projects. Also, this simplifies the packaging and allow each subproject 
owners to take ownership of the code. Guidance from Horizon folks will be 
appreciated to help the interested people get started. Question is: does 
Horizon plugin follow the same model as Neutron plugins like all the code is 
part of Horizon umbrella? If yes, then this might not be the ideal option.

Cathy> Thanks Akihiro for starting this discussion. +1 for the idea of doing 
this within each sub-project repo since its functionality is closely associated 
with the other code patches of the sub-project. Networking-sfc has already 
developed a Horizon dashboard in Horizon tree, but we got suggestion from 
Horizon team to move the code to the separate project repo. We are interested 
in trying this approach in the network-sfc project. Since this is a new way to 
add Horizon plugin, we would like to get guidance from Horizon folks. Is 
Horizon folks OK for this option and will give each Neutron sub-project the 
needed support? I think  Fawad raised a good question here. Does the Horizon 
code in each Neutron sub-project repo a part of Horizon umbrella? Do we need to 
get Horizon team’s approval for the code merge? If so, it comes back to the 
issue of how we can ensure faster iteration?



(d) a separate repo per neutron sub-project
Similar to (c)
- [+] A dedicate repo for dashboard simplifies the directory tree.
- [-] Need to setup a separate repo.
- [-] Lead to too many repos and the horizon team/liaison cannot cover all.
 Agree


Note that this mail is not intended to move the current neutron
support in horizon
to outside of horizon tree. I would like to discuss Horizon support of
additional features.

Akihiro

[1] http://docs.openstack.org/developer/horizon/plugins.html

__
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

__
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

Re: [openstack-dev] [neutron][sfc]

[Cathy Zhang]

Hi Oguz,

I will forward you the email on the steps of using DevStack to set up SFC. 

As you mentioned, the DevStack support patch for networking-sfc is being worked 
on and under review. 
The codes that support this feature including unit test codes have been 
developed and uploaded for review. We are now  actively working on integration 
testing of all code pieces as well as end-to-end testing of this feature, and 
bug fixes. 

Thanks,
Cathy

-Original Message-
From: Oguz Yarimtepe [mailto:oguzyarimt...@gmail.com] 
Sent: Tuesday, November 24, 2015 1:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][sfc]

Hi,

Is there any working Devstack configuration for sfc testing? I just saw one 
commit that is waiting review.

__
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

__
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

[openstack-dev] [neutron] [networking-sfc] Service Chain project IRC meeting Topic for 11/19/2015

[Cathy Zhang]

Hi everyone,

I have added some topics to the following link for our project meeting 
discussion tomorrow. Feel free to add topics you would like to discuss to this 
link.

https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting

Note that due to the day time change, the meeting time is now 9am pacific time.

Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Networking-sfc not just a shell. It has API, DB, DB Migration, Common Driver 
Manager, OVS Driver, OVS Agent, CLI, Horizon etc. codes uploaded for review for 
over one month. The project team is in the final review stage. And a patch for 
adding DevStack support for networking-sfc has also been uploaded for review. 
Once these codes are merged, the codes will be ready for download and 
deployment. 

Thanks,
Cathy

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Monday, November 16, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

Networking-sfc is still just a shell - there is no functional code.

-- 
Sean M. Collins

__
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

__
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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Hi Duarte,

We have just rebased the patches. We are in the stage of more comprehensive 
testing, bug fixes, review, and incorporating review comments. The code patches 
including the devstack patch will be merged once they are properly reviewed, 
and you can then download and deploy this functionality.

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, November 16, 2015 10:34 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

Hi networking-sfc folks,

I can't seem to be able to deploy the current networking-sfc using DevStack and 
my hint is that the latest review stack is dependent on previous patches that 
have not been updated/rebased yet ([1] and [2]) - and are depending on outdated 
patches.

In [3] you can see the output of q-svc after a clean DevStack installation 
(based on master) with the local.conf specified in [4].
I have pointed /opt/stack/networking-sfc to the last patch in the 
networking-sfc review stack, [5].

Please advise on how to proceed in order to get networking-sfc to work.

[1] https://review.openstack.org/#/c/227285
[2] https://review.openstack.org/#/c/227100
[3] http://paste.openstack.org/show/479020/
[4] http://paste.openstack.org/show/479021/
[5] https://review.openstack.org/#/c/238428/

Best regards,

[intel]

Igor Duarte Cardoso
Software Engineer
+353 61 777 858
SIE1-2-170
Intel Shannon Ltd.
Dromore House, East Park
Shannon, Co. Clare
IRELAND


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
__
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

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

I have updated the etherpad to add "Overall requirement - API cross check among 
the features that can manipulate the same flow's forwarding behavior".

Thanks,
Cathy

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Monday, November 16, 2015 7:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

On 11/13/2015 7:03 PM, Henry Fourie wrote:

>
>   I wonder whether just pushing flows into the existing tables at random 
> points in time can be unstable and break the usual flow assumed by the main 
> agent loop.
> LF> No not expect any issues.
>
> Am I making sense?
>
> [1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
>

I attempted to describe a possible issue at the bottom of the Etherpad in the 
bullet point "Overall requirement - Flow prioritization mechanism"



__
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

__
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

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Hi Kyle,

Thanks for adding patch [3] to clarify the current API status.

Cathy

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Monday, November 16, 2015 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant 
> wrote:
On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
>> This is a challenge. Personally, I haven't been able to get it all working
>> yet. But we're in a dilemma because we want to get good reviews of the code
>> before merging. Since the full functionality is quite a lot of code we
>> wanted to chop it into more easily reviewable chunks. Unfortunately that
>> makes it more difficult to pull it all in at once to test the whole thing
>> prior to completing the review and merge.
>
> I would be concerned about that. I am sympathetic to the chicken and egg
> problem of a new repo and new code, but I briefly looked at both of
> those reviews and they both are quite large. 1K LOC is usually the upper
> limit for a sane patch set. It may be worth trying to break into
> smaller, more manageable pieces - even if the initial commits just
> create some empty classes and stubbed methods, and then later start
> introducing the actual method bodies in small pieces with good unit
> tests for each one. Small pieces. Tiny steps.

Another thing I've been thinking about is the difference between having
a repo like networking-sfc where a sub-group is able to try out new
things while also managing expectations with consumers of Neutron.  How
does someone know the difference between something a bit more
experimental vs. when an API is established and can be considered stable
and maintained with backwards copmatibility like any other OpenStack
REST API?
In the case of SFC, consumers of the API should know it's tagged as 
"release:independent" [1], and also it should be clear there is no release made 
and the code isn't stable in the docs, but that isn't currently the case 
looking here [2]. Thus, I've submitted [3] to make this a bit more clear, 
comments welcome.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] http://docs.openstack.org/developer/networking-sfc/
[3] https://review.openstack.org/246001

I think networking-sfc should be able to keep merging code, including
the proposed API, but I think it should be clearly marked as
experimental and subject to change.  That's based on my experience so
far studying this proposal, SFC more generally, and watching other
efforts happening within Neutron that affect this.

How can we manage these expectations more clearly?
Well, since it hasn't released yet, I agree, lets experiment and let other 
backends try this out, and at the same time not lock things down. We just need 
to be clear about the intent here.
Thanks,
Kyle

--
Russell Bryant

__
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

__
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

[openstack-dev] Regarding OVN project and integration with SFC

[Cathy Zhang]

Hi Russell,

Has the OVN code been released in Liberty? If not when is it planned for 
release?
Will it replace existing OVS Driver and OVS Agent or it will provide an 
alternative path of
programming the OVS? It is on the networking-sfc project roadmap to support OVN 
integration with SFC.
We would like to work with you on adding an OVN driver and Agent to integrate 
with the networking-sfc API.
How would you like to proceed with this integration work?

Thanks,
Cathy
__
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

[openstack-dev] [neutron] [networking-sfc] We will resume our weekly Service Chain project IRC meeting starting on 11/12/2015

[Cathy Zhang]

Hi everyone,

Here is the meeting info:
Weekly on Thursday at 1700 
UTC 
in #openstack-meeting-4 (IRC 
webclient)
 .
Due to the day time saving change, the meeting will start at 9am pacific time.

Thanks,
Cathy
__
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

Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers

[Cathy Zhang]

Agree with Paul and Louis. The networking-sfc repo should be preserved to 
support the service function chain functionality. Flow classifier is just 
needed to specify what flows will go through the service port chain. 

The flow classifier API is designed as a separate plugin which is independent 
of the port chain plugin. We will support the effort of evolving it to a common 
service classifier API and moving it out of the networking-sfc repo when the 
time comes. 

Thanks,
Cathy

-Original Message-
From: Henry Fourie [mailto:louis.fou...@huawei.com] 
Sent: Wednesday, November 11, 2015 2:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic 
classifiers

Paul,
   Agree completely that the networking-sfc repo should be preserved as it 
includes functionality beyond that of just a classifier - it defines the 
service chain structure. 

Work on a common service classifier API could be done by the networking-sfc 
team to help in evaluating that API.

 - Louis   

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us]
Sent: Wednesday, November 11, 2015 1:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic 
classifiers

On 11/10/2015 8:30 AM, Sean M. Collins wrote:
> On Mon, Nov 09, 2015 at 07:58:34AM EST, Jay Pipes wrote:
>
>> 2) Keep the security-group API as-is to keep outward compatibility with AWS.
>> Create a single, new service-groups and service-group-rules API for
>> L2 to L7 traffic classification using mostly the modeling that Sean has put 
>> together.
>> Remove the networking-sfc repo and obselete the classifier spec. Not 
>> sure what should/would happen to the FWaaS API, frankly.
>
> As to the REST-ful API for creating classifiers, I don't know if it 
> should reside in the networking-sfc project. It's a big enough piece 
> that it will most likely need to be its own endpoint and repo, and 
> have stakeholders from other projects, not just networking-sfc. That 
> will take time and quite a bit of wrangling, so I'd like to defer that 
> for a bit and just work on all the services having the same data 
> model, where we can make changes quickly, since they are not visible 
> to API consumers.
>

I agree that the service classifier API should NOT reside in the networking-sfc 
project, but I don't understand why Jay suggests removing the networking-sfc 
repo. The classifier specified by networking-sfc is needed only because there 
isn't a pre-existing classifier API. As soon as we can converge on a common 
classifier API I am completely in favor of using it in place of the one in the 
networking-sfc repo, but SFC is more than just classifying traffic. We need a 
classifier in order to determine which traffic to redirect, but we also need 
the API to specify how to redirect the traffic that has been identified by 
classifiers.



__
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

__
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

__
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

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

Hi Ihar,

Thanks for initiating this discussion. I am in OPNFV Summit. Henry Fourie of 
SFC project team will reply with our feedback. 

Cathy

-Original Message-
From: Ihar Hrachyshka [mailto:ihrac...@redhat.com] 
Sent: Monday, November 09, 2015 4:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?

Thanks Thomas, much appreciated.

I need to admit that we haven’t heard from SFC folks just yet. I will try to 
raise awareness that we wait for their feedback today on team meeting.  
Adding [sfc] tag to the topic to get more attention.

Ihar

Thomas Morin  wrote:

> Hi Ihar,
>
> Ihar Hrachyshka :
>> Reviving the thread.
>> [...] (I appreciate if someone checks me on the following though):
>
> This is an excellent recap.
>
>>  I set up a new etherpad to collect feedback from subprojects [2].
>
> I've filled in details for networking-bgpvpn.
> Please tell me if you need more information.
>
>> Once we collect use cases there and agree on agent API for extensions 
>> (even if per agent type), we will implement it and define as stable 
>> API, then pass objects that implement the API into extensions thru 
>> extension manager. If extensions support multiple agent types, they 
>> can still distinguish between which API to use based on agent type 
>> string passed into extension manager.
>>
>> I really hope we start to collect use cases early so that we have 
>> time to polish agent API and make it part of l2 extensions earlier in 
>> Mitaka cycle.
>
> We'll be happy to validate the applicability of this approach as soon 
> as something is ready.
>
> Thanks for taking up this work!
>
> -Thomas
>
>
>
>> Ihar Hrachyshka  wrote:
>>
 On 30 Sep 2015, at 12:53, Miguel Angel Ajo  wrote:



 Ihar Hrachyshka wrote:
>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:
>>
>> Hi Ihar,
>>
>> Ihar Hrachyshka :
 Miguel Angel Ajo :
> Do you have a rough idea of what operations you may need to do?
 Right now, what bagpipe driver for networking-bgpvpn needs to 
 interact with is:
 - int_br OVSBridge (read-only)
 - tun_br OVSBridge (add patch port, add flows)
 - patch_int_ofport port number (read-only)
 - local_vlan_map dict (read-only)
 - setup_entry_for_arp_reply method (called to add static ARP
 entries)
>>> Sounds very tightly coupled to OVS agent.
> Please bear in mind, the extension interface will be available 
> from different agent types (OVS, SR-IOV, [eventually LB]), so 
> this interface you're talking about could also serve as a 
> translation driver for the agents (where the translation is 
> possible), I totally understand that most extensions are 
> specific agent bound, and we must be able to identify the 
> agent we're serving back exactly.
 Yes, I do have this in mind, but what we've identified for now 
 seems to be OVS specific.
>>> Indeed it does. Maybe you can try to define the needed pieces in 
>>> high level actions, not internal objects you need to access to.
>>> Like ‘- connect endpoint X to Y’, ‘determine segmentation id for 
>>> a network’ etc.
>> I've been thinking about this, but would tend to reach the 
>> conclusion that the things we need to interact with are pretty 
>> hard to abstract out into something that would be generic across 
>> different agents.  Everything we need to do in our case relates 
>> to how the agents use bridges and represent networks internally:
>> linuxbridge has one bridge per Network, while OVS has a limited 
>> number of bridges playing different roles for all networks with 
>> internal segmentation.
>>
>> To look at the two things you  mention:
>> - "connect endpoint X to Y" : what we need to do is redirect the 
>> traffic destinated to the gateway of a Neutron network, to the 
>> thing that will do the MPLS forwarding for the right BGP VPN 
>> context (called VRF), in our case br-mpls (that could be done 
>> with an OVS table too) ; that action might be abstracted out to 
>> hide the details specific to OVS, but I'm not sure on how to  
>> name the destination in a way that would be agnostic to these 
>> details, and this is not really relevant to do until we have a 
>> relevant context in which the linuxbridge would pass packets to 
>> something doing MPLS forwarding (OVS is currently the only option 
>> we support for MPLS forwarding, and it does not really make sense 
>> to mix linuxbridge for Neutron
>> L2/L3 and OVS for MPLS)
>> - "determine segmentation id for a network": this is something 
>> really OVS-agent-specific, the linuxbridge agent uses multiple 
>> 

Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension access agent methods ?

[Cathy Zhang]

Hi Vikram,

Thanks for the heads-up. Take care of yourself and your family.
We will provide the feedback on L2 agent.

Thanks,
Cathy

From: Vikram Choudhary [mailto:viks...@gmail.com]
Sent: Monday, November 09, 2015 6:59 PM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
access agent methods ?


Hi Cathy,

Could you please check on this. My mother passed away yesterday and I will be 
on leave for couple of weeks.

Thanks
Vikram
On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka" 
<ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
Thanks Thomas, much appreciated.

I need to admit that we haven’t heard from SFC folks just yet. I will try to 
raise awareness that we wait for their feedback today on team meeting. Adding 
[sfc] tag to the topic to get more attention.

Ihar

Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> wrote:
Hi Ihar,

Ihar Hrachyshka :
Reviving the thread.
[...] (I appreciate if someone checks me on the following though):

This is an excellent recap.
 I set up a new etherpad to collect feedback from subprojects [2].

I've filled in details for networking-bgpvpn.
Please tell me if you need more information.
Once we collect use cases there and agree on agent API for extensions (even if 
per agent type), we will implement it and define as stable API, then pass 
objects that implement the API into extensions thru extension manager. If 
extensions support multiple agent types, they can still distinguish between 
which API to use based on agent type string passed into extension manager.

I really hope we start to collect use cases early so that we have time to 
polish agent API and make it part of l2 extensions earlier in Mitaka cycle.

We'll be happy to validate the applicability of this approach as soon as 
something is ready.

Thanks for taking up this work!

-Thomas


Ihar Hrachyshka <ihrac...@redhat.com<mailto:ihrac...@redhat.com>> wrote:
On 30 Sep 2015, at 12:53, Miguel Angel Ajo 
<mangel...@redhat.com<mailto:mangel...@redhat.com>> wrote:



Ihar Hrachyshka wrote:
On 30 Sep 2015, at 12:08, 
thomas.mo...@orange.com<mailto:thomas.mo...@orange.com> wrote:

Hi Ihar,

Ihar Hrachyshka :
Miguel Angel Ajo :
Do you have a rough idea of what operations you may need to do?
Right now, what bagpipe driver for networking-bgpvpn needs to interact with is:
- int_br OVSBridge (read-only)
- tun_br OVSBridge (add patch port, add flows)
- patch_int_ofport port number (read-only)
- local_vlan_map dict (read-only)
- setup_entry_for_arp_reply method (called to add static ARP entries)
Sounds very tightly coupled to OVS agent.
Please bear in mind, the extension interface will be available from different 
agent types
(OVS, SR-IOV, [eventually LB]), so this interface you're talking about could 
also serve as
a translation driver for the agents (where the translation is possible), I 
totally understand
that most extensions are specific agent bound, and we must be able to identify
the agent we're serving back exactly.
Yes, I do have this in mind, but what we've identified for now seems to be OVS 
specific.
Indeed it does. Maybe you can try to define the needed pieces in high level 
actions, not internal objects you need to access to. Like ‘- connect endpoint X 
to Y’, ‘determine segmentation id for a network’ etc.
I've been thinking about this, but would tend to reach the conclusion that the 
things we need to interact with are pretty hard to abstract out into something 
that would be generic across different agents.  Everything we need to do in our 
case relates to how the agents use bridges and represent networks internally: 
linuxbridge has one bridge per Network, while OVS has a limited number of 
bridges playing different roles for all networks with internal segmentation.

To look at the two things you  mention:
- "connect endpoint X to Y" : what we need to do is redirect the traffic 
destinated to the gateway of a Neutron network, to the thing that will do the 
MPLS forwarding for the right BGP VPN context (called VRF), in our case br-mpls 
(that could be done with an OVS table too) ; that action might be abstracted 
out to hide the details specific to OVS, but I'm not sure on how to  name the 
destination in a way that would be agnostic to these details, and this is not 
really relevant to do until we have a relevant context in which the linuxbridge 
would pass packets to something doing MPLS forwarding (OVS is currently the 
only option we support for MPLS forwarding, and it does not really make sense 
to mix linuxbridge for Neutron L2/L3 and OVS for MPLS)
- "determine segmentation id for a network": this is something really 
OVS-agent-specific, the linuxbridge agent uses multiple linux bridges, and does 
not rely on internal segmentation

Completely abstracting out packet forwarding pipelines in OVS and

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

Hi Pino,

Please see inline.

Cathy

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Monday, November 02, 2015 10:22 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: Re: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

On Mon, Nov 2, 2015 at 9:56 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:


From: Giuseppe (Pino) de Candia 
[mailto:gdecan...@midokura.com<mailto:gdecan...@midokura.com>]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

>
> Cathy> No restriction as long as the ports are routable. Originally we think 
> we need to specify L2 and L3 service type. But later we found out it is not 
> needed if we program the switch to set the next hop destination to the 
> service function’s MAC. This way no matter whether it is L2 or L3, it always 
> works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible encapsulation to 
signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service 
port's MAC

How can the SDN implementation know which kind of service it's dealing with to 
decide whether to modify the MAC?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.
I don't think that works. For L3 services, the packet's destination MAC must be 
set equal to the service port's MAC. That means that all the original 
destination MACs get re-written to a single MAC.

In my L2 use-case, the VLAN is being used for signaling, and the VNF instance 
is shared across multiple tenants with overlapping IPs. Therefore, I use the 
MAC to identify the service chain instance and get a packet back on its 
original network path.

Cathy> Not sure why you use MAC to identify the service chain instance? It is 
better to use a separate chain ID for this purpose.

So, I won't modify the packet at all. Can you suggest another solution? And why 
so much resistance to adding a flag when we can actually show use-cases? Note 
that this is already actually running code today, using MidoNet's service 
chaining API.

Cathy> If you use a separate chainID, then you will not need a flag to handle 
the use cases. If you really need a flag, one way is to extend the SF parameter 
to specify a L2/L3 type.

thanks,
Pino


Thanks,

Cathy

__
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

Re: [openstack-dev] [neutron][networking-sfc] API clarification questions

[Cathy Zhang]

From: Giuseppe (Pino) de Candia [mailto:gdecan...@midokura.com]
Sent: Saturday, October 31, 2015 10:08 PM
To: Cathy Zhang
Cc: Henry Fourie; OpenStack Development Mailing List (not for usage questions); 
Irena Berezovsky
Subject: RE: [openstack-dev] [neutron][networking-sfc] API clarification 
questions

>
> Cathy> No restriction as long as the ports are routable. Originally we think 
> we need to specify L2 and L3 service type. But later we found out it is not 
> needed if we program the switch to set the next hop destination to the 
> service function’s MAC. This way no matter whether it is L2 or L3, it always 
> works.
>

Hi Cathy, my understanding is that:
-for an L2 service, don't modify the packet (ignoring possible encapsulation to 
signal policy )
-for an L3 service, set the dst MAC in the packet equal to the the service 
port's MAC

How can the SDN implementation know which kind of service it's dealing with to 
decide whether to modify the MAC?

Cathy> You can always modify the MAC which will work for both L2 and L3 service.

Thanks,

Cathy
__
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