Internet-Draft Egress Peer Engineering using BGP-LU October 2024
Gredler, et al. Expires 17 April 2025 [Page]
Workgroup:
Inter-Domain Routing
Internet-Draft:
draft-gredler-idr-bgplu-epe-16
Published:
Intended Status:
Informational
Expires:
Authors:
H. Gredler, Ed.
RtBrick Inc.
K. Vairavakkalai, Ed.
Juniper Networks, Inc.
C. Ramachandran
Juniper Networks, Inc.
B. Rajagopalan
Juniper Networks, Inc.
E. Aries
Juniper Networks, Inc.
L. Fang
eBay

Egress Peer Engineering using BGP-LU

Abstract

The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

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 17 April 2025.

▲

Table of Contents

1. Introduction

Today, BGP-LU [RFC3107] is used both as an intra-AS [SEAMLESS-MPLS] and inter-AS routing protocol. BGP-LU may advertise a MPLS transport path between IGP regions and Autonomous Systems. Those paths may span one or more router hops. This document describes advertisement and use of one-hop MPLS label-switched paths (LSPs) for traffic-engineering the links between Autonomous Systems.

Consider Figure 1: an ASBR router (R2) advertises a labeled host route for the remote-end IP address of its link (IP3). The BGP next-hop gets set to R2s loopback IP address. For the advertised Label <N> a forwarding action of 'POP and forward' to next-hop (IP3) is installed in R2's MPLS forwarding table. Now consider if R2 had several links and R2 would advertise labels for all of its inter-AS links. By pushing the corresponding MPLS label <N> on the label-stack an ingress router R1 may control the egress peer selection.

          AS1           :        AS2
                        :
+----+   iBGP   +----+  :  eBGP   +----+
| R1 |----------| R2 |-IP2----IP3-| R3 |
+----+          +----+  :         +----+
                        :
   -----------traffic-flow---------->
   <------------route-flow-----------
Figure 1: single-hop LSPs

Of course, since R1 and R2 may not be directly connected to each other, if the interior routers within AS1 do not maintain routes to external destinations, carrying traffic to such destinations would require a tunnel from R1 to R2. Such tunnel could be realized as either a MPLS Label Switched Path (LSP), or by GRE [RFC2784].

2. Motivation, Rationale and Applicability

BGP-LU is often just seen as a 'stitching' protocol for connecting Autonomous Systems. BGP-LU is often not viewed as a viable protocol for solving the Inter-domain traffic-engineering problem.

With this document the authors want to clarify the use of BGP-LU for Egress Peering traffic-engineering purposes and encourage both implementers and network operators to use a widely deployed and operationally well understood protocol, rather than inventing new protocols or new extensions to the existing protocols.

3. Sample Topology

The following topology (Figure 2) and IP addresses shall be used throughout the Egress Peering Engineering advertisement examples.

                                 :                  :
           AS 1                  :        AS 2      :     AS 4
                                 :                  :
                                 :      +-----+     :
                           /IP2--:-IP3--|ASBR3|     :
+-----+             +-----+-IP4--:-IP5--+-----+-----------+-----+
| R1  +-------------+ASBR1|      :                        |ASBR6|
+--+--+             +--+--+-IP6--:-IP7--+-----+-----------+-----+
   |                   |   \     :      |ASBR4|     :    /
   |                   |    \    :      +-----+     :   /
   |                   |     IP8-                    ---
   |                   |         \ ................ /
   |                   |          IP9-           ---
   |                   |         :    \         /   :
   |                   |         :     \       /    :
+--+--+             +--+--+      :      +--+--+     :
| R2  +-------------+ASBR2|-IP10-:-IP11-|ASBR5|     :
+-----+             +-----+      :      +-----+     :
                                 :                  :
                                 :        AS3       :
                                 :                  :
Figure 2: Sample Topology

3.1. Loopback IP addresses and Router-IDs

4. Service Route Advertisement

In Figure 3 a simple network layout is shown. There are two classes of BGP speakers:

  1. Ingress Routers

  2. Controllers

Ingress routers receive BGP-LU routes from the ASBRs. Each BGP-LU route corresponds to an egress link. Furthermore Ingress routers receive their service routes using the BGP protocol. The BGP Add-paths extension [RFC7911] ensures that multiple paths to a given service route may get advertised.

