[openstack-dev] [neutron] [classifier] No meeting today

[Duarte Cardoso, Igor]

There is no CCF meeting today since key people are on vacation.

Current work can be seen at 
https://review.openstack.org/#/q/project:openstack/neutron-classifier.

Best regards,
Igor D.C.

__
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] [classifier] Asking for feedback regarding Classification Types

[Duarte Cardoso, Igor]

Hi Neutron,

The CCF team has been discussing what protocols should be supported on the 
first version of the CCF (Common Classification Framework).

A potential list exhaustive list is available at [1]. However, this is likely 
overkill in terms of protocols that will actually be used for classification 
purposes at the API layer in Neutron (Neutron Stadium).

So think of this mail as a call for protocols that definitely have to be 
implemented in the CCF so that interested services/projects can consume from it.

If you have any other comments or important information, definitely let us know.

[1] 
https://github.com/openstack/neutron-lib/blob/99d4f1f35f8d915f48bfaa677f690b29bc4b0dbe/neutron_lib/constants.py#L176-L198
CCF: https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework

Best regards,
Igor D.C.

__
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] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that we have the Common Classification Framework meeting today, in 
about an hour, at #openstack-meeting.

It will be a short update about the code and PTG.

Agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_22_August_2017

Best regards,
Igor D.C.

__
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] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that we have the Common Classification Framework meeting today, in 
about an hour, at #openstack-meeting.

It will be a short update about the code and plans for the PTG.

Agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_8_August_2017

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-dev] [[neutron] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that we have the Common Classification Framework meeting today, in 
about an hour, at #openstack-meeting.

We'll talk about the v0 code submission

Agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_25_July_2017

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-dev] [neutron] No CCF meeting

[Duarte Cardoso, Igor]

Hi all,

The repository has been updated to pass the gate: 
https://review.openstack.org/#/c/480199/.

There will be no meeting today as we have no outstanding topics to discuss and 
are still working on submitting the first round of code of the Common 
Classification Framework, which is due for pike-3.

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] [ceilometer][networking-sfc] Meters/Statistics for Networking-SFC

[Duarte Cardoso, Igor]

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

[openstack-dev] [neutron] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that we have the Common Classification Framework meeting today, in 
about an hour, at #openstack-meeting.

We'll talk about the status of the spec and implementation.

Agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_13_June_2017

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-dev] [neutron] [classifier] Common Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Friendly reminder that there will be a Common Classification Framework meeting 
in about half an hour at #openstack-meeting.

Today's agenda: 
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_30_May_2017

The spec seems to have reached general agreement and an attempted final 
patchset has now been submitted: https://review.openstack.org/#/c/333993/

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-dev] [neutron] [classifier] No meeting today

[Duarte Cardoso, Igor]

Hi all,

Since David is off and there isn't anything particular to discuss except what's 
in the spec, there will be no Common Classification Framework IRC meeting today.

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-dev] [neutron] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that the Common Classification Framework meeting is today 1400 UTC @ 
#openstack-meeting.

Agenda:
https://wiki.openstack.org/wiki/Neutron/CommonClassificationFramework#Discussion_Topic_18_April_2017
Feel free to add more topics.

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-dev] [neutron] [classifier] CCF Meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that the Common Classification Framework meeting is today in about an 
hour @ #openstack-meeting.

Agenda:
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_4_April_2017

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] About insertion modes and SFC Encapsulation

[Duarte Cardoso, Igor]

Below,

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 21, 2017 6:29 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Also, for TAP devices, they can be deployed in both active ( forward traffic 
back to networking​ devices) and passive mode . Our *current BP* scope is only 
for passive TAP. Apart from these two, there are other mode of deployment s 
also.

Others reading can add.

On Tue, Mar 21, 2017, 11:16 PM Vikash Kumar 
<vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote:
Hi Igor,


On Tue, Mar 21, 2017 at 10:02 PM, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Hi Vikash,

It’s best to start with RFC 7665.

NSH decouples traffic forwarding from both the internals of packets and service 
functions. A special entity called SFF will take on that job. L2/L3 then become 
something that the SFF might have to deal with it.

​which means it can co-exist with (L2/L3 insertion mode) and not necessarily 
mutually exclusive.
[IDC] It can’t because it shouldn’t be captured in the API. When you create a 
port-chain you have to specify the encap protocol that will render it as a 
whole, let’s say NSH. Then you go to the port-pairs and specify whether they 
support that protocol or whether they have to be proxied in an L2 or an L3 way 
(and these three possibilities are mutually exclusive).
If the port-pair supports NSH, you don’t specify anything about L2 or L3 
insertion modes. The logical SFFs (physically OVS e.g.) will be configured with 
the flows that will be able to forward traffic to the right service function – 
those flows can look like an L2 if the port-pair is on the current node and we 
just need to push NSH on Ethernet, or maybe they will look like an L4 insertion 
mode, if we have to cross nodes using VXLAN – but this will be 
backend/deployment/environment specific, and that’s what I mean by “L2/L3 then 
become something that the SFF might have to deal with it”. It’s not something 
to capture in the API.

​

However, networking-sfc API doesn’t expose or require details about individual 
SFC dataplane elements such as the SFF… it is up to the backend/driver to know 
those low-level details.

​Agree.
​

NSH doesn’t classify and forward traffic itself. It’s only a header that 
identifies what and where in the chain the packet belongs to/is (plus other 
goodies such as metadata). Classifier will classify, SFF will forward.

​   I was referring to NSH in totality and not excluding SFF 
(https://tools.ietf.org/html/draft-ietf-sfc-nsh-12). Look like I extended the 
scope of NSH in term of  SFC. ​



By the way, I left a question on the tap blueprint whiteboard, I’ll copy it 
here too:
“Is there a use case for "tap chains"? I.e. not only you send traffic to your 
tap function, but then your tap function also sends traffic to a next hop too, 
so a full chain starts after traffic gets tapped at the first chain (the first 
chain also continues).”
I suppose the answer is no since you mentioned “Note - TAP SFs do not forward 
packet”, but I’m happy to hear extended info about this – from anyone reading.

Best regards,
Igor.

From: Vikash Kumar 
[mailto:vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>]
Sent: Tuesday, March 21, 2017 3:32 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] About insertion modes and SFC 
Encapsulation

Hi,
   Moving definition of SF from port-pair to port-pair-group looks good.
   TAP is also an insertion mode like L2/L3 but since it simplifies to keep 
'tap-enabled' field also in port-pair-group, so it should be fine from 
implementation point of view (Note - TAP SFs do not forward packet). TAP 
enabled and L2/L3 insertion mode should be mutually exclusive.
   According to IETF draft NSH can classify & forward traffic (correct ?) but 
then the draft assumes uniformity of working of devices (which IMHO refers L3) 
which doesn't cover the entire use case. Can insertion mode (L2/L3) & traffic 
encapsulation(NSH) co-exist also ?



On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
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

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

[Duarte Cardoso, Igor]

Hi Vikash,

It’s best to start with RFC 7665.

NSH decouples traffic forwarding from both the internals of packets and service 
functions. A special entity called SFF will take on that job. L2/L3 then become 
something that the SFF might have to deal with it. However, networking-sfc API 
doesn’t expose or require details about individual SFC dataplane elements such 
as the SFF… it is up to the backend/driver to know those low-level details.

NSH doesn’t classify and forward traffic itself. It’s only a header that 
identifies what and where in the chain the packet belongs to/is (plus other 
goodies such as metadata). Classifier will classify, SFF will forward.


