[openstack-dev] [Neutron][L3] BGP Dynamic Routing Proposal

A, Keshava keshava.a at hp.com
Mon Jun 23 17:37:25 UTC 2014 

Hi,

If this BaGpipe BGP does not support MPLS data plane driver, what is advantage of this BGP from current.

What you are thinking (if I am right) is something like this below which is traditional deployment model of EVPN solution.

https://tools.ietf.org/html/draft-rabadan-l2vpn-dci-evpn-overlay-01#ref-EVPN-Overlays



[cid:image002.jpg at 01CF8F37.E2FBF4D0]

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.

If you see the current’ Mobile Backhaul solutions’ the PW will start right from the CSR (Cell Site Router)  in LTE network.

Then we can also think these  CN(or NN )  similar to CSR box so that Pseudo wire can be started right from these box ?



If we are not thinking of starting MPLS from CNs I think existing BGP (which is underway) will  be sufficient.





Thanks  & regards,

keshava





-----Original Message-----
From: Thomas Morin [mailto:tmmorin.orange at 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 .





Hope that helps,



-Thomas





> -----Original Message-----

> From: Thomas Morin [mailto:thomas.morin at 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 <yamamoto> 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 <devvesa at gmail.com<mailto:devvesa at gmail.com>> 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 <nachi at ntti3.com<mailto:nachi at ntti3.com>> 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 <gongysh at unitedstack.com<mailto:gongysh at unitedstack.com>>:

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

>>>>>>> <yamamoto at valinux.co.jp<mailto:yamamoto at valinux.co.jp>>

>>>>>>> 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-d

>>>>>>>> e

>>>>>>>> v

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>> _______________________________________________

>>>>>>> OpenStack-dev mailing list

>>>>>>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de

>>>>>>> v

>>>>>>>

>>>>>>

>>>>>> _______________________________________________

>>>>>> OpenStack-dev mailing list

>>>>>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at 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 at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>>>

>>>>

>>>> _______________________________________________

>>>> OpenStack-dev mailing list

>>>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>

>>> _______________________________________________

>>> OpenStack-dev mailing list

>>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>

>> _______________________________________________

>> OpenStack-dev mailing list

>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>

>

>

> _______________________________________________

> OpenStack-dev mailing list

> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140623/e6e8eb40/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 12103 bytes
Desc: image002.jpg
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140623/e6e8eb40/attachment.jpg>

More information about the OpenStack-dev mailing list