As outlined in [RFC9087], Controllers receive BGP-LU routes from the ASBRs as well. However the service routes may be received either using the BGP protocol plus the BGP Add-paths extension [RFC7911] or alternatively The BGP Monitoring protocol [RFC7854] (BMP). BMP has support for advertising the RIB-In of a BGP router. As such it might be a suitable protocol for feeding all potential egress paths of a service-route from a ASBR into a controller.

5. Egress Next-hop Advertisement

An ASBR assigns a distinct label for each of its next-hops facing an eBGP peer and advertises it to its internal BGP mesh. The ASBR programs a forwarding action 'POP and forward' into the MPLS forwarding table. Note that the neighboring AS is not required to support exchanging NLRIs with the local AS using BGP-LU. It is the local ASBR (ASBR{1,2}) which generates the BGP-LU routes into its iBGP mesh or controller facing session(s). The forwarding next-hop for those routes points to the link-IP addresses of the remote ASBRs (ASBR{3,4,5}). Note that the generated BGP-LU routes always match the BGP next-hop that the remote ASBRs set their BGP service routes to, such that the software component doing route-resolution understands the association between the BGP service route and the BGP-LU forwarding route.

5.1. iBGP meshing and BGP nexthop rewrite policy

Throughout this document we describe how the BGP next-hop of both BGP Service Routes and BGP-LU routes shall be rewritten. This may clash with existing network deployments and existing network configurations guidelines which may mandate to rewrite the BGP next-hop when an BGP update enters an AS.

The Egress peering use case assumes a central controller as shown Figure 3. In order to support both existing BGP nexthop guidelines and the suggestion described in this document, an implementation SHOULD support several internal BGP peer-groups:

  1. iBGP peer group for Ingress Routers

  2. iBGP peer group for Controllers

The first peer group MAY be left unchanged and use any existing BGP nexthop rewrite policy. The second peer group MUST use the BGP rewrite policy described in this document for both service and BGP-LU routes.

Of course a common iBGP peer group and a common rewrite policy may be used if the proposed policy is compatible with existing routing software implementations of BGP next-hop route resolution.

+-----------+
| Ingress   |
|  Router   |
+-----------+
     ^
     |
+-----------+
|    BGP    |               +------------+
|   Route   |-------------->| Controller |
| Reflector |               +------------+
+-----------+                     ^
     ^   ^                        |
     |   |                        |
     |   +-------------------+    |
     |                       |    |
     v                       v    v
+-----------+             +-----------+
|    BGP    |             |    BGP    |
|   ASBR1   |    . . .    |   ASBR2   |
+-----------+             +-----------+
Figure 3: Selective iBGP NH rewrite

5.2. Single-hop eBGP

In Figure 2 the ASBR{1,5} and ASBR{2,5} links are examples for single-hop eBGP advertisements.

5.3. Multi-hop eBGP

Todays operational practice for load-sharing across parallel links is to configure a single multi-hop eBGP session between a pair of routers. The IP addresses for the Multi-hop eBGP session are typically sourced from the loopback IP interfaces. Note that those IP addresses do not share an IP subnet. Most often those loopback IP addresses are most specific host routes. Since the BGP next-hops of the received BGP service routes are typically rewritten to the remote routers loopback IP address they cannot get immediatly resolved by the receiving router. To overcome this, the operator configures a static route with next-hops pointing to each of the remote-IP addresses of the underlying links.

In Figure 2 both ASBR{1,3} links are examples of a multi-hop eBGP advertisement. In order to advertise a distinct label for a common FEC throughout the iBGP mesh, ASBR1 and all the receiving iBGP routers need to support the BGP Add-paths extension. [RFC7911].

5.4. Grouping of Peers

In addition to offering a distinct BGP-LU label for each egress link, an ASBR MAY want to advertise a BGP-LU label which represents a load-balancing forwarding action across a set of peers. The difference is here that the ingress node gives up individual link control, but rather delegates the load-balancing decision to a particular egress router which has the freedom to send the traffic down to any link in the Peer Set as identified by the BGP-LU label.

Assume that ASBR1 wants to advertise a label identifying the Peer Set {ASBR3, ASBR4, ASBR5}.

