RFE implementation not attended, reopen if needed.

** Changed in: neutron
       Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1921461

Title:
  [RFE] Enhancement to Neutron BGPaaS to directly support Neutron
  Routers & bgp-peering from such routers over internal & external
  Neutron Networks

Status in neutron:
  Won't Fix

Bug description:
  #Problem Description

  There are good foundation APIs in Neutron BGPaaS that brought in BGP
  service functionality into Neutron through Neutron Dynamic Routing.

  However there are telco use cases which requires “multiple service-
  addresses hosted by a VNF” to be advertised via BGP Control Plane
  towards peers which are ISP-PE-Routers. These “service-addresses” are
  typically Non-Neutron-IP-Networks and/or Non-Neutron-IP-Prefixes that
  are used internally inside the VNF applications. This advertisement
  enables the ISP-PE-Routers to learn such “service-addresses hosted by
  VNF”, thus enabling L3 connectivity towards such service-endpoints-
  hosted-by-VNF from ISP networks.

  The above requires BGPaaS APIs to support BGP-Peering directly towards
  the VNFs from a Neutron Router hosting the internal-networks of the
  VNF. In addition, we also require the BGPaaS API to support BGP-
  Peering towards the ISP-PE-Routers directly over the Neutron External
  Networks.

  Both of the above are not feasible today within existing BGPaaS,  because
  a. Existing BGPaaaS supports only peering over special networks which are not 
managed via Neutron
  b. Similarly there is a non-availability of APIs to make the BGPSpeaker 
directly peer with VNFs over Neutron Internal Networks.

  There is a another use-case where we wanted to automate multiple-BGP-
  Peering towards VNFs from a given BGPSpeaker, as and when a VNF
  Cluster is scaled-out/scaled-in.  For this we will be bringing in the
  bgp-peer-group concepts and API for use with Neutron BGPaaS.

  So through Specification we wanted to address the above 3 use-cases by :
  a. Enhancing BGPaaS API support within “bgp” extension under 
neutron-dynamic-routing
  b. Enhance BGPaaS Reference implementations to support the enhanced APIs.

  #Proposed Change

  Proposal is to enhance existing BGPaaS, allow neutron router to be
  associated to a BGP Speaker and allow BGP Speaker to peer with both
  the internal-Networks and External-Networks present on that Neutron
  Router. This will be implemented using enhancements to the neutron-
  service and neutron-dynamic-routing. A BGP speaker will be associated
  to a router. BGP speaker will be running inside the L3 router
  namespace which enables access to all the neutron-router-interfaces
  i.e.. both internal/external interfaces. BGP functionality provided by
  OS-Ken will be reused to excite BGP speaker functionality to run only
  within the neutron router namespace.

  “Enhanced-L3-Plugin” will be running in Neutron-Server on controller-
  host and “Enhanced-L3-agent” on compute-host. Once router is
  associated to bgpspeaker, the ‘Enhanced BGP Service Plugin’ will
  schedule the request to create a BGPSpeaker towards
  ‘Enhanced-L3-Plugin’. ‘Enhanced-L3-Plugin’ in turn will realize the
  scheduling of the BGP Speaker towards the ‘Enhanced-L3-Agent’ that is
  already hosting the router. ‘Enhanced-L3-Agent’ realizes bgpspeaker
  inside the router-namespace and now bgpspeaker can peer with anybody
  reachable for router, through the router-interface-ip-address of
  router.​

  The proposal is to provide the below functionalities
  Use-case 1.a)
  ~~~~~~~~~~~~~
                1. Provide the ability to associate a single neutron router to 
a BGP Speaker (along with optional address-scope)
                2. Provide the ability to disassociate that single neutron 
router from a BGP Speaker
                3. Provide the ability to implicitly make a bgp-speaker 
highly-available whenever the bgp-speaker is associated with a HA capable 
neutron-router.
                4. Provide the ability for the BGP Speaker to expose the entire 
list of routes it is currently managing (be it multiple bgp-peers)

  Use-case 1.b)
  ~~~~~~~~~~~~~
                1.Provide the ability to create a BGP Peer Group with BFD & 
other parameters
                2.Provide the ability to delete a BGP Peer Group (when its not 
in use by any BGPPeer)
                3.Provide the ability to create a bgp-peer using an existing 
bgp-peeer-group
                4.Provide the ability to create BGP peers with update-source 
and next-hop-self parameters

  * Add the following new APIs to Neutron: (more details in the spec)
  PUT /v2.0/bgp-speakers/<bgp-speaker-id>/add_router
  PUT  /v2.0/bgp-speakers/<bgp-speaker-id>/remove_router
  GET /v2.0/bgp-speakers/<bgp-speaker-id>/get_routes
  POST /v2.0/bgp-peer-groups/
  DELETE /v2.0/bgp-peer-groups/<bgp-peer-group-id>

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1921461/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to     : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Reply via email to