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

[Andreas Scheuring]

Perfect.

The agent will have all static hooks for the extensions in place, like
they are used in todays agents (the modular agent was derived from
existing lb agent). The knowledge which concrete extension
implementation to chose (e.g. lb) comes from the implementation specific
manager class that is required for instantiating the modular agent. So
it is ensured that with lb you get the lb extensions, with sriov you get
the sriov extensions.

There are no plans to make extensions more "modular" (whatever this
means in this context) as well in the first round. But we can discuss
for a second stage.

Thanks

-- 
Andreas
(IRC: scheuran)



On Mi, 2015-11-18 at 15:28 +0100, Ihar Hrachyshka wrote:
> Andreas Scheuring  wrote:
> 
> > Hi all,
> > I wonder if this is somehow in conflict with the modular l2 agent
> > approach I'm currently following up for linuxbridge, macvtap and sriov?
> > - RFE: [1]
> > - Frist patchset [2]
> >
> > I don't think so, but to be sure I wanted to raise it up.
> 
> I don’t believe it’s in conflict, though generally, I suggest you move  
> extensions code into modular l2 agent pieces, if possible. We will have  
> extensions enabled for lb, ovs, and sr-iov the least in Mitaka.
> 
> 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][sfc] How could an L2 agent extension access agent methods ?

[Andreas Scheuring]

Hi all, 
I wonder if this is somehow in conflict with the modular l2 agent
approach I'm currently following up for linuxbridge, macvtap and sriov?
- RFE: [1]
- Frist patchset [2]

I don't think so, but to be sure I wanted to raise it up.




[1] https://bugs.launchpad.net/neutron/+bug/1468803
[2] https://review.openstack.org/#/c/246318/

-- 
Andreas
(IRC: scheuran)



On Mo, 2015-11-16 at 20:42 +, Cathy Zhang wrote:
> I have updated the etherpad to add "Overall requirement - API cross check 
> among the features that can manipulate the same flow's forwarding behavior".
> 
> Thanks,
> Cathy
> 
> -Original Message-
> From: Paul Carver [mailto:pcar...@paulcarver.us] 
> Sent: Monday, November 16, 2015 7:50 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [neutron][sfc] How could an L2 agent extension 
> access agent methods ?
> 
> On 11/13/2015 7:03 PM, Henry Fourie wrote:
> 
> >
> >   I wonder whether just pushing flows into the existing tables at random 
> > points in time can be unstable and break the usual flow assumed by the main 
> > agent loop.
> > LF> No not expect any issues.
> >
> > Am I making sense?
> >
> > [1] https://etherpad.openstack.org/p/l2-agent-extensions-api-expansion
> >
> 
> I attempted to describe a possible issue at the bottom of the Etherpad in the 
> bullet point "Overall requirement - Flow prioritization mechanism"
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


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

[Ihar Hrachyshka]

Andreas Scheuring  wrote:


Hi all,
I wonder if this is somehow in conflict with the modular l2 agent
approach I'm currently following up for linuxbridge, macvtap and sriov?
- RFE: [1]
- Frist patchset [2]

I don't think so, but to be sure I wanted to raise it up.


I don’t believe it’s in conflict, though generally, I suggest you move  
extensions code into modular l2 agent pieces, if possible. We will have  
extensions enabled for lb, ovs, and sr-iov the least in Mitaka.


Ihar

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

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

[Paul Carver]

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



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

Am I making sense?

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



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




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

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

[Cathy Zhang]

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

Thanks,
Cathy

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

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

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

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



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

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

Re: [openstack-dev] [neutron][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][sfc] How could an L2 agent extension access agent methods ?

[Ihar Hrachyshka]

Henry Fourie  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?


Speaking of new ovs tables you need, how do you reference to them? 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? 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.


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

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

[Paul Carver]

On 11/9/2015 9:59 PM, Vikram Choudhary wrote:

Hi Cathy,

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


I'm very sorry to hear that. Please take all the time you need.


__
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 <thomas.mo...@orange.com> wrote:

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

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

[Cathy Zhang]

