IDR S. Sangli
Internet-Draft S. Hegde
Intended status: Standards Track R. Das
Expires: January 10, 2022 Juniper Networks Inc.
B. Decraene
Orange
July 09, 2021
Generic Metric for the AIGP attribute
draft-ssangli-idr-bgp-generic-metric-aigp-00
Abstract
This document defines extensions to the AIGP attribute to carry
Generic Metric sub-types. This is applicable when multiple domains
exchange BGP routing information. The extension will aid in intent-
based end-to-end path selection.
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 January 10, 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
Sangli, et al. Expires January 10, 2022 [Page 1]
Internet-Draft Generic Metric for AIGP attribute July 2021
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Multiple Metric types . . . . . . . . . . . . . . . . . . . . 4
4. Generic Metric TLV . . . . . . . . . . . . . . . . . . . . . 5
5. Usage of Generic-Metric TLV . . . . . . . . . . . . . . . . . 5
6. Updates to Decision Procedure . . . . . . . . . . . . . . . . 6
7. Use-case: Different Metrics across Domains . . . . . . . . . 7
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Large Networks belonging to an enterprise may consist of nodes in the
order of thousands and may span across multiple IGP domains where
each domain can run separate IGPs or levels/areas. BGP may be used
to interconnect such IGP domains, with one or more IGP domains within
an Autonomous System. The enterprise network can have multiple
Autonomous Systems and BGP may be employed to provide connectivity
between these domains. Furthermore, BGP can be used to provide
routing over a large number of such independent administrative
domains.
The traffic types have evolved over years and operators have resorted
to defining different metric types within a IGP domain (ISIS or OSPF)
for IGP path computation. An operator may wish for intent-based end-
to-end path selection. The intent can be bandwidth or delay for
example, and need to select paths across multiple domains satisfying
the high-bandwidth or low-delay paths. The intent is expressed as
metric types and metric values. Some metrics can be assigned
administratively by an operator and they are described in the base
ISIS, OSPF specifications. Other metrics, for example, are the
Traffic Engineering Default Metric defined in [RFC5305] and
[RFC3630], Min Unidirectional delay metric defined in [RFC8570] and
[RFC7471]. There may be other metrics such as jitter, reliability,
fiscal cost, etc. that an operator may wish to express as the cost of
Sangli, et al. Expires January 10, 2022 [Page 2]
Internet-Draft Generic Metric for AIGP attribute July 2021
a link. The procedures mentioned in the above specifications
describe the IGP path computation within IGP domains.
With the advent of 5G applications and Network Slicing applications,
an operator may wish to provision end-to-end paths across multiple
domains to cater to traffic constraints. This is also known as
intent-based inter-domain routing and there are certain architectures
being developed as described in
[I-D.hegde-spring-seamless-sr-architecture] and
[I-D.dskc-bess-bgp-car-problem-statement]. The transport planes as
described in [I-D.kaliraj-idr-bgp-classful-transport-planes] and
color-based routing as described in [I-D.dskc-bess-bgp-car] describe
how end-to-end intent-based paths can be established. The proposal
described in this document can be used in conjunction with such
architectures.
When multiple domains are interconnected via BGP, protocol extensions
for advertising best-external path and/or ADDPATH as described in
[RFC7911] are employed to take advantage of network connectivity thus
providing alternate paths. The color-based routing and Transport
Plane routing proposals result in alternate paths for a reaching a
destination. During the BGP bestpath computation, the step(e) as per
section 9.1.2.2 of [RFC4271], the interior cost of a route as
determined via the IGP metric value can be used to break the tie. In
a network spanning multiple IGP domains, the AIGP TLV encoded within
the AIGP attribute described in [RFC7311] can be used to compute the
AIGP-enhanced interior cost to be used in the decision process for
selecting the bestpath as documented in section 2 of [RFC7311]. The
[RFC7311] specifies how AIGP TLV can carry the accumulated IGP metric
value.
There is a need to synchronize the metric-type values carried between
IGP and BGP in order to avoid operational overhead of translation
between them. The existing AIGP TLV carries a TLV type and metric-
value where TLV type does not map to IGP metric-types defined in the
IGP metric-type registry. Hence there is a need to provide a generic
metric template to embed the IGP metric-type values within the AIGP
attribute. This document extends the AIGP attribute for carrying
Generic-Metric TLV and the well-defined sub metric types. This
document also provides procedures for handling Generic-Metric during
the BGP bestpath computation.
2. 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
Sangli, et al. Expires January 10, 2022 [Page 3]
Internet-Draft Generic Metric for AIGP attribute July 2021
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Multiple Metric types
Consider the network as shown in Figure 1. The network has multiple
domains. Each domain runs a separate IGP instance. Within each
domain iBGP sessions are established between the PE routers. eBGP
sessions are established between the Border Routers across domains.
An operator wishes to compute end-to-end path optimized for a metric-
type delay. Each domain will be enabled to compute the IGP paths
based on metric-type delay. Such values should also be propagated to
the adjacent domains for effective end-to-end path computation.
------IBGP-----EBGP------IBGP------EBGP------IBGP-----
| | | | | |
+-------------+ +-------------+ +-------------+
| | | | | |
| ASBR1+--+ASBR2 ASBR3+--+ASBR4 |
| | . . | | . . | |
PE1+ Domain1 | . | Domain2 | . | Domain3 +PE2
| | . . | | . . | |
| ASBR5+--+ASBR6 ASBR7+--+ASBR8 |
| | | | | |
+-------------+ +-------------+ +-------------+
|----ISIS1----| |----ISIS2----| |----ISIS3----|
Figure 1: WAN Network
The AIGP TLV in the AIGP attribute as specified in [RFC7311] supports
the IGP default metric. If all domains use IGP cost as the metric,
then one can compute the end-to-end path with shortest IGP cost.
However if an operator wishes to compute the end-to-end path with
metric other than IGP cost, we need additional extensions to the AIGP
attribute for carry the metric-types and metric values.
The [I-D.ietf-lsr-flex-algo-bw-con] proposes a generic metric type
that can embed multiple metric types within it. It supports both
standard metric-types and user-defined metric-types. This document
leverages the generic-metric draft and proposes extensions to the
AIGP attribute to carry Generic Metric TLV as specified below.
Sangli, et al. Expires January 10, 2022 [Page 4]
Internet-Draft Generic Metric for AIGP attribute July 2021
4. Generic Metric TLV
This document proposes a new TLV : Generic-Metric TLV in the AIGP
attribute. This will carry the metric type and metric value used in
the network. The format is shown below.
0 1 2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | metric-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..........................
Figure 2: Generic-Metric TLV
Generic-Metric TLV Type (1 octet): Code point to be assigned by
IANA
Generic-Metric TLV Length (2 octets): 9 or more
Generic-Metric TLV Value (9 octets): 2 sub-fields as shown below:
1. metric-type (1 octet): Value from IGP metric-type registry.
2. metric-value (8 octets): Value range (0 - 0xffffffffffffffff)
5. Usage of Generic-Metric TLV
When a BGP speaker wishes to generate AIGP attribute with Generic-
Metric TLV for a prefix, it MUST perform the following procedures.
1. The procedures specified in [RFC7311] section 3.4 should be
followed that describes creation of attribute, modifications by
the originator and non-originator of the route.
2. If the difference between the new metric-value and the
advertised metric-value is less than the configured threshold, the
update MAY be suppressed. If the new metric-value is above the
configured threshold, a new BGP update containing the new metric-
value SHOULD be advertised.
3. If the domain uses a metric type other than IGP cost for the
IGP path computation, the BGP speaker MAY add Generic-Metric TLV
to the AIGP attribute before advertising to a neighboring BGP
speaker.
Sangli, et al. Expires January 10, 2022 [Page 5]
Internet-Draft Generic Metric for AIGP attribute July 2021
4. The metric-type sub-field in the Generic-Metric TLV will carry
the value indicating the type of the metric as specified in the
IGP metric-type registry.
5. The value of the metric or cost to reach the prefix being
advertised will be encoded in the metric-value sub-field. This is
the cost or the distance to the destination prefix from the
advertising BGP speaker which sets itself as the next hop as
described in section 3.4 of [RFC7311].
6. Procedures for defining the cost to reach a next hop for
various metric-types is outside the scope of this document.
When a BGP speaker wishes to send a BGP update attaching the AIGP
attribute, it must validate if that session has been enabled for
sending the AIGP attribute as per procedures mentioned in [RFC7311].
When a BGP speaker receives a BGP update that has the AIGP attribute
with Generic-Metric TLV it MUST perform the following procedures.
1. It must validate if that session has been enabled to receive
the AIGP attribute as per rules mentioned in [RFC7311].
2. If the BGP speaker does not recognize the Generic-Metric TLV
or type of metric encoded in metric-type subfield of the TLV, then
the BGP speaker will ignore the Generic-Metric TLV and follow the
BGP decision procedure as specified in [RFC7311].
3. If the metric-type matches with the type of the metric
configured on the router, then the metric-value sub-field MUST be
used in the AIGP-enhanced interior cost computation as specified
in the next section.
4. If the metric-type does not match with the type of the metric
configured on the router, then the BGP speaker may translate cost
encoded in the metric-value field for computing the AIGP-enhanced
interior cost specified in [RFC7311]. A policy may be used to
provide the metric translation.
6. Updates to Decision Procedure
When a route has the AIGP attribute with Generic-Metric TLV and the
metric-type sub-field matches with the type of the metric used in the
current domain, the AIGP-enhanced interior cost should be computed as
below.
Let A be the value of the value of the metric-value sub-field of
the Generic-Metric TLV.
Sangli, et al. Expires January 10, 2022 [Page 6]
Internet-Draft Generic Metric for AIGP attribute July 2021
Let m be the cost to reach the next hop that IGP uses for its path
computation as described in [RFC7311].
The AIGP-enhanced interior cost will be A+m as described in
[RFC7311].
If the type of the metric used in the domain does not match the
metric-type sub-field of the Generic-Metric TLV, the metric-value may
be translated to the type of the metric used in the domain. The
translated metric value can be zero.
The translated metric value MUST be used in the AIGP-enhanced
interior cost computation which will be used in the decision process
as described in [RFC7311].
7. Use-case: Different Metrics across Domains
+--------------+
| Domain2 |
| |
......+ASBR21 ASBR22+....
. | | .
+------------+ . | igp-metric | . +--------------+
| Domain1 | . +--------------+ . | Domain4 |
| | . . | |
| ASBR11+.. ..+ASBR41 |
+PE1 | | PE2+
| ASBR12+.. ..+ASBR42 |
| | . . | |
| IGP-metric | . . | delay-metric |
+------------+ . +--------------+ . +--------------+
. | Domain3 | .
. | | .
......+ASBR31 ASBR32+....
| |
| delay-metric |
+--------------+
Figure 3: Different metric across network
Each domain is a separate Autonomous System. Within each domain,
ASBR and PE form iBGP peering. The IGP within each domain uses
domain specific metric. Domain3 and Domain4 use delay as the metric
while Domain1 and Domain2 use IGP cost as the metric. ASBRs across
domains form eBGP peering. The use-case is to find delay-based end-
to-end path from Domain1 to Domain4.
Sangli, et al. Expires January 10, 2022 [Page 7]
Internet-Draft Generic Metric for AIGP attribute July 2021
This can be achieved by the advertising router to add the AIGP
attribute with metric type 1 that represents delay metric. In the
above network diagram, ASBR41 (and ASBR42) will advertise prefix
PE2-loopback with Generic-Metric TLV with metric-type 1. The metric-
value sub-field of the Generic-Metric TLV will represent the cost to
reach PE2's loopback end-point from the advertising router as they
will do next hop self.
In Domain3, when ASRB32 advertises the prefix PE2-loopback within the
local domain, it may add cost to the metric-value, the value
representing the delay introduced by the DMZ link between ASRB32 to
ASBR42. When ASRBR31 advertises the prefix PE2-lookback, it will
perform the following procedures.
1. Compute the delay d of the path to reach ASBR32 from which it
has chosen the bestpath.
2. Add the above d value to the metric-value sub-field of the
Generic-Metric TLV.
In Domain2 however, the local metric type IGP cost. The ASBR22 may
follow the procedure similar to ASBR32 and add the delay value
corresponding to the DMZ link between ASBR22 and ASBR41 before
advertising the path internally in Domain2. When ASBR21 computes the
AIGP-enhanced interior cost, as mentioned before, it may translate
the igp cost to reach ASBR22 and may add the translated value to the
delay-metric. In the above network example, the delay cost from
ASBR21 to ASBR22 is negligible and hence delay-metric value will be
unchanged.
The procedures for AIGP-enhanced interior cost computation at ASBR11
(and ASBR12) will follow DMZ delay computation procedure described
above. PE1 will have two paths to reach PE2-loopback: P1 via ASBR11
(and domain2) and P2 via ASBR12 (and domain3), each having respective
AIGP-enhanced interior cost representing end-to-end delay. The BGP
decision process described in [RFC7311] will result in delay
optimized end-to-end path for PE2-loopback on PE1 that can be used to
resolve the service prefixes.
8. Deployment Considerations
It can be noted that a domain may translate the metric-value of the
metric-type used in the local domain to the metric-type present in
the Generic-Metric TLV. The idea is to propagate the cost of
reaching the prefix through the domain while maintaining the metric-
type chosen by the originating router and domain. The translation of
metric types to the one carried in the AIGP attribute can be done via
policy. Definition of such policies and how they can be enforced is
Sangli, et al. Expires January 10, 2022 [Page 8]
Internet-Draft Generic Metric for AIGP attribute July 2021
outside the scope of this document. In topologies where there is a
common router between adjacent domains that do iBGP peering, the
Border router can provide the translation.
All routers of a domain MUST compute the AIGP-enhanced interior cost
as described above to be used during decision process. Within a
domain, if one router R1 applies AIGP-enhanced interior cost while R2
does not, it may lead to routing loop unless some sort of tunnelling
technology viz MPLS, SRv6, IP, etc. is adopted to reach the next hop.
In a network where any tunnelling technology is used, one can
incrementally deploy the Generic-Metric functionality. In a network
without any tunnelling technology, it is recommended that all routers
should support Generic-Metric based AIGP-enhanced interior cost
computation.
9. Backward Compatibility
When a BGP speaker receives an update with the AIGP attribute it may
have Generic-Metric TLV. If the BGP speaker understands the AIGP
attribute but does not understand the Generic-Metric TLV, it will
process the AIGP attribute as per [RFC7311]. However when it needs
to advertise the prefix to its peers it will pass on the AIGP
attribute with all the TLVs including the unknown Generic-Metric TLV
as per [RFC7311]. If a BGP speaker does not understand the Generic-
Metric TLV, it may chose sub-optimal BGP path.
10. Security Considerations
This document does not introduce any new security considerations
beyond those already specified in [RFC4271], [RFC7311].
11. IANA Considerations
IANA is requested to assign a code point for Generic Metric TLV. The
metric-type field refers to the IGP metric-type registry defined in
[I-D.ietf-lsr-flex-algo-bw-con]
12. Acknowledgements
The authors would like to thank John Scudder and Jeff Haas for
careful review and suggestions.
13. References
Sangli, et al. Expires January 10, 2022 [Page 9]
Internet-Draft Generic Metric for AIGP attribute July 2021
13.1. Normative References
[I-D.dskc-bess-bgp-car]
Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K.,
Steinberg, D., Jalil, L., Su, Y., Guichard, J., Patel, K.,
and H. Wang, "BGP Color-Aware Routing (CAR)", draft-dskc-
bess-bgp-car-02 (work in progress), May 2021.
[I-D.dskc-bess-bgp-car-problem-statement]
Rao, D., Agrawal, S., Filsfils, C., Talaulikar, K.,
Decraene, B., Steinberg, D., Jalil, L., Guichard, J.,
Patel, K., and W. Henderickx, "BGP Color-Aware Routing
Problem Statement", draft-dskc-bess-bgp-car-problem-
statement-03 (work in progress), May 2021.
[I-D.hegde-spring-seamless-sr-architecture]
Hegde, S., Bowers, C., Xu, X., Gulko, A., Bogdanov, A.,
Uttaro, J., Jalil, L., Khaddam, M., and A. Alston,
"Seamless Segment Routing Architecture", draft-hegde-
spring-seamless-sr-architecture-00 (work in progress),
February 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-00 (work in progress), May 2021.
[I-D.kaliraj-idr-bgp-classful-transport-planes]
Vairavakkalai, K., Venkataraman, N., Rajagopalan, B.,
Mishra, G., Khaddam, M., Xu, X., and R. J. Szarecki, "BGP
Classful Transport Planes", draft-kaliraj-idr-bgp-
classful-transport-planes-07 (work in progress), February
2021.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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>.
Sangli, et al. Expires January 10, 2022 [Page 10]
Internet-Draft Generic Metric for AIGP attribute July 2021
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
13.2. Informative References
[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>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
"BGP-MPLS IP Virtual Private Network (VPN) Extension for
IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
<https://www.rfc-editor.org/info/rfc4659>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[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>.
[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>.
Sangli, et al. Expires January 10, 2022 [Page 11]
Internet-Draft Generic Metric for AIGP attribute July 2021
[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>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[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
Srihari Sangli
Juniper Networks Inc.
Exora Business Park
Bangalore, KA 560103
India
Email: ssangli@juniper.net
Shraddha Hegde
Juniper Networks Inc.
Exora Business Park
Bangalore, KA 560103
India
Email: shraddha@juniper.net
Reshma Das
Juniper Networks Inc.
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: dreshma@juniper.net
Bruno Decraene
Orange
France
Email: bruno.decraene@orange.com
Sangli, et al. Expires January 10, 2022 [Page 12]