Re: [openstack-dev] [neutron][neutron-lib]Service function defintion files

[Henry Fourie]

Armando,
I agree with Paul. My understanding was that the API definition files for 
stadium projects were to be included in neutron-lib to ensure suitable 
oversight.
- Louis

From: CARVER, PAUL [mailto:pc2...@att.com]
Sent: Friday, December 29, 2017 11:35 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][neutron-lib]Service function defintion 
files

I think it sort of was intentional, although probably not the primary focus. I 
don’t remember if it is a stadium requirement or merely a suggestion, but I 
believe it is strongly encouraged that “official” stadium sub-projects should 
follow neutron’s release cycle whereas “unofficial” projects are free to do 
whatever they want with regard to release cycle, just like with regard to API.

The definition of “stadium” is in some sense tautological. The main benefit of 
being in the stadium is that you tell someone you’re in the stadium they 
automatically know that there’s a set of assumptions that they can make about 
the project. The requirement for being in the stadium is that you do the 
necessary work to make those assumptions valid.

If the developers don’t care whether people can validly make those assumptions, 
there’s no pressure on them to be in the stadium. If the users don’t care about 
those assumptions, there’s no reason why they should prefer stadium projects 
over non-stadium projects. It’s essentially just a label that declares that a 
specific set of requirements have been met. It’s up to each individual to 
evaluate whether they care about that specific set of requirements.

--
Paul Carver
VoIP: 732-545-7377
Cell: 908-803-1656
E: pcar...@att.com
Q Instant Message
It is difficult to make predictions. Especially about the future.


From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Friday, December 29, 2017 14:00
To: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [neutron][neutron-lib]Service function defintion 
files

On 28 December 2017 at 06:57, CARVER, PAUL 
> wrote:
It was a gating criteria for stadium status. The idea was that the for a 
stadium project the neutron team would have review authority over the API but 
wouldn't necessarily review or be overly familiar with the implementation.

A project that didn't have it's API definition in neutron-lib could do anything 
it wanted with its API and wouldn't be a neutron subproject because the neutron 
team wouldn't necessarily know anything at all about it.

For a neutron subproject there would at least theoretically be members of the 
neutron team who are familiar with the API and who ensure some sort of 
consistency across APIs of all neutron subprojects.

This is also a gating criteria for publishing API documentation on 
api.openstack.org
 vs publishing somewhere else. Again, the idea being that the neutron team 
would be able, at least in some sense, to "vouch for" the OpenStack networking 
APIs, but only for "official" neutron stadium subprojects.

Projects that don't meet the stadium criteria, including having api-def in 
neutron-lib, are "anything goes" and not part of neutron because no one from 
the neutron team is assumed to know anything about them. They may work just 
fine, it's just that you can't assume that anyone from neutron has anything to 
do with them or even knows what they do.

OK - that makes logical sense, though it does seem that it would tie specific 
versions of every service in that list to a common version of neutron-lib as a 
byproduct, so it would be impossible to upgrade LBaaS without also potentially 
having to upgrade bgpvpn, for instance.  I don't know if that was the 
intention, but I wouldn't have expected it.
--
Ian.
__
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] Stepping down from core

[Henry Fourie]

Armando,
Appreciate all the hard work and sage advice. Best wishes.
- Louis

From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, December 15, 2017 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] Stepping down from core

Hi neutrinos,

To some of you this email may not come as a surprise.

During the past few months my upstream community engagements have been more and 
more sporadic. While I tried hard to stay committed and fulfill my core 
responsibilities I feel like I failed to retain the level of quality and 
consistency that I would have liked ever since I stepped down from being the 
Neutron PTL back at the end of Ocata.

I stated many times when talking to other core developers that being core is a 
duty rather than a privilege, and I personally feel like it's way overdue for 
me to recognize on the mailing list that it's the time that I state officially 
my intention to step down due to other commitments.

This does not mean that I will disappear tomorrow. I'll continue to be on 
neutron IRC channels, support the neutron team, being the release liasion for 
Queens, participate at meetings, and be open to providing feedback to anyone 
who thinks my opinion is still valuable, especially when dealing with the 
neutron quirks for which I might be (git) blamed :)

Cheers,
Armando

__
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] No networking-sfc meetings until Jan 11

[Henry Fourie]

There will no networking-sfc meetings until Jan 11. Seasons greetings.

https://wiki.openstack.org/wiki/Meetings/ServiceFunctionChainingMeeting
- Louis
__
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 meetings cancelled this week

[Henry Fourie]

All,
  networking-sfc meetings will resume on May 18.
- Louis
__
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] No networking-sfc meeting today

[Henry Fourie]

All,
   There will be no networking-sfc meetings for the next two weeks.
Will resume on May 18.
- Louis
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we like to have horizon dashboard for neutron stadium projects?

[Henry Fourie]

Akihiro,
Option (a) would have my vote.
 - Louis

-Original Message-
From: Akihiro Motoki [mailto:amot...@gmail.com] 
Sent: Monday, April 10, 2017 8:09 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [neutron][sfc][fwaas][taas][horizon] where would we 
like to have horizon dashboard for neutron stadium projects?

Hi neutrinos (and horizoners),

As the title says, where would we like to have horizon dashboard for neutron 
stadium projects?
There are several projects under neutron stadium and they are trying to add 
dashboard support.

I would like to raise this topic again. No dashboard support lands since then.
Also Horizon team would like to move in-tree neutron stadium dashboard (VPNaaS 
and FWaaS v1 dashboard) to outside of horizon repo.

Possible approaches


Several possible options in my mind:
(a) dashboard repository per project
(b) dashboard code in individual project
(c) a single dashboard repository for all neutron stadium projects

