Egress Peer Engineering using BGP-LU

Today BGP-LU is used both as an intra-AS 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 (LSP) for traffic-engineering the links between Autonomous Systems. Consider Figure : 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----------- 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 Switch Path (LSP), or by GRE.

BGP-LU is often just seen as a 'stitching' protocol for connecting Autonomous Systems. BGP-LU is often not visible 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 operator to use a widely deployed and operationally well understood protocol, rather than inventing new protocols or new extensions to the existing protocols.

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

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

R1: 192.168.1.1 R2: 192.168.1.2 ASBR1: 192.168.1.11 ASBR2: 192.168.1.12 ASBR3: 192.168.1.13 ASBR4: 192.168.1.14 ASBR5: 192.168.1.15 ASBR5: 192.168.1.15

ASBR1 to ASBR3 link #1: 10.0.0.1, 10.0.0.2 ASBR1 to ASBR3 link #2: 10.0.0.3, 10.0.0.4 ASBR1 to ASBR4 link: 10.0.0.5, 10.0.0.6 ASBR1 to ASBR5 link: 10.0.0.7, 10.0.0.8 ASBR2 to ASBR5 link: 10.0.0.9, 10.0.0.10

An ASBR assigns for each of its egress links facing an eBGP peer, a distinct label 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. 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.

In the ASBR{1,5} and ASBR{2,5} links are examples for single-hop eBGP advertisements. ASBR5 advertises a BGP service (SAFI-1) route {172.16/12} to ASBR1 with a BGP next-hop of 10.0.0.8. ASBR1 re-advertises this BGP service route towards its iBGP mesh (R{1,2}) it does not overwrite the BGP next-hop, but rather leave it unchanged. ASBR1 advertises a BGP-LU route {10.0.0.8/32, label 100} with a BGP next hop of 192.168.1.11. ASBR1 programs a MPLS forwarding state of 'POP and forward' to 10.0.0.8 for the advertised label 100. ASBR5 advertises a BGP service (SAFI-1) route {172.16/12} to ASBR2 with a BGP next-hop of 10.0.0.10. ASBR2 re-advertises this BGP service route towards its iBGP mesh (R{1,2}) it does not overwrite the BGP next-hop, but rather leave it unchanged. ASBR2 advertises BGP-LU route {10.0.0.10/32, label 101} with a BGP next hop of 192.168.1.12. ASBR2 programs a MPLS forwarding state of 'POP and forward' to 10.0.0.10 for the advertised label 101. Note that in order for ASBR1 to advertise towards its | iBGP mesh multiple next hops (10.0.0.8, 10.0.0.10) for the route to 172.16/12, ASBR1 and R{1,2} have to support the BGP Add-paths extension. .

Todays operational practice for load-sharing across parallel links is to configure a single multi-hop eBGP session between a pair of routers. Since the BGP next-hops of the received BGP service routes are typically not on a common IP subnet, the operator configures a static route with next-hops pointing to each of the remote-IP addresses of the underlying links. In 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. . ASBR3 advertises a BGP service (SAFI-1) route {172.16/12} over multi-hop eBGP to ASBR1 with a BGP next-hop of 192.168.1.13. ASBR1 re-advertises this BGP service route towards its iBGP mesh (R{1,2}) it does not overwrite the BGP next-hop, but rather leave it unchanged. Note that the iBGP routers SHOULD support the BGP Add-paths extensions . such that ASBR can re-advertise all paths to the SAFI-1 route {172.16/12}. For link #1, ASBR1 advertises into its iBGP mesh a BGP-LU route {192.168.1.13/32, label 102} with a BGP next hop of 192.168.1.11. To differentiate this from the link #2 route-advertisement (which contains the same FEC) it is setting the path-ID to 1. ASBR1 programs a MPLS forwarding state of 'POP and forward' to 10.0.0.2 for the advertised label 102. For link #2, ASBR1 advertises into its iBGP mesh a BGP-LU route {192.168.1.13/32, label 103} with a BGP next hop of 192.168.1.11. To differentiate this from the link #1 route-advertisement (which contains the same FEC) it is setting the path-ID to 2. ASBR1 programs a MPLS forwarding state of 'POP and forward' to 10.0.0.4 for the advertised label 103.

In addition to offer 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 all links going to a particular Peer. For link #1 and link #2 in , ASBR1 advertises a BGP-LU route {192.168.1.13/32, label 104} with a BGP next hop of 192.168.1.11. To differentiate this from the link #1 and link #2 route-advertisements (which contains the same FEC) it is setting the path-ID to 3. ASBR1 programs a MPLS forwarding state of 'POP and load-balance' to 10.0.0.2 and 10.0.0.4 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 in both BGP-LU and BGP service advertisements, protection can be provided at the BGP-LU, at the BGP service or both levels.

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 resolve 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.

ASBR1 is both originator and receiver of BGP routing information. For this protection method it is required that the ASBRs support the 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.

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 link current utilization, such that it can adjust the traffic that gets sent to a particular interface. In 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.

Many thanks to Yakov Rekhter for his detailed review and insightful comments

This documents does not request any action from IANA.

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