Internet Engineering Task Force (IETF) H. Sitaraman, Ed.
Request for Comments: 8426 V. Beeram
Category: Informational Juniper Networks
ISSN: 2070-1721 I. Minei
Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
July 2018
Internet Engineering Task Force (IETF) H. Sitaraman, Ed.
Request for Comments: 8426 V. Beeram
Category: Informational Juniper Networks
ISSN: 2070-1721 I. Minei
Google, Inc.
S. Sivabalan
Cisco Systems, Inc.
July 2018
Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence
RSVP-TE和段路由（SR）标签交换路径（LSP）共存的建议
Abstract
摘要
Operators are looking to introduce services over Segment Routing (SR) Label Switched Paths (LSPs) in networks running Resource Reservation Protocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SR LSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network. Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE.
运营商希望在运行资源预留协议-流量工程（RSVP-TE）LSP的网络中，通过段路由（SR）标签交换路径（LSP）引入服务。在某些情况下，运营商还将现有服务从RSVP-TE迁移到SR LSP。例如，可能有某些服务非常适合SR，并且需要在同一网络中与RSVP-TE共存。根据运营商的意图，将流量引入或迁移到SR可能需要与RSVP-TE在同一网络中共存较长时间。下面的文档提供了解决方案选项，用于在整个网络中保持流量工程数据库的一致性，并说明SR和RSVP-TE之间的不同带宽利用率。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8426.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8426.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Solution Options . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Static Partitioning of Bandwidth . . . . . . . . . . . . 4
3.2. Centralized Management of Available Capacity . . . . . . 4
3.3. Flooding SR Utilization in IGP . . . . . . . . . . . . . 5
3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5
3.5. TED Consistency by Reflecting SR Traffic . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Multiplier Value Range . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Solution Options . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Static Partitioning of Bandwidth . . . . . . . . . . . . 4
3.2. Centralized Management of Available Capacity . . . . . . 4
3.3. Flooding SR Utilization in IGP . . . . . . . . . . . . . 5
3.4. Running SR over RSVP-TE . . . . . . . . . . . . . . . . . 5
3.5. TED Consistency by Reflecting SR Traffic . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Multiplier Value Range . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Introduction of SR [RFC8402] in the same network domain as RSVP-TE [RFC3209] presents the problem of accounting for SR traffic and making RSVP-TE aware of the actual available bandwidth on the network links. RSVP-TE is not aware of how much bandwidth is being consumed by SR services on the network links; hence, both at computation time (for a distributed computation) and at signaling time, RSVP-TE LSPs will incorrectly place loads. This is true where RSVP-TE paths are distributed or centrally computed without a common entity managing both SR and RSVP-TE computation for the entire network domain.
在与RSVP-TE[RFC3209]相同的网络域中引入SR[RFC8402]提出了计算SR流量并使RSVP-TE知道网络链路上实际可用带宽的问题。RSVP-TE不知道网络链路上的SR服务正在消耗多少带宽；因此，无论是在计算时（对于分布式计算）还是在信令时，RSVP-TE LSP都会错误地放置负载。如果RSVP-TE路径是分布式的或集中计算的，而没有一个公共实体管理整个网络域的SR和RSVP-TE计算，则情况就是如此。
The problem space can be generalized as a dark bandwidth problem to cases where any other service exists in the network that runs in parallel across common links and whose bandwidth is not reflected in the available and reserved values in the Traffic Engineering Database (TED). In most practical instances, given the static nature of the traffic demands, limiting the reservable bandwidth available to RSVP-TE has been an acceptable solution. However, in the case of SR traffic, there is assumed to be very dynamic traffic demands, and there is considerable risk associated with stranding capacity or overbooking service traffic resulting in traffic drops.
问题空间可概括为暗带宽问题，适用于网络中存在任何其他服务的情况，这些服务在公共链路上并行运行，其带宽未反映在流量工程数据库（TED）中的可用和保留值中。在大多数实际情况下，考虑到流量需求的静态性质，限制RSVP-TE可用的可保留带宽是一个可接受的解决方案。然而，在SR交通的情况下，假设存在非常动态的交通需求，并且存在与搁浅容量或超售服务交通相关的相当大的风险，从而导致交通量下降。
The high-level requirements to consider are:
需要考虑的高层次要求是：
1. Placement of SR LSPs in the same domain as RSVP-TE LSPs must not introduce inaccuracies in the TED used by distributed or centralized path computation engines.
1. 将SR LSP放置在与RSVP-TE LSP相同的域中，不得在分布式或集中式路径计算引擎使用的TED中引入不精确性。
2. Engines that compute RSVP-TE paths may have no knowledge of the existence of the SR paths in the same domain.
2. 计算RSVP-TE路径的引擎可能不知道同一域中是否存在SR路径。
3. Engines that compute RSVP-TE paths should not require a software upgrade or change to their path-computation logic.
3. 计算RSVP-TE路径的引擎不需要软件升级或更改其路径计算逻辑。
4. Protocol extensions should be avoided or be minimal as, in many cases, this coexistence of RSVP-TE and SR may be needed only during a transition phase.
4. 应避免协议扩展或尽量减少协议扩展，因为在许多情况下，RSVP-TE和SR的共存可能仅在过渡阶段才需要。
5. Placement of SR LSPs in the same domain as RSVP-TE LSPs that are computed in a distributed fashion must not require migration to a central controller architecture for the RSVP-TE LSPs.
5. 以分布式方式计算的SR LSP与RSVP-TE LSP在同一域中的位置不得要求迁移到RSVP-TE LSP的中央控制器体系结构。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following section lists SR and RSVP coexistence solution options. A specific solution is not recommended as all solutions are valid, even though some may not satisfy all the requirements. If a solution is acceptable for an operator based on their deployment model, then such a solution can be chosen.
以下部分列出了SR和RSVP共存解决方案选项。不建议使用特定的解决方案，因为所有解决方案都是有效的，即使某些解决方案可能不满足所有要求。如果基于部署模型的解决方案对运营商是可接受的，则可以选择这样的解决方案。
In this model, the static reservable bandwidth of an interface can be statically partitioned between SR and RSVP-TE; each one can operate within that bandwidth allocation and SHOULD NOT preempt the other.
在该模型中，可以在SR和RSVP-TE之间静态划分接口的静态可保留带宽；每一个都可以在该带宽分配内操作，并且不应该抢占另一个。
While it is possible to configure RSVP-TE to only reserve up to a certain maximum link bandwidth and manage the remaining link bandwidth for other services, this is a deployment where SR and RSVP-TE are separated in the same network (ships in the night) and can lead to suboptimal link bandwidth utilization not allowing each to consume more, if required and constraining the respective deployments.
虽然可以将RSVP-TE配置为仅保留某个最大链路带宽，并管理其他服务的剩余链路带宽，但这是一种部署，其中SR和RSVP-TE在同一网络中分开（在夜间发货），可能导致链路带宽利用率不理想，不允许各自消耗更多，如果需要并限制各自的部署。
The downside of this approach is the inability to use the reservable bandwidth effectively and the inability to use bandwidth left unused by the other protocol.
这种方法的缺点是无法有效地使用可保留带宽，也无法使用其他协议未使用的带宽。
In this model, a central controller performs path placement for both RSVP-TE and SR LSPs. The controller manages and updates its own view of the in-use and available capacity. As the controller is a single common entity managing the network it can have a unified and consistent view of the available capacity at all times.
在该模型中，中央控制器为RSVP-TE和SR LSP执行路径放置。控制器管理并更新其自己的在用和可用容量视图。由于控制器是管理网络的单一公共实体，因此它可以始终对可用容量有一个统一一致的视图。
A practical drawback of this model is that it requires the introduction of a central controller managing the RSVP-TE LSPs as a prerequisite to the deployment of any SR LSPs. Therefore, this approach is not practical for networks where distributed TE with RSVP-TE LSPs is already deployed, as it requires a redesign of the network and is not backwards compatible. This does not satisfy requirement 5.
该模型的一个实际缺点是，需要引入一个中央控制器来管理RSVP-TE LSP，作为部署任何SR LSP的先决条件。因此，这种方法不适用于已经部署了带有RSVP-TE LSP的分布式TE的网络，因为它需要重新设计网络，并且不向后兼容。这不符合要求5。
Note that it is not enough for the controller to just maintain the unified view of the available capacity, it must also perform the path computation for the RSVP-TE LSPs, as the reservations for the SR LSPs are not reflected in the TED.
请注意，控制器仅保持可用容量的统一视图是不够的，它还必须执行RSVP-TE LSP的路径计算，因为SR LSP的保留未反映在TED中。
Using techniques in [RFC7810], [RFC7471], and [RFC7823], the SR utilization information can be flooded in IGP-TE, and the RSVP-TE path computation engine (Constrained Shortest Path First (CSPF)) can be changed to consider this information. This requires changes to the RSVP-TE path computation logic and would require upgrades in deployments where distributed computation is done across the network.
使用[RCF7810]、[RCF771]和[RCF7823 ]中的技术，可以在IGP-TE中淹没SR利用信息，并且可以改变RSVP TE路径计算引擎（约束最短路径优先（CSPF））来考虑该信息。这需要更改RSVP-TE路径计算逻辑，并需要在跨网络进行分布式计算的部署中进行升级。
This does not fit with requirements 3 and 4 mentioned earlier.
这不符合前面提到的要求3和4。
SR can run over dedicated RSVP-TE LSPs that carry only SR traffic. In this model, the LSPs can be one-hop or multi-hop and can provide bandwidth reservation for the SR traffic based on functionality such as auto-bandwidth. The model of deployment would be similar in nature to running LDP over RSVP-TE. This would allow the TED to stay consistent across the network and any other RSVP-TE LSPs will also be aware of the SR traffic reservations. In this approach, non-SR traffic MUST NOT take the SR-dedicated RSVP-TE LSPs, unless required by policy.
SR可以在仅承载SR通信量的专用RSVP-TE LSP上运行。在该模型中，lsp可以是一跳或多跳，并且可以基于诸如自动带宽之类的功能为SR业务提供带宽预留。部署模型在本质上类似于在RSVP-TE上运行LDP。这将允许TED在整个网络中保持一致，并且任何其他RSVP-TE LSP也将知道SR流量预留。在此方法中，除非政策要求，否则非SR流量不得采用SR专用RSVP-TE LSP。
The drawback of this solution is that it requires SR to rely on RSVP-TE for deployment. Furthermore, the accounting accuracy/frequency of this method is dependent on performance of auto-bandwidth for RSVP-TE. Note that, for this method to work, the SR-dedicated RSVP-TE LSPs must be set up with the best setup and hold priorities in the network.
此解决方案的缺点是需要SR依赖RSVP-TE进行部署。此外，该方法的计算精度/频率取决于RSVP-TE的自动带宽性能。请注意，要使此方法起作用，SR专用RSVP-TE LSP必须在网络中以最佳设置和保持优先级进行设置。
The solution relies on dynamically measuring SR traffic utilization on each TE interface and reducing the bandwidth allowed for use by RSVP-TE. It is assumed that SR traffic receives precedence in terms of the placement on the path over RSVP traffic (that is, RSVP traffic can be preempted from the path in case of insufficient resources). This is logically equivalent to SR traffic having the best preemption priority in the network. Note that this does not necessarily mean that SR traffic has higher QoS priority; in fact, SR and RSVP traffic may be in the same QoS class.
该解决方案依赖于动态测量每个TE接口上的SR流量利用率，并减少RSVP-TE允许使用的带宽。假设SR通信在路径上的位置优先于RSVP通信（即，在资源不足的情况下，RSVP通信可以从路径中抢占）。这在逻辑上相当于网络中具有最佳抢占优先级的SR通信量。注意，这并不一定意味着SR业务具有更高的QoS优先级；事实上，SR和RSVP流量可能处于相同的QoS级别。
Reducing the bandwidth allowed for use by RSVP-TE can be explored using the three parameters available in IGP-TE ([RFC5305] [RFC3630]), namely Maximum-Link-Bandwidth, Maximum-Reservable-Bandwidth, and Unreserved-Bandwidth.
可以使用IGP-TE中可用的三个参数（[RFC5305][RFC3630]）来探索减少RSVP-TE允许使用的带宽，即最大链路带宽、最大可保留带宽和无保留带宽。
o Maximum-Link-Bandwidth: This parameter can be adjusted to accommodate the bandwidth required for SR traffic with cascading impacts on Maximum-Reservable-Bandwidth and Unreserved-Bandwidth. However, changing the maximum bandwidth for the TE link will prevent any compute engine for SR or RSVP from determining the real static bandwidth of the TE link. Further, when the Maximum-Reservable-Bandwidth is derived from the Maximum-Link-Bandwidth, its definition changes since Maximum-Link-Bandwidth will account for the SR traffic.
o 最大链路带宽：可以调整此参数以适应SR流量所需的带宽，并对最大可保留带宽和非保留带宽产生级联影响。但是，更改TE链路的最大带宽将阻止SR或RSVP的任何计算引擎确定TE链路的实际静态带宽。此外，当从最大链路带宽导出最大可保留带宽时，其定义改变，因为最大链路带宽将考虑SR业务。
o Unreserved-Bandwidth: SR traffic could directly adjust the Unreserved-Bandwidth, without impacting Maximum-Link-Bandwidth or Maximum-Reservable-Bandwidth. This model is equivalent to the option described in Section 3.4. Furthermore this would result in overloading IGP-TE advertisements to directly reflect both RSVP-TE bandwidth bookings and SR bandwidth measurements.
o 无保留带宽：SR流量可以直接调整无保留带宽，而不会影响最大链路带宽或最大可保留带宽。该模型相当于第3.4节所述的选项。此外，这将导致IGP-TE广告过载，以直接反映RSVP-TE带宽预订和SR带宽测量。
o Maximum-Reservable-Bandwidth: As the preferred option, SR traffic could adjust the Maximum-Reservable-Bandwidth, with cascading impact on the Unreserved-Bandwidth.
o 最大可保留带宽：作为首选选项，SR流量可以调整最大可保留带宽，对未保留带宽产生级联影响。
The following methodology can be used at every TE node for this solution, using the following parameters:
使用以下参数，此解决方案的每个TE节点都可以使用以下方法：
o T: Traffic statistics collection time interval.
o T：交通统计数据收集时间间隔。
o k: The number of traffic statistics samples that can provide a smoothing function to the statistics collection. The value of k is a constant integer multiplier greater or equal to 1.
o k：可以为统计收集提供平滑功能的交通统计样本数。k的值是大于或等于1的常数整数乘数。
o N: Traffic averaging calculation (adjustment) interval such that N = k * T.
o N：交通量平均计算（调整）间隔，使得N=k*T。
o Maximum-Reservable-Bandwidth: The maximum available bandwidth for RSVP-TE.
o 最大可保留带宽：RSVP-TE的最大可用带宽。
o If Diffserv-aware MPLS Traffic Engineering (DS-TE) [RFC4124] is enabled, the Maximum-Reservable-Bandwidth SHOULD be interpreted as the aggregate bandwidth constraint across all Class-Types independent of the Bandwidth Constraints model.
o 如果启用了区分服务感知MPLS流量工程（DS-TE）[RFC4124]，则最大可保留带宽应解释为所有类别类型的聚合带宽约束，与带宽约束模型无关。
o Initial Maximum-Reservable-Bandwidth: The Maximum-reservable-bandwidth for TE when no SR traffic or RSVP-TE reservations exist on the interface.
o 初始最大可保留带宽：接口上不存在SR流量或RSVP-TE保留时TE的最大可保留带宽。
o RSVP-unreserved-bandwidth-at-priority-X: Maximum-Reservable-Bandwidth - sum of (existing reservations at priority X and all priorities better than X).
o RSVP-unreserved-bandwidth-at-priority-X：最大可保留带宽-总带宽（优先级为X的现有保留和优于X的所有优先级）。
o SR traffic threshold percentage: The percentage difference of traffic demand that, when exceeded, can result in a change to the RSVP-TE Maximum-Reservable-Bandwidth.
o SR traffic threshold percentage（SR流量阈值百分比）：流量需求的百分比差异，当超过该百分比时，可能导致RSVP-TE最大可保留带宽的变化。
o IGP-TE update threshold: Specifies the frequency at which IGP-TE updates should be triggered based on TE bandwidth updates on a link.
o IGP-TE更新阈值：指定根据链路上的TE带宽更新触发IGP-TE更新的频率。
o M: An optional multiplier that can be applied to the SR traffic average. This multiplier provides the ability to grow or shrink the bandwidth used by SR. Appendix A offers further guidance on M.
o M：一个可选的乘数，可应用于SR流量平均值。该乘数提供了增加或减少SR使用的带宽的能力。附录A提供了有关M。
At every interval T, each node SHOULD collect the SR traffic statistics for each of its TE interfaces. The measured SR traffic includes all labeled SR traffic and any traffic entering the SR network over that TE interface. Further, at every interval N, given a configured SR traffic threshold percentage and a set of collected SR traffic statistics samples across the interval N, the SR traffic average (or any other traffic metric depending on the algorithm used) over this period is calculated. This method of sampling traffic statistics and adjusting bandwidth reservation accordingly is similar to how bandwidth gets adjusted for auto-bandwidth RSVP-TE LSPs.
在每个间隔T，每个节点应收集其每个TE接口的SR流量统计数据。测量的SR流量包括所有标记的SR流量以及通过该TE接口进入SR网络的任何流量。此外，在每个间隔N，给定配置的SR业务阈值百分比和跨间隔N收集的SR业务统计样本集，计算该时段的SR业务平均值（或取决于所用算法的任何其他业务度量）。这种对流量统计数据进行采样并相应调整带宽预留的方法类似于自动带宽RSVP-TE LSP的带宽调整方法。
If the difference between the new calculated SR traffic average and the current SR traffic average (that was computed in the prior adjustment) is at least SR traffic threshold percentage, then two values MUST be updated:
如果新计算的SR流量平均值与当前SR流量平均值（在先前调整中计算）之间的差值至少为SR流量阈值百分比，则必须更新两个值：
o New Maximum-Reservable-Bandwidth = Initial Maximum-Reservable-Bandwidth - (new SR traffic average * M)
o 新最大可保留带宽=初始最大可保留带宽-（新SR流量平均*M）
o New RSVP-unreserved-bandwidth-at-priority-X = New Maximum-Reservable-Bandwidth - sum of (existing reservations at priority X and all priorities better than X)
o New RSVP-unreserved-bandwidth-at-priority-X=新的最大可保留带宽-总（优先级为X的现有保留以及优于X的所有优先级）
A DS-TE LSR that advertises a Bandwidth Constraints TLV should update the bandwidth constraints for class-types based on operator policy. For example, when Russian Dolls Model (RDM) [RFC4127] is in use, then
播发带宽约束TLV的DS-TE LSR应根据操作员策略更新类类型的带宽约束。例如，当使用俄罗斯玩偶模型（RDM）[RFC4127]时
only BC0 may be updated. Whereas, when Maximum Allocation Model (MAM) [RFC4125] is in use, then all Bandwidth Constraints (BCs) may be updated equally such that the total value updated is equal to the newly calculated SR traffic average.
只能更新BC0。然而，当使用最大分配模型（MAM）[RFC4125]时，所有带宽约束（bc）可以被同等地更新，使得更新的总值等于新计算的SR业务平均值。
Note that the computation of the new RSVP-unreserved-bandwidth-at-priority-X MAY result in RSVP-TE LSPs being hard or soft preempted. Such preemption will be based on relative priority (e.g., low to high) between RSVP-TE LSPs. The IGP-TE update threshold SHOULD allow for more frequent flooding of unreserved bandwidth. From an operational point of view, an implementation SHOULD be able to expose both the configured and the actual values of the Maximum-Reservable-Bandwidth.
注意，新RSVP-unreserved-bandwidth-at-priority-X的计算可能导致RSVP-TE lsp被硬抢占或软抢占。这种抢占将基于RSVP-TE LSP之间的相对优先级（例如，从低到高）。IGP-TE更新阈值应允许更频繁的无保留带宽泛滥。从操作的角度来看，实现应该能够公开最大可保留带宽的配置值和实际值。
If LSP preemption is not acceptable, then the RSVP-TE Maximum-Reservable-Bandwidth cannot be reduced below what is currently reserved by RSVP-TE on that interface. This may result in bandwidth not being available for SR traffic. Thus, it is required that any external controller managing SR LSPs SHOULD be able to detect this situation (for example, by subscribing to TED updates [RFC7752]) and SHOULD take action to reroute existing SR paths.
如果LSP抢占不可接受，则RSVP-TE最大可保留带宽不能降低到该接口上RSVP-TE当前保留的带宽以下。这可能导致带宽不可用于SR通信。因此，要求管理SR LSP的任何外部控制器能够检测到这种情况（例如，通过订阅TED更新[RFC7752]），并采取措施重新路由现有SR路径。
Generically, SR traffic (or any non-RSVP-TE traffic) should have its own priority allocated from the available priorities. This would allow SR to preempt other traffic according to the preemption priority order.
一般来说，SR通信量（或任何非RSVP TE通信量）应该从可用优先级中分配自己的优先级。这将允许SR根据抢占优先级顺序抢占其他通信量。
In this solution, the logic to retrieve the statistics, calculating averages and taking action to change the Maximum-Reservable-Bandwidth is an implementation choice, and all changes are local in nature. However, note that this is a new network trigger for RSVP-TE preemption and thus is a consideration for the operator.
在该解决方案中，检索统计信息、计算平均值和采取措施更改最大可保留带宽的逻辑是一种实现选择，所有更改本质上都是局部的。但是，请注意，这是RSVP-TE抢占的新网络触发器，因此是运营商的考虑事项。
The above solution offers the advantage of not introducing new network-wide mechanisms especially during scenarios of migrating to SR in an existing RSVP-TE network and reusing existing protocol mechanisms.
上述解决方案的优点是不引入新的网络范围机制，特别是在现有RSVP-TE网络中迁移到SR和重用现有协议机制的情况下。
This document has no IANA actions.
本文档没有IANA操作。
This document describes solution options for the coexistence of RSVP-TE and SR LSPs in the same administrative domain. The security considerations for SR are described in [RFC8402]. The security considerations pertaining to RSVP-TE are described in [RFC5920]. The
本文档描述了RSVP-TE和SR LSP在同一管理域中共存的解决方案选项。[RFC8402]中描述了SR的安全注意事项。[RFC5920]中描述了与RSVP-TE有关的安全注意事项。这个
security considerations of each architecture are typically unaffected by the presence of the other. However, when RSVP-TE and SR LSPs coexist, it is possible for a hijacked SR traffic stream to maliciously consume sufficient bandwidth and cause disruption to RSVP-TE LSPs. With the solution option specified in Section 3.5, the impact to RSVP-TE traffic can be controlled and paths re-routed. Some latent risk of disruption still remains because this solution option relies on taking statistics samples and adopting to new traffic flows only after the adjustment period. The defensive mechanisms described in the base SR security framework should be employed to guard against situations that result in SR traffic hijacking or denial of service.
每个体系结构的安全考虑通常不受其他体系结构的影响。然而，当RSVP-TE和SR LSP共存时，被劫持的SR业务流可能恶意地消耗足够的带宽并对RSVP-TE LSP造成中断。通过第3.5节中规定的解决方案选项，可以控制对RSVP-TE流量的影响，并重新路由路径。一些潜在的中断风险仍然存在，因为此解决方案选项依赖于仅在调整期后采集统计样本并采用新的交通流。应采用基本SR安全框架中描述的防御机制来防范导致SR流量劫持或拒绝服务的情况。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<https://www.rfc-editor.org/info/rfc3209>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402]Filsfils，C.，Ed.，Previdi，S.，Ed.，Ginsberg，L.，Decarene，B.，Litkowski，S.，和R.Shakir，“段路由架构”，RFC 8402，DOI 10.17487/RFC8402，2018年7月<https://www.rfc-editor.org/info/rfc8402>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<https://www.rfc-editor.org/info/rfc3630>.
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, DOI 10.17487/RFC4124, June 2005, <https://www.rfc-editor.org/info/rfc4124>.
[RFC4124]Le Faucheur，F.，编辑，“支持区分服务感知MPLS流量工程的协议扩展”，RFC 4124DOI 10.17487/RFC4124，2005年6月<https://www.rfc-editor.org/info/rfc4124>.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4125, DOI 10.17487/RFC4125, June 2005, <https://www.rfc-editor.org/info/rfc4125>.
[RFC4125]Le Faucheur，F.和W.Lai，“区分服务感知MPLS流量工程的最大分配带宽约束模型”，RFC 4125，DOI 10.17487/RFC4125，2005年6月<https://www.rfc-editor.org/info/rfc4125>.
[RFC4127] Le Faucheur, F., Ed., "Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 4127, DOI 10.17487/RFC4127, June 2005, <https://www.rfc-editor.org/info/rfc4127>.
[RFC4127]Le Faucheur，F.，Ed.“区分服务感知MPLS流量工程的俄罗斯玩偶带宽约束模型”，RFC 4127，DOI 10.17487/RFC4127，2005年6月<https://www.rfc-editor.org/info/rfc4127>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<https://www.rfc-editor.org/info/rfc5305>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<https://www.rfc-editor.org/info/rfc5920>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471]Giacalone，S.，Ward，D.，Drake，J.，Atlas，A.，和S.Previdi，“OSPF交通工程（TE）度量扩展”，RFC 7471，DOI 10.17487/RFC7471，2015年3月<https://www.rfc-editor.org/info/rfc7471>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752]Gredler，H.，Ed.，Medved，J.，Previdi，S.，Farrel，A.，和S.Ray，“使用BGP的链路状态和流量工程（TE）信息的北向分布”，RFC 7752，DOI 10.17487/RFC7752，2016年3月<https://www.rfc-editor.org/info/rfc7752>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <https://www.rfc-editor.org/info/rfc7810>.
[RFC7810]Previdi，S.，Ed.，Giacalone，S.，Ward，D.，Drake，J.，和Q.Wu，“IS-IS交通工程（TE）度量扩展”，RFC 7810，DOI 10.17487/RFC7810，2016年5月<https://www.rfc-editor.org/info/rfc7810>.
[RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, "Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions", RFC 7823, DOI 10.17487/RFC7823, May 2016, <https://www.rfc-editor.org/info/rfc7823>.
[RFC7823]Atlas，A.，Drake，J.，Giacalone，S.，和S.Previdi，“使用TE度量扩展的显式路由标签交换路径（LSP）的基于性能的路径选择”，RFC 7823，DOI 10.17487/RFC7823，2016年5月<https://www.rfc-editor.org/info/rfc7823>.
The following is a suggestion for the range of values for M:
以下是M值范围的建议：
M is a per-node positive real number that ranges from 0 to 2 with a default of 1 and may be expressed as a percentage.
M是一个每个节点的正实数，范围从0到2，默认值为1，可以用百分比表示。
o If M < 1, then the SR traffic average is being understated, which can result in the link getting full even though Maximum-Reservable-Bandwidth does not reach zero.
o 如果M<1，则SR流量平均值被低估，这可能导致链路满，即使最大可保留带宽未达到零。
o If M > 1, then the SR traffic average is overstated, thereby resulting in the Maximum-Reservable-Bandwidth reaching zero before the link gets full. If the reduction of Maximum-Reservable-Bandwidth becomes a negative value, then a value of zero SHOULD be used and advertised.
o 如果M>1，则SR业务平均值被夸大，从而导致最大可保留带宽在链路满之前达到零。如果最大可保留带宽的减少值变为负值，则应使用并公布零值。
Acknowledgements
致谢
The authors would like to thank Steve Ulrich for his detailed review and comments.
作者要感谢Steve Ulrich的详细评论和评论。
Contributors
贡献者
Chandra Ramachandran Juniper Networks Email: csekar@juniper.net
Chandra Ramachandran Juniper Networks电子邮件：csekar@juniper.net
Raveendra Torvi Juniper Networks Email: rtorvi@juniper.net
Raveendra Torvi Juniper Networks电子邮件：rtorvi@juniper.net
Sudharsana Venkataraman Juniper Networks Email: sudharsana@juniper.net
Sudharsana Venkataraman Juniper Networks电子邮件：sudharsana@juniper.net
Martin Vigoureux Nokia Email: martin.vigoureux@nokia.com
Martin Vigoureux诺基亚电子邮件：Martin。vigoureux@nokia.com
Authors' Addresses
作者地址
Harish Sitaraman (editor) Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Harish Sitaraman（编辑）Juniper Networks 1133 Innovation Way Sunnyvale，CA 94089美利坚合众国
Email: hsitaraman@juniper.net
Email: hsitaraman@juniper.net
Vishnu Pavan Beeram Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
Vishnu Pavan Beeram Juniper Networks美国马萨诸塞州韦斯特福德科技园大道10号，邮编01886
Email: vbeeram@juniper.net
Email: vbeeram@juniper.net
Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
Email: inaminei@google.com
Email: inaminei@google.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Siva Sivabalan思科系统公司，加拿大安大略省卡纳塔创新大道2000号K2K 3E8
Email: msiva@cisco.com
Email: msiva@cisco.com