Hi Ihar,

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

Cathy

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

Thanks Thomas, much appreciated.

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

Ihar

Thomas Morin <thomas.mo...@orange.com> wrote:

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

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

[Cathy Zhang]

Hi Vikram,

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

Thanks,
Cathy

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


Hi Cathy,

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

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

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

Ihar

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

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

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

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

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

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

Thanks for taking up this work!

-Thomas


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



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

Hi Ihar,

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

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

Completely abstracting out packet forwarding pipelines in OVS and

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

[Ihar Hrachyshka]

Thanks Thomas, much appreciated.

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


Ihar

Thomas Morin  wrote:


Hi Ihar,

Ihar Hrachyshka :

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


This is an excellent recap.


 I set up a new etherpad to collect feedback from subprojects [2].


I've filled in details for networking-bgpvpn.
Please tell me if you need more information.

Once we collect use cases there and agree on agent API for extensions  
(even if per agent type), we will implement it and define as stable API,  
then pass objects that implement the API into extensions thru extension  
manager. If extensions support multiple agent types, they can still  
distinguish between which API to use based on agent type string passed  
into extension manager.


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


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


Thanks for taking up this work!

-Thomas




Ihar Hrachyshka  wrote:


On 30 Sep 2015, at 12:53, Miguel Angel Ajo  wrote:



Ihar Hrachyshka wrote:

On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:

Hi Ihar,

Ihar Hrachyshka :

Miguel Angel Ajo :

Do you have a rough idea of what operations you may need to do?
Right now, what bagpipe driver for networking-bgpvpn needs to  
interact with is:

- int_br OVSBridge (read-only)
- tun_br OVSBridge (add patch port, add flows)
- patch_int_ofport port number (read-only)
- local_vlan_map dict (read-only)
- setup_entry_for_arp_reply method (called to add static ARP  
entries)

Sounds very tightly coupled to OVS agent.
Please bear in mind, the extension interface will be available  
from different agent types
(OVS, SR-IOV, [eventually LB]), so this interface you're talking  
about could also serve as
a translation driver for the agents (where the translation is  
possible), I totally understand
that most extensions are specific agent bound, and we must be  
able to identify

the agent we're serving back exactly.
Yes, I do have this in mind, but what we've identified for now  
seems to be OVS specific.
Indeed it does. Maybe you can try to define the needed pieces in  
high level actions, not internal objects you need to access to.  
Like ‘- connect endpoint X to Y’, ‘determine segmentation id for a  
network’ etc.
I've been thinking about this, but would tend to reach the  
conclusion that the things we need to interact with are pretty hard  
to abstract out into something that would be generic across  
different agents.  Everything we need to do in our case relates to  
how the agents use bridges and represent networks internally:  
linuxbridge has one bridge per Network, while OVS has a limited  
number of bridges playing different roles for all networks with  
internal segmentation.


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


Completely abstracting out packet forwarding pipelines in OVS and  
linuxbridge agents would possibly allow defining an interface that  
agent extension could use without to know about anything specific to  
OVS or the linuxbridge, but I believe this is a very significant  
taks to tackle.


If you look for a clean way to integrate with reference agents, then  
it’s something that we should try to achieve. I agree it’s not an  
easy thing.


Just an idea: can we have a resource for traffic forwarding, similar  
to security groups? I know folks are not ok with extending security  
groups API due to compatibility reasons, so maybe fwaas is the place  
to experiment with it.


Hopefully it will be acceptable to create an interface, even it  
exposes a set of methods specific to the linuxbridge agent and a set  
of methods 

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

[Vikram Choudhary]

Hi Cathy,

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

Thanks
Vikram
On 09-Nov-2015 6:15 pm, "Ihar Hrachyshka"  wrote:

