Internet DRAFT - draft-szarecki-teas-bw-aware-bypass-no-reservation
draft-szarecki-teas-bw-aware-bypass-no-reservation
Traffic Engineering Architecture and Signaling R.J. Szarecki
Internet-Draft J. Mitchell
Intended status: Informational Google LLC
Expires: 26 July 2024 23 January 2024
MPLS FRR bypass path calculation with bandwidth awareness without
reservation
draft-szarecki-teas-bw-aware-bypass-no-reservation-00
Abstract
RFC4090 documents facility backup FRR in MPLS-TE networks. This
document describes methods that allow the Point of Local Repair (PLR)
to find a path with sufficient available bandwidth to accommodate
protected traffic, while not making undesired reservations that would
require additional capacity. Below aspects are covered:
* Automatic determination of bypass required bandwidth by the PLR
* Calculation of path based on this information using constrained
shortest path algorithm (CSPF)
* Determination of RSVP SENDER-TSPEC rate value for bypass tunnel
signaling
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 July 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Szarecki & Mitchell Expires 26 July 2024 [Page 1]
Internet-Draft bw-aware-bypass-no-reservation January 2024
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Finding of bypass required bandwidth . . . . . . . . . . . . 3
2.1. Static Protected Bandwidth . . . . . . . . . . . . . . . 3
2.2. Dynamically Computed Protected Bandwidth . . . . . . . . 4
2.3. Hybrid Approach . . . . . . . . . . . . . . . . . . . . . 4
3. Bypass path computation . . . . . . . . . . . . . . . . . . . 5
4. Bypass tunnel signaling . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Network operators use MPLS-TE technology, as described in [RFC3209],
to optimize network resources (bandwidth over network graph) while
providing prioritized treatment - high bandwidth and low loss. This
is often done by combination of bandwidth reservation for LSPs and
protection (of some more critical) of them by facility backup
[RFC4090] technique. The facility backup technique uses a pre-
signaled bypass tunnel (instantiated as MPLS LSP) to temporally carry
impacted LSP around a faulty resource, such as a link or node,
immediately after failure. In many networks, operators have not
configured the LSPs to have bandwidth protection desired, and
therefore the bypass tunnels are provisioned without any matching
bandwidth reservation constraint, to prevent the booking of bandwidth
for these tunnels which only carry traffic briefly during failure
events until global convergence. Without a bandwidth reservation
constraint that matches the protected LSPs required bandwidth, the
bypass tunnels are typically routed on the shortest path between the
Point of Local Repair (PLR) and Merge Point (MP) based on a CSPF
satisfying any other constraints such as shared risk link groups
Szarecki & Mitchell Expires 26 July 2024 [Page 2]
Internet-Draft bw-aware-bypass-no-reservation January 2024
(SRLG). This practice has the limitation that the bypass tunnel
could be routed over interfaces that have available bandwidth much
lower than protected resource's reservations. This limitation is
specifically common in networks that utilize IGP metric values based
on distance or latency rather than bandwidth. Such networks may have
a large difference between the highest and lowest capacity of
adjacencies between various locations.
This document provides procedures that the headend routing node of
the bypass tunnel (PLR) can utilize to optimize bypass tunnel path
computation, so it is routed over links in a network that are more
likely to have sufficient available bandwidth, while still not
utilizing bandwidth reservations. Procedures described are local to
PLR, hence do not impose any special requirements on other nodes in
the network, and could be deployed incrementally. These procedures
could be deployed whether bypass tunnel's Merge Point (MP) is
explicitly provisioned via local configuration or when the PLR
automatically determines the necessary MP form Traffic Engineering
Database (TED) and inspection of RRO of protected LSPs.
1.1. Requirements Language
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.
2. Finding of bypass required bandwidth
In order for the PLR to perform bypass path computation that has
sufficient available bandwidth, the volume of traffic expected to be
protected by a given bypass tunnel needs to be determined even if it
will not be utilized in RSVP signaling. In this document the
terminology protected bandwidth (PBW) refers to this value.
2.1. Static Protected Bandwidth
The PBW for the bypass tunnel can be computed by an offline tool and
configured on the PLR either on per bypass tunnel basis, globally or
on per protected resource basis. The accuracy of utilization of this
method is limited by the offline modeling and the current network
state, so it may not be as reactive as the other approach this
document describes. The exact procedure on how the offline tool
calculates PBW is out of scope of this document.
Szarecki & Mitchell Expires 26 July 2024 [Page 3]
Internet-Draft bw-aware-bypass-no-reservation January 2024
2.2. Dynamically Computed Protected Bandwidth
Since the PLR is aware of the bandwidth reservations by the LSPs per
protected resource, such as a link or node, the PLR can compute
protected bandwidth per bypass tunnel to match the sum of these
protected LSPs bandwidth reservations, and can update the required
bandwidth utilized for CSPF on a bypass tunnel on regular intervals.
By setting the interval by which the value is reset, referred to as
the PBW timer, the operator can balance accuracy versus computational
resources and churn included by making this calculation. To reduce
the error rate from a single measurement between intervals, multiple
samples of the aggregate value of PBW can be stored and only the
largest sample over several sample periods utilized for the next PBW
timer induced CSPF.
Optionally, a percentage scaled value of the top sample could be
applied to optimize the trade off between how much of the sum of
protected LSPs bandwidth reservations the PBW should account for.
For instance, a Implementation should allow the application of a
scaling factor in the range from 0% to at least 200% of PBW to derive
the value, however the default value should be 100%.
Implementations may apply some logic to prevent negligible changes
requiring churn induced by re-routing of the tunnel by comparing the
value to be utilized versus the previous PBW timer initiated value if
that value is retained by the implementation. The periodic
computation interval is expected to be shorter or equal to
optimization timer LSPs implementing bypass tunnel.
This overall approach and implementation of this technology is
conceptually very similar to many existing vendor implementations of
the "auto-bandwidth" feature, a generalized summary of which is
described in Section 4 of [RFC8733]. Because the number of bypass
tunnels in many networks is relatively low compared to protected
LSPs, the cost of re-computation and associated churn is likely to be
relatively low in comparison to those incurred if the network
utilizes auto-bandwidth for their protected LSPs.
2.3. Hybrid Approach
The initial PBW value utilized for a bypass tunnel using this
approach even when using the dynamically computed PBW maybe incorrect
for a long period of time after initial bypass tunnel creation if the
PBW timer period is long as the number of protected LSPs over a newly
created bypass tunnel will likely rapidly increase in a number of
network events such as when new protected resource, such as a new
interface, becomes operational. Initially there will be just very
few LSP (or just one) LSP that require protection, hence PBW may be
Szarecki & Mitchell Expires 26 July 2024 [Page 4]
Internet-Draft bw-aware-bypass-no-reservation January 2024
initially very low. Implementations SHOULD allow for configuration
of minimum PBW value to be used when a bypass tunnel is initialized
and in place of the dynamically calculated PBW if the dynamically
calculated PBW is lower than the minimum PBW configured.
3. Bypass path computation
The network path for the bypass tunnel is computed using the same
logic as described in Section 6.2 of [RFC4090]. There are four
classes of events that trigger the computation of a bypass path:
1. Expiration of existing bypass lsp reoptimization timer
2. Receipt of PathErr due to network failure along existing bypass
path or failure of existing bypass egress interface on PLR
3. Initialization of new bypass tunnel
4. Change of reserved bandwidth of protected LSP or signaling of a
new LSP that is to be protected by an existing bypass tunnel
The last event can occur quite frequently, especially in networks
that utilize automatic bandwidth determination for protected LSPs
with aggressive intervals. As such, these events SHOULD NOT trigger
bypass path re-computation. This is because including these events
would lead to never converging network and adversely impact
computational resources - control plane CPU of network device.
For the events of the first three classes, the PBW value determined
as per Section 2 should be used to derive path computation bandwidth
constraints utilized by CSPF. This value together with other
constraining attributes configured, (e.g. SRLG) are used as
arguments for path computation by CSPF procedure.. The result of this
process is an ordered list of network interfaces in the form of
Explicit Route Object (ERO) for bypass tunnel, that is used for
signaling of LSP instantiating bypass tunnel.
4. Bypass tunnel signaling
Bypass tunnels are instantiated as an LSP that have head-end on PLR
and tail-end on MP. They are signaled by RSVP just like any other
MPLS LSP. Specifically PLR uses and inserts ERO objects into PATH
messages to enforce network path given bypass traverses. The other
important RSVP PATH's object is Traffic-Specification (T-SPEC), which
encodes bandwidth that needs to be reserved for signaled LSP.
Szarecki & Mitchell Expires 26 July 2024 [Page 5]
Internet-Draft bw-aware-bypass-no-reservation January 2024
Under this procedure, T-SPEC bandwidth is independent of the
bandwidth utilized by the CSPF algorithm as described in Section 2.
Since the purpose of the procedures in this document are to provide a
less likely to be congested path for the backup tunnel, the LSP
bandwidth for the bypass tunnels should be configured to a value
smaller than the value of PBW (Section 2) and value utilized for CSPF
(Section 3) procedures, otherwise reservations are more likely to
fail due to lack of available bandwidth on the computed path.
Implementation SHOULD support static configuration of signaled
bandwidth independent from the PBW, including signaled bandwidth of
zero bps value.
PLR MUST insert The ERO object in RSVP PATH. Its value MUST be the
ERO computed as per Section 3.
Note: If ERO returned by path computation described in Section 3 is
equal to network path bypass tunnel currently traverses, and the
signaled bandwidth did not changed (e.g. because it has a statically
configured value), there is no need for signaling a new LSP -
existing one can be refreshed and utilized.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
This document does not introduce new security issues. The security
considerations listed in Section 9 of [RFC4090] still remain
relevant.
7. References
7.1. Normative References
[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>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
7.2. Informative References
Szarecki & Mitchell Expires 26 July 2024 [Page 6]
Internet-Draft bw-aware-bypass-no-reservation January 2024
[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>.
[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>.
[RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and
L. Fang, "Path Computation Element Communication Protocol
(PCEP) Extensions for MPLS-TE Label Switched Path (LSP)
Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733,
DOI 10.17487/RFC8733, February 2020,
<https://www.rfc-editor.org/info/rfc8733>.
Acknowledgements
TBD
Contributors
TBD
Authors' Addresses
Rafal Jan Szarecki
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America
Email: rszarecki@gmail.com
Jon Mitchell
Google LLC
1600 Amphitheatre Parkway
Mountain View, California 94043
United States of America
Email: jrmitche@puck.nether.net
Szarecki & Mitchell Expires 26 July 2024 [Page 7]