Which one sounds better?

Pros and Cons


(a) dashboard repository per project
  example, networking-sfc-dashboard repository for networking-sfc
  Pros
   - Can use existing horizon related project convention and knowledge
 (directory structure, testing, translation support)
   - Not related to the neutron stadium inclusion. Each project can provide its 
dashboard
 support regardless of neutron stadium inclusion.
 Cons
   - An additional repository is needed.

(b) dashboard code in individual project
  example, dashboard module for networking-sfc
  Pros:
   - No additional repository
   - Not related to the neutron stadium inclusion. Each project can provide its 
dashboard
 support regardless of neutron stadium inclusion.
 Cons:
   - Requires extra efforts to support neutron and horizon codes in a single 
repository
 for testing and translation supports. Each project needs to explore the 
way.

(c) a single dashboard repository for all neutron stadium projects
   (something like neutron-advanced-dashboard)
  Pros:
- No additional repository per project
  Each project do not need a basic setup for dashboard and possible makes 
things simple.
  Cons:
- Inclusion criteria depending on the neutron stadium inclusion/exclusion
  (Similar discussion happens as for neutronclient OSC plugin)
  Project before neutron stadium inclusion may need another implementation.


My vote is (a) or (c) (to avoid mixing neutron and dashboard codes in a repo).

Note that as dashboard supports for feature in the main neutron repository are 
implemented in the horizon repository as we discussed several months ago.
As an example, trunk support is being development in the horizon repo.

Thanks,
Akihiro

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

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

[Henry Fourie]

Igor,
  Inline.

-Louis

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

Hi networking-sfc,

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

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

Here are my thoughts, let me know yours:


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

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


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

port-pair (service-function-params):

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

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

LF: agree, it appears that L2, L3, MPLS, NSH are mutually exclusive.
Agree on tap-enabled.

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

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

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

Re: [openstack-dev] [neutron][sfc] stable/ocata version

[Henry Fourie]

Gary,
   Awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Saturday, March 04, 2017 11:01 PM
To: OpenStack List
Subject: [openstack-dev] [neutron][sfc] stable/ocata version

Hi,
We are pretty blocked at the moment with our gating on stable/ocata. This is 
due to the fact that there is no networking-sfc version tagged for ocata.
Is there any ETA for this?
Thanks
Gary

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

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

[Henry Fourie]

Jeffrey,
   The branch pull is awaiting approval:
https://review.openstack.org/#/c/439200

-Louis

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

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

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

-Louis

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

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

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



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

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

[Henry Fourie]

Gary,
   The plan is to have a stable/ocata branch by end of month.

-Louis

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

Hi,
When will this repo have a stable/ocata branch?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Fourie]

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

[Henry Fourie]

Igor,
  See inline.

-Louis

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.
LF:  - this is only true for OVS drivers.

2.  The flow-classifier must be unique in its (full) definition.
LF: correct

3.  A port-chain can have multiple flow-classifiers associated with exactly 
the same definition BUT different logical source ports.
LF: correct


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.
LF: If a port-chain has no classifier, then there is no classification so no 
traffic flows through it.

5. The flow classifiers can only be used once, by a single port-chain.
LF: correct.


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).
LF: correct

7. A port-pair's ingress cannot be in use by another port-pair's ingress.
LF: correct a SF port can only be the  ingress port of one port pair.

8. A port-pair's egress cannot be in use by another port-pair's egress.
LF: correct a SF port can only be the  egress port of one port pair.

9. A port-pair can be associated to another port-pair's ingress and egress 
ports BUT swapped (i1=e2, e1=i2).
LF: correct.

10. The port-pairs become "in use" when a port-pair-group associates them, so 
they can't be reused across port-pair-groups.
LF: correct, a port-pair can only be in one port-pair group.

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).
LF: correct.

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] [stadium] subprojects on independent release cycle

[Henry Fourie]

Armando,
   networking-sfc will cut a stable/ocata branch by March 10.

-Louis

From: Armando M. [mailto:arma...@gmail.com]
Sent: Wednesday, February 08, 2017 8:16 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [stadium] subprojects on independent 
release cycle



On 2 February 2017 at 16:09, Armando M. 
> wrote:
Hi neutrinos,

I have put a number of patches in the merge queue for a few sub-projects. We 
currently have a number of these that are on an independent release schedule. 
In particular:

  *   networking-bagpipe
  *   networking-bgpvpn
  *   networking-midonet
  *   networking-odl
  *   networking-sfc
Please make sure that between now and March 10th [1], you work to prepare at 
least one ocata release that works with neutron's [2] and cut a stable branch 
before than. That would incredibly help consumers who are interested in 
assembling these bits together and start testing ocata as soon as it's out.

Your collaboration is much appreciated.

Many thanks,
Armando

Hi neutrinos,

I did not hear anything back from the liaisons of the above mentioned project 
over the past few days. Can you clarify your plans for cutting an Ocata release?

Thanks,
Armando


[1] https://releases.openstack.org/ocata/schedule.html
[2] https://review.openstack.org/#/c/428474/

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

[Henry Fourie]

Michael,
  Regarding horizon support for networking-sfc, the screens shown
on the demo were developed in an earlier patch that was not merged.
https://review.openstack.org/#/c/258430/

This work is still in progress.
 - Louis

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

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

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

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


--
Bernard Cafarelli

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

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

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

[Henry Fourie]

Cathy,
   I believe Mohan Kumar did that work.
 - Louis

-Original Message-
From: Cathy Zhang 
Sent: Tuesday, January 24, 2017 5:39 PM
To: OpenStack Development Mailing List (not for usage questions); Henry Fourie; 
Vikram Choudhary
Cc: Cathy Zhang
Subject: RE: [openstack-dev] [networking-sfc]

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

