| 2021-03-26 07:02:28 |
Manu |
bug |
|
|
added bug |
| 2021-03-26 07:03:34 |
Manu |
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 2nd use-case where we wanted to improve network convergence for the BGP Control Plane and for this we would like to integrate BFD-Service for use while BGP-Peering from BGPSpeakers. For this we will take advantage of the APIs available from bfd-as-a-service initiative, and such BFD-Monitors will be used while configuring BGP-Peering for BGPSpeakers.
There is a 3rd 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 BGPSpeaker 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 configure bfd-monitoring when configuring BGP peering, to enable BFD monitoring of BGP-Peering-Link between the BGP Speaker and the BGP Peer
2.Provide the ability to unconfigure bfd-monitor from an existing BGP peering
Use-case 1.c)
~~~~~~~~~~~~~
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>
POST /v2.0/bgp-peers/
PUT /v2.0/bgp-peers/{bgp-peer-id} |
#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 2nd use-case where we wanted to improve network convergence for the BGP Control Plane and for this we would like to integrate BFD-Service for use while BGP-Peering from BGPSpeakers. For this we will take advantage of the APIs available from bfd-as-a-service initiative, and such BFD-Monitors will be used while configuring BGP-Peering for BGPSpeakers.
There is a 3rd 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 configure bfd-monitoring when configuring BGP peering, to enable BFD monitoring of BGP-Peering-Link between the BGP Speaker and the BGP Peer
2.Provide the ability to unconfigure bfd-monitor from an existing BGP peering
Use-case 1.c)
~~~~~~~~~~~~~
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>
POST /v2.0/bgp-peers/
PUT /v2.0/bgp-peers/{bgp-peer-id} |
|
| 2021-03-26 07:29:39 |
Lajos Katona |
tags |
|
rfe |
|
| 2021-03-26 07:33:26 |
Balazs Gibizer |
bug |
|
|
added subscriber Balazs Gibizer |
| 2021-03-26 09:52:38 |
Vivekanandan Narasimhan |
bug |
|
|
added subscriber Bence Romsics |
| 2021-03-26 09:53:37 |
Vivekanandan Narasimhan |
bug |
|
|
added subscriber Lajos Katona |
| 2021-03-26 09:55:31 |
Vivekanandan Narasimhan |
bug |
|
|
added subscriber Vivekanandan Narasimhan |
| 2021-04-06 11:21:10 |
Manu B |
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 2nd use-case where we wanted to improve network convergence for the BGP Control Plane and for this we would like to integrate BFD-Service for use while BGP-Peering from BGPSpeakers. For this we will take advantage of the APIs available from bfd-as-a-service initiative, and such BFD-Monitors will be used while configuring BGP-Peering for BGPSpeakers.
There is a 3rd 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 configure bfd-monitoring when configuring BGP peering, to enable BFD monitoring of BGP-Peering-Link between the BGP Speaker and the BGP Peer
2.Provide the ability to unconfigure bfd-monitor from an existing BGP peering
Use-case 1.c)
~~~~~~~~~~~~~
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>
POST /v2.0/bgp-peers/
PUT /v2.0/bgp-peers/{bgp-peer-id} |
#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> |
|
| 2021-04-08 07:30:11 |
Slawek Kaplonski |
tags |
rfe |
rfe-triaged |
|
| 2021-04-09 14:54:43 |
Slawek Kaplonski |
tags |
rfe-triaged |
rfe-approved |
|
| 2021-04-21 09:27:54 |
Manu B |
attachment added |
|
Neutron gw router support.pptx https://bugs.launchpad.net/neutron/+bug/1921461/+attachment/5490561/+files/Neutron%20gw%20router%20support.pptx |
|
| 2021-10-18 15:03:21 |
LIU Yulong |
bug |
|
|
added subscriber LIU Yulong |
| 2022-01-17 09:58:15 |
Kabanov Oleg |
bug |
|
|
added subscriber Kabanov Oleg |
| 2022-08-19 14:18:04 |
Andrew Bonney |
bug |
|
|
added subscriber Andrew Bonney |
| 2022-10-18 14:22:00 |
Rodolfo Alonso |
neutron: status |
New |
Won't Fix |
|
