Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi, keshav...@hp.com : > > If this BaGpipe BGP does not support MPLS data plane driver, what is > advantage of this BGP from current. Just to avoid any misunderstanding: Bagpipe BGP **does** support an MPLS dataplane for IPVPN today. For E-VPN, bagpipe could support an MPLS dataplane with a new dataplane driver, but for now, having just a VXLAN driver is fine enough for intra-DC use cases. (to what "current" BGP solution do you want to compare with?) > What you are thinking (if I am right) is something like this below which is > traditional deployment model of E-VPN solution. I see your point, inter-DC would also be addressable with E-VPN, combined or not with other techniques. > https://tools.ietf.org/html/draft-rabadan-l2vpn-dci-evpn-overlay-01#ref-EVPN-Overlays The above describe ways, among others, to do inter-DC. > But what I was thinking is something like PW(pseudo wire) right from CN node > itself, so that there will not be any breakage/stitching/mapping related > issue. Sorry, but I don't get your point yet: - what problem are you trying to solve here? - what motivation to introduce PWs? [...] > > If we are not thinking of starting MPLS from CNs I think existing BGP (which > is underway) will be sufficient. (Again, I'm not sure which use of BGP you are referring to above.) Just to be 100% clear: starting an MPLS encap (or VXLAN) from CNs, based on BGP VPN routes, *is* a scenario we favor here. Best, -Thomas > -Original Message- > From: Thomas Morin [mailto:tmmorin.ora...@gmail.com] On Behalf Of Thomas Morin > Sent: Monday, June 23, 2014 7:25 PM > To: A, Keshava; OpenStack Dev > Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal > > > > Hi, > > > > 2014-06-22, A, Keshava: > > > > > > I have some of the basic question about deployment model of using this > > BaGPipe BGP in virtual cloud network. > > > > > > 1. We want MPLS to start right from compute node as part Tennant traffic ? > > > > BaGPipe BGP component is indeed adapted to be run on compute nodes to > encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external to the > datacenter. In this case you are interconnecting each VM at once with a /32 > VPNv4 route. [A] > > > > But you could use it as well on a network node to interconnect a whole > virtual network with one BGP route. However doing so does not simplify > deployments and requires additional care to handle redundancy. > > > > And to implement virtual networks with BaGPipe, the proposed target would be > to use it on compute nodes; but in that case MPLS is not the only option, and > what we currently support is VXLAN (E-VPN with a VXLAN encapsulation). > > > > > > > 2. We want L3 VRF separation right on Compute nodes (or NN Node) ? > > > Tenant = VRF ? > > > Tenant span can be across multiple CN nodes, then have BGP to > > Full mesh with in CN ? > > > > As said in another comment, a tenant (or project depending on the > > terminology) is not a network construct; tenants just own networks. > > > > In [A] above, for a virtual network interconnected with a VPN, there would be > one VRF on each compute node with a VM connected to this virtual network. > > > > (I'm not getting your question on having BGP as a full mesh in compute > > nodes) > > > > > 3. How to have E-VPN connectivity mapping at NN/CN nodes ? > > > Is there an L2 VPN psuedowire thinking from CN nodes itself ? > > > > I'm not sure I get your question. > > When BaGPipe BGP is used on compute nodes to build a virtual network, NN > don't need to be involved. They only will be involved once a router port (on > a NN) is connected to a virtual network. > > > > Note also that in E-VPN there is no notion of pseudowire; E-VPN does not > involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and > forwarding tables involve dynamically adding an encap header based on a > static forwarding table (rather than tunnels or pseudowires). > > > > > > > 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ? > > > > > > > When E-VPN is used, network traffic inside a virtual network is carried as > Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe does not > support any MPLS dataplane driver for E-VPN). When IP VPN is used (eg. > between virtual networks, or to/from an external IP VPN), traffic is carried > as IP traffic in MPLS or MPLS-GRE. > > > > > Help me understand the deployment model for this . &g
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi Ian, Ian Wells : When you say things like 'tenant = VRF' (and, in fact, I presume you mean 'network = VRF', since networks and tenants are two different things) then that's actually more to do with how you implement the networking overlay layer in Neutron. While interesting, and while it could potentially use a BGP speaker and VRFs to do it, it's not the same use case as advertising routes externally, or terminating an external MPLS VPN in Openstack. I could do either of those things independently of the other. Terminating VPNs requires an extension API and could potentially glue on to a current plugin (much like VPNaaS). Writing overlays is a new plugin entirely. Indeed. There's a use for BGP speakers in both arenas (and additionally within the distributed virtual router, which is a third case) so perhaps we could address who's using which speaker for precisely what? We plan to propose an implementation of the BGP VPN interconnection API ( https://review.openstack.org/#/c/93329/1 ) that will use BaGPipe BGP for IP VPN VRF. And we are also working on a mechanism driver that will use BaGPipe BGP and E-VPN/VXLAN. Best, -Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi, 2014-06-22, A, Keshava: I have some of the basic question about deployment model of using this BaGPipe BGP in virtual cloud network. 1. We want MPLS to start right from compute node as part Tennant traffic ? BaGPipe BGP component is indeed adapted to be run on compute nodes to encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external to the datacenter. In this case you are interconnecting each VM at once with a /32 VPNv4 route. [A] But you could use it as well on a network node to interconnect a whole virtual network with one BGP route. However doing so does not simplify deployments and requires additional care to handle redundancy. And to implement virtual networks with BaGPipe, the proposed target would be to use it on compute nodes; but in that case MPLS is not the only option, and what we currently support is VXLAN (E-VPN with a VXLAN encapsulation). 2. We want L3 VRF separation right on Compute nodes (or NN Node) ? Tenant = VRF ? Tenant span can be across multiple CN nodes, then have BGP to Full mesh with in CN ? As said in another comment, a tenant (or project depending on the terminology) is not a network construct; tenants just own networks. In [A] above, for a virtual network interconnected with a VPN, there would be one VRF on each compute node with a VM connected to this virtual network. (I'm not getting your question on having BGP as a full mesh in compute nodes) 3. How to have E-VPN connectivity mapping at NN/CN nodes ? Is there an L2 VPN psuedowire thinking from CN nodes itself ? I'm not sure I get your question. When BaGPipe BGP is used on compute nodes to build a virtual network, NN don't need to be involved. They only will be involved once a router port (on a NN) is connected to a virtual network. Note also that in E-VPN there is no notion of pseudowire; E-VPN does not involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and forwarding tables involve dynamically adding an encap header based on a static forwarding table (rather than tunnels or pseudowires). 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ? When E-VPN is used, network traffic inside a virtual network is carried as Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe does not support any MPLS dataplane driver for E-VPN). When IP VPN is used (eg. between virtual networks, or to/from an external IP VPN), traffic is carried as IP traffic in MPLS or MPLS-GRE. Help me understand the deployment model for this . Hope that helps, -Thomas -Original Message- From: Thomas Morin [mailto:thomas.mo...@orange.com] Sent: Thursday, June 19, 2014 9:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal Hi everyone, Sorry, I couldn't make it in time for the IRC meeting. Just saw in the logs: 15:19:12 are orange folks here? they might want to introduce their bgp speaker. The best intro to BaGPipe BGP is the README on github: https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md Beyond just speaking the BGP protocol on the wire, BaGPipe is a an implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. It can be run as a service exposing a REST API, or a library inside an agent; it handles the lifecylcle of VRFs and port attached/detached from them and appropriately circulates event to/from BGP peers based on VRF import/export rules and RTC publish/subscribe semantics. It's complete enough to let us build neutron virtual networks with IP VPNs, and interconnect them with external VPNs; the parts for Opentsack integration are not on this github, I'm just mentioning this for the sake of illustrating the relative maturity. Although it does not address plain IP, this would I believe by a really easy addition to make. I'll do my best to attend next week IRC meeting, but until this, feel free to ask. We can also do a Q&A session on IRC if that sounds convenient. Best, -Thomas 2014-06-13, YAMAMOTO Takashi: an update after today's l3 meeting: here's a new version of ryu bgp api patch. http://sourceforge.net/p/ryu/mailman/message/32453021/ it has been merged to the ryu master. https://github.com/osrg/ryu.git here's formatted documentation: http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html YAMAMOTO Takashi YAMAMOTO Takashi I have seen the Ryu team is involved and responsive to the community. That goes a long way to support it as the reference implementation for BPG speaking in Neutron. Thank you for your support. I'll look forward to the API and documentation refinement Let's be sure to document any work that needs to be done so that it will support
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi, 2014-06-22, A, Keshava: I have some of the basic question about deployment model of using this BaGPipe BGP in virtual cloud network. 1. We want MPLS to start right from compute node as part Tennant traffic ? BaGPipe BGP component is indeed adapted to be run on compute nodes to encapsulate tenant traffic as MPLS traffic toward BGP IP VPNs external to the datacenter. In this case you are interconnecting each VM at once with a /32 VPNv4 route. [A] But you could use it as well on a network node to interconnect a whole virtual network with one BGP route. However doing so does not simplify deployments and requires additional care to handle redundancy. And to implement virtual networks with BaGPipe, the proposed target would be to use it on compute nodes; but in that case MPLS is not the only option, and what we currently support is VXLAN (E-VPN with a VXLAN encapsulation). 2. We want L3 VRF separation right on Compute nodes (or NN Node) ? Tenant = VRF ? Tenant span can be across multiple CN nodes, then have BGP to Full mesh with in CN ? As said in another comment, a tenant (or project depending on the terminology) is not a network construct; tenants just own networks. In [A] above, for a virtual network interconnected with a VPN, there would be one VRF on each compute node with a VM connected to this virtual network. (I'm not getting your question on having BGP as a full mesh in compute nodes) 3. How to have E-VPN connectivity mapping at NN/CN nodes ? Is there an L2 VPN psuedowire thinking from CN nodes itself ? I'm not sure I get your question. When BaGPipe BGP is used on compute nodes to build a virtual network, NN don't need to be involved. They only will be involved once a router port (on a NN) is connected to a virtual network. Note also that in E-VPN there is no notion of pseudowire; E-VPN does not involve learning on incoming (MPLS- or VXLAN-) encapsulated traffic, and forwarding tables involve dynamically adding an encap header based on a static forwarding table (rather than tunnels or pseudowires). 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ? When E-VPN is used, network traffic inside a virtual network is carried as Ethernet in VXLAN, MPLS or MPLS-over-GRE (note that today BaGPipe does not support any MPLS dataplane driver for E-VPN). When IP VPN is used (eg. between virtual networks, or to/from an external IP VPN), traffic is carried as IP traffic in MPLS or MPLS-GRE. Help me understand the deployment model for this . Hope that helps, -Thomas -Original Message- From: Thomas Morin [mailto:thomas.mo...@orange.com] Sent: Thursday, June 19, 2014 9:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal Hi everyone, Sorry, I couldn't make it in time for the IRC meeting. Just saw in the logs: 15:19:12 are orange folks here? they might want to introduce their bgp speaker. The best intro to BaGPipe BGP is the README on github: https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md Beyond just speaking the BGP protocol on the wire, BaGPipe is a an implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. It can be run as a service exposing a REST API, or a library inside an agent; it handles the lifecylcle of VRFs and port attached/detached from them and appropriately circulates event to/from BGP peers based on VRF import/export rules and RTC publish/subscribe semantics. It's complete enough to let us build neutron virtual networks with IP VPNs, and interconnect them with external VPNs; the parts for Opentsack integration are not on this github, I'm just mentioning this for the sake of illustrating the relative maturity. Although it does not address plain IP, this would I believe by a really easy addition to make. I'll do my best to attend next week IRC meeting, but until this, feel free to ask. We can also do a Q&A session on IRC if that sounds convenient. Best, -Thomas 2014-06-13, YAMAMOTO Takashi: an update after today's l3 meeting: here's a new version of ryu bgp api patch. http://sourceforge.net/p/ryu/mailman/message/32453021/ it has been merged to the ryu master. https://github.com/osrg/ryu.git here's formatted documentation: http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html YAMAMOTO Takashi YAMAMOTO Takashi I have seen the Ryu team is involved and responsive to the community. That goes a long way to support it as the reference implementation for BPG speaking in Neutron. Thank you for your support. I'll look forward to the API and documentation refinement Let's be sure to document any work that needs to be done so that it will support
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
On 21 June 2014 17:17, A, Keshava wrote: > Hi Thomas, > > This is interesting. > I have some of the basic question about deployment model of using this > BaGPipe BGP in virtual cloud network. > > 1. We want MPLS to start right from compute node as part Tennant traffic ? > 2. We want L3 VRF separation right on Compute nodes (or NN Node) ? > Tenant = VRF ? > Tenant span can be across multiple CN nodes, then have BGP to > Full mesh with in CN ? > 3. How to have E-VPN connectivity mapping at NN/CN nodes ? > Is there an L2 VPN psuedowire thinking from CN nodes itself ? > 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ?ic > Routing bp. > > When you say things like 'tenant = VRF' (and, in fact, I presume you mean 'network = VRF', since networks and tenants are two different things) then that's actually more to do with how you implement the networking overlay layer in Neutron. While interesting, and while it could potentially use a BGP speaker and VRFs to do it, it's not the same use case as advertising routes externally, or terminating an external MPLS VPN in Openstack. I could do either of those things independently of the other. Terminating VPNs requires an extension API and could potentially glue on to a current plugin (much like VPNaaS). Writing overlays is a new plugin entirely. There's a use for BGP speakers in both arenas (and additionally within the distributed virtual router, which is a third case) so perhaps we could address who's using which speaker for precisely what? -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi Thomas, This is interesting. I have some of the basic question about deployment model of using this BaGPipe BGP in virtual cloud network. 1. We want MPLS to start right from compute node as part Tennant traffic ? 2. We want L3 VRF separation right on Compute nodes (or NN Node) ? Tenant = VRF ? Tenant span can be across multiple CN nodes, then have BGP to Full mesh with in CN ? 3. How to have E-VPN connectivity mapping at NN/CN nodes ? Is there an L2 VPN psuedowire thinking from CN nodes itself ? 4. Tennant traffic is L2 or L3 or MPLS ? Where will be L2 terminated ? Help me understand the deployment model for this . -Original Message- From: Thomas Morin [mailto:thomas.mo...@orange.com] Sent: Thursday, June 19, 2014 9:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal Hi everyone, Sorry, I couldn't make it in time for the IRC meeting. Just saw in the logs: 15:19:12 are orange folks here? they might want to introduce their bgp speaker. The best intro to BaGPipe BGP is the README on github: https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md Beyond just speaking the BGP protocol on the wire, BaGPipe is a an implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. It can be run as a service exposing a REST API, or a library inside an agent; it handles the lifecylcle of VRFs and port attached/detached from them and appropriately circulates event to/from BGP peers based on VRF import/export rules and RTC publish/subscribe semantics. It's complete enough to let us build neutron virtual networks with IP VPNs, and interconnect them with external VPNs; the parts for Opentsack integration are not on this github, I'm just mentioning this for the sake of illustrating the relative maturity. Although it does not address plain IP, this would I believe by a really easy addition to make. I'll do my best to attend next week IRC meeting, but until this, feel free to ask. We can also do a Q&A session on IRC if that sounds convenient. Best, -Thomas 2014-06-13, YAMAMOTO Takashi: >> an update after today's l3 meeting: >> here's a new version of ryu bgp api patch. >> http://sourceforge.net/p/ryu/mailman/message/32453021/ > > it has been merged to the ryu master. > https://github.com/osrg/ryu.git > > here's formatted documentation: > http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html > http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html > > YAMAMOTO Takashi > >> >> YAMAMOTO Takashi >> >>> I have seen the Ryu team is involved and responsive to the community. >>> That goes a long way to support it as the reference implementation >>> for BPG speaking in Neutron. Thank you for your support. I'll look >>> forward to the API and documentation refinement >>> >>> Let's be sure to document any work that needs to be done so that it >>> will support the features we need. We can use the comparison page >>> for now [1] to gather that information (or links). If Ryu is >>> lacking in any area, it will be good to understand the timeline on >>> which the features can be delivered and stable before we make a >>> formal decision on the reference implementation. >>> >>> Carl >>> >>> [1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >>> >>> On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa wrote: >>>> After watch the documentation and the code of exabgp and Ryu, I >>>> find the Ryu speaker much more easy to integrate and pythonic than >>>> exabgp. I will use it as well as reference implementation in the Dynamic >>>> Routing bp. >>>> >>>> Regards, >>>> >>>> >>>> On 5 June 2014 18:23, Nachi Ueno wrote: >>>>> >>>>>> Yamamoto >>>>> Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. >>>>> >>>>>> Yong >>>>> Ya, we have already decided to have the driver architecture. >>>>> IMO, this discussion is for reference impl. >>>>> >>>>> 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : >>>>>> I think maybe we can device a kind of framework so that we can >>>>>> plugin different BGP speakers. >>>>>> >>>>>> >>>>>> On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi >>>>>> >>>>>> wrote: >>>>>>> >>>>>>&
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi everyone, Sorry, I couldn't make it in time for the IRC meeting. Just saw in the logs: 15:19:12 are orange folks here? they might want to introduce their bgp speaker. The best intro to BaGPipe BGP is the README on github: https://github.com/Orange-OpenSource/bagpipe-bgp/blob/master/README.md Beyond just speaking the BGP protocol on the wire, BaGPipe is a an implementation of BGP VPNs (IP VPNs and E-VPNs) including the forwarding part. It can be run as a service exposing a REST API, or a library inside an agent; it handles the lifecylcle of VRFs and port attached/detached from them and appropriately circulates event to/from BGP peers based on VRF import/export rules and RTC publish/subscribe semantics. It's complete enough to let us build neutron virtual networks with IP VPNs, and interconnect them with external VPNs; the parts for Opentsack integration are not on this github, I'm just mentioning this for the sake of illustrating the relative maturity. Although it does not address plain IP, this would I believe by a really easy addition to make. I'll do my best to attend next week IRC meeting, but until this, feel free to ask. We can also do a Q&A session on IRC if that sounds convenient. Best, -Thomas 2014-06-13, YAMAMOTO Takashi: an update after today's l3 meeting: here's a new version of ryu bgp api patch. http://sourceforge.net/p/ryu/mailman/message/32453021/ it has been merged to the ryu master. https://github.com/osrg/ryu.git here's formatted documentation: http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html YAMAMOTO Takashi YAMAMOTO Takashi I have seen the Ryu team is involved and responsive to the community. That goes a long way to support it as the reference implementation for BPG speaking in Neutron. Thank you for your support. I'll look forward to the API and documentation refinement Let's be sure to document any work that needs to be done so that it will support the features we need. We can use the comparison page for now [1] to gather that information (or links). If Ryu is lacking in any area, it will be good to understand the timeline on which the features can be delivered and stable before we make a formal decision on the reference implementation. Carl [1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa wrote: After watch the documentation and the code of exabgp and Ryu, I find the Ryu speaker much more easy to integrate and pythonic than exabgp. I will use it as well as reference implementation in the Dynamic Routing bp. Regards, On 5 June 2014 18:23, Nachi Ueno wrote: Yamamoto Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. Yong Ya, we have already decided to have the driver architecture. IMO, this discussion is for reference impl. 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : I think maybe we can device a kind of framework so that we can plugin different BGP speakers. On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi wrote: hi, ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. we (ryu team) love to hear any suggestions and/or requests. we are currently working on our bgp api refinement and documentation. hopefully they will be available early next week. for both of bgp blueprints, it would be possible, and might be desirable, to create reference implementations in python using ryu or exabgp. (i prefer ryu. :-) YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi all, We've just released our implementation of BGP VPN extensions (called 'BaGPipe'), under a opensource license : https://github.com/Orange-OpenSource/bagpipe-bgp It reuses some code from ExaBGP, but with a dedicated engine for VPN instance creation through a rest API, and a modular architecture to drive a dataplane (e.g. OpenVSwtich). It is based on an internal development we did to address IaaS/IP VPN interconnection issues; although still young the project was the basis for a few working lab prototypes. There is more info in the README. I filled-in a column for BaGPipe on the wiki page ( https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison ), to give an idea where it stands, and let people think how that could address needs in Openstack. I also added a line to specify support for Route-Target-constrained distribution of VPN routes (RFC4684), because it is a real need beyond VPNv4/v6 routes for some VPN interconnection use deployments. Best, -Thomas Nachi Ueno : > Hi folks > > ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. > Ryu is supporting it, however they have no internal api to binding > neutron network & route target. > so I think contrail is a only solution for BGPVPN implementation now. > > > > 2014-05-30 2:22 GMT-07:00 Mathieu Rohon : >> Hi, >> >> I was about mentionning ExaBGP too! can we also consider using those >> BGP speakers for BGPVPN implementation [1]. >> This would be consistent to have the same BGP speaker used for every >> BGP needs inside Neutron. >> >> [1]https://review.openstack.org/#/c/93329/ >> >> >> On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa wrote: >>> Hello Takashi, >>> >>> thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing >>> blueprint[2], I've added a new column for this speaker in the wiki page. I >>> plan to fill it soon. >>> >>> ExaBgp was our first choice because we thought that run something in library >>> mode would be much more easy to deal with (especially the exceptions and >>> corner cases) and the code would be much cleaner. But seems that Ryu BGP >>> also can fit in this requirement. And having the help from a Ryu developer >>> like you turns it into a promising candidate! >>> >>> I'll start working now in a proof of concept to run the agent with these >>> implementations and see if we need more requirements to compare between the >>> speakers. >>> >>> [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >>> [2]: https://review.openstack.org/#/c/90833/ >>> >>> Regards, >>> >>> >>> On 29 May 2014 18:42, YAMAMOTO Takashi wrote: as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if someone provides more info for other bgp speakers. YAMAMOTO Takashi > Good afternoon Neutron developers! > > There has been a discussion about dynamic routing in Neutron for the > past few weeks in the L3 subteam weekly meetings. I've submitted a review > request of the blueprint documenting the proposal of this feature: > https://review.openstack.org/#/c/90833/. If you have any feedback or > suggestions for improvement, I would love to hear your comments and > include > your thoughts in the document. > > Thank you. > > Sincerely, > Artem Dmytrenko _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
> an update after today's l3 meeting: > here's a new version of ryu bgp api patch. > http://sourceforge.net/p/ryu/mailman/message/32453021/ it has been merged to the ryu master. https://github.com/osrg/ryu.git here's formatted documentation: http://ryu.readthedocs.org/en/latest/library_bgp_speaker.html http://ryu.readthedocs.org/en/latest/library_bgp_speaker_ref.html YAMAMOTO Takashi > > YAMAMOTO Takashi > >> I have seen the Ryu team is involved and responsive to the community. >> That goes a long way to support it as the reference implementation for >> BPG speaking in Neutron. Thank you for your support. I'll look >> forward to the API and documentation refinement >> >> Let's be sure to document any work that needs to be done so that it >> will support the features we need. We can use the comparison page for >> now [1] to gather that information (or links). If Ryu is lacking in >> any area, it will be good to understand the timeline on which the >> features can be delivered and stable before we make a formal decision >> on the reference implementation. >> >> Carl >> >> [1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >> >> On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa wrote: >>> After watch the documentation and the code of exabgp and Ryu, I find the Ryu >>> speaker much more easy to integrate and pythonic than exabgp. I will use it >>> as well as reference implementation in the Dynamic Routing bp. >>> >>> Regards, >>> >>> >>> On 5 June 2014 18:23, Nachi Ueno wrote: > Yamamoto Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. >Yong Ya, we have already decided to have the driver architecture. IMO, this discussion is for reference impl. 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : > I think maybe we can device a kind of framework so that we can plugin > different BGP speakers. > > > On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi > > wrote: >> >> hi, >> >> > ExaBgp was our first choice because we thought that run something in >> > library mode would be much more easy to deal with (especially the >> > exceptions and corner cases) and the code would be much cleaner. But >> > seems >> > that Ryu BGP also can fit in this requirement. And having the help >> > from >> > a >> > Ryu developer like you turns it into a promising candidate! >> > >> > I'll start working now in a proof of concept to run the agent with >> > these >> > implementations and see if we need more requirements to compare >> > between >> > the >> > speakers. >> >> we (ryu team) love to hear any suggestions and/or requests. >> we are currently working on our bgp api refinement and documentation. >> hopefully they will be available early next week. >> >> for both of bgp blueprints, it would be possible, and might be >> desirable, >> to create reference implementations in python using ryu or exabgp. >> (i prefer ryu. :-) >> >> YAMAMOTO Takashi >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> -- >>> Jaume Devesa >>> Software Engineer at Midokura >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
an update after today's l3 meeting: here's a new version of ryu bgp api patch. http://sourceforge.net/p/ryu/mailman/message/32453021/ YAMAMOTO Takashi > I have seen the Ryu team is involved and responsive to the community. > That goes a long way to support it as the reference implementation for > BPG speaking in Neutron. Thank you for your support. I'll look > forward to the API and documentation refinement > > Let's be sure to document any work that needs to be done so that it > will support the features we need. We can use the comparison page for > now [1] to gather that information (or links). If Ryu is lacking in > any area, it will be good to understand the timeline on which the > features can be delivered and stable before we make a formal decision > on the reference implementation. > > Carl > > [1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison > > On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa wrote: >> After watch the documentation and the code of exabgp and Ryu, I find the Ryu >> speaker much more easy to integrate and pythonic than exabgp. I will use it >> as well as reference implementation in the Dynamic Routing bp. >> >> Regards, >> >> >> On 5 June 2014 18:23, Nachi Ueno wrote: >>> >>> > Yamamoto >>> Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. >>> >>> >Yong >>> Ya, we have already decided to have the driver architecture. >>> IMO, this discussion is for reference impl. >>> >>> 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : >>> > I think maybe we can device a kind of framework so that we can plugin >>> > different BGP speakers. >>> > >>> > >>> > On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi >>> > >>> > wrote: >>> >> >>> >> hi, >>> >> >>> >> > ExaBgp was our first choice because we thought that run something in >>> >> > library mode would be much more easy to deal with (especially the >>> >> > exceptions and corner cases) and the code would be much cleaner. But >>> >> > seems >>> >> > that Ryu BGP also can fit in this requirement. And having the help >>> >> > from >>> >> > a >>> >> > Ryu developer like you turns it into a promising candidate! >>> >> > >>> >> > I'll start working now in a proof of concept to run the agent with >>> >> > these >>> >> > implementations and see if we need more requirements to compare >>> >> > between >>> >> > the >>> >> > speakers. >>> >> >>> >> we (ryu team) love to hear any suggestions and/or requests. >>> >> we are currently working on our bgp api refinement and documentation. >>> >> hopefully they will be available early next week. >>> >> >>> >> for both of bgp blueprints, it would be possible, and might be >>> >> desirable, >>> >> to create reference implementations in python using ryu or exabgp. >>> >> (i prefer ryu. :-) >>> >> >>> >> YAMAMOTO Takashi >>> >> >>> >> ___ >>> >> OpenStack-dev mailing list >>> >> OpenStack-dev@lists.openstack.org >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> > ___ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Jaume Devesa >> Software Engineer at Midokura >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
I have seen the Ryu team is involved and responsive to the community. That goes a long way to support it as the reference implementation for BPG speaking in Neutron. Thank you for your support. I'll look forward to the API and documentation refinement Let's be sure to document any work that needs to be done so that it will support the features we need. We can use the comparison page for now [1] to gather that information (or links). If Ryu is lacking in any area, it will be good to understand the timeline on which the features can be delivered and stable before we make a formal decision on the reference implementation. Carl [1] https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison On Thu, Jun 5, 2014 at 10:36 AM, Jaume Devesa wrote: > After watch the documentation and the code of exabgp and Ryu, I find the Ryu > speaker much more easy to integrate and pythonic than exabgp. I will use it > as well as reference implementation in the Dynamic Routing bp. > > Regards, > > > On 5 June 2014 18:23, Nachi Ueno wrote: >> >> > Yamamoto >> Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. >> >> >Yong >> Ya, we have already decided to have the driver architecture. >> IMO, this discussion is for reference impl. >> >> 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : >> > I think maybe we can device a kind of framework so that we can plugin >> > different BGP speakers. >> > >> > >> > On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi >> > >> > wrote: >> >> >> >> hi, >> >> >> >> > ExaBgp was our first choice because we thought that run something in >> >> > library mode would be much more easy to deal with (especially the >> >> > exceptions and corner cases) and the code would be much cleaner. But >> >> > seems >> >> > that Ryu BGP also can fit in this requirement. And having the help >> >> > from >> >> > a >> >> > Ryu developer like you turns it into a promising candidate! >> >> > >> >> > I'll start working now in a proof of concept to run the agent with >> >> > these >> >> > implementations and see if we need more requirements to compare >> >> > between >> >> > the >> >> > speakers. >> >> >> >> we (ryu team) love to hear any suggestions and/or requests. >> >> we are currently working on our bgp api refinement and documentation. >> >> hopefully they will be available early next week. >> >> >> >> for both of bgp blueprints, it would be possible, and might be >> >> desirable, >> >> to create reference implementations in python using ryu or exabgp. >> >> (i prefer ryu. :-) >> >> >> >> YAMAMOTO Takashi >> >> >> >> ___ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Jaume Devesa > Software Engineer at Midokura > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
After watch the documentation and the code of *exabgp* and *Ryu*, I find the *Ryu* speaker much more easy to integrate and pythonic than *exabgp*. I will use it as well as reference implementation in the Dynamic Routing bp. Regards, On 5 June 2014 18:23, Nachi Ueno wrote: > > Yamamoto > Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. > > >Yong > Ya, we have already decided to have the driver architecture. > IMO, this discussion is for reference impl. > > 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : > > I think maybe we can device a kind of framework so that we can plugin > > different BGP speakers. > > > > > > On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi > > > wrote: > >> > >> hi, > >> > >> > ExaBgp was our first choice because we thought that run something in > >> > library mode would be much more easy to deal with (especially the > >> > exceptions and corner cases) and the code would be much cleaner. But > >> > seems > >> > that Ryu BGP also can fit in this requirement. And having the help > from > >> > a > >> > Ryu developer like you turns it into a promising candidate! > >> > > >> > I'll start working now in a proof of concept to run the agent with > these > >> > implementations and see if we need more requirements to compare > between > >> > the > >> > speakers. > >> > >> we (ryu team) love to hear any suggestions and/or requests. > >> we are currently working on our bgp api refinement and documentation. > >> hopefully they will be available early next week. > >> > >> for both of bgp blueprints, it would be possible, and might be > desirable, > >> to create reference implementations in python using ryu or exabgp. > >> (i prefer ryu. :-) > >> > >> YAMAMOTO Takashi > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
> Yamamoto Cool! OK, I'll make ryu based bgpspeaker as ref impl for my bp. >Yong Ya, we have already decided to have the driver architecture. IMO, this discussion is for reference impl. 2014-06-05 0:24 GMT-07:00 Yongsheng Gong : > I think maybe we can device a kind of framework so that we can plugin > different BGP speakers. > > > On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi > wrote: >> >> hi, >> >> > ExaBgp was our first choice because we thought that run something in >> > library mode would be much more easy to deal with (especially the >> > exceptions and corner cases) and the code would be much cleaner. But >> > seems >> > that Ryu BGP also can fit in this requirement. And having the help from >> > a >> > Ryu developer like you turns it into a promising candidate! >> > >> > I'll start working now in a proof of concept to run the agent with these >> > implementations and see if we need more requirements to compare between >> > the >> > speakers. >> >> we (ryu team) love to hear any suggestions and/or requests. >> we are currently working on our bgp api refinement and documentation. >> hopefully they will be available early next week. >> >> for both of bgp blueprints, it would be possible, and might be desirable, >> to create reference implementations in python using ryu or exabgp. >> (i prefer ryu. :-) >> >> YAMAMOTO Takashi >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
I think maybe we can device a kind of framework so that we can plugin different BGP speakers. On Thu, Jun 5, 2014 at 2:59 PM, YAMAMOTO Takashi wrote: > hi, > > > ExaBgp was our first choice because we thought that run something in > > library mode would be much more easy to deal with (especially the > > exceptions and corner cases) and the code would be much cleaner. But > seems > > that Ryu BGP also can fit in this requirement. And having the help from a > > Ryu developer like you turns it into a promising candidate! > > > > I'll start working now in a proof of concept to run the agent with these > > implementations and see if we need more requirements to compare between > the > > speakers. > > we (ryu team) love to hear any suggestions and/or requests. > we are currently working on our bgp api refinement and documentation. > hopefully they will be available early next week. > > for both of bgp blueprints, it would be possible, and might be desirable, > to create reference implementations in python using ryu or exabgp. > (i prefer ryu. :-) > > YAMAMOTO Takashi > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
hi, > ExaBgp was our first choice because we thought that run something in > library mode would be much more easy to deal with (especially the > exceptions and corner cases) and the code would be much cleaner. But seems > that Ryu BGP also can fit in this requirement. And having the help from a > Ryu developer like you turns it into a promising candidate! > > I'll start working now in a proof of concept to run the agent with these > implementations and see if we need more requirements to compare between the > speakers. we (ryu team) love to hear any suggestions and/or requests. we are currently working on our bgp api refinement and documentation. hopefully they will be available early next week. for both of bgp blueprints, it would be possible, and might be desirable, to create reference implementations in python using ryu or exabgp. (i prefer ryu. :-) YAMAMOTO Takashi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
> Hi folks > > ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. > Ryu is supporting it, however they have no internal api to binding > neutron network & route target. can you explain a little more? do you have api suggestions? YAMAMOTO Takashi > so I think contrail is a only solution for BGPVPN implementation now. > > > > 2014-05-30 2:22 GMT-07:00 Mathieu Rohon : >> Hi, >> >> I was about mentionning ExaBGP too! can we also consider using those >> BGP speakers for BGPVPN implementation [1]. >> This would be consistent to have the same BGP speaker used for every >> BGP needs inside Neutron. >> >> [1]https://review.openstack.org/#/c/93329/ >> >> >> On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa wrote: >>> Hello Takashi, >>> >>> thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing >>> blueprint[2], I've added a new column for this speaker in the wiki page. I >>> plan to fill it soon. >>> >>> ExaBgp was our first choice because we thought that run something in library >>> mode would be much more easy to deal with (especially the exceptions and >>> corner cases) and the code would be much cleaner. But seems that Ryu BGP >>> also can fit in this requirement. And having the help from a Ryu developer >>> like you turns it into a promising candidate! >>> >>> I'll start working now in a proof of concept to run the agent with these >>> implementations and see if we need more requirements to compare between the >>> speakers. >>> >>> [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >>> [2]: https://review.openstack.org/#/c/90833/ >>> >>> Regards, >>> >>> >>> On 29 May 2014 18:42, YAMAMOTO Takashi wrote: as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if someone provides more info for other bgp speakers. YAMAMOTO Takashi > Good afternoon Neutron developers! > > There has been a discussion about dynamic routing in Neutron for the > past few weeks in the L3 subteam weekly meetings. I've submitted a review > request of the blueprint documenting the proposal of this feature: > https://review.openstack.org/#/c/90833/. If you have any feedback or > suggestions for improvement, I would love to hear your comments and > include > your thoughts in the document. > > Thank you. > > Sincerely, > Artem Dmytrenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> -- >>> Jaume Devesa >>> Software Engineer at Midokura >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
I've tested exabgp against a v6 peer, and it's an independent feature, so I added that as a row separately from whether v6 advertisements work. Might be worth making the page general and adding in the vpn feature set too. On 30 May 2014 16:50, Nachi Ueno wrote: > Hi folks > > ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. > Ryu is supporting it, however they have no internal api to binding > neutron network & route target. > so I think contrail is a only solution for BGPVPN implementation now. > > > > 2014-05-30 2:22 GMT-07:00 Mathieu Rohon : > > Hi, > > > > I was about mentionning ExaBGP too! can we also consider using those > > BGP speakers for BGPVPN implementation [1]. > > This would be consistent to have the same BGP speaker used for every > > BGP needs inside Neutron. > > > > [1]https://review.openstack.org/#/c/93329/ > > > > > > On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa > wrote: > >> Hello Takashi, > >> > >> thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic > Routing > >> blueprint[2], I've added a new column for this speaker in the wiki > page. I > >> plan to fill it soon. > >> > >> ExaBgp was our first choice because we thought that run something in > library > >> mode would be much more easy to deal with (especially the exceptions and > >> corner cases) and the code would be much cleaner. But seems that Ryu BGP > >> also can fit in this requirement. And having the help from a Ryu > developer > >> like you turns it into a promising candidate! > >> > >> I'll start working now in a proof of concept to run the agent with these > >> implementations and see if we need more requirements to compare between > the > >> speakers. > >> > >> [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison > >> [2]: https://review.openstack.org/#/c/90833/ > >> > >> Regards, > >> > >> > >> On 29 May 2014 18:42, YAMAMOTO Takashi wrote: > >>> > >>> as per discussions on l3 subteem meeting today, i started > >>> a bgp speakers comparison wiki page for this bp. > >>> > >>> https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison > >>> > >>> Artem, can you add other requirements as columns? > >>> > >>> as one of ryu developers, i'm naturally biased to ryu bgp. > >>> i appreciate if someone provides more info for other bgp speakers. > >>> > >>> YAMAMOTO Takashi > >>> > >>> > Good afternoon Neutron developers! > >>> > > >>> > There has been a discussion about dynamic routing in Neutron for the > >>> > past few weeks in the L3 subteam weekly meetings. I've submitted a > review > >>> > request of the blueprint documenting the proposal of this feature: > >>> > https://review.openstack.org/#/c/90833/. If you have any feedback or > >>> > suggestions for improvement, I would love to hear your comments and > include > >>> > your thoughts in the document. > >>> > > >>> > Thank you. > >>> > > >>> > Sincerely, > >>> > Artem Dmytrenko > >>> > >>> ___ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >> -- > >> Jaume Devesa > >> Software Engineer at Midokura > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi folks ExaBGP won't suit for BGPVPN implementation because it isn't support vpnv4. Ryu is supporting it, however they have no internal api to binding neutron network & route target. so I think contrail is a only solution for BGPVPN implementation now. 2014-05-30 2:22 GMT-07:00 Mathieu Rohon : > Hi, > > I was about mentionning ExaBGP too! can we also consider using those > BGP speakers for BGPVPN implementation [1]. > This would be consistent to have the same BGP speaker used for every > BGP needs inside Neutron. > > [1]https://review.openstack.org/#/c/93329/ > > > On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa wrote: >> Hello Takashi, >> >> thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing >> blueprint[2], I've added a new column for this speaker in the wiki page. I >> plan to fill it soon. >> >> ExaBgp was our first choice because we thought that run something in library >> mode would be much more easy to deal with (especially the exceptions and >> corner cases) and the code would be much cleaner. But seems that Ryu BGP >> also can fit in this requirement. And having the help from a Ryu developer >> like you turns it into a promising candidate! >> >> I'll start working now in a proof of concept to run the agent with these >> implementations and see if we need more requirements to compare between the >> speakers. >> >> [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >> [2]: https://review.openstack.org/#/c/90833/ >> >> Regards, >> >> >> On 29 May 2014 18:42, YAMAMOTO Takashi wrote: >>> >>> as per discussions on l3 subteem meeting today, i started >>> a bgp speakers comparison wiki page for this bp. >>> >>> https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >>> >>> Artem, can you add other requirements as columns? >>> >>> as one of ryu developers, i'm naturally biased to ryu bgp. >>> i appreciate if someone provides more info for other bgp speakers. >>> >>> YAMAMOTO Takashi >>> >>> > Good afternoon Neutron developers! >>> > >>> > There has been a discussion about dynamic routing in Neutron for the >>> > past few weeks in the L3 subteam weekly meetings. I've submitted a review >>> > request of the blueprint documenting the proposal of this feature: >>> > https://review.openstack.org/#/c/90833/. If you have any feedback or >>> > suggestions for improvement, I would love to hear your comments and >>> > include >>> > your thoughts in the document. >>> > >>> > Thank you. >>> > >>> > Sincerely, >>> > Artem Dmytrenko >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Jaume Devesa >> Software Engineer at Midokura >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hi, I was about mentionning ExaBGP too! can we also consider using those BGP speakers for BGPVPN implementation [1]. This would be consistent to have the same BGP speaker used for every BGP needs inside Neutron. [1]https://review.openstack.org/#/c/93329/ On Fri, May 30, 2014 at 10:54 AM, Jaume Devesa wrote: > Hello Takashi, > > thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing > blueprint[2], I've added a new column for this speaker in the wiki page. I > plan to fill it soon. > > ExaBgp was our first choice because we thought that run something in library > mode would be much more easy to deal with (especially the exceptions and > corner cases) and the code would be much cleaner. But seems that Ryu BGP > also can fit in this requirement. And having the help from a Ryu developer > like you turns it into a promising candidate! > > I'll start working now in a proof of concept to run the agent with these > implementations and see if we need more requirements to compare between the > speakers. > > [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison > [2]: https://review.openstack.org/#/c/90833/ > > Regards, > > > On 29 May 2014 18:42, YAMAMOTO Takashi wrote: >> >> as per discussions on l3 subteem meeting today, i started >> a bgp speakers comparison wiki page for this bp. >> >> https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison >> >> Artem, can you add other requirements as columns? >> >> as one of ryu developers, i'm naturally biased to ryu bgp. >> i appreciate if someone provides more info for other bgp speakers. >> >> YAMAMOTO Takashi >> >> > Good afternoon Neutron developers! >> > >> > There has been a discussion about dynamic routing in Neutron for the >> > past few weeks in the L3 subteam weekly meetings. I've submitted a review >> > request of the blueprint documenting the proposal of this feature: >> > https://review.openstack.org/#/c/90833/. If you have any feedback or >> > suggestions for improvement, I would love to hear your comments and include >> > your thoughts in the document. >> > >> > Thank you. >> > >> > Sincerely, >> > Artem Dmytrenko >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Jaume Devesa > Software Engineer at Midokura > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
Hello Takashi, thanks for doing this! As we have proposed ExaBgp[1] in the Dynamic Routing blueprint[2], I've added a new column for this speaker in the wiki page. I plan to fill it soon. ExaBgp was our first choice because we thought that run something in library mode would be much more easy to deal with (especially the exceptions and corner cases) and the code would be much cleaner. But seems that Ryu BGP also can fit in this requirement. And having the help from a Ryu developer like you turns it into a promising candidate! I'll start working now in a proof of concept to run the agent with these implementations and see if we need more requirements to compare between the speakers. [1]: https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison [2]: https://review.openstack.org/#/c/90833/ Regards, On 29 May 2014 18:42, YAMAMOTO Takashi wrote: > as per discussions on l3 subteem meeting today, i started > a bgp speakers comparison wiki page for this bp. > > https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison > > Artem, can you add other requirements as columns? > > as one of ryu developers, i'm naturally biased to ryu bgp. > i appreciate if someone provides more info for other bgp speakers. > > YAMAMOTO Takashi > > > Good afternoon Neutron developers! > > > > There has been a discussion about dynamic routing in Neutron for the > past few weeks in the L3 subteam weekly meetings. I've submitted a review > request of the blueprint documenting the proposal of this feature: > https://review.openstack.org/#/c/90833/. If you have any feedback or > suggestions for improvement, I would love to hear your comments and include > your thoughts in the document. > > > > Thank you. > > > > Sincerely, > > Artem Dmytrenko > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Jaume Devesa Software Engineer at Midokura ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal
as per discussions on l3 subteem meeting today, i started a bgp speakers comparison wiki page for this bp. https://wiki.openstack.org/wiki/Neutron/BGPSpeakersComparison Artem, can you add other requirements as columns? as one of ryu developers, i'm naturally biased to ryu bgp. i appreciate if someone provides more info for other bgp speakers. YAMAMOTO Takashi > Good afternoon Neutron developers! > > There has been a discussion about dynamic routing in Neutron for the past few > weeks in the L3 subteam weekly meetings. I've submitted a review request of > the blueprint documenting the proposal of this feature: > https://review.openstack.org/#/c/90833/. If you have any feedback or > suggestions for improvement, I would love to hear your comments and include > your thoughts in the document. > > Thank you. > > Sincerely, > Artem Dmytrenko ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