By the way, I left a question on the tap blueprint whiteboard, I’ll copy it 
here too:
“Is there a use case for "tap chains"? I.e. not only you send traffic to your 
tap function, but then your tap function also sends traffic to a next hop too, 
so a full chain starts after traffic gets tapped at the first chain (the first 
chain also continues).”
I suppose the answer is no since you mentioned “Note - TAP SFs do not forward 
packet”, but I’m happy to hear extended info about this – from anyone reading.

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 21, 2017 3:32 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

Hi,
   Moving definition of SF from port-pair to port-pair-group looks good.
   TAP is also an insertion mode like L2/L3 but since it simplifies to keep 
'tap-enabled' field also in port-pair-group, so it should be fine from 
implementation point of view (Note - TAP SFs do not forward packet). TAP 
enabled and L2/L3 insertion mode should be mutually exclusive.
   According to IETF draft NSH can classify & forward traffic (correct ?) but 
then the draft assumes uniformity of working of devices (which IMHO refers L3) 
which doesn't cover the entire use case. Can insertion mode (L2/L3) & traffic 
encapsulation(NSH) co-exist also ?



On Mon, Mar 20, 2017 at 11:35 PM, Cathy Zhang 
<cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>> wrote:
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<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

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

[Duarte Cardoso, Igor]

Hi Cathy,

I understand MPLS is a special protocol because:
- It allows Service Function Path identification (rfc7665) -> compatible with 
SFC Encapsulation
- It doesn't fully encapsulate the original frames -> incompatible with SFC 
Encapsulation
- Not necessary for this conversation, but also important to keep in mind: it 
can't transport additional metadata -> incompatible with SFC Encapsulation

So, I will start by discussing NSH specifically (being the fully-compatible SFC 
Encapsulation protocol). And so, the way I look at insertion modes (if split 
from correlations) is that in practice they become something I would describe 
as "SFC Proxy modes".

If a Service Function supports NSH, great, the NSH-encapsulated packets are 
fully exposed to the SFs and no "SFC Proxy mode" needs to be dictated (NSH is 
the mechanism itself). So, specifying L2 or L3 for insertion types would be of 
no meaning. At runtime and at the network forwarding level we might witness 
different ways of reaching the SFs, which could approximate L2 or L3 insertion 
types - but this isn't something to be modelled in networking-sfc's API but 
rather automatically controlled by the backend.

If a Service Function does not support NSH, we are in the presence of a legacy 
SF and so more information is needed to model how this SF expects packets 
(since there is no standard way). Consequently, specifying the insertion types, 
such as L2 or L3, is important. For the former, it means the SF machine has its 
interfaces running in promiscuous mode and is similar to a switch, for the 
latter it means the SF machine's interfaces are not in promiscuous mode and it 
is similar to a router.

With NSH, these insertion mode details are abstracted from the SFs.
The networking backend of neutron/networking-sfc will already know where each 
VM is and how to reach them and will  be responsible for making sure the NSH 
packet is delivered to the correct hop without needing additional information 
(from the networking-sfc API).

So, in summary, L2, L3, NSH and (in practice today @ networking-sfc) MPLS, are 
all mutually exclusive.

Best regards,
Igor.

From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Monday, March 20, 2017 6:05 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [networking-sfc] About insertion modes and SFC 
Encapsulation

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 p

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

[Duarte Cardoso, Igor]

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

[openstack-dev] [neutron] [classifier] New CCF meeting time decided (next tomorrow)

[Duarte Cardoso, Igor]

Hi all,

After [1], a new meeting time/day has been decided.

With 6 votes, Tuesdays at 1400 UTC was the most wanted time slot [2].

Eavesdrop has been updated to reflect this [3] and all up-do-date information 
can be found at [4].

Due to conflicting times at the IRC channel, the meeting also switched from odd 
to even weeks, meaning that the next meeting will be tomorrow (Match 21st) at 
1400UTC.

Let me also take this opportunity to invite you to review the Common 
Classification Framework spec [5] and the early PoC code based on 
neutron/classifier.

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-March/113370.html
[2] http://doodle.com/poll/9s2meppbkdg7ya7e (as of today)
[3] https://review.openstack.org/#/c/441068/
[4] http://eavesdrop.openstack.org/#Neutron_Common_Classification_Framework
[5] https://review.openstack.org/#/c/333993/
[6] https://review.openstack.org/#/c/445577/

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] patch test failed due to "import error: vlanmanager"

[Duarte Cardoso, Igor]

Hi Vikash,

What OS were you trying on before?

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Thursday, March 9, 2017 10:08 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>; ke...@benton.pub
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Tried on Ubuntu 16.04, its fine.

On Thu, Mar 9, 2017 at 12:17 PM, Vikash Kumar 
<vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote:
Import path looks OK
https://github.com/openstack/networking-sfc/blob/master/networking_sfc/services/sfc/agent/extensions/openvswitch/sfc_driver.py#L23



Are u suggesting something else?

On Thu, Mar 9, 2017 at 3:02 AM, Kevin Benton 
<ke...@benton.pub<mailto:ke...@benton.pub>> wrote:
That location was recently changed in the Neutron side.[1] It sounds like sfc 
has to be updated.

1. 
https://github.com/openstack/neutron/commit/4ec456d31501f09c68b5c23c488878da32dce75e

On Tue, Mar 7, 2017 at 9:41 PM, Vikash Kumar 
<vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>> wrote:
Hi Igor,
   This is weird. I just did a fresh clone and executed "tox" command. I am 
getting same error. Am I missing anything here ? There is no private change 
here.  Below is the link for entire log.

 http://paste.openstack.org/show/601870/

On Tue, Mar 7, 2017 at 10:46 PM, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Hi Vikash,
Please stick to pastebin for complete logs.

Check your migration files:

FAILED: Contract HEAD file does not match migration timeline head, expected: 
48072cb59133

Best regards,
Igor.

From: Vikash Kumar 
[mailto:vikash.ku...@oneconvergence.com<mailto:vikash.ku...@oneconvergence.com>]
Sent: Tuesday, March 7, 2017 5:03 PM
To: openstack-dev 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps: 
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt, 
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed: 
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname, 
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
 
git+https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
 
git+https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.

Re: [openstack-dev] [networking-sfc] patch test failed due to "import error: vlanmanager"

[Duarte Cardoso, Igor]

Hi Vikash,
Please stick to pastebin for complete logs.

Check your migration files:

FAILED: Contract HEAD file does not match migration timeline head, expected: 
48072cb59133

Best regards,
Igor.

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Tuesday, March 7, 2017 5:03 PM
To: openstack-dev 
Subject: Re: [openstack-dev] [networking-sfc] patch test failed due to "import 
error: vlanmanager"

Complete log:

 py35 create: /home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35
