Egress Peer Engineering using BGP-LUJuniper Networks, Inc.1194 N. Mathilda Ave.SunnyvaleCA94089UShannes@juniper.netJuniper Networks, Inc.1194 N. Mathilda Ave.SunnyvaleCA94089USkaliraj@juniper.netJuniper Networks, Inc.Electra, Exora Business Park Marathahalli - Sarjapur Outer Ring RoadBangaloreKA560103Indiacsekar@juniper.netJuniper Networks, Inc.Electra, Exora Business Park Marathahalli - Sarjapur Outer Ring RoadBangaloreKA560103Indiabalajir@juniper.netMicrosoft5600 148th Ave NERedmondWA98052USlufang@microsoft.com
Routing
Inter-Domain RoutingMPLSBGPLabel advertisementEgress Peer EngineeringTraffic Engineering
The MPLS source routing paradigm provides path control
for both intra- and inter- Autonomous System (AS) traffic.
For Intra-AS path control, protocols like
RSVP-TE and
CR-LDP are utilized.
This documents outlines how MPLS routers
may use the BGP labeled unicast protocol (BGP-LU)
for doing traffic-engineering on inter-AS links.
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.
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.
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 traffic-engineering purposes and encourage
both implementers and network operator to use a widely deployed and
operationally well understood protocol,
rather than inventing and deploying new protocols.
The following topology
and IP addresses shall be used throughout
the Egress Peering Engineering advertisement examples.
R1: 192.168.1.1R2: 192.168.1.2ASBR1: 192.168.1.11ASBR2: 192.168.1.12ASBR3: 192.168.1.13ASBR4: 192.168.1.14ASBR5: 192.168.1.15ASBR5: 192.168.1.15ASBR1 to ASBR3 link #1: 10.0.0.1, 10.0.0.2ASBR1 to ASBR3 link #2: 10.0.0.3, 10.0.0.4ASBR1 to ASBR4 link: 10.0.0.5, 10.0.0.6ASBR1 to ASBR5 link: 10.0.0.7, 10.0.0.8ASBR2 to ASBR5 link: 10.0.0.9, 10.0.0.10An ASBR assigns for each of its egress links facing a BGP
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 NRLIs using BGP-LU.
It is the local ASBR (ASBR{1,2})
which generates the BGP-LU routes. 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}
over a single-hop eBGP session 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.
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.
For link #1, ASBR1 advertises 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 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 high frequency updates of the
advertised per-link BGP-LU labels.
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.