Louis/Vikram,

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

Thanks,
Cathy

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

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

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

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


--
Bernard Cafarelli

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

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

Re: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 devices?

[Henry Fourie]

Vikash,
   Unclear what you mean by SFC spinning an L2 IDS?
What is the behavior of L2 IDS devices?

-Louis

From: Vikash Kumar [mailto:vikash.ku...@oneconvergence.com]
Sent: Wednesday, January 18, 2017 10:49 PM
To: openstack-dev
Subject: [openstack-dev] [networking-sfc] Does SFC support chaining of Layer 2 
devices?

All,
   I am exploring SFC for chaining an IDS device (strictly in L2 mode). As of 
now, it looks SFC default supports only L3 devices. SFC APIs doesn't have any 
way to specify the nature of device and without that, it seems there is no way 
an operator can spin any device/VNF except L3 mode VNFs. Is anything I am 
missing here ? Can one still spin a L2 IDS with SFC ?


--
Regards,
Vikash
__
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] PTL nominations deadline and non-candidacy

[Henry Fourie]

Armando
   Appreciate your efforts, leadership and guidance.

-Louis

From: Armando M. [mailto:arma...@gmail.com]
Sent: Monday, January 09, 2017 6:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] PTL nominations deadline and non-candidacy

Hi neutrinos,

The PTL nomination week is fast approaching [0], and as you might have guessed 
by the subject of this email, I am not planning to run for Pike. If I look back 
at [1], I would like to think that I was able to exercise the influence on the 
goals I set out with my first self-nomination [2].

That said, when it comes to a dynamic project like neutron one can't never 
claim to be *done done* and for this reason, I will continue to be part of the 
neutron core team, and help the future PTL drive the next stage of the 
project's journey.

I must admit, I don't write this email lightly, however I feel that it is now 
the right moment for me to step down, and give someone else the opportunity to 
grow in the amazing role of neutron PTL! I have certainly loved every minute of 
it!

Cheers,
Armando

[0] https://releases.openstack.org/ocata/schedule.html
[1] 
https://review.openstack.org/#/q/project:openstack/election+owner:armando-migliaccio
[2] https://review.openstack.org/#/c/223764/
__
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] Next networking-sfc meeting on 1/5/2017

[Henry Fourie]

All,
   As many people will be away over the holiday season we will have the next 
networking-sfc meeting on 1/5/2017.
Best wishes for the season.

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

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

[Henry Fourie]

Igor
+1

-Louis

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Wednesday, November 23, 2016 3:26 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [networking-sfc] #networking-sfc IRC channel

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

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

[Henry Fourie]

+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

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

[Henry Fourie]

Navdeep,
  Post port-chain, port-pair-group, port-pair config to questions at 
https://launchpad.net/networking-sfc
  Use these commands to determine traffic flow and post results also.

  sudo ovs-ofctl -O openflow13 dump-flows br-int

  sudo ovs-ofctl -O Openflow13 dump-groups br-int


-Louis

From: Navdeep Uniyal [mailto:navdeep.uni...@neclab.eu]
Sent: Wednesday, October 12, 2016 3:06 AM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Cathy,

Thanks for your reply. I have the setup done without any errors with only one 
vm in the chain. I want to move all the icmp traffic from vm1 to vm3 via vm2. 
My Flow classifier looks like:
"neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
10.0.0.18/32 --destination-ip-prefix 10.0.0.6/32 --protocol icmp FC1"
But using tcpdump on vm2 ingress port, I could not see any traffic. Please let 
me know how can I debug this and what could be the possible issue.


Best Regards,
Navdeep Uniyal


From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Dienstag, 11. Oktober 2016 19:50
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [networking-sfc][devstack][mitaka]

Hi Navdeep,

Please see inline.

Cathy

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

Hi all,

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

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

Cathy




Below is the flow classifier:

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



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


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

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  
Road, London, 

Re: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

[Henry Fourie]

+1

From: Armando M. [mailto:arma...@gmail.com]
Sent: Saturday, September 17, 2016 9:41 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron] Adding ihrachys to the neutron-drivers team

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team [1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as 
stable core, downstream package whisperer, release and oslo liaison (I am sure 
I am forgetting some other capacity he is in) is going to put him at great 
comfort in the newly appointed role, and help him grow and become wise even 
further.

Even though we have not been meeting regularly lately we will resume our 
Thursday meetings soon [2], and having Ihar onboard by then will be highly 
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] 
http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
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] PTL candidacy

[Henry Fourie]

+1

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Friday, September 16, 2016 3:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tacker] PTL candidacy

Hi Tackers,

I would like to announce my candidacy to continue as Tacker PTL for the Ocata
dev cycle.

I'm a member of the Tacker community right from its Neutron ServiceVM days.
I actively participated in its transition into NFV Orchestration area and its
graduation into big-tent. Since becoming an official project our developer
community has grown and has more diverse [1].

Newton was a packed cycle for us with many stellar achievements from the
community: VNF Scaling, Audit Events, VNF Forwarding Graph using Neutron
Networking-SFC (we are almost there!) and External Alarm-based Monitoring
using Ceilometer. As usual tons of refactoring work happened to continue
to shed the "Neutronisms" in the project.

Along the way, we have become a better openstack citizen following best
practices like Reno release-notes, better release processes, and better
python3 support. We also expanded our core-team with three new members.

My vision for Tacker Ocata is along the following workstreams identified
in the recent weekly meeting.

