Huang,

No we don't implement any sort of tunnel manager. Once the full capabilities of ovsdb are in place we will provide the ability to create and discover tunnels in a remote open vswitch database.

Evan

On Tue, Oct 1, 2013 at 8:46 PM, huang denghui <huangdenghui@...> wrote:

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57，"Colin Dixon" <ckd@...>写道：

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
> Sent by: controller-dev-bounces@...
>
> Hi
>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.
>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others
> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.
>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 
> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.
>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others
> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
> I second this viewpoint as well.
>
> Thanks,
> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>
>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  
>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?
>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.
>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.
>
> My .02c
>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...
> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.
> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */
>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?
> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.
> But, we have to make sure the functionality is not redundant with
> something that exists already.
> So, please share all the functionalities that this module addresses.
>
> Thanks,
> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?
>
> Hi
>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?
>
> _______________________________________________ controller-dev mailing list
> controller-dev@... https://
> lists.opendaylight.org/mailman/listinfo/controller-dev
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

Hi Evan
     Great,then,Will it be in place in the ODL first release?

在 2013 10 2 10:15，"Evan Zeller" <evanrzeller@...>写道：

Huang,

No we don't implement any sort of tunnel manager. Once the full capabilities of ovsdb are in place we will provide the ability to create and discover tunnels in a remote open vswitch database.

Evan

On Tue, Oct 1, 2013 at 8:46 PM, huang denghui <huangdenghui@...> wrote:

Hi ovsdb guys
     Do you guys already implement a unified tunnel service that can discover new tunnel and accept requests to establish them?

在 2013 10 2 05:57，"Colin Dixon" <ckd@...>写道：

While I agree that we don't want a toxic dumpsite, the idea that we would want a unified way to represent tunnels, i.e., virtual links, in our topology and a unified way to route into and out of them seems like it would be a good thing.

OVSDB would be one of the southbound drivers that would need to notify this unified tunnel service about new tunnels as well as accept requests to establish them.

Am I off my rocker here?

--Colin