py35 installdeps: 
-r/home/vikash/guess_vk/python-dev/networking-sfc/requirements.txt, 
-r/home/vikash/guess_vk/python-dev/networking-sfc/test-requirements.txt
py35 develop-inst: /home/vikash/guess_vk/python-dev/networking-sfc
py35 installed: 
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated,  f = open(fullname, 
"rU"),alabaster==0.7.10,alembic==0.9.1,amqp==1.4.9,anyjson==0.3.3,appdirs==1.4.2,astroid==1.3.8,Babel==2.3.4,beautifulsoup4==4.5.3,cachetools==2.0.0,cffi==1.9.1,cliff==2.4.0,cmd2==0.7.0,contextlib2==0.5.4,coverage==4.3.4,cryptography==1.7.2,debtcollector==1.12.0,decorator==4.0.11,docutils==0.13.1,dulwich==0.17.1,eventlet==0.19.0,extras==1.0.0,fasteners==0.14.1,fixtures==3.0.0,flake8==2.5.5,futurist==0.21.0,greenlet==0.4.12,hacking==0.12.0,httplib2==0.10.3,idna==2.4,imagesize==0.7.1,iso8601==0.1.11,Jinja2==2.9.5,jsonpatch==1.15,jsonpointer==1.10,jsonschema==2.6.0,keystoneauth1==2.18.0,keystonemiddleware==4.14.0,kombu==3.0.37,linecache2==1.0.0,logilab-common==1.3.0,logutils==0.3.4.1,Mako==1.0.6,MarkupSafe==0.23,mccabe==0.2.1,mock==2.0.0,monotonic==1.2,mox3==0.20.0,msgpack-python==0.4.8,netaddr==0.7.19,netifaces==0.10.5,-e
 
git+https://github.com/openstack/networking-sfc.git@c51052e3748e917731f449b0ff4dc20d2e484490#egg=networking_sfc,-e
 
git+https://github.com/openstack/neutron.git@41be555eddb0f9947fdaa4e73fa74a72677d4d11#egg=neutron,neutron-lib==1.2.0,openstackdocstheme==1.6.1,openstacksdk==0.9.13,os-api-ref==1.3.0,os-client-config==1.26.0,os-testr==0.8.0,osc-lib==1.3.0,oslo.concurrency==3.19.0,oslo.config==3.22.0,oslo.context==2.12.1,oslo.db==4.17.0,oslo.i18n==3.13.0,oslo.log==3.21.0,oslo.messaging==5.18.0,oslo.middleware==3.23.1,oslo.policy==1.19.0,oslo.reports==1.17.0,oslo.rootwrap==5.4.0,oslo.serialization==2.17.0,oslo.service==1.19.0,oslo.utils==3.22.0,oslo.versionedobjects==1.22.0,oslosphinx==4.10.0,oslotest==2.14.0,ovs==2.7.0,packaging==16.8,paramiko==2.1.2,Paste==2.0.3,PasteDeploy==1.5.2,pbr==2.0.0,pecan==1.2.1,pep8==1.5.7,pika==0.10.0,pika-pool==0.1.3,positional==1.1.1,prettytable==0.7.2,psutil==5.2.0,psycopg2==2.7,pyasn1==0.2.3,pycadf==2.5.0,pycparser==2.17,pyflakes==0.8.1,Pygments==2.2.0,pyinotify==0.9.6,pylint==1.4.5,PyMySQL==0.7.10,pyparsing==2.2.0,python-cinderclient==1.11.0,python-dateutil==2.6.0,python-designateclient==2.6.0,python-editor==1.0.3,python-glanceclient==2.6.0,python-keystoneclient==3.10.0,python-mimeparse==1.6.0,python-neutronclient==6.1.0,python-novaclient==7.1.0,python-openstackclient==3.8.1,python-subunit==1.2.0,pytz==2016.10,PyYAML==3.12,reno==2.1.2,repoze.lru==0.6,requests==2.12.5,requests-mock==1.3.0,requestsexceptions==1.2.0,retrying==1.3.3,rfc3986==0.4.1,Routes==2.4.1,ryu==4.12,simplejson==3.10.0,six==1.10.0,snowballstemmer==1.2.1,Sphinx==1.5.3,SQLAlchemy==1.0.17,sqlalchemy-migrate==0.11.0,sqlparse==0.2.3,statsd==3.2.1,stevedore==1.21.0,tempest-lib==1.0.0,Tempita==0.5.2,tenacity==3.7.1,testrepository==0.0.20,testresources==2.0.1,testscenarios==0.5.0,testtools==2.2.0,tinyrpc==0.5,traceback2==1.4.0,unittest2==1.1.0,waitress==1.0.2,warlock==1.2.0,WebOb==1.6.3,WebTest==2.0.26,wrapt==1.10.8
py35 runtests: PYTHONHASHSEED='177840'
py35 runtests: commands[0] | find . -type f -name *.py[c|o] -delete
py35 runtests: commands[1] | find . -type d -name __pycache__ -delete
py35 runtests: commands[2] | 
/home/vikash/guess_vk/python-dev/networking-sfc/tools/ostestr_compat_shim.sh
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site.py:165:
 DeprecationWarning: 'U' mode is deprecated
  f = open(fullname, "rU")
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/positional/__init__.py:74:
 DeprecationWarning: inspect.getargspec() is deprecated, use 
inspect.signature() instead
  spec = inspect.getargspec(func)
/home/vikash/guess_vk/python-dev/networking-sfc/.tox/py35/lib/python3.5/site-packages/wrapt/wrappers.py:522:
 DeprecationWarning: Using the 

[openstack-dev] [neutron] [classifier] New CCF meeting time

[Duarte Cardoso, Igor]

Hi community,

The following text was sent earlier to people that were recently engaged on the 
Common Classification Framework (mainly at the PTG) and also earlier 
contributors to neutron-classifier, I'm now resending this to the 
community-scope, in case someone is very interested in joining our IRC meetings 
but the current time isn't really compatible.

The current IRC meeting time for the CCF is meant to be US friendly. However, 
most of the people now interested in this effort are outside of the US, and 
some have expressed how difficult it is to connect to the meeting on their 
local timezones.

I intend to move the meeting to a time that is compatible with the majority of 
people, since that is the best we can achieve without creating 2 different 
times.

I have created a Doodle where you can specify what times you're available: 
http://doodle.com/poll/9s2meppbkdg7ya7e.

The possibilities right now are from 8am to midnight UTC, since both I and 
David are located at that timezone and would be impossible for us to make it.

At Doodle you can select your own timezone (there's a link at the top-right of 
the table view) so you can view the possibilities and vote for them in local 
time.

I appreciate if you can fill in the Doodle so we can meet more often on IRC, 
thank you!

So far, there is majority for Tuesdays at 2:00 PM.

The pending patch is at https://review.openstack.org/#/c/441068/. It also 
changes from odd Tuesdays to even Tuesdays so we can keep meeting at 
#openstack-meeting.

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-dev] [neutron] [classifier] Common Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Reminding that the Common Classification Framework meeting today hasn't been 
canceled.
The meeting will be held on 1700 UTC @ #openstack-meeting.

Agenda:
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_28_February_2017

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] [neutron] neutron-classifier (CCF) at the PTG

[Duarte Cardoso, Igor]

Hi all,

I’ve added a photo of our whiteboard drafting today to the wiki: 
https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Atlanta_PTG_main_whiteboard_drafting
Best regards,
Igor.

From: Thomas Morin [mailto:thomas.mo...@orange.com]
Sent: Friday, February 17, 2017 2:51 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] neutron-classifier (CCF) at the PTG

Hi,

I have no opinion on where/when this should happen, but will be interested to 
participate.

-Thomas

Tue Feb 14 2017 15:39:22 GMT+0100 (CET), Duarte Cardoso, Igor:
Hi neutron,

Me and David would like to discuss the Common Classification Framework (CCF) 
(current approach based on openstack/neutron-classifier) at the PTG but we 
aren’t sure if the main session is the appropriate forum for that or if we 
should only have a meeting with the interested people and a few Neutron cores 
or PTL (to discuss if and how this work could be brought closer to Neutron 
itself).

I appreciate your feedback, thanks!