* Decomposed VIM drivers:
We need to enable a healthy ecosystem of VIM drivers beyond the current
default openstack VIM driver. Our user community has mixed hypervisor/cloud
technology in their deployments - with some existing pre-openstack systems
(a.la, VMware), some OpenStack based clouds, and, forward looking 
into
Containers and public clouds. All this needs an easy to add VIM driver to
bolt underneath Tacker. Luckily our architecture is designed with this in
mind right from day one. We just need to make it easy (a) for developers to
bring in new VIM drivers and (b) for deployers to quickly add new VIM
capabilities without requiring a fork-lift upgrade of Tacker for every new
VIM type.

As part of this workstream, I'd work towards bringing in a Container VIM
type interfacing with Magnum / Zun.

Lifecycle Features:
* Finish left over Newton features - VNFC and NSD
* Better integration with external EM / FCAPS systems
* Enable support for VNFs leveraging Neutron's latest VLAN aware VM feature

Project maintenance:
 * Doc: API reference guide
 * Pecan API framework
 * OSC support
 * Finish python3x TC goal

Tons of fun things to do! However, Ocata is going to be a short cycle.
So, over next few weeks, I'll help to continue to groom these topics and
zoom in on those that are implementable in one dev cycle and clearly
identify some tracks that would carry over to the next cycle.

In Ocata, given an opportunity to serve as your PTL, I'll continue my role
as the "chief enabler" for this amazing community of developers that I'm so
proud to lead over the last two cycles.

- Sridhar Ramaswamy (irc: sridhar_ram)

[1] http://stackalytics.com/?module=tacker-group=commits

__
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] Proposing Mohan Kumar for networking-sfc core

[Henry Fourie]

+1

From: Cathy Zhang
Sent: Monday, June 13, 2016 11:36 AM
To: openstack-dev@lists.openstack.org; Cathy Zhang
Subject: [openstack-dev] [neutron][networking-sfc] Proposing Mohan Kumar for 
networking-sfc core

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


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

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

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

[Henry Fourie]

Alioune,
   The logical-source-port refers to a Neutron port of the VM that
originates the traffic that is to be processed by the port-chain.

-Louis

From: Alioune [mailto:baliou...@gmail.com]
Sent: Thursday, June 09, 2016 6:50 AM
To: Mohan Kumar
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][SFC]

Thanks Mohan,

After setting service_plugins and adding sfc tables to neutrondb, I can create 
port-pair, port-pair-group but classifier creation still claim a 
logical-source-port parameter.

neutron flow-classifier-create  --ethertype IPv4  --source-ip-prefix 
55.55.55.2/32  --destination-ip-prefix 
55.55.55.9/32  --protocol tcp  --source-port 22:22  
--destination-port 1:65000 FC1
ERROR:
neutron flow-classifier-create: error: argument --logical-source-port is 
required
Try 'neutron help flow-classifier-create' for more information.

Please someone can explain what does --logical-source-port correspond to ?
Does the classifier require port-create like SF ?

Regards,


On 9 June 2016 at 09:21, Mohan Kumar 
> wrote:
Alioune,

networking-sfc  resources not installed / not reachable , If installation is 
okay, Possibly you may missed service_plugins entry in neutron.conf ( in case 
of manual networking-sfc installation)

it should be ,

service_plugins = 
neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,networking_sfc.services.flowclassifier.plugin.FlowClassifierPlugin,networking_sfc.services.sfc.plugin.SfcPlugin

and restart q-svc services in screen -x

Thanks.,
Mohankumar.N

On Thu, Jun 9, 2016 at 12:58 AM, Alioune 
> wrote:
I've switched from devstack to a normal deployment of openstack/mitaka and 
neutron-l2 agent is working fine with sfc. I can boot instances, create ports.
However I can not create neither flow-classifier nor port-pair ...

neutron flow-classifier-create --ethertype IPv4 --source-ip-prefix 
22.1.20.1/32 --destination-ip-prefix 
172.4.5.6/32 --protocol tcp --source-port 23:23 
--destination-port 100:100 FC1

returns: neutron flow-classifier-create: error: argument --logical-source-port 
is required
Try 'neutron help flow-classifier-create' for more information.

 neutron port-pair-create --ingress=p1 --egress=p2 PP1
404 Not Found

The resource could not be found.

Neutron server returns request_ids: ['req-1bfd0983-4a61-4b32-90b3-252004d90e65']

neutron --version
4.1.1

p1,p2,p3,p4 have already been created, I can ping instances attached to these 
ports.
Since I've not installed networking-sfc, are there additional config to set in 
neutron config files ?
Or is it due to neutron-client version ?

Regards

On 8 June 2016 at 20:31, Mohan Kumar 
> wrote:

neutron agent not able to fetch details from ovsdb . Could you check below 
options 1.restart ovsdb-server and execute ovs_vsctl list-br  2.   execute ovs- 
vsctl list-br manually and try to check error.

3. Could be ovs cleanup issue , please check the output of sudo service 
openvswitch restart and /etc/init.d/openvswich** restart , both should be same

Thanks.,
Mohankumar.N
On Jun 7, 2016 6:04 PM, "Alioune" 
> wrote:
Hi Mohan/Cathy
 I've installed now ovs 2.4.0 and followed 
https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining but I got 
this error :
Regards,

