示例规范 - 您的 RFE 标题¶

包含您的 Launchpad RFE 的 URL

介绍段落 – 为什么要做这个功能？一段**部署者、开发者和运维人员**都能理解的散文。

您真的需要提交规范吗？大多数功能可以通过提交 RFE bug 并继续进行来完成。在大多数情况下，提交 RFE 并在 neutron 文档的 devref 文件夹中记录您的设计就足够了。如果该功能看起来非常大或存在争议，那么驱动程序团队可能会要求提供规范，或者您可以随时自行提交规范（如果需要）。

问题描述¶

问题详细描述

对于新功能，这应该是一个用例列表。确保您清楚每个用例中的参与者：最终用户与部署者。确保您确定核心的哪个区域受到影响；对于完全新的功能，应该清楚为什么您认为它应该成为核心的一部分。
对于现有功能的重大重构，需要描述该功能中正在解决的问题。

请注意，为该功能提交的 RFE 已经有了描述。本节不应简单地复制该描述；如果足够，您可以简单地引用该描述，并使用此空间来捕获基于 bug 评论或规范反馈的描述更改。

您打算如何解决这个问题？

本节是可选的，并提供了一个区域，以便在需要时与用例同时讨论您的高级设计。请注意，高级设计是指“从轨道视角”对事情将如何发生的粗略概述。

本节应从功能角度“限定”工作范围：在此更改之后，“neutron 端到端系统”将是什么样子？您打算触及哪些 Neutron 区域以及您打算如何处理它们？以下列表并非旨在成为要填写的模板，而是您提出的更改描述中需要考虑的区域的启动器。

我是否会看到新的 CLI 命令？ * OpenStack CLI 是否包含在 neutronclient 之外？
您打算如何支持或影响以下方面：* 地址管理，例如 IPv6、DHCP * 路由，例如 DVR/HA * 插件、ML2 驱动程序，例如 OVS、LinuxBridge * 代理，例如元数据 * 高级服务，例如 *-aas。 * 调度、配额和策略管理，例如管理员与用户权限 * API 和扩展 * 客户端 * 对服务或树外插件/驱动程序的影响
您打算在初始版本中不支持什么？

您不需要详细说明 API 或数据模型更改。这些级别的详细信息属于 neutron devref 文档。

请在此处添加任何有用的参考资料。您不需要有任何参考资料。此外，即使您的参考资料不可用，此规范也应仍然有意义。