[RFE] metric for the route
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Opinion
|
Wishlist
|
Unassigned | ||
python-openstackclient |
Confirmed
|
Undecided
|
XU Xiaodan |
Bug Description
Problem Description
===================
A routing metric is a quantitative value used to evaluate the path cost.
But neutron can't specify a different metric with the same destination address,which is useful to realize FRR(Fast Reroute) in Telecoms and NFV scenario.
There is no optional argument for metric:
root@ubuntudbs:
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
usage: neutron router-update [-h] [--name NAME] [--description DESCRIPTION]
root@ubuntudbs:
usage: openstack router set [-h] [--name <name>] [--description <description>]
Proposal
========
A new optional argument metric can be added to set the metric for the routes.
This value can be set by the user or have a default value.
Command Line Client Impact
-------
::
openstack router set [--route destination=
neutron router-update [--route destination=CIDR,
Argument metric is optional.
REST API Impact
---------------
A new API extension to the routes resource is going to be introduced.
Set the metric for the routes :
.. code-block:: python
PUT /v2.0/routers/
Accept: application/json
{
"router": {
{
}
]
}
}
References
==========
.. [1] api-ref for the neutron router,
https:/
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
tags: | added: ap rfe |
tags: |
added: api removed: ap |
Changed in neutron: | |
status: | New → Confirmed |
Changed in neutron: | |
assignee: | nobody → zhangyanxian (zhang-yanxian) |
Changed in neutron: | |
importance: | Undecided → Wishlist |
Changed in python-openstackclient: | |
assignee: | nobody → XU Xiaodan (xiaodan) |
status: | New → Confirmed |
tags: | added: rfe-triaged |
Changed in neutron: | |
assignee: | XU Xiaodan (xiaodan) → Bin Lu (369283883-o) |
tags: | removed: rfe |
That means we may owns multiple routes with different Routers, one link down, the backup one can hold on. I think it is valid in real case, but for namespaced baesd reference implementation, it's hard to find some good usecases. Could u provider some more usecases? Do you use other L3 backend? :)