controller-dev-bounces@... wrote on 09/24/2013 07:33:32 PM:
> From: huang denghui <huangdenghui@...>
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Date: 09/24/2013 07:34 PM
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
> Sent by: controller-dev-bounces@...
>
> Hi
>
>         >>as Ken pointed out, the actual work on the controller
> (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.

>          I totally agree that, Since from architecture point of
> view, there is SAL there, All network functions should not sit
> directly on specific southbound plugin, So it must be a general
> service in SAL to offer this functionality.
>
>
>       >>FWIW, we already have (under development) similar work
> happening in OVSDB plugin side.
>        Yeah, i know, from my understanding, by it, app can configure
> Tunnel for OVSDB capable switch. i think there are many other
> southbound plugins out there also need to tunnel manager. especially
> for some overlay solutions.
>
>
> >>>>Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
>       Yeah, i support this viewpoint as well.
>
>
> >>>>So, I think we can discuss more on this topic maybe in the
> upcoming Technical work stream and get inputs from others
> and find a path forward.

>         Sounds great, I would like to follow this topic.

> Br
>   denghui
>

> 2013/9/25 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> I agree with Ken's assessment.
>
> Net-virt-platform's TunnelManager functionality seems to be very
> specific to OpenFlow (as you mentioned) and might be a 
> better fit for the open flow plugin. But, as Ken pointed out, the
> actual work on the controller (SAL) and the services/apps that 
> Makes use of Controller modules and SAL is a more generalized form
> of this which can address similar functionalities
> Across various southbound plugins such as OVSDB, OF, PCE etc.
> FWIW, we already have (under development) similar work happening in
> OVSDB plugin side.
>
> So, I think we can discuss more on this topic maybe in the upcoming
> Technical work stream and get inputs from others
> and find a path forward.
>
> >> Without purpose, the accumulation of modules in daylight will
> look like a toxic dumpsite of half-realized ideas.
> I second this viewpoint as well.
>
> Thanks,
> -Madhu
>
> From: Ken Gray <kgray@...>
> Date: Tuesday, September 24, 2013 8:17 AM
> To: huang denghui <huangdenghui@...>, Madhu Venugopal <vmadhu@...>
>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> This seems like a subset of functionality that might be made
> available as a service app …with some existing hardcoded
> dependencies that would have to be made compliant with more generic
> SAL hooks (for example, that tunnel could be set up by the OVS
> plugin via the SAL, NETCONF via that controller service, etc) and
> the definition of functionality is limited to a single context.  
>
> There's also questions (in my mind) about the state creation here …
> would there be ties to the permanent state storage work that is
> slated for the future or is this all ephemeral? …is a similar sort
> of functionality echoed in the PCE component?
>
> I'd suggest that (to be a project) we don't just port in existing
> software but examine the services we want to expose, the groups of
> projects that may be exposing or want to use that service …and then
> whether porting this, or hacking this code …is a good starting point.
>
> Without purpose, the accumulation of modules in daylight will look
> like a toxic dumpsite of half-realized ideas.
>
> My .02c
>
> From: huang denghui <huangdenghui@...>
> Date: Tue, 24 Sep 2013 21:07:02 +0800
> To: "Madhu Venugopal (vmadhu)" <vmadhu@...>
> Cc: "controller-dev@..." <controller-
> dev@...>
> Subject: Re: [controller-dev] Porting net-virt-platform
> TunnelManager into ODL?
>
> Hi Madhu

>    Thanks for you reply. TunnelManager is responsible for managing
> Tunnel information for Openflow switch, it is functionality should
> include the following but not limited, maybe more...
> 1.Collecting and maintaining  Tunnel information about Tunnel
> capable openflow switch, such as tunnel port, IP address, and MAC address.
> 2.Offering some services, such as
>    2.1.  determine whether a switch is Tunnel capable or not?
>    2.2.  get tunnel IP or MAC address of certain Tunnel capable switch.
>   
>

> The following is the original description of tunnalmanager module
> coming from net-virt-platform.
>
> /**
>  * TunnelManager collects and maintains information regarding the tunneling
>  * capability of connected switches (consult ITunnelManagerService for more
>  * information on the API tunnelManager offers). As of the Fat Tire release,
>  * TunnelManager no longer creates or deletes tunnel ports in
> connected switches.
>  *
>  * A switch is defined as
>  *   'tunneling-capable': If it has been configured with a
> OFPortType.TUNNEL port
>  *                        and a OFPortType.TUNNEL_LOOPBACK port
> using out of band
>  *                        techniques (eg. using ovs-vsctl or our
> install script).
>  *   'tunneling-enabled': By default a tunneling-capable switch is
> tunneling-enabled
>  *                        It is however possible to enable or
> disable the tunneling
>  *                        function on a tunnel-capable switch using
> the CLI or REST-API
>  *   'tunneling-active':  A tunneling-enabled switch with a tunnel-endpoint IP
>  *                        address on the TUNNEL_LOOPBACK port is
> deemed active for tunneling
>  *
>  *  A tunnel port is defined as
>  *    a port configured on a switch with name 'tun-bsn'. This port
> is necessarily
>  *    an OpenFlow port - i.e. a port under OpenFlow control. Note
> that there is
>  *    a single such port on a switch; it is created or removed by
> means other than
>  *    the controller; and no IP address is configured on this port.
> Packets sent
>  *    out of this port will get encapsulated with (currently) GRE
> encap and then
>  *    reappear through the TUNNEL_LOOPBACK port.
>  *
>  *  A tunnel-endpoint is defined as
>  *    a host-OS interface on which the tunnel-IP address for the switch is
>  *    configured. In the past, this 'could' be the 'ovs-br0' port in
> an OVS (in which case
>  *    it is OpenFlow visible); or it could be some other interface (eg. eth3)
>  *    which is not OpenFlow controllable. In our current FatTire solution, the
>  *    tunnel-endpoint is the OFPortType.TUNNEL_LOOPBACK port (named
> tun-loopback).
>  *
>  * @author Saurav Das
>  */
>

> 2013/9/24 Madhu Venugopal (vmadhu) <vmadhu@...>
> Hi Huang,
>
> Can you please explain the functionality of TunnelManager ?
> I don’t think there is an existing effort to port that. So it is
> reasonable item to do.
> But, we have to make sure the functionality is not redundant with
> something that exists already.
> So, please share all the functionalities that this module addresses.
>
> Thanks,
> -Madhu
>
> From: huang denghui <huangdenghui@...>
> Date: Monday, September 23, 2013 8:59 AM
> To: "controller-dev@..." <controller-
> dev@...>
> Subject: [controller-dev] Porting net-virt-platform TunnelManager into ODL?
>
> Hi
>      I want to porting TunnelManager module of net-virt-platform
> into ODL controller, Is it a reasonable item to do now? Does anyone
> already have the same effort on it?
>
> _______________________________________________ controller-dev mailing list
> controller-dev@... https://
> lists.opendaylight.org/mailman/listinfo/controller-dev
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..."
<discuss@...>, "<controller-
dev@...>" <controller-
dev@...>, "<affinity-dev@...>"
<affinity-dev@...>, "bgpcep-
dev@..." <bgpcep-dev@...>,
"<defense4all-dev@...>" <defense4all-
dev@...>, "dlux-dev@..."
<dlux-dev@...>,
"infrastructure@..."
<infrastructure@...>, "lispflowmapping-
dev@..." <lispflowmapping-
dev@...>, "opendove-dev@..."
<opendove-dev@...>, "openflowplugin-
dev@..." <openflowplugin-
dev@...>, "openflowjava-
dev@..." <openflowjava-
dev@...>, "ovsdb-dev@..."
<ovsdb-dev@...>,
"snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 02:01 PM
Subject: Re: [OpenDaylight Discuss] Next vHackfest
Sent by: discuss-bounces@...

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

Guys,
What would you find useful for the next vHackfest in terms of

dates/times? Keep in mind API freeze is Oct 14.

Possibilities that occur to me would be:

1) Modeling and MD-SAL integration
2) Cross project collaboration
3) Plugging into the OpenStack Neutron Service