Finally ASBR1 programs a MPLS forwarding state of 'POP and load-balance' to {203.0.113.3, 203.0.113.5, 203.0.113.7, 203.0.113.9} for the advertised label 104.

It is desirable to provide a local-repair based protection scheme, in case a redundant path is available to reach a peer AS. Protection may be applied at multiple levels in the routing stack. Since the ASBR has insight into both BGP-LU and BGP service advertisements, protection can be provided at the BGP-LU, at the BGP service or both levels.

6.1. FRR backup routes

Assume the network operator wants to provide a local-repair next-hop for the 172.16/12 BGP service route at ASBR1. The active route resolves over the parallel links towards ASBR3. In case the link #1 between ASBR{1,3} fails there are now several candidate backup paths providing protection against link or node failure.

Assuming that the remaining link #2 between ASBR{1,3} has enough capacity, and link-protection is sufficient, this link MAY serve as temporary backup.

However if node-protection or additional capacity is desired, then the local link between ASBR{1,4} or ASBR{1,5} MAY be used as temporary backup.

6.1.2. Remote BGP-LU labels

ASBR1 is both originator and receiver of BGP routing information. For this protection method it is required that the ASBRs support the [ADV-BEST-EXTERNAL] behavior. ASBR1 receives both the BGP-LU and BGP service routes from ASBR2 and therefore can use the ASBR2 advertised label as a backup path given that ASBR1 has a tunnel towards ASBR2.

6.1.3. Local IP forwarding tables

For protecting plain unicast (Internet) routing information a very simple backup scheme could be to recurse to the relevant IP forwarding table and do an IP lookup to further determine a new egress link.

For a software component which controls the egress link selection it may be desirable to know about a particular egress links current utilization, such that it can adjust the traffic that gets sent to a particular interface.

In [LINK-BW] a community for reporting link-bandwidth is specified. Rather than reporting the static bandwidth of the link, the ASBRs shall report the available bandwidth as seen by the data-plane via the link-bandwidth community in their BGP-LU update message.

It is crucial that ingress routers learn quickly about congestion of an egress link and hence it is desired to get timely updates of the advertised per-link BGP-LU routes carrying the available bandwidth information when the available bandwidth crosses a certain (preconfigured) threshold.

Controllers may also utilize the link-bandwidth community among other common mechanisms to retrieve data-plane statistics (e.g. SNMP, NETCONF)

8. Acknowledgements

Many thanks to Yakov Rekhter, Chris Bowers and Jeffrey (Zhaohui) Zhang for their detailed review and insightful comments.

Special thanks to Richard Steenbergen and Tom Scholl who brought up the original idea of using MPLS for BGP based egress load-balancing at their inspiring talk at Nanog 48.

9. IANA Considerations

This documents does not request any action from IANA.

10. Security Considerations

This document does not introduce any change in terms of BGP security.

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2784]
Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, , <https://www.rfc-editor.org/info/rfc2784>.
[RFC3107]
Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, DOI 10.17487/RFC3107, , <https://www.rfc-editor.org/info/rfc3107>.
[RFC7854]
Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, , <https://www.rfc-editor.org/info/rfc7854>.
[RFC7911]
Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, , <https://www.rfc-editor.org/info/rfc7911>.
[RFC9087]
Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, , <https://www.rfc-editor.org/info/rfc9087>.

11.2. Informative References

[ADV-BEST-EXTERNAL]
Marques, Ed., "Advertise Best External", , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-best-external-05>.
Mohapatra, Ed. and Fernando, Ed., "Link Bandwidth", , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07>.
[SEAMLESS-MPLS]
Leymann, Ed. and Konstantynowicz, Ed., "Seamless MPLS Architecture", , <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07>.

Authors' Addresses

Hannes Gredler (editor)
RtBrick Inc.
Kaliraj Vairavakkalai (editor)
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Chandra Ramachandran
Juniper Networks, Inc.
Electra, Exora Business Park Marathahalli - Sarjapur Outer Ring Road
Bangalore 560103
KA
India
Balaji Rajagopalan
Juniper Networks, Inc.
Electra, Exora Business Park Marathahalli - Sarjapur Outer Ring Road
Bangalore 560103
KA
India
Ebben Aries
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
United States of America
Luyuan Fang
eBay
411 108th Ave NE
Bellevue, WA 98004
United States of America