|
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
|
|
Hi folks, Forwarding this to the correct mail list.
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
|
|
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
|
|
Hi Evan
Great,then,Will it be in place in the ODL first release?
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
|
|
Ed Warnicke (eaw) <eaw@...>
Huang,
We have some tunnel models coming out of bgpcep… hopefully we can get folks to
converge on a general tunnel model.
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
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
|
|