What do you guys think? If we wanted to do this before Oct 14,

next Thursday might be a

good day.

Also, what worked and didn't work last time, how could we do it

better this time?

Ed

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

<graycol.gif>"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...

---

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally:

1)  Model and MD-SAL Integration

2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

<graycol.gif>"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...

---

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

So long as the Neutron Service part is between 1:00pm to 5:00pm US CDT, I'm fine.  My morning of 10/17 is already booked up.

Ryan

"Ed Warnicke (eaw)" ---10/07/2013 12:32:22 PM---How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 1)  Model and MD

From: "Ed Warnicke (eaw)" <eaw@...>
To: Ryan Moats/Omaha/IBM@IBMUS,
Cc: "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<controller-dev@...>" <controller-dev@...>, "<controller-dev-bounces@...>" <controller-dev-bounces@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "discuss@..." <discuss@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, "tsc@..." <tsc@...>
Date: 10/07/2013 12:32 PM
Subject: Re: [controller-dev] Next vHackfest

How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally:

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

<graycol.gif>"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>,
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and
> dates/times?  Keep in mind API freeze is Oct 14.
>
> Possibilities that occur to me would be:
>
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
>
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a
> good day.
>
> Also, what worked and didn't work last time, how could we do it better this time?
>
> Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Hi all,

 

For the OpenStack Neutron Service part, Sarath and I, from VTN project, will be fine between 2:00pm to 4:00pm PDT (6:00am – 8:00am JST).

 

I mean the following time slot:

Oct 17. 2:00pm – 4:00pm PDT

Oct 17. 4:00pm – 6:00pm US CDT

Oct 18. 6.00am – 8:00am JST

 

Thanks,

Hideyuki Tai

 

 

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Ryan Moats
Sent: Tuesday, October 08, 2013 2:52 AM
To: Ed Warnicke (eaw)
Cc: discuss@...; openflowplugin-dev@...; tsc@...; ovsdb-dev@...; dlux-dev@...; bgpcep-dev@...; <affinity-dev@...>; <defense4all-dev@...>; opendove-dev@...; snmp4sdn@...; lispflowmapping-dev@...; openflowjava-dev@...; <controller-dev@...>; infrastructure@...; <controller-dev-bounces@...>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Next vHackfest

 