+ neutron-ovs-cleanup
2016-06-07 11:25:36.465 22147 INFO neutron.common.config [-] Logging enabled!
2016-06-07 11:25:36.468 22147 INFO neutron.common.config [-] 
/usr/local/bin/neutron-ovs-cleanup version 7.1.1.dev4
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl [-] Unable 
to execute ['ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'list-br'].
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Traceback 
(most recent call last):
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File 
"/opt/stack/neutron/neutron/agent/ovsdb/impl_vsctl.py", line 63, in run_vsctl
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl 
log_fail_as_error=False).rstrip()
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl   File 
"/opt/stack/neutron/neutron/agent/linux/utils.py", line 159, in execute
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl raise 
RuntimeError(m)
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl RuntimeError:
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Command: 
['sudo', 'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--', 
'list-br']
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl Exit code: 1
2016-06-07 11:25:36.505 22147 ERROR neutron.agent.ovsdb.impl_vsctl
2016-06-07 11:25:36.505 22147 ERROR 

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

[Henry Fourie]

Gary,
Yes, it will be.

-Louis

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, June 06, 2016 2:39 AM
To: OpenStack List
Subject: [openstack-dev] [Neutron][Networking-SFC] Stable/mitaka version

Hi,
In git the project has a stable/liberty and trunk version. Will this be 
supported in stable/mitaka?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

[Henry Fourie]

Ryan,
   I agree that having rules in the ACL table with actions that would steer the 
packets to SFC
Processing would be a good approach.

-Louis

From: Ryan Moats [mailto:rmo...@us.ibm.com]
Sent: Tuesday, May 31, 2016 10:18 AM
To: John McDowall
Cc: Justin Pettit; Russell Bryant; Ben Pfaff; OpenStack Development Mailing 
List; disc...@openvswitch.org
Subject: Re: [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall 
> wrote 
on 05/26/2016 11:08:43 AM:

> From: John McDowall 
> >
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org"
> >, Justin Pettit 
> >,
> "OpenStack Development Mailing List"  d...@lists.openstack.org>, Russell Bryant 
> >
> Date: 05/26/2016 11:09 AM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> My (incomplete) throughts about the flow-classifier are:
>
> 1)  ACL’s are more about denying access, while the flow classifier
> is more about steering selected traffic to a path, so we would need
> to deny-all except allowed flows.
> 2)  The networking-sfc team has done a nice job with the drivers so
> ovn has its own flow-classifier driver which allows us to align the
> flow-classifier with the matches supported in ovs/ovn, which could
> be an advantage.

The ACL table has a very simple flow-classifier structure and I'd
like to see if that can be re-used for the purpose of the SFC classifier
(read that I feel the Logical_Flow_Classifier table is too complex).
My initial thoughts were to look at extending the action column and
using the external-ids field to differentiate between legacy ACLs and
those that are used to intercept traffic and route it to an SFC.

>
> What were your thoughts on the schema it adds a lot of tables and a
> lot of commands – cannot think of anyway around it

In this case, I think that the other tables are reasonable and I'm
uncomfortable trying to stretch the existing tables to cover that
information...

Ryan

>
> Regards
>
> John
>
> From: Ryan Moats >
> Date: Wednesday, May 25, 2016 at 9:12 PM
> To: John McDowall 
> >
> Cc: Ben Pfaff >, 
> "disc...@openvswitch.org" <
> disc...@openvswitch.org>, Justin Pettit 
> >, OpenStack
> Development Mailing List 
> >,
>  Russell Bryant <
> russ...@ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall 
> > wrote 
> on 05/25/2016
> 07:27:46 PM:
>
> > From: John McDowall 
> > >
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: "disc...@openvswitch.org" 
> > >, "OpenStack
> > Development Mailing List" 
> > >,
> >  Ben
> > Pfaff >, Justin Pettit 
> > >, Russell Bryant
> > >
> > Date: 05/25/2016 07:28 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > Ok – I will let the experts weigh in on load balancing.
> >
> > In the meantime I have attached a couple of files to show where I am
> > going. The first is sfc_dict.py and is a representation of the dict
> > I am passing from SFC to OVN. This will then translate to the
> > attached ovn-nb schema file.
> >
> > One of my concerns is that SFC almost doubles the size of the ovn-nb
> > schema but I could not think of any other way of doing it.
> >
> > Thoughts?
> >
> > John
>
> The dictionary looks fine for a starting point, and the more I look
> at the classifier, the more I wonder if we can't do something with
> the current ACL table to avoid duplication in the NB database
> definition...
>
> Ryan
>
> > From: Ryan Moats >
> > Date: Wednesday, May 25, 2016 at 7:27 AM
> > To: John McDowall 
> > >
> > Cc: "disc...@openvswitch.org" 
> > >, OpenStack
> > Development Mailing List 
> > 

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

[Henry Fourie]

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

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

[Henry Fourie]

Doug,
   Networking-sfc API currently has two reference SFC implementations that are 
open source:
the OVS driver and the ONOS driver. Work is also in progress for an ODL SFC 
driver and an OVN
driver.

-Louis

From: Doug Wiegley [mailto:doug...@parksidesoftware.com]
Sent: Friday, May 20, 2016 5:48 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][TC] support of NSH in networking-SFC

In a nutshell, you’ve got it, you can’t add an API without a reference 
implementation, including data-plane, which has to be open-source (though does 
not have to itself be openstack.)

o   Especially as Stadium, can we let Neutron to lead the industry, given broad 
enough community interest?

You can do anything you want outside the stadium, which is where 
experimental/incubation is meant to happen.  Inside the stadium means, 
“official openstack project”, which means it has an open-source implementation.

If all backends are closed-source, it’s not open as openstack defines it: 
https://governance.openstack.org/reference/opens.html

There isn’t any wiggle room there. This isn’t a neutron argument; feel free to 
take it up with the TC.

Thanks,
doug



On May 20, 2016, at 6:37 PM, Elzur, Uri 
> wrote:

Hi Armando, Cathy, All

First I apologize for the delay, returning from a week long international trip. 
(yes, I know,  a lousy excuse on many accounts…)