Best regards,
Igor.





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<mailto: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] - Neutron team social in Atlanta on Thursday

[Duarte Cardoso, Igor]

+1

Best regards,
Igor.

From: Vasudevan, Swaminathan (PNB Roseville) 
[mailto:swaminathan.vasude...@hpe.com]
Sent: Friday, February 17, 2017 8:30 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on 
Thursday

Count me in.

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 11:19 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

Hi all,

I'm organizing a Neutron social event for Thursday evening in Atlanta somewhere 
near the venue for dinner/drinks. If you're interested, please reply to this 
email with a "+1" so I can get a general count for a reservation.

Cheers,
Kevin Benton
__
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-classifier (CCF) at the PTG

[Duarte Cardoso, Igor]

Hi neutron,

Me and David would like to discuss the Common Classification Framework (CCF) 
(current approach based on openstack/neutron-classifier) at the PTG but we 
aren't sure if the main session is the appropriate forum for that or if we 
should only have a meeting with the interested people and a few Neutron cores 
or PTL (to discuss if and how this work could be brought closer to Neutron 
itself).

I appreciate your feedback, thanks!

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-dev] [neutron] [classifier] Common Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Common Classification Framework developers and interested parties are invited 
for today's meeting. The agenda is below, feel free to add more topics.

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

1700 UTC @ #openstack-meeting.

Me and David will be at the PTG to discuss this work as well.

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

[Duarte Cardoso, Igor]

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

[Duarte Cardoso, Igor]

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

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

[Duarte Cardoso, Igor]

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

[openstack-dev] [neutron] [classifier] No Common Classification Framework meeting

[Duarte Cardoso, Igor]

Hi,

There will be no Common Classification Framework this week.
The PTG PoC is still being worked on and is starting to look good, kudos to 
David for most of the work so far.

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-dev] [neutron] [classifier] Common Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Common Classification Framework developers and interested parties are invited 
for today's meeting. The agenda is below, feel free to add more topics.

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

1700 UTC @ #openstack-meeting.

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] Limitation on port chains + flow classifiers

[Duarte Cardoso, Igor]

Thanks Bernard, Louis, IRC meeting,

Given the encapsulation requirement when having SFC Graphs, there is then no 
need to call flowclassifier_basic_conflict() for the said graphs. I will see 
how to avoid calling flowclassifier_basic_conflict() specifically when creating 
graphs of port chains. Will likely need to touch multiple parts of the code 
since port chain resources must already exist before a graph can connect them. 

Best regards,
Igor.

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

On 10 January 2017 at 14:13, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com> 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

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

[Duarte Cardoso, Igor]

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/9b4a918177768a036c192a62fa473841c333b644/networking_sfc/db/sfc_db.py#L259
[2] 
https://github.com/openstack/networking-sfc/blob/b8dd1151343fef826043f408cd3027c5133fde30/networking_sfc/db/flowclassifier_db.py#L159

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] [neutron] [classifier] No Common Classifier / Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Likewise, no meeting today.

The next meeting will be on January 17th.

Best regards,
Igor.

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Tuesday, December 20, 2016 12:21 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron] [classifier] No Common Classifier / 
Classification Framework meeting

Hi all,

Tomorrow, Tuesday 20th December 2016, there will be no Common Classification 
Framework meeting, as there are no major topics to discuss.
Meanwhile we are working on an initial PoC for the framework. As a reminder, 
please take a look at the respective spec: 
https://review.openstack.org/#/c/333993.

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-dev] [neutron] [classifier] No Common Classifier / Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Tomorrow, Tuesday 20th December 2016, there will be no Common Classification 
Framework meeting, as there are no major topics to discuss.
Meanwhile we are working on an initial PoC for the framework. As a reminder, 
please take a look at the respective spec: 
https://review.openstack.org/#/c/333993.

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-dev] [neutron] [classifier] Common Classifier / Classification Framework meeting

[Duarte Cardoso, Igor]

Hi all,

Common Classification Framework developers and interested parties are invited 
for today's meeting. The agenda is below, feel free to add more topics.

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

1700 UTC @ #openstack-meeting.

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-dev] [networking-sfc] #networking-sfc IRC channel

[Duarte Cardoso, Igor]

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-dev] [neutron] [classifier] Common Classifier + OVS Flow Manager Meeting

[Duarte Cardoso, Igor]

Hi all,

Common Classifier / OVS Flow Manager developers and interested parties are 
invited for today's meeting. The agenda is below, feel free to add more topics.

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

The time has not changed (still 1700 UTC), but multiple locations have had 
daylight saving time clock changes since the last meeting, so double-check your 
current local time offset against UTC.

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] [neutron] [classifier] At the Summit: Common Classifier + OVS Flow Management

[Duarte Cardoso, Igor]

Hi all,

We are at Ballroom B. First table on the right.

Best regards,
Igor.


-Original Appointment-
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, October 24, 2016 3:45 PM
To: OpenStack Development Mailing List (not for usage questions); Miguel Angel 
Ajo Pelayo; 'Ihar Hrachyshka'; 'Vikram Choudhary'; 'Sean M. Collins'; 'Haim 
Daniel'; 'Mathieu Rohon'; Shaughnessy, David; Eichberger, German; Cathy Zhang; 
Henry Fourie; Armando M.
Subject: [openstack-dev] [neutron] [classifier] At the Summit: Common 
Classifier + OVS Flow Management
When: 27 October 2016 12:30-14:00 (UTC+01:00) Brussels, Copenhagen, Madrid, 
Paris.
Where: Hilton (P0 - Ballroom Foyer)


Hi again,

I'm setting the meeting for Thursday 12:30pm, at the Hilton (P0 - Ballroom 
Foyer).
Let's gather together and talk about these 2 efforts.

_
From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Thursday, October 20, 2016 3:08 PM
To: 
openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>; 
Miguel Angel Ajo Pelayo <majop...@redhat.com<mailto:majop...@redhat.com>>; 
'Ihar Hrachyshka' <ihrac...@redhat.com<mailto:ihrac...@redhat.com>>; 'Vikram 
Choudhary' <vikram.choudh...@huawei.com<mailto:vikram.choudh...@huawei.com>>; 
'Sean M. Collins' <s...@coreitpro.com<mailto:s...@coreitpro.com>>; 'Haim 
Daniel' <hdan...@redhat.com<mailto:hdan...@redhat.com>>; 'Mathieu Rohon' 
<mathieu.ro...@gmail.com<mailto:mathieu.ro...@gmail.com>>; Shaughnessy, David 
<david.shaughne...@intel.com<mailto:david.shaughne...@intel.com>>; Eichberger, 
German <german.eichber...@hpe.com<mailto:german.eichber...@hpe.com>>; Cathy 
Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>>; Henry Fourie 
<louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>>; Armando M. 
<arma...@gmail.com<mailto:arma...@gmail.com>>
Subject: [openstack-dev] [neutron] [classifier] At the Summit: Common 
Classifier + OVS Flow Management


Hi,

Two etherpads were created on the last meeting as placeholders to what can be 
discussed at the summit regarding the common classification 
framework/classifier and the OVS flow manager:
https://etherpad.openstack.org/p/neutron-common-classification-framework-barcelona
https://etherpad.openstack.org/p/neutron-ovs-flow-management-barcelona
Feel free to add topics to the pads.

How/where would you like to meet at the summit to discuss future work on these 
2 efforts?
I'm okay meeting during lunch time from Tuesday to Friday, or even during 
Monday, or at the contributors meet-up on Friday.
Thoughts?