So long as the Neutron Service part is between 1:00pm to 5:00pm US CDT, I'm fine.  My morning of 10/17 is already booked up.

Ryan

<image001.gif>"Ed Warnicke (eaw)" ---10/07/2013 12:32:22 PM---How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 1)  Model and MD

From: "Ed Warnicke (eaw)" <eaw@...>
To: Ryan Moats/Omaha/IBM@IBMUS, 
Cc: "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<controller-dev@...>" <controller-dev@...>, "<controller-dev-bounces@...>" <controller-dev-bounces@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "discuss@..." <discuss@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, "tsc@..." <tsc@...>
Date: 10/07/2013 12:32 PM
Subject: Re: [controller-dev] Next vHackfest

---

How would folks feel about doing a vHackfest on Thursday Oct 17 covering minimally: 

1)  Model and MD-SAL Integration
2)  Plugging into the OpenStack Neutron Service

That way Ryan can participate, and folks have time to prep?

Sound good?

Ed

On Oct 7, 2013, at 8:48 AM, Ryan Moats <rmoats@...> wrote:

I've seen some +1s for the OpenStack Neutron Service.  Unfortunately, I'm going put a -1 on that because I'm off to Minnesota on PTO Thursday and Friday this week and I'd sorta like to be part of the conversation.

Ryan

<graycol.gif>"Ed Warnicke (eaw)" ---10/03/2013 12:17:56 PM---Looping in all the dev lists to the conversation. Ed

From: "Ed Warnicke (eaw)" <eaw@...>
To: "discuss@..." <discuss@...>, "<controller-dev@...>" <controller-dev@...>, "<affinity-dev@...>" <affinity-dev@...>, "bgpcep-dev@..." <bgpcep-dev@...>, "<defense4all-dev@...>" <defense4all-dev@...>, "dlux-dev@..." <dlux-dev@...>, "infrastructure@..." <infrastructure@...>, "lispflowmapping-dev@..." <lispflowmapping-dev@...>, "opendove-dev@..." <opendove-dev@...>, "openflowplugin-dev@..." <openflowplugin-dev@...>, "openflowjava-dev@..." <openflowjava-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>, "snmp4sdn@..." <snmp4sdn@...>, 
Cc: "tsc@..." <tsc@...>
Date: 10/03/2013 12:17 PM
Subject: Re: [controller-dev] Next vHackfest
Sent by: controller-dev-bounces@...

---

Looping in all the dev lists to the conversation.

Ed
On Oct 3, 2013, at 12:13 PM, "Ed Warnicke (eaw)" <eaw@...>
wrote:

> Guys,
> What would you find useful for the next vHackfest in terms of themes and 
> dates/times?  Keep in mind API freeze is Oct 14.
> 
> Possibilities that occur to me would be:
> 
> 1)  Modeling and MD-SAL integration
> 2)  Cross project collaboration
> 3)  Plugging into the OpenStack Neutron Service
> 
> What do you guys think?  If we wanted to do this before Oct 14, next Thursday might be a 
> good day.
> 
> Also, what worked and didn't work last time, how could we do it better this time?
> 
> Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

hi Madhu,

Would you be update the github ovsdb_netty repo or there's gonna be a new branch out of official odl ovsdb gerrit git repo

Best

Zhipeng

On Fri, Oct 11, 2013 at 1:34 PM, Madhu Venguopal <mavenugo@...> wrote:

As discussed through various channels, I will go ahead and pull a topic branch under ovsdb for
the netty based json-rpc & marshal/de-marshal from/to java POJO objects using jackson.
I will also port most of the spread out code into this 1 location so that we can all start to contribute
in this branch without impacting the working master.

Please raise a flag if you have any concerns.

Thanks,
-Madhu

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@....org
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

--

Zhipeng Huang

Master Of Science & Research Assistant

Mobile Ad-Hoc Network Lab

California Institute for Telecommunications and Information Technology

Department of Electric Engineering and Computer Science

Department of Networked Systems

University of California, Irvine

Phone: 949-419-4241

Email: zhipengh@...

Office: Calit2 Building Room 2402