> Thanks Thomas, much appreciated.
>
> I need to admit that we haven’t heard from SFC folks just yet. I will try
> to raise awareness that we wait for their feedback today on team meeting.
> Adding [sfc] tag to the topic to get more attention.
>
> Ihar
>
> Thomas Morin  wrote:
>
> Hi Ihar,
>>
>> Ihar Hrachyshka :
>>
>>> Reviving the thread.
>>> [...] (I appreciate if someone checks me on the following though):
>>>
>>
>> This is an excellent recap.
>>
>>  I set up a new etherpad to collect feedback from subprojects [2].
>>>
>>
>> I've filled in details for networking-bgpvpn.
>> Please tell me if you need more information.
>>
>> Once we collect use cases there and agree on agent API for extensions
>>> (even if per agent type), we will implement it and define as stable API,
>>> then pass objects that implement the API into extensions thru extension
>>> manager. If extensions support multiple agent types, they can still
>>> distinguish between which API to use based on agent type string passed into
>>> extension manager.
>>>
>>> I really hope we start to collect use cases early so that we have time
>>> to polish agent API and make it part of l2 extensions earlier in Mitaka
>>> cycle.
>>>
>>
>> We'll be happy to validate the applicability of this approach as soon as
>> something is ready.
>>
>> Thanks for taking up this work!
>>
>> -Thomas
>>
>>
>>
>> Ihar Hrachyshka  wrote:
>>>
>>> On 30 Sep 2015, at 12:53, Miguel Angel Ajo  wrote:
>
>
>
> Ihar Hrachyshka wrote:
>
>> On 30 Sep 2015, at 12:08, thomas.mo...@orange.com wrote:
>>>
>>> Hi Ihar,
>>>
>>> Ihar Hrachyshka :
>>>
 Miguel Angel Ajo :
>
>> Do you have a rough idea of what operations you may need to do?
>>
> Right now, what bagpipe driver for networking-bgpvpn needs to
> interact with is:
> - int_br OVSBridge (read-only)
> - tun_br OVSBridge (add patch port, add flows)
> - patch_int_ofport port number (read-only)
> - local_vlan_map dict (read-only)
> - setup_entry_for_arp_reply method (called to add static ARP
> entries)
>
 Sounds very tightly coupled to OVS agent.

> Please bear in mind, the extension interface will be available
>> from different agent types
>> (OVS, SR-IOV, [eventually LB]), so this interface you're talking
>> about could also serve as
>> a translation driver for the agents (where the translation is
>> possible), I totally understand
>> that most extensions are specific agent bound, and we must be
>> able to identify
>> the agent we're serving back exactly.
>>
> Yes, I do have this in mind, but what we've identified for now
> seems to be OVS specific.
>
 Indeed it does. Maybe you can try to define the needed pieces in
 high level actions, not internal objects you need to access to. Like ‘-
 connect endpoint X to Y’, ‘determine segmentation id for a network’ 
 etc.

>>> I've been thinking about this, but would tend to reach the
>>> conclusion that the things we need to interact with are pretty hard to
>>> abstract out into something that would be generic across different 
>>> agents.
>>> Everything we need to do in our case relates to how the agents use 
>>> bridges
>>> and represent networks internally: linuxbridge has one bridge per 
>>> Network,
>>> while OVS has a limited number of bridges playing different roles for 
>>> all
>>> networks with internal segmentation.
>>>
>>> To look at the two things you  mention:
>>> - "connect endpoint X to Y" : what we need to do is redirect the
>>> traffic destinated to the gateway of a Neutron network, to the thing 
>>> that
>>> will do the MPLS forwarding for the right BGP VPN context (called VRF), 
>>> in
>>> our case br-mpls (that could be done with an OVS table too) ; that 
>>> action
>>> might be abstracted out to hide the details specific to OVS, but I'm not
>>> sure on how to  name the destination in a way that would be agnostic to
>>> these details, and this is not really relevant to do until we have a
>>> relevant context in which the linuxbridge would pass packets to 
>>> something
>>> doing MPLS forwarding (OVS is currently the only option we support for 
>>> MPLS
>>> forwarding, and it does not really make sense to mix linuxbridge for
>>> Neutron L2/L3 and OVS for MPLS)
>>> - "determine segmentation id for a network": this is something
>>> really OVS-agent-specific, the linuxbridge agent uses