Best regards,
Igor.
  << File: ATT1.txt >>

__
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

[Duarte Cardoso, Igor]

+1

Best regards,
Igor.

From: Ofer Ben-Yacov [mailto:ofer.benya...@gmail.com]
Sent: Tuesday, October 25, 2016 10:25 AM
To: OpenStack Development Mailing List (not for usage questions) 

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


+1

בתאריך 25 באוק׳ 2016 09:38,‏ "Omer Anson" 
> כתב:

+1

On Oct 24, 2016 10:30, "Henry Fourie" 
> wrote:
+1



__
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] [classifier] At the Summit: Common Classifier + OVS Flow Management

[Duarte Cardoso, Igor]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Romance Standard Time
BEGIN:STANDARD
DTSTART:16010101T03
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Duarte Cardoso, Igor":MAILTO:igor.duarte.card...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=OpenStack 
 Development Mailing List (not for usage questions):MAILTO:openstack-dev@li
 sts.openstack.org
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Miguel Ang
 el Ajo Pelayo:MAILTO:majop...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ihar Hrac
 hyshka':MAILTO:ihrac...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Vikram Ch
 oudhary':MAILTO:vikram.choudh...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sean M. C
 ollins':MAILTO:s...@coreitpro.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Haim Dani
 el':MAILTO:hdan...@redhat.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Mathieu R
 ohon':MAILTO:mathieu.ro...@gmail.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Shaughness
 y, David":MAILTO:david.shaughne...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN="Eichberger
 , German":MAILTO:german.eichber...@hpe.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Cathy Zhan
 g:MAILTO:cathy.h.zh...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Henry Four
 ie:MAILTO:louis.fou...@huawei.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Armando M.
 :MAILTO:arma...@gmail.com
DESCRIPTION;LANGUAGE=en-US:Hi again\,\n\nI’m setting the meeting for Thur
 sday 12:30pm\, at the Hilton (P0 - Ballroom Foyer).\nLet’s gather togeth
 er and talk about these 2 efforts.\n\n____
 _____\nFrom: Duarte Cardoso\, Igor [mailto:igor.duarte.cardoso@intel.c
 om]\nSent: Thursday\, October 20\, 2016 3:08 PM\nTo: openstack-dev@lists.o
 penstack.org<mailto:openstack-dev@lists.openstack.org>\; Miguel Angel Ajo 
 Pelayo <majop...@redhat.com<mailto:majop...@redhat.com>>\; 'Ihar Hrachyshk
 a' <ihrac...@redhat.com<mailto:ihrac...@redhat.com>>\; 'Vikram Choudhary' 
 <vikram.choudh...@huawei.com<mailto:vikram.choudh...@huawei.com>>\; 'Sean 
 M. Collins' <s...@coreitpro.com<mailto:s...@coreitpro.com>>\; 'Haim Daniel
 ' <hdan...@redhat.com<mailto:hdan...@redhat.com>>\; 'Mathieu Rohon' >\; Shaughnessy\, David 
 <david.shaughne...@intel.com<mailto:david.shaughne...@intel.com>>\; Eichbe
 rger\, German <german.eichber...@hpe.com<mailto:german.eichber...@hpe.com>
 >\; Cathy Zhang <cathy.h.zh...@huawei.com<mailto:cathy.h.zh...@huawei.com>
 >\; Henry Fourie <louis.fou...@huawei.com<mailto:louis.fou...@huawei.com>>
 \; Armando M. <arma...@gmail.com<mailto:arma...@gmail.com>>\nSubject: [ope
 nstack-dev] [neutron] [classifier] At the Summit: Common Classifier + OVS 
 Flow Management\n\n\nHi\,\n\nTwo etherpads were created on the last meetin
 g as placeholders to what can be discussed at the summit regarding the com
 mon classification framework/classifier and the OVS flow manager:\nhttps:/
 /etherpad.openstack.org/p/neutron-common-classification-framework-barcelon
 a\nhttps://etherpad.openstack.org/p/neutron-ovs-flow-management-barcelona\
 nFeel free to add topics to the pads.\n\nHow/where would you like to meet 
 at the summit to discuss future work on these 2 efforts?\nI’m okay meeti
 ng during lunch time from Tuesday to Friday\, or even during Monday\, or a
 t the contributors meet-up on Friday.\nThoughts?\n\nBest regards\,\nIgor.\
 n\n
SUMMARY;LANGUAGE=en-US:[neutron] [classifier] At the Summit: Common Classif
 ier + OVS Flow Management
DTSTART;TZID=Romance Standard Time:20161027T123000
DTEND;TZID=Romance Standard Time:20161027T14
UID:04008200E00074C5B7101A82E0089082FD080D2ED201000
 01000F91FB92F8F6B4F4B80025D1CCB7EDEBD
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20161024T134401Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:0
LOCATION;LANGUAGE=en-US:Hilton (P0 - Ballroom Foyer)
X-MICROSOFT-CDO-APPT-SEQUENCE:0
X-MICROSOFT-CDO-OWNERAPPTID:1981327328
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:0
X-MICROSOFT-DISALLOW-COUNTER:FALSE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR

[openstack-dev] [neutron] [classifier] At the Summit: Common Classifier + OVS Flow Management

[Duarte Cardoso, Igor]

Hi,

Two etherpads were created on the last meeting as placeholders to what can be 
discussed at the summit regarding the common classification 
framework/classifier and the OVS flow manager:
https://etherpad.openstack.org/p/neutron-common-classification-framework-barcelona
https://etherpad.openstack.org/p/neutron-ovs-flow-management-barcelona
Feel free to add topics to the pads.

How/where would you like to meet at the summit to discuss future work on these 
2 efforts?
I'm okay meeting during lunch time from Tuesday to Friday, or even during 
Monday, or at the contributors meet-up on Friday.
Thoughts?

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-dev] [neutron] [classifier] At the Summit: Common Classifier + OVS Flow Management

[Duarte Cardoso, Igor]

Hi,

Two etherpads were created on the last meeting as placeholders to what can be 
discussed at the summit regarding the common classification 
framework/classifier and the OVS flow manager:
https://etherpad.openstack.org/p/neutron-common-classification-framework-barcelona
https://etherpad.openstack.org/p/neutron-ovs-flow-management-barcelona
Feel free to add topics to the pads.

How/where would you like to meet at the summit to discuss future work on these 
2 efforts?
I'm okay meeting during lunch time from Tuesday to Friday, or even during 
Monday, or at the contributors meet-up on Friday.
Thoughts?

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] [neutron] [classifier] Common Classifier + OVS Flow Management Meeting

[Duarte Cardoso, Igor]

Reminder that the meeting is in 1 hour,

Best regards,
Igor.

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, October 10, 2016 5:14 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron] [classifier] Common Classifier + OVS Flow 
Management Meeting

Hi Common Classifier and OVS Flow Management community,

Feel free to add topics to the next meeting's agenda at:
https://wiki.openstack.org/w/index.php?title=Neutron/CommonFlowClassifier=edit=5

Time, location and recurrence are unchanged, so the next meeting will be 
tomorrow (11th October) at 17:00 UTC [1] on #openstack-meeting [2].

Current agenda:

Important links about the Common Classifier / Common Classification Framework:
-  https://review.openstack.org/#/q/topic:bug/1476527
-  https://bugs.launchpad.net/networking-sfc/+bug/1476527
-  https://github.com/openstack/neutron-classifier
-  [3] included in topic above as well

Important links about OVS Flow Management:
-  https://review.openstack.org/#/q/topic:bug/1563967
-  https://bugs.launchpad.net/neutron/+bug/1563967


The spec in [3] seems to have reached a very stable state. If you haven't yet 
reviewed it to understand if and how your use cases fit there, be sure to do it 
as soon as possible.

[1] 
http://eavesdrop.openstack.org/calendars/neutron-common-classifier-meeting.ics
[2] http://eavesdrop.openstack.org/#Neutron_Common_Classifier_meeting
[3] https://review.openstack.org/#/c/320439/

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-dev] [neutron] [classifier] Common Classifier + OVS Flow Management Meeting

[Duarte Cardoso, Igor]

Hi Common Classifier and OVS Flow Management community,

Feel free to add topics to the next meeting's agenda at:
https://wiki.openstack.org/w/index.php?title=Neutron/CommonFlowClassifier=edit=5

Time, location and recurrence are unchanged, so the next meeting will be 
tomorrow (11th October) at 17:00 UTC [1] on #openstack-meeting [2].

Current agenda:

Important links about the Common Classifier / Common Classification Framework:
-  https://review.openstack.org/#/q/topic:bug/1476527
-  https://bugs.launchpad.net/networking-sfc/+bug/1476527
-  https://github.com/openstack/neutron-classifier
-  [3] included in topic above as well

Important links about OVS Flow Management:
-  https://review.openstack.org/#/q/topic:bug/1563967
-  https://bugs.launchpad.net/neutron/+bug/1563967


The spec in [3] seems to have reached a very stable state. If you haven't yet 
reviewed it to understand if and how your use cases fit there, be sure to do it 
as soon as possible.

[1] 
http://eavesdrop.openstack.org/calendars/neutron-common-classifier-meeting.ics
[2] http://eavesdrop.openstack.org/#Neutron_Common_Classifier_meeting
[3] https://review.openstack.org/#/c/320439/

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] [tacker] [networking-sfc] Removing required port-id from classifier

[Duarte Cardoso, Igor]

Hi Tim,

Just about the second part of your email:

> how are IETF SFC/NSH related API/plugin changes going?  
I'm essentially finished with NSH encap support [1], just have to fix a few 
bugs and write the tests. Then I will work on connecting port-chains together 
so we can have SFC graphs, kind of like IETF's branching/reclassification "SFC 
Encapsulation" chains (described with higher detail in the NSH draft).

> Can we expect to have attributes like path-id, encap type soon?  
The NSH patch I mentioned above will allow NSH encap to be specified for both 
port-chains and port-pairs and, if port-pairs do not support the port-chain's 
encapsulation, it's up to the driver to SFC-Proxy the traffic accordingly (OVS 
will install SFC-proxy flows, just like it does today by default, for MPLS). 
Regarding the path-id, I was working on a patch to facilitate that [2], but we 
ended up merging one focused only on enabling the path-id ("chain_id") [3]. So 
we have both attributes now.

[1] https://review.openstack.org/#/c/373465
[2] https://review.openstack.org/#/c/346175
[3] https://review.openstack.org/#/c/355336

Best regards,
Igor.

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 4, 2016 6:07 PM
To: OpenStack Development Mailing List (not for usage questions) 
; Cathy Zhang 
Subject: [openstack-dev] [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.  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?  

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

__
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] [classifier] Common Classifier + OVS Flow Management Meeting

[Duarte Cardoso, Igor]

Hi Common Classifier and OVS Flow Management community,

Cathy has kindly allowed me to drive the next common classifier/flow management 
IRC meetings.

Time, location and recurrence are unchanged, so the next meeting will be next 
Tuesday (27th September) at 17:00 UTC [1] on #openstack-meeting [2].

>From then on, we should have a meeting every 2 weeks.

Feel free to add topics to the meeting's agenda at:
https://wiki.openstack.org/w/index.php?title=Neutron/CommonFlowClassifier=edit=5


Important links about the Common Classifier / Common Classification Framework:

-  https://review.openstack.org/#/q/topic:bug/1476527

-  https://bugs.launchpad.net/networking-sfc/+bug/1476527

-  https://github.com/openstack/neutron-classifier

-  [3] included in topic above as well

Important links about OVS Flow Management:

-  https://review.openstack.org/#/q/topic:bug/1563967

-  https://bugs.launchpad.net/neutron/+bug/1563967


Specifically, the spec in [3] seems to have reached a very stable state. If you 
haven't yet reviewed it to understand if and how your use cases fit there, be 
sure to do it as soon as possible.


[1] 
http://eavesdrop.openstack.org/calendars/neutron-common-classifier-meeting.ics
[2] http://eavesdrop.openstack.org/#Neutron_Common_Classifier_meeting
[3] https://review.openstack.org/#/c/320439/

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] [neutron] [classifier] Spec detailing both approaches

[Duarte Cardoso, Igor]

Thanks Vikram!

I’ve added my approach to the spec and made it compatible with spec docs/py27, 
I’ll submit it now so part of the community can still take a look before the 
end of the week :)

Best regards,
Igor.

From: Vikram Choudhary [mailto:viks...@gmail.com]
Sent: Friday, June 24, 2016 3:09 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] [classifier] Spec detailing both 
approaches

Hi Igor/Cathy/Louis,

Thanks for driving this effort. Will certainly help with the review!

Thanks
Vikram

On Fri, Jun 24, 2016 at 5:47 PM, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Hi Cathy, Louis,

I'll reupload the Neutron spec today to openstack/neutron-specs along with the 
rst file and the neutron-classifier-inspired approach detailed, replacing [1] 
and [2] from openstack/neutron, is that okay?

Review from the Neutron community, interested consumers and neutron-classifier 
contributors will be highly appreciated.

[1] https://review.openstack.org/#/c/332584/
[2] https://review.openstack.org/#/c/332958/

Best regards,
Igor.


__
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

[openstack-dev] [neutron] [classifier] Spec detailing both approaches

[Duarte Cardoso, Igor]

Hi Cathy, Louis,

I'll reupload the Neutron spec today to openstack/neutron-specs along with the 
rst file and the neutron-classifier-inspired approach detailed, replacing [1] 
and [2] from openstack/neutron, is that okay?

Review from the Neutron community, interested consumers and neutron-classifier 
contributors will be highly appreciated.

[1] https://review.openstack.org/#/c/332584/
[2] https://review.openstack.org/#/c/332958/

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-dev] [neutron] [classifier] Requesting feedback on typed classifications model

[Duarte Cardoso, Igor]

Hi community and common classifier team,

In anticipation to the next common classifier meeting, I've added a meeting 
agenda item to the next meeting's agenda [1] about the proposed "typed 
classifications" model for the new common classifier.

The typed classifications model is described in [2, comment #26] and 
essentially separates classification matches into different classification 
types, instead of grouping all kinds of different classifications into a single 
monolithic structure such as [3].

This kind of model is actually not new, as neutron-classifier was already 
following such a path [4].
Can someone give feedback on the described model and how neutron-classifier is 
planned to be reused for the new effort?

[1] https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier
[2] https://bugs.launchpad.net/neutron/+bug/1476527
[3] https://wiki.openstack.org/w/images/c/c8/Neutron_Common_Classifier.png
[4] 
https://github.com/openstack/neutron-classifier/blob/10b2eb3127f4809e52e3cf1627c34228bca80101/neutron_classifier/common/constants.py#L17

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] support of NSH in networking-SFC

[Duarte Cardoso, Igor]

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.



