Internet DRAFT - draft-peng-idr-bgp-metric-credit
draft-peng-idr-bgp-metric-credit
Network Shaofu. Peng
Internet-Draft Bin. Tan
Intended status: Standards Track ZTE Corporation
Expires: July 1, 2022 December 28, 2021
BGP Metric Credit Based Routing
draft-peng-idr-bgp-metric-credit-00
Abstract
This document defines an optional metric related BGP path attribute
that can be advertised with BGP intent routes, to provide more clear
intent information used for the next-hop resolution.
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 July 1, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Peng & Tan Expires July 1, 2022 [Page 1]
Internet-Draft BGP Metric Credit December 2021
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Extensions for BGP Route Metric . . . . . . . . . . . . . . . 4
2.1. Extensions for Metric Type and Metric . . . . . . . . . . 4
2.2. Extensions for Metric Credit . . . . . . . . . . . . . . 4
3. Process of Received Metric Credit . . . . . . . . . . . . . . 6
3.1. Only Total Metric Credit Provided . . . . . . . . . . . . 6
3.2. Metric Credit Piece Provided . . . . . . . . . . . . . . 7
3.3. Select Underlay Path According to Suggested Metric Credit 7
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Example of Intent with Average Metric Credit . . . . . . 8
4.2. Example of Intent with Metric Credit Piece . . . . . . . 10
4.3. Example of Intent Shared by Multiple Path . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Normative References . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
In large-scale networks across multiple domains, BGP can be used to
advertise intent route and provide end-to-end intent aware path.
According to corresponding intent information, a BGP intent route
selects the expected underlay path for the next hop resolution. The
underlay path may be an MPLS-TE tunnel, an SR policy, an IGP Flex-
algo route, or a direct link, established segment by segment based on
the same intent.
There are many methods to make BGP carry intent information during
route advertisement.
[I-D.zhou-idr-inter-domain-lcu] describe a simple method, termed
as BGP-LU color, combined with [RFC7911], to create multiple BGP-
LU color path to the same destination, using color as intent
identifier.
[I-D.kaliraj-idr-bgp-classful-transport-planes] defines new
"Classful Transport" SAFI NLRI and "Transport Class" Route Target
extended community, to advertise intent based routes with related
Transport Class identifier as intent identifier.
[I-D.dskc-bess-bgp-car] defines new "BGP CAR" SAFI NLRI that
contains a Color field as intent identifier to advertise intent
based routes.
Peng & Tan Expires July 1, 2022 [Page 2]
Internet-Draft BGP Metric Credit December 2021
[I-D.lp-lsr-bgp-algorithm] introduces Algorithm Extended Community
to advertise BGP algorithm routes, using algorithm as intent
identifier.
Once a BGP speaker received an intent route advertised from neighbor,
it will check the related intent template in local. The intent
template could be a Color template, a Flex-algorithm Definition, or
some other modules. The intent template contains a set of
constraints, such as the reserved bandwidth to be provided in the
path, the boundary minimum and maximum delay, the boundary delay
jitter, the boundary packet loss rates, including or excluding
specific nodes or links, limiting the calculation of the path in a
specific virtual network, and so on. The detailed intent information
itself are not recommended to be directly carried in the advertised
route.
On the ingress PE node in the network, a BGP intent route to the
egress PE will be selected according to the service SLA. The intent
template configured on the ingress PE node is generally consistent
with the service SLA. However this does not mean that the intent
template configured on the intermediate nodes should also be
consistent with the service SLA. For example, the SLA of the service
is to "provide a path with an upper delay boundary of 100ms from
ingress PE to egress PE". In this case, the upper delay of 100ms
refers to end-to-end delay constraint, not for each segment. A
possible method is to include different delay constraints in the
intent template configured on different BGP speakers along the path.
However, this static configuration method has shortcomings, because
an intent template is not necessarily bound to a specific end-to-end
path and may be used for multiple paths.
It can be seen that the information contained in the intent template
is not enough to represent the complete intent. This often occurs on
cumulable metric attributes.
This document describes extensions to carry the metric credit
information in the BGP route advertisement, as a supplement to the
intent template, so that the BGP speaker receiving the BGP intent
route can establish (or select) the underlay path to the downstream
BGP speaker with more accurate intent indication.
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.
Peng & Tan Expires July 1, 2022 [Page 3]
Internet-Draft BGP Metric Credit December 2021
2. Extensions for BGP Route Metric
This section describes some extensions related to metric, so that
when BGP speaker advertise intent route to upstream neighbors, it
carries optional metric type, metric, and metric credit information.
2.1. Extensions for Metric Type and Metric
[RFC7311] defines AIGP Attribute to represent basic IGP default
metric type and its cumulative value.
[I-D.ssangli-idr-bgp-generic-metric-aigp] defines extensions to the
AIGP attribute to carry Generic Metric sub-types, to meet more metric
types, such as Min Unidirectional delay metric defined in [RFC8570],
TE Default Metric defined in [RFC5305], Bandwidth Metric defined in
[I-D.ietf-lsr-flex-algo-bw-con], etc.
This document reuse the above definitions.
2.2. Extensions for Metric Credit
A new path attribute type (TBD): METRIC-CREDIT attribute, is
introduced in this document. It is an optional non-transitive
attribute, which is used to specify end-to-end total metric credit,
estimated BGP hop counts, and metric credit piece information.
The format of attribute value is shown below.
+----------------------------------------------------+
| Count of Sources (1 octet) |
+----------------------------------------------------+
| Flags (1 octet) | <--- 1st Source
+----------------------------------------------------+
// Network Address of Source (variable) //
+----------------------------------------------------+
| Total Metric Credit for Source (4 octets) |
+----------------------------------------------------+
| Estimated BGP Hops Count for Source (1 octet) |
+----------------------------------------------------+
// Current Hop Number (1 octet) //
+----------------------------------------------------+
// Metric Credit Piece [Hops Count] (variable) //
+----------------------------------------------------+
// ... For other Sources ... // <--- 2nd Source
+----------------------------------------------------+
Figure 1: Metric Credit Path Attribute Format
Peng & Tan Expires July 1, 2022 [Page 4]
Internet-Draft BGP Metric Credit December 2021
Count of Sources (1 octet): Indicates how many sources (i.e. ingress
PE) have corresponding metric credit information.
Flags (1 octet): Currently three flags are defined.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|F|P| |
+-+-+-+-+-+-+-+-+
Figure 2
S-Flag: Source Address Flag. The Network Address of Source field
is included when S-Flag is set, and not included when unset.
F-Flag: Address Family Flag. Indicate the address family of the
Network Address of Source field. 0 for 32 bits IPv4 address, 1 for
128 bits IPv6 address.
P-Flag: Piece Flag. Indicates whether specific metric credit
piece information (Current Hop Number field and Metric Credit
Piece [] field) is included.
Network Address of Source (variable octets): Represents the IP
address of the source. When S-flag is 0, this field does not exist;
When S-flag is 1 and F-flag is 0, this field is a 32-bits IPv4
address; When S-flag is 1 and F-flag is 1, this field is a 128-bits
IPv6 address. If this field does not exist, it means that the metric
credit information is independent of the specific source. This
generally occurs in the scenario that want to control the
establishment of intent paths according to the metric credit in
coarse granularity. For example, in a small administrative domain,
when the egress PE advertise BGP intent routes to multiple ingress
PEs, only a single unified metric credit information for all source
is carried.
Total Metric Credit for Source (4 octets): Represents the total
metric credit from a specific ingress PE (or any source, when the
Network Address of Source field does not exist) to egress PE.
Estimated BGP Hops Count for Source (1 octet): Represents the
estimated number of BGP hops from a specific ingress PE (or any
source, when the Network Address of Source field does not exist) to
egress PE. Only those BGP speakers who modified BGP next hop to self
when receiving BGP intent route are counted.
Current Hop Number (1 octet): Represents the current index of the
array Metric Credit Piece[]. Note that when P-flag is 0, the
Peng & Tan Expires July 1, 2022 [Page 5]
Internet-Draft BGP Metric Credit December 2021
"Current Hop Number" and "Metric Credit Piece[]" fields do not exist.
In the BGP intent route advertisement originated from egress PE, the
initial value of Current Hop Number is 0; When the BGP intent route
advertisement received by an upstream BGP speaker and the BGP speaker
modifies the BGP next hop to self, it read the item from the array
Metric Credit Piece[] using Current Hop Number as index, to obtain
the metric credit piece that is available from the current BGP
speaker to the neighbor of the downstream BGP speaker. When the BGP
speaker continue to advertise the route to the upstream BGP speaker
neighbor and modify BGP next hop to self, it increase the Current Hop
Number by 1. Note that when using Current Hop Number as index to
read items from the array Metric Credit Piece[], it must avoid array
out of bounds.
Metric Credit Piece[] (variable octets): Is an array. The number of
items is specified by Estimated BGP Hops Count for Source. Each item
occupies 3 bytes (in microseconds) for each BGP speaker along the
intent path. There are strict restrictions on the use of Metric
Credit Piece[], i.e., BGP intent route must be advertised to a
specific ingress PE hop by hop in strict accordance with the
propagated path expected by egress PE. When an exception occurs,
e.g., a BGP speaker finds that the Current Hop Number value in the
received BGP intent route is greater than or equal to the Estimated
BGP Hops Count for Source value, then it must stop using Metric
Credit Piece[] for BGP next hop resolution.
3. Process of Received Metric Credit
When a BGP speaker receives BGP intent route with metric credit
information from neighbors, it obtains the intent identififer from
the route advertisement, looks up the intent template locally to
obtain the detailed intent information, and selects underlay path
according to the intent information.
The metric credit attribute information contained in the route
advertisement can provide a suggested metric credit value for this
BGP speaker to select underlay path destinated to the downstream
neighbor BGP speaker.
3.1. Only Total Metric Credit Provided
If the metric credit attribute only contains the total metric credit
related to the source, but does not contain the explicit metric
credit piece information, then for each source:
Let metric_residual_value = "Total Metric Credit for Source" -
"metric of AIGP Attribute"
Peng & Tan Expires July 1, 2022 [Page 6]
Internet-Draft BGP Metric Credit December 2021
Let average_metric_credit_value = "Total Metric Credit for Source"
/ "Estimated BGP Hops Count for Source"
The suggested metric credit for the current segment is the minimum
value of metric_residual_value (note: negative values need to be
excluded) and average_metric_credit_value for all sources.
3.2. Metric Credit Piece Provided
If the BGP intent route advertisement also contains explicit metric
credit piece information, then:
Let explicit_metric_credit_piece_value = Metric Credit
Piece[Current Hop Number]
The suggested metric credit for the current segment is the minimum
value of metric_residual_value (note: negative values need to be
excluded) and explicit_metric_credit_piece_value for all sources.
It is recommonded that this option is mainly used in the case that
only a single source related metric credit piece information is
included in the intent route that is advertised to a single ingress
PE. Multiple source related metric credit piece information may
bring conflicts and cause inaccurate suggested metric credit.
To include explicit BGP speaker list in the route advertisement and
specify metric credit piece for each segment, will be described in
the next version.
3.3. Select Underlay Path According to Suggested Metric Credit
The purpose of suggested metric credit is to restrict that the
cumulative metric of the resolved underlay path cannot exceed the
expected value. However, in some cases, if the BGP speaker finds
that there is no underlay path that can meet the suggested value,
this constraint can be relaxed appropriately by local policy.
For the BGP intent route installed on the received BGP speaker, the
metric value is updated to the metric of AIGP attribute plus the
cumulative metric of the underlay path for the corresponding metric
type.
4. Examples
Peng & Tan Expires July 1, 2022 [Page 7]
Internet-Draft BGP Metric Credit December 2021
4.1. Example of Intent with Average Metric Credit
As shown in Figure 3, it contains two IGP domains. BGP neighbors are
established between PE1 and ABR, ABR and PE2, to advertise BGP intent
routes. Egress PE2 advertise its loopback route, loopback-PE2, to
ABR through BGP, and carries intent identifier and metric credit
attribute.
+---------P1---------+ +---------P4---------+
/ | \ / | \
PE1---------P2----------ABR-----------P5----------PE2
\ | / \ | /
+---------P3---------+ +---------P6---------+
|<---- IGP domain 1 ---->||<---- IGP domain 2 ---->|
TE-path-11: PE1-P1-ABR TE-path-12: ABR-P4-PE2
TE-path-21: PE1-P3-ABR TE-path-22: ABR-P6-PE2
Figure 3: Inter-area Intent Routing
There are two services to communicate between ingress PE1 and egress
PE2. The intent of the first service is that the end-to-end total
delay of the transport path used shall not exceed 10ms, for the
intent of the second service, it is 100ms. Since two intent aware
paths need to be instantiated between the same source/destination for
two services, in general, two intent identifiers, intent-1000 and
intent-2000, need to be configured on the egress PE2.
The intent-1000 template may have the following configuration:
metric-type: Unidirectional Link Delay (ms)
total-metric-credit: 10 (ms)
metric-credit enabled
The intent-2000 template may have the following configuration:
metric-type: Unidirectional Link Delay (ms)
total-metric-credit: 100 (ms)
metric-credit enabled
The above intent template are also configured in other BGP speakers
(i.e., ABR and PE1). However, it should be noted that since the
Peng & Tan Expires July 1, 2022 [Page 8]
Internet-Draft BGP Metric Credit December 2021
intent template contains the metric credit enabled command, these BGP
speakers, for the matched intent routes that are not originated from
themselvs, will not select the underlay path to the downstream BGP
speaker neighbor only according to the total metric contained in the
intent template. Instead, they should obtain the suggested metric
credit from the received BGP intent route, and then select the
appropriate underlay path that meets the suggested metric credit.
The total metric credit included in the intent template is mainly
used for egress PE2 to generate metric credit information that is
encoded in the originated intent route. Other BGP speakers (non
initiator) cannot directly use it to select underlay paths.
PE2 advertises two BGP intent routes, <prefix = loopback-PE2, intent-
id = 1000> and <prefix = loopback-PE2, intent-id = 2000>, which are
advertised to ABR respectively. The BGP next hop in the advertised
route is set to PE2.
The metric related information encoded in <prefix = loopback-PE2,
intent-id = 1000> is:
metric-type: Unidirectional Link Delay
metric: assume an initial value of 0
metric-credit information:
Count of Sources: 1
S-Flag = 1, F-Flag = 0, P-Flag = 0
Network Address of Source: loopback-PE1
Total Metric Credit for Source: 10
Estimated BGP Hops Count for Source: 2
Similarly, the metric related information encoded in <prefix =
loopback-PE2, intent-id = 2000> is:
metric-type: Unidirectional Link Delay
metric: assume an initial value of 0
metric-credit information:
Count of Sources: 1
Peng & Tan Expires July 1, 2022 [Page 9]
Internet-Draft BGP Metric Credit December 2021
S-Flag = 1, F-Flag = 0, P-Flag = 0
Network Address of Source: loopback-PE1
Total Metric Credit for Source: 100
Estimated BGP Hops Count for Source: 2
After receiving the first route advetisement, ABR knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor PE2 is 5ms, i.e., the average metric credit 5, the residual
metric credit 10, taking the minimum one, then select an ultra-low
delay path not exceeding 5ms to progress PE2, assuming TE path-12 in
Figure 3.
After receiving the second route advetisement, ABR knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor PE2 is 50ms, i.e., the average metric credit 50, the
residual metric credit 100, taking the minimum one, then select a low
delay path not exceeding 50ms to progress PE2, assuming TE path-22 in
Figure 3.
ABR continues to advertise the above two BGP intent routes to the
upstream BGP speaker neighbor PE1, where the metric is accumulated by
the selected underlay path, the BGP next hop is modified to ABR, and
the metric credit information is unchanged.
After receiving the first route advetisement, PE1 knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor ABR is 5ms, i.e., the average metric credit 5, the residual
metric credit 6, taking the minimum one, then select an ultra-low
delay path to ABR, assuming TE path-11 in Figure 3.
After receiving the second route advetisement, PE1 knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor ABR is 50ms, i.e., the average metric credit 50, the
residual metric credit 60, taking the minimum one, then select a low
delay path to ABR, assuming TE path-12 in Figure 3.
4.2. Example of Intent with Metric Credit Piece
Based on the first example, assume that two IGP domains are managed
by a single provider, which is familiar with the performance of the
network, and the propagated path of BGP intent route is clear, then,
intent template may include explicit metric credit piece information.
Thus the intent routes originated from PE2 will contain more
information related with metric credit piece.
Peng & Tan Expires July 1, 2022 [Page 10]
Internet-Draft BGP Metric Credit December 2021
The metric related information encoded in <prefix = loopback-PE2,
intent-id = 1000> is:
metric-type: Unidirectional Link Delay
metric: assume an initial value of 0
metric-credit information:
Count of Sources: 1
S-Flag = 1, F-Flag = 0, P-Flag = 1
Network Address of Source: loopback-PE1
Total Metric Credit for Source: 10
Estimated BGP Hops Count for Source: 2
Current Hop Number: 0
Metric Credit Piece [2]: [0] = 4, [1] = 6
Similarly, the metric related information encoded in <prefix =
loopback-PE2, intent-id = 2000> is:
metric-type: Unidirectional Link Delay
metric: assume an initial value of 0
metric-credit information:
Count of Sources: 1
S-Flag = 1, F-Flag = 0, P-Flag = 1
Network Address of Source: loopback-PE1
Total Metric Credit for Source: 100
Estimated BGP Hops Count for Source: 2
Current Hop Number: 0
Metric Credit Piece [2]: [0] = 40, [1] = 60
After receiving the first route advetisement, ABR knows that the
suggested metric credit from itself to the downstream BGP speaker
Peng & Tan Expires July 1, 2022 [Page 11]
Internet-Draft BGP Metric Credit December 2021
neighbor ABR is 4ms, i.e., the explicit metric credit piece 4, the
residual metric credit 10, taking the minimum one, then select an
ultra-low delay path to PE2, assuming TE path-12 in Figure 3.
After receiving the second route advetisement, ABR knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor ABR is 40ms, i.e., the explicit metric credit piece 40, the
residual metric credit 100, taking the minimum one, then select a low
delay path to PE2, assuming TE path-22 in Figure 3.
ABR continues to advertise the above two BGP intent routes to the
upstream BGP speaker neighbor PE1, where the metric is accumulated by
the selected underlay path, the BGP next hop is modified to ABR, and
the Current Hop Number is incremented by 1.
After receiving the first route advetisement, PE1 knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor ABR is 6ms, i.e., the explicit metric credit piece 6, the
residual metric credit 6, taking the minimum one, then select an
ultra-low delay path to ABR, assuming TE path-11 in Figure 3.
After receiving the second route advetisement, PE1 knows that the
suggested metric credit from itself to the downstream BGP speaker
neighbor ABR is 60ms, i.e., the explicit metric credit piece 60, the
residual metric credit 60, taking the minimum one, then select a low
delay path to ABR, assuming TE path-12 in Figure 3.
4.3. Example of Intent Shared by Multiple Path
As shown in Figure 4, it contains three AS. BGP neighbors are
established between PE1 and ASBR1, ASBR1 and ASBR2, ASBR1 and ASBR3,
ASBR2 and PE2, ASBR3 and PE3, to advertise BGP intent routes carrying
intent identifier and metric credit attribute.
Peng & Tan Expires July 1, 2022 [Page 12]
Internet-Draft BGP Metric Credit December 2021
+---------P1---------+ +--------P4---------+
/ | \ / | \
PE1---------P2----------ASBR1---ASBR2---------P5----------PE2
\ | / \ \ | /
+---------P3---------+ \ +--------P6---------+
\
\
\ +---------P7---------+
\ / | \
+--ASBR3-------P8----------PE3
\ | /
+---------P9---------+
TE-path-11:PE1-P1-ASBR1 TE-path-12:ASBR1-ASBR2 TE-path-13: ASBR2-P4-PE2
TE-path-21:PE1-P3-ASBR1 TE-path-22:ASBR1-ASBR3 TE-path-23: ASBR3-P7-PE3
Figure 4: Inter-AS Intent Routing
In this example, the same type of service needs to communicate
between PE1 and PE2, PE1 and pE3. The intent of this type of service
is the specific value related to the end-to-end total delay and
distance of the transport path used.
PE2 and pE3 will respectively config the intent templates with the
same intent identifier, e.g., intent-1000.
The intent-1000 template configured on PE2 have the following
configuration:
metric-type: Unidirectional Link Delay (ms)
total-metric-credit: 200 (ms)
metric-credit enabled
The intent-1000 template also configured on PE3 have the following
configuration:
metric-type: Unidirectional Link Delay (ms)
total-metric-credit: 300 (ms)
metric-credit enabled
PE2 advertises BGP intent route, <prefix = loopback-PE2, intent-id =
1000>, which is advertised to ASBR2. The metric related information
encoded is:
metric-type: Unidirectional Link Delay
Peng & Tan Expires July 1, 2022 [Page 13]
Internet-Draft BGP Metric Credit December 2021
metric: assume an initial value of 0
metric-credit information:
Count of Sources: 1
S-Flag = 1, F-Flag = 0, P-Flag = 0
Network Address of Source: loopback-PE1
Total Metric Credit for Source: 200
Estimated BGP Hops Count for Source: 3
Similarly, PE3 advertises BGP intent route, <prefix = loopback-PE3,
intent-id = 1000>, which is advertised to ASBR3. The metric related
information encoded is:
metric-type: Unidirectional Link Delay
metric: assume an initial value of 0
metric-credit information:
Count of Sources: 1
S-Flag = 1, F-Flag = 0, P-Flag = 0
Network Address of Source: loopback-PE1
Total Metric Credit for Source: 300
Estimated BGP Hops Count for Source: 3
Then, ASBR2 and ASBR3 will use the suggested metric credit 66 and
100, taking minimum value from residual metric credit and average
metric credit, to select the transport path for <prefix = loopback-
PE2, intent-id = 1000> and <prefix = loopback-PE3, intent-id = 1000>
respectively, assuming TE path-13 with cumulated metric 60 and TE
path-23 with cumulated metric 100 in Figure 4.
Similarly, ASBR1 will also use suggested metric credit 66 and 100, to
select the transport path for <prefix = loopback-PE2, intent-id =
1000> and <prefix = loopback-PE3, intent-id = 1000> respectively,
assuming TE path-12 with cumulated metric 10 and TE path-22 with
cumulated metric 10 in Figure 4.
Peng & Tan Expires July 1, 2022 [Page 14]
Internet-Draft BGP Metric Credit December 2021
Similarly, PE1 will also use suggested metric credit 66 and 100, to
select the transport path for <prefix = loopback-PE2, intent-id =
1000> and <prefix = loopback-PE3, intent-id = 1000> respectively,
assuming TE path-11 with cumulated metric 60 and TE path-21 with
cumulated metric 100 in Figure 4.
5. IANA Considerations
This document request the METRIC_CREDIT entry to the "BGP Path
Attributes" registry:
+=======+=========================+================+
| Value | Code | Reference |
+=======+=========================+================+
| TBD | METRIC_CREDIT | This Document |
+-------+-------------------------+----------------+
6. Security Considerations
TBD
7. Acknowledgements
TBD
8. Normative References
[I-D.dskc-bess-bgp-car]
Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K.,
Steinberg, D., Jalil, L., Su, Y., Decraene, B., Guichard,
J., Patel, K., and H. Wang, "BGP Color-Aware Routing
(CAR)", draft-dskc-bess-bgp-car-03 (work in progress),
October 2021.
[I-D.ietf-lsr-flex-algo-bw-con]
Hegde, S., J, W. B. A., Shetty, R., Decraene, B., Psenak,
P., and T. Li, "Flexible Algorithms: Bandwidth, Delay,
Metrics and Constraints", draft-ietf-lsr-flex-algo-bw-
con-01 (work in progress), July 2021.
[I-D.kaliraj-idr-bgp-classful-transport-planes]
Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D.
J. Gowda, "BGP Classful Transport Planes", draft-kaliraj-
idr-bgp-classful-transport-planes-12 (work in progress),
August 2021.
Peng & Tan Expires July 1, 2022 [Page 15]
Internet-Draft BGP Metric Credit December 2021
[I-D.lp-lsr-bgp-algorithm]
Yao, L. and P. Shaofu, "Advertisement of Algorithm in
BGP", draft-lp-lsr-bgp-algorithm-00 (work in progress),
March 2021.
[I-D.ssangli-idr-bgp-generic-metric-aigp]
Sangli, S., Hegde, S., Das, R., and B. Decraene, "Generic
Metric for the AIGP attribute", draft-ssangli-idr-bgp-
generic-metric-aigp-01 (work in progress), July 2021.
[I-D.zhou-idr-inter-domain-lcu]
Chen, R., Dai, C., and S. Peng, "Inter-domain Network
Slicing via BGP-LU", draft-zhou-idr-inter-domain-lcu-02
(work in progress), January 2021.
[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>.
[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>.
[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
DOI 10.17487/RFC7311, August 2014,
<https://www.rfc-editor.org/info/rfc7311>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>.
[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>.
[RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
2019, <https://www.rfc-editor.org/info/rfc8570>.
Authors' Addresses
Peng & Tan Expires July 1, 2022 [Page 16]
Internet-Draft BGP Metric Credit December 2021
Shaofu Peng
ZTE Corporation
China
Email: peng.shaofu@zte.com.cn
Bin Tan
ZTE Corporation
China
Email: tan.bin@zte.com.cn
Peng & Tan Expires July 1, 2022 [Page 17]