If I’m attempting to summarize all the responses, it seems like
• A given abstraction in Neutron is allowed (e.g. in support of SFC), 
preferably not specific to a given technology e.g. NSH for SFC
• A stadium project is not held to the same tests (but we do not have a 
“formal” model here, today) and therefore can support even a specific 
technology e.g. NSH (definitely better with abstractions to meet Neutron 
standards for future integration)

However,
• There still is a chicken and egg phenomenon… how can a technology 
become main stream with OPEN SOURCE support  if we can’t get an OpenStack to 
support the required abstractions before the technology was adopted elsewhere??
o   Especially as Stadium, can we let Neutron to lead the industry, given broad 
enough community interest?
• BTW,  in this particular case, there originally has been a direct ODL 
access as a NSH solution (i.e. NO OpenStack option), then we got Tacker (now an 
Neutron Stadium project, if I get it right) to support SFC and NSH, but we are 
still told that networking-sfc (another Neutron Stadium project ) can’t do the 
same….
• Also regarding the  following comment made on another message in this 
thread, “As to OvS features, I guess the OvS ml is a better place, but wonder 
if the Neutron community wants to hold itself hostage to the pace of other 
projects who are reluctant to adopt a feature”, what I mean is again, that 
chicken and egg situation as above. Personally, I think OpenStack Neutron 
should allow mechanisms that are of interest / value to the networking 
community at large, to “ experiment with the abstraction” as you stated, 
independent of other organizations/projects…

SOOO, is the bottom line that we agree that supporting NSH explicitly in 
networking-sfc can be added now?


Thx

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

From: Armando M. [mailto:arma...@gmail.com]
Sent: Friday, May 13, 2016 5:14 PM
To: Cathy Zhang >
Cc: OpenStack Development Mailing List (not for usage questions) 
>
Subject: Re: [openstack-dev] [Neutron] support of NSH in networking-SFC



On 13 May 2016 at 16:01, Cathy Zhang 
> wrote:
Hi Uri,

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

One can support NSH whichever way they see fit. NSH in OVS is not something 
Neutron can do anything about. Neutron is about defining abstractions that can 
apply to a variety of technologies and experiment with what open source 
component is available on the shelves. Anyone can take the abstraction and 
deliver whatever technology stack they want with it and we'd happily gather any 
feedback to iterate on the abstraction to address more and more use case.


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

Thanks,
Cathy

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

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

[Henry Fourie]

All,
   Please use the networking-sfc etherpad to record discussions at
the meetups:

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

 - Louis

-Original Message-
From: Paul Carver [mailto:pcar...@paulcarver.us] 
Sent: Tuesday, April 26, 2016 10:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [networking-sfc] Network-sfc project 
f2f2 meet-up place and time

On 4/26/2016 00:35, Akihiro Motoki wrote:
> Hi Cathy and folks interested in SFC and classifers!
>
> Can't we use a different room like Salon D?
> Salon C is a lunch room and at that time there are no sessions in other rooms.
> It would be great if we can use Salon D or E (after looking at the 
> first day's session) I think we can gather more easily and concentrate 
> the discussion if we use some different space.
> Thought?
>

Akihiro,

Unless I've misunderstood the emails, the plan for Tuesday is a social lunch 
for the SFC team to get together. The plan for Wednesday is a working lunch to 
discuss flow classifiers in various projects and figure out how to converge on 
a single flow classifier API/model that can be shared by everything that needs 
to specify flows.

If that's correct, then meeting in Salon C for lunch on Tuesday makes sense. 
For Wednesday we probably ought to grab boxed lunches and find a quiet room.


__
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] [tacker] No weekly IRC meeting next week - Feb 2

[Henry Fourie]

Sridhar,
   What time will the Tacker mid-cycle meeting start/end?

-Louis

From: Sridhar Ramaswamy [mailto:sric...@gmail.com]
Sent: Tuesday, January 26, 2016 11:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [tacker] No weekly IRC meeting next week - Feb 2

As discussed in today's irc meeting, we are skipping next weekly meeting 
scheduled for Tuesday Feb 2nd [1] as we already have a 2-day mid-cycle meetup 
[2] later this week.

- Sridhar

[1] https://wiki.openstack.org/wiki/Meetings/Tacker
[2] https://etherpad.openstack.org/p/tacker-mitaka-midcycle
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Henry Fourie]

Igor,
   I suggest you add the installation instructions here.

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


-Louis

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

Hi networking-sfc,

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

Best regards,
Igor.

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

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

[Henry Fourie]

Ihar,
   See inline.
- Louis

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

Henry Fourie <louis.fou...@huawei.com> wrote:

> Ihar,
>Networking-sfc installs flows on br-int and br-tun for steering 
> traffic to the SFC port-pairs. On each bridge additional tables are 
> used for an egress forwarding pipeline (from the service VM port) and 
> an ingress pipeline (to the service VM port). Rpc operations between 
> the OVS driver and agents is used to initiate the flow installation.
>
> We'd like to work with you on defining the L2 extensions.

Hi Henry,

thanks for taking time to specify your needs. Could you please update the 
etherpad [1] with these details?

LF> Will do.

Speaking of new ovs tables you need, how do you reference to them?
LF> br-int has one new table SF_SELECTOR in the ingress pipeline that is used 
steer traffic to the correct service VM
by matching on the NSP (Network Service Path) of the MPLS (NSH) header.
br-tun has two new tables in the egress pipeline: GRP_SELECTOR used to select a 
Group Table by matching on the NSP of the MPLS (NSH) header
and a set of Group Tables to perform load distribution for a port-pair group.
  
 Is there any ordering guarantees for flows you will need to set that should be 