__
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 

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

[Duarte Cardoso, Igor]

"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."

ODL requires a patched OvS too [1].

[1] 
https://wiki.opendaylight.org/view/Service_Function_Chaining:Main#Building_Open_vSwitch_with_VxLAN-GPE_and_NSH_support

Best regards,
Igor.

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Tuesday, May 31, 2016 3:13 AM
To: OpenStack Development Mailing List (not for usage questions) 

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.



__
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

[Duarte Cardoso, Igor]

Hi all,

As Uri mentioned, there is a concrete proposal for an enhanced SFC API (with 
support for open, IETF SFC Encapsulation [1] and NSH [2]) that was publicly 
shared last month as a neutron spec at [3].

Service Function Chaining (SFC) is the effort of normalizing and standardizing 
nomenclature, definitions and protocols that will guide how SFC will be done, 
and is led by the IETF SFC WG [4]. If implementing  SFC in OpenStack as 
standards-compliant as possible is a negative thing, please let me know 
straight away.

Now, it’s only natural that additional SFC implementation work for OpenStack 
should land on the already established networking-sfc project. As far as I 
understand, the project has been hard at work, focusing on completing a first 
phase of development that would enable linear port chains to be instantiated 
(which finished around the beginning of this year). The project has 
demonstrated its value for some of today’s use cases and I definitely 
congratulate the whole team on the success.

In an attempt to create the least disruption possible in the existing project 
and sticking to OpenStack best practices, I have been trying to engage with the 
team to consider and review the SFC Encapsulation proposal [5, 6, 7 and part of 
3], which I’d be absolutely delighted to develop myself.

The discussion around this thread and sibling threads seems to have been about 
supporting NSH in networking-sfc. The team has already said they will support 
NSH [7, 8, 9] as an attribute of the existing API parameter chain_parameters. 
But there’s a blurred line here: what exactly does it take to support NSH/SFC 
Encapsulation in networking-sfc? Let me quote Uri:

“I hear (…) that we have an agreement that the SFC abstraction (…) is use of 
NSH approach. This includes internal representation of the chain, support of 
metadata etc.”

Supporting NSH is not simply about enabling the dataplane protocol. If we 
considered that it was, then it would be acceptable to say that yeah OVS must 
support NSH before (or maybe ODL when there’s a finalized driver – and then 
it’s ODL’s responsibility to setup a compatible OVS deployment). But NSH is an 
SFC Encapsulation protocol and approach, and the only [protocol] being worked 
on by the WG.

The networking-sfc API requires changes to properly support NSH/SFC 
Encapsulation:

· Enable NSH dataplane support (planned by networking-sfc – I have no 
concerns with this);

· Support of metadata (less critical since it is doesn’t really change 
how we look at the chaining topology, so less disruptive and could be 
implemented later in the future)

· Support correct SFC abstraction/representation of chains and paths 
(highly critical since this is how IETF SFC compatible chains can be built – 
which justifies why NSH includes a Service Path Header [2])

And this is what we mean by supporting NSH in networking-sfc. If only the last 
point can be supported today, then NSH/SFC Encapsulation is already on the 
right track.
And the best part is that it would only require a small change in the API – the 
ability to link different port-chains together as part of a scope (a Service 
Function Chain, or a graph).

Interestingly, such an API enhancement would also work with existing upstream 
OVS, if networking-sfc is running in “legacy” mode (i.e. without actually 
encapsulating traffic into any protocol, like today – so it’s fine). It would 
not be possible to guarantee that traffic from a chain is kept inside that same 
chain because that depends on what happens inside of a Service Function. But 
assuming the functions don’t change traffic in any way, the inter-linking of 
port-chains would still work – in the same way that creating multiple, unlinked 
port-chains work together when specifying their flow classifiers’ source 
neutron ports as the previous port-chains’s last neutron ports.

Also, in anticipation: SFC “graph” != VNFFG [10].

Let me know your thoughts and questions.

[1] https://www.rfc-editor.org/rfc/rfc7665.txt
[2] https://www.ietf.org/id/draft-ietf-sfc-nsh-05.txt
[3] https://review.openstack.org/#/c/308453/
[4] https://datatracker.ietf.org/wg/sfc/charter/
[5] https://etherpad.openstack.org/p/networking-sfc-and-sfc-encapsulation
[6] 
https://wiki.openstack.org/wiki/Neutron/ServiceChainUseCases#SFC_Encapsulation
[7] 
http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-05-19-17.02.log.html
[8] 
http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-01-21-17.00.log.html
[9] 
http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-05-26-17.00.log.html
[10] 
http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf

Best regards,
Igor.

From: Elzur, Uri [mailto:uri.el...@intel.com]
Sent: Wednesday, May 25, 2016 8:38 PM
To: OpenStack Development Mailing List (not for usage questions) 

Re: [openstack-dev] [neutron] [networking-sfc] Adding use case to wiki?

[Duarte Cardoso, Igor]

Thanks Louis,

Best regards,
Igor.

From: Henry Fourie [mailto:louis.fou...@huawei.com]
Sent: Monday, May 23, 2016 5:59 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Adding use case to wiki?

Igor,
   Add them here https://wiki.openstack.org/wiki/Neutron/ServiceChainUseCases

-  Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, May 23, 2016 9:14 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [networking-sfc] Adding use case to wiki?

Hi networking-sfc,

As discussed at the last meeting I was to add the SFC Encapsulation use case to 
the networking-sfc wiki:
#action paul, john igor to add use-cases to wiki

Where exactly is the place to insert use cases in the wiki? Is there one 
already?
None of these seem to have any section for that purpose:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining

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-dev] [neutron] [networking-sfc] Adding use case to wiki?

[Duarte Cardoso, Igor]

Hi networking-sfc,

As discussed at the last meeting I was to add the SFC Encapsulation use case to 
the networking-sfc wiki:
#action paul, john igor to add use-cases to wiki

Where exactly is the place to insert use cases in the wiki? Is there one 
already?
None of these seem to have any section for that purpose:
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining
https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
https://wiki.openstack.org/wiki/Neutron/APIForServiceChaining

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-dev] [group-based-policy] Can PTs move to other PTGs?

[Duarte Cardoso, Igor]

Hi GBP,

While I was working on the QoS PoC for GBP I observed that policy targets 
require to be associated to a PTG. They also don't seem to be updatable with a 
different PTG, at least not with the CLI. However, looking at the API I see, 
for policy targets:

'policy_target_group_id': {'allow_post': True, 'allow_put': True,
   'validate': {'type:uuid_or_none': None},
   'required': True, 'is_visible': True},

The PTG seems to be updatable, and can even be None. Both Horizon and the CLI 
don't seem to allow/offer a way to change the PTG or even detach the PT from 
the PTG. So, my questions are, should PTs be allowed to move to other PTGs? Or 
even not belong to any at all? Depending on the answer, should the snippet 
above be corrected?

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] [neutron] [networking-sfc] A standards-compliant SFC API

[Duarte Cardoso, Igor]

Hi Vikram,

Thanks for the response. I’m happy to provide enhancements instead of building 
the API from scratch, the semantics may change considerably though, resulting 
in what’s essentially a new API, but let’s see. I invite you to read the spec 
[1] thoroughly. Let’s continue there so we can better scope the discussion.

[1] https://review.openstack.org/#/c/308453/

Best regards,
Igor.

From: Vikram Choudhary [mailto:viks...@gmail.com]
Sent: Thursday, April 21, 2016 3:39 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant 
SFC API

Just a quick glance over the proposal seems like the networking-sfc also does 
the same. In addition, networking-sfc is successfully integrated with ONOS[1] 
and planned for ODL[2], OVN [3] & Tacker[4] (without any issues with the 
existing API's so far). In addition, If we feel the existing networking-sfc 
API's has issues then let's enhance them rather than a fresh effort from the 
scratch.

Let's discuss more about the proposal over the submitted spec.

[1] 
https://github.com/openstack/networking-onos/blob/master/doc/source/devref/sfc_driver.rst
[2] https://review.openstack.org/#/c/300898/
[3] 
https://blueprints.launchpad.net/networking-sfc/+spec/networking-sfc-ovn-driver
[4] 
https://blueprints.launchpad.net/networking-sfc/+spec/tacker-networking-sfc-driver


On Thu, Apr 21, 2016 at 1:24 AM, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Thanks for the feedback Armando,

Adding missing tag.

Best regards,
Igor.

From: Armando M. [mailto:arma...@gmail.com<mailto:arma...@gmail.com>]
Sent: Wednesday, April 20, 2016 6:03 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] [neutron][sfc] A standards-compliant SFC API


On 20 April 2016 at 09:31, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Dear OpenStack Community,

We've been investigating options in/around OpenStack for supporting Service 
Function Chaining. The networking-sfc project has made significant progress in 
this space, and we see lots of value in what has been completed. However, when 
we looked at the related IETF specs on SFC we concluded that there would be 
value in further developing an SFC API and related classification functionality 
to enhance the alignment between the work in the OpenStack community with the 
standards work. We would like to propose the SFC part as a potential 
networking-sfc v2 API, but are open to other options too based on your feedback.

I have submitted a spec to the neutron-specs repo [1], where you can check what 
our initial thoughts for this new API are, and provide your feedback or 
questions regarding the same.

Your thoughts on this are deeply appreciated. We are looking forward to having 
further discussions with everyone interested in giving feedback or establishing 
collaborations during the OpenStack Summit in Austin.

[1] https://review.openstack.org/#/c/308453

Thanks for reaching out.

The networking-sfc initiative so far has been pretty autonomous. The project 
has its own launchpad project [1] and its own docs to document APIs and 
proposals [2]. During the long journey that Neutron has been through, we have 
been adjusting how to manage the project in order to strike a good balance 
between development agility, product stability and community needs. We're 
always looking forward to improving that balance and this means that how we 
track certain initiatives may evolve in the future. For now, it's probably best 
to target the mailing list with tag [networking-sfc] (in addition to neutron), 
as well as the project noted below.

[1] https://launchpad.net/networking-sfc
[2] http://docs.openstack.org/developer/networking-sfc/


Thank you,
Igor & the Intel OpenStack networking team.

__
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://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.

Re: [openstack-dev] [neutron] [networking-sfc] A standards-compliant SFC API

[Duarte Cardoso, Igor]

Thanks for the feedback Armando,

Adding missing tag.

Best regards,
Igor.

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, April 20, 2016 6:03 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][sfc] A standards-compliant SFC API


On 20 April 2016 at 09:31, Duarte Cardoso, Igor 
<igor.duarte.card...@intel.com<mailto:igor.duarte.card...@intel.com>> wrote:
Dear OpenStack Community,

We've been investigating options in/around OpenStack for supporting Service 
Function Chaining. The networking-sfc project has made significant progress in 
this space, and we see lots of value in what has been completed. However, when 
we looked at the related IETF specs on SFC we concluded that there would be 
value in further developing an SFC API and related classification functionality 
to enhance the alignment between the work in the OpenStack community with the 
standards work. We would like to propose the SFC part as a potential 
networking-sfc v2 API, but are open to other options too based on your feedback.

I have submitted a spec to the neutron-specs repo [1], where you can check what 
our initial thoughts for this new API are, and provide your feedback or 
questions regarding the same.

Your thoughts on this are deeply appreciated. We are looking forward to having 
further discussions with everyone interested in giving feedback or establishing 
collaborations during the OpenStack Summit in Austin.

[1] https://review.openstack.org/#/c/308453

Thanks for reaching out.

The networking-sfc initiative so far has been pretty autonomous. The project 
has its own launchpad project [1] and its own docs to document APIs and 
proposals [2]. During the long journey that Neutron has been through, we have 
been adjusting how to manage the project in order to strike a good balance 
between development agility, product stability and community needs. We're 
always looking forward to improving that balance and this means that how we 
track certain initiatives may evolve in the future. For now, it's probably best 
to target the mailing list with tag [networking-sfc] (in addition to neutron), 
as well as the project noted below.

[1] https://launchpad.net/networking-sfc
[2] http://docs.openstack.org/developer/networking-sfc/


Thank you,
Igor & the Intel OpenStack networking team.

__
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

[openstack-dev] [neutron][sfc] A standards-compliant SFC API

[Duarte Cardoso, Igor]

Dear OpenStack Community,

We've been investigating options in/around OpenStack for supporting Service 
Function Chaining. The networking-sfc project has made significant progress in 
this space, and we see lots of value in what has been completed. However, when 
we looked at the related IETF specs on SFC we concluded that there would be 
value in further developing an SFC API and related classification functionality 
to enhance the alignment between the work in the OpenStack community with the 
standards work. We would like to propose the SFC part as a potential 
networking-sfc v2 API, but are open to other options too based on your feedback.

I have submitted a spec to the neutron-specs repo [1], where you can check what 
our initial thoughts for this new API are, and provide your feedback or 
questions regarding the same.

Your thoughts on this are deeply appreciated. We are looking forward to having 
further discussions with everyone interested in giving feedback or establishing 
collaborations during the OpenStack Summit in Austin.

[1] https://review.openstack.org/#/c/308453

Thank you,
Igor & the Intel OpenStack networking 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

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

[Duarte Cardoso, Igor]

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

[openstack-dev] [group-based-policy] Meeting today

[Duarte Cardoso, Igor]

Hi GBP team,

Is the meeting today not going to happen due to US Thanksgiving?

Best regards,

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

__
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] Deploying current networking-sfc

[Duarte Cardoso, Igor]

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

[openstack-dev] [group-based-policy] QoS support in GBP

[Duarte Cardoso, Igor]

Hi OpenStack Group-based Policy team,

As I unofficially said before, I am interested in bringing basic QoS to GBP via 
the Neutron QoS API which currently offers bandwidth limitation at the port and 
network level, since Liberty.

I have added the item to today's Meeting Agenda for an initial discussion about 
this and where it would best fit for GBP.

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] [Group-based-policy]

[Duarte Cardoso, Igor]

Hi Ernesto,

Let me answer the first question for you.

You can use GBP without OpenDaylight.

OpenDaylight has a separate Group-based Policy project, which might make you 
wonder if you need it to run OpenStack GBP. Don’t worry, you can deploy 
OpenStack GBP right away without OpenDaylight.

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

From: Ernesto Valentino [mailto:ern.valent...@gmail.com]
Sent: Tuesday, November 10, 2015 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Group-based-policy]

Dear sirs,
I'm a student trying to testing Group Based Policy functionalities. I have some 
questions about it, because from the documentation is not clear to me what role 
assume opendaylight in the plug-in.
I can use gbp only with openstack or is mandatory to use it with opendaylight? 
And next, if I want to add my personal nfv to gbp is there a possibility to do 
that or not ? Thanks so much for answering.
Waiting for your kind reply.

Best regards,
Ernesto Valentino
--
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