provided in scope of that public API of the agent?
LF> No.

 I wonder whether just pushing flows into the existing tables at random points 
in time can be unstable and break the usual flow assumed by the main agent loop.
LF> No not expect any issues.

Am I making sense?

[1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion

Ihar

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

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

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

[Henry Fourie]

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

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

 - Louis   

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

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

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



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

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

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

[Henry Fourie]

Ihar,
   Networking-sfc installs flows on br-int and br-tun for steering
traffic to the SFC port-pairs. On each bridge additional tables are used
for an egress forwarding pipeline (from the service VM port) and an
ingress pipeline (to the service VM port). Rpc operations between the
OVS driver and agents is used to initiate the flow installation.

We'd like to work with you on defining the L2 extensions.

 - Louis


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

Thanks Thomas, much appreciated.

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

Ihar

Thomas Morin  wrote:

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



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

Re: [openstack-dev] New PyCharm License

[Henry Fourie]

Andrew,
   My launchpad id is lfourie
 - Louis

-Original Message-
From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com] 
Sent: Monday, September 21, 2015 10:10 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] New PyCharm License

Hi Andrew,

My launchpad id is abhishek-kekane

Thank you,

Abhishek

From: Andrew Melton [andrew.mel...@rackspace.com]
Sent: Monday, September 21, 2015 10:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] New PyCharm License

Hi devs,


I've got the new license for the next year. As always, please reply to this 
email with your launchpad-id if you would like a license.


Also, if there are other JetBrains products you use to contribute to OpenStack, 
please let me know and I will request licenses.

​

--Andrew


__
Disclaimer: This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data. If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding.
__
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] The proposed Neutron API extension for packet forwarding has a lot of duplication to the Neutron SFC API

[Henry Fourie]

Anita,
   The spec https://review.openstack.org/#/c/204695/ has this history: it is 
the latest
in a series of patches on the spec 'API for Service Chaining' 
https://review.openstack.org/#/c/192933/.
On Jun 17 Armando ported our original spec 'Neutron API for Service Chaining'
https://review.openstack.org/#/c/177946/ that dates from April 16 to the new 
networking-sfc repo.

  This spec, mentioned in the reviews above, has essentially the same content 
although it
has evolved as a result of comments from several reviewers, as well as input 
received during the
networking-sfc meetings over the last several months.

 - Louis 

-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info] 
Sent: Monday, July 27, 2015 2:20 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] The proposed Neutron API extension for packet 
forwarding has a lot of duplication to the Neutron SFC API

On 07/24/2015 06:50 PM, Cathy Zhang wrote:
 Hi Everyone,
 In our last networking-sfc project IRC meeting, an issue was brought up that 
 the API proposed in https://review.openstack.org/#/c/186663/ has a lot of 
 duplication to the SFC API https://review.openstack.org/#/c/192933/ that is 
 being currently implemented. In the IRC meeting, the project team reached 
 consensus that we only need one API and the service chain API can cover the 
 functionality needed by https://review.openstack.org/#/c/186663/. Please 
 refer to the meeting log 
 http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-07-23-17.02.log.html
  for more discussion info. Please let us know if you have different opinion.
 Thanks,
 Cathy
 
 
 
 
 __
  OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

I think you need to acknowledge in both email topic and in content that Sean 
tried to draw the fact that you are duplicating this work on July 16th. 
Collaboration is much more than our meeting decided you shouldn't do your 
work. Perhaps taking a step back and acknowledging the work of others might 
set a nicer tone to your efforts.

Thanks,
Anita.

__
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] service chaining feature development meeting at 10am pacific time June 11

[Henry Fourie]

Sean,
   See
http://eavesdrop.openstack.org/meetings/sfc_project/2015/sfc_project.2015-06-11-17.01.log.html


-  Louis

From: Mooney, Sean K [mailto:sean.k.moo...@intel.com]
Sent: Thursday, June 11, 2015 9:46 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Hi can anyone provide a link to today's irc meeting logs?

Looking at http://eavesdrop.openstack.org/meetings/ I cannot see a 
Neutron_Service_Chaining_meeting directory
Are the logs being stored in 
http://eavesdrop.openstack.org/meetings/service_chaining/2015/ ?
If so the logs for today's meeting seem to be missing.

Regards
sean
From: Cathy Zhang [mailto:cathy.h.zh...@huawei.com]
Sent: Thursday, June 11, 2015 1:45 AM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Here is the updated agenda for tomorrow's meeting:


1. Update on last meeting's action items

2.   Neutron port chain API for SFC

3.   Unified API and data model for flow classifier that can be used for 
SFC, QoS, Packet forwarding etc.

4. Summary on the SFC Feature project scope: functional module breakdown 
and their architecture relationship, and Module development ownership sign-up

5. Deep dive into technical questions on etherpad if there is time.

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, June 10, 2015 3:23 PM
To: Cathy Zhang; OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [Neutron] service chaining feature development 
meeting at 10am pacific time June 11

Add the following item to the agenda:

unified data model for flow classifiers

Thanks,
Cathy

From: Cathy Zhang
Sent: Wednesday, June 10, 2015 3:12 PM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Subject: [openstack-dev] [Neutron] service chaining feature development meeting 
at 10am pacific time June 11

Hello everyone,

Our next weekly IRC meeting for the OpenStack service chain feature development 
is 10am pacific time June 11 (UTC 1700, hope I am doing the correct time 
conversion this time)  Following is the meeting info:

Weekly on Thursday at 1700 
UTChttp://www.timeanddate.com/worldclock/fixedtime.html?hour=18min=00sec=0 
in #openstack-meeting-4

You can also find the meeting info at 
http://eavesdrop.openstack.org/#Neutron_Service_Chaining_meeting

Agenda:

6. Update on last meeting's action items

7. Summary on the SFC Feature project scope: functional module breakdown 
and their architecture relationship as well as their relationship to OpenStack 
Neutron, the types of service functions that will be chained in this feature 
development

8. Module development ownership sign-up

9. Deep dive into technical questions on etherpad if there is time.


Anyone who would like to contribute to this feature development is welcome to 
join the meeting. Hope the time is good for most people.





Thanks,

Cathy



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

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Henry Fourie]

+1 for policy-target

-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] 
Sent: Friday, August 08, 2014 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

Thanks Jay for your constructive feedback on this. I personally think that 
'policy-target' is a good option. I am not sure what the rest of the team 
thinks, perhaps they can chime in.

On Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/07/2014 01:17 PM, Ronak Shah wrote:

 Hi,
 Following a very interesting and vocal thread on GBP for last couple 
 of days and the GBP meeting today, GBP sub-team proposes following 
 name changes to the resource.


 policy-point for endpoint
 policy-group for endpointgroup (epg)

 Please reply if you feel that it is not ok with reason and suggestion.


 Thanks Ronak and Sumit for sharing. I, too, wasn't able to attend the 
 meeting (was in other meetings yesterday and today).

 I'm very happy with the change from endpoint-group - policy-group.

 policy-point is better than endpoint, for sure. The only other 
 suggestion I might have would be to use policy-target instead of 
 policy-point, since the former clearly delineates what the object is 
 used for (a target for a policy).

 But... I won't raise a stink about this. Sorry for sparking long and 
 tangential discussions on GBP topics earlier this week. And thanks to 
 the folks who persevered and didn't take too much offense to my questioning.

 Best,
 -jay



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Henry Fourie]

+1

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Wednesday, August 06, 2014 10:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

This is the consequence of a proposal that is not following the standardized 
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198

Well, I did bring  this point during the Hong Kong Summit but as you can see my 
comments were totally ignored:
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

I clearly saw this kind of issues coming. Let me quote myself what I suggested: 
For instance: endpoints should be enforcement point

I do not understand why GBP did not include this suggestion...

Edgar

From: Kevin Benton blak...@gmail.commailto:blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, August 6, 2014 at 10:22 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


What I was referring to was also not Keystone's definition of an endpoint. It's 
almost as if the term has many uses and was not invented for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template' 
since this was clearly already in use by Horizon?
On Aug 6, 2014 9:24 AM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints

You see how you used the term endpoints there? :P

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy

[Henry Fourie]

Ryan,
   So this is intended to associate a contract with a source EPG and a 
destination EPG – right?

-  Louis


From: Mandeep Dhami [mailto:dh...@noironetworks.com]
Sent: Wednesday, July 30, 2014 12:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Subrahmanyam Ongole
Subject: Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in 
group policy

Hi Ryan:

As I stated in the patch review, the suggestion to use a profiled API like 
IETF/CCITT is indeed very interesting. As a profiled API has not been tried 
with any neutron model before, and as there is no existing design pattern/best 
practices for how best to structure that, my recommendation is to create a new 
patch (dependent on this patch) to try that experiment.

That patch will also clarify what is meant you mean by a profiled API and how 
that might interact with other openstack services like Heat and Horizon.

Regards,
Mandeep
-


On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi 
hemanthrav...@gmail.commailto:hemanthrav...@gmail.com wrote:
Hi,

Adding this CLI command seems to be a good way to provide support for the 
second model. This can be submitted as a new review patch to work through the 
approaches to implement this. I suggest the current CLI patch [1] be reviewed 
for the existing spec and completed.

Ryan, would it possible for you to start a new review submit for the new 
command(s). Could you also provide any references for profiled API in IETF, 
CCITT.

Thanks,
-hemanth

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

On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats 
rmo...@us.ibm.commailto:rmo...@us.ibm.com wrote:

As promised in Monday's Neutron IRC minutes [1], this mail is a trip down 
memory lane looking at the history of the
Neutron GP project..  The original GP google doc [2] included specifying policy 
via both a produce/consume 1-group
approach and as a link between two groups.  There was an email thread [3] that 
discussed the relationship between
these models early on, but that discussion petered out and during a later IRC 
meeting [4] the concept of contracts
were added, but without changing the basic use case requirements from the 
original document.  A followup meeting [5]
began the discussion of how to express the original model from the contract 
data model but that discussion doesn't
appear to have been completed either.  The PoC in Atlanta raised a set of 
issues [6],[7] around the complexity of the
resulting PoC code.

The good news is that having looked through the proposed GP code commits (links 
to which can be found at [8) I
believe that folks that want to be able to specify policies via the 2-group 
approach (and yes, I'm one of them) can have
that without changing the model encoded in those commits. Rather, it can be 
done via the WiP CLI code commit by
providing a profiled API - this is a technique used by the IETF, CCITT, etc. 
to allow a rich API to be consumed in
common ways.  In this case, what I'm envisioning is something like

neutron policy-apply [policy rule] [src group] [destination group]

in this case, the CLI would perform the contract creation for the policy rule, 
and assigning the proper produce/consume
edits to the specified source and destination groups.  Note:  this is in 
addition to the CLI providing direct access to the
underlying data model.  I believe that this is the simplest way to bridge the 
gap and provide support to folks who want
to specify policy as something between two groups.

Ryan Moats (regXboi)

References:
[1] 
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt
[2] 
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit
[3] http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html
[4] 
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html
[5] 
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html
[6] http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html
[7] 
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html
[8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev