]> Independent Contributor

gmalyushkin@gmail.com

Routing BGP Enabled ServiceS This document discusses the IP VPN convergence aspects and specifies procedures for IP VPN to signal the attachment circuit failure. The specified procedures help significantly improve the IP VPN convergence. About This Document Status information for this document may be found at . Discussion of this document takes place on the BGP Enabled ServiceS Working Group mailing list (), which is archived at . Subscribe at .

Introduction Neither IP VPN nor IPv6 VPN have a mass routes withdrawal mechanism. The failure of a connection to a CE forces a PE to withdraw all affected VPN routes instead of noticing other PE routers about the attachment circuit failure. These routes may be packed into one or more BGP UPDATE messages and then disseminated through the network. Depending on the BGP topology these messages may be further processed and replicated by intermediate nodes (e.g., route reflectors). In general, every affected route must be withdrawn from all interested parties. The number of failed routes impacts the convergence time. More routes require more time. A sophisticated intermediate BGP topology may also negatively affect this time. Network`s convergence speed is important. There is a potential traffic loss that lasts until the failure notification (BGP UPDATE messages) reaches other members participating in the affected VPN service (i.e., routers using the affected VPN routes for traffic forwarding). Moreover, this loss happens at the egress point where the failed CE router is connected to the network and after traffic has proceeded a whole path. There is a mechanism to avoid this traffic loss that acts while the network is converging which is named the BGP PIC edge . This mechanism depends on the availability of an extra exit point for every affected route. In case when the CE router is connected to a pair of PE routers (i.e., it is multihomed) and a link between the CE and one of these PE fails all affected traffic can be redirected by this PE toward another. On the other hand, the BGP PIC edge when it is active at egress is associated with the sub-optimal routing. Traffic from an ingress PE must follow the path toward the egress PE where the failed link with the CE is attached. Then this egress PE redirects traffic thanks to the pre-installed backup records toward another PE. Such a tromboning can negatively influence traffic characteristics (delay, loss rate, etc.). Another problem with the BGP PIC edge at egress is a possible routing loop. Suppose a CE router is connected to a pair of PE routers and contributes to them a set of routes. These PE install these routes and propagate them via internal BGP VPN sessions. Both PEs receive these routes via a PE-CE protocol and the internal BGP VPN sessions. The routes received via the internal BGP VPN sessions are used as backups for the routes received via the PE-CE protocol. When the CE fails the PE routers activate their backups sending traffic to each other until TTL reaches zero. The BGP PIC edge mechanism is a transient solution. As soon as all VPN members are notified about the unreachability of all affected VPN routes traffic will be sent to the extra exit point in an optimal way or it will be dropped at ingress. The goal of the solution described in this document is to decrease the time required by all VPN members to be aware of the failure thus reduce the time the BGP PIC edge lasts. This solution does not replace the BGP PIC edge and can be applied to networks in parallel with it. It is recommended to combine them together. Even if destinations that were advertised by a failed CE lack alternatives the time of the network reaction may be important. Imagine that the CE advertises a huge number of routes and attracts a considerable amount of traffic, but for some reason, these routes do not have an alternative exit point. Until all other members of the VPN service are aware of the failure traffic will flow through the network in vain. The solution described in this document will significantly reduce this time. This document refers to in all cases when a logic of the latter is applicable to both address families. is referred to explicitly if it introduces a new logic.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Terminoly The document uses the terminology defined in , , , and .

AC

Attachment Circuit.

GRT

Global Routing Table.

EC

BGP Extended Community .

BGP VPN route

Either a VPN-IPv4 or VPN-IPv6 route.

Abstract Next-Hop (ANH) address

An artificial IPv4 or IPv6 address in the GRT that represents an address of CE in VRF.

Linked Address (LA)

An actual IPv4 or IPv6 address of CE that is bound (linked) to ANH.

ANH proxying

A unidirectional dependency between the statuses of ANH and LA.

Solution Description Consider the topology in . CE1 and CE2 maintain external BGP sessions with PE1 for IPv4 and IPv6 unicast address families. Both CEs send routes via these sessions, which must be reachable by CE3 through the VPN service. PE1 exports routes installed into VRF1 and send them as VPN routes to PE2.

IP/MPLS network with IP VPN

shows the routes received from the CEs and installed into VRF1 by PE1 on the left and VPN routes advertised by PE1 on the right. The most interesting column here is "VPN Next-Hops". The address of 192.0.2.1 is a primary address of PE1 which is used as a default VPN next-hop address and as a source address of internal BGP sessions. All routes of CE2 use the default address of PE1 as the next-hop when exported as VPN routes. There is a special export policy on PE1 for the internal BGP sessions that modifies next-hops for the VPN-IPv4 routes of CE1 to the address of 192.0.2.100 and for the VPN-IPv6 routes of CE1 to the address of ::ffff:192.0.2.200.

Export routes into VPN by PE1

PE1 advertises unicast host-specific routes for the addresses 192.0.2.1, 192.0.2.100, and 192.0.2.200 via a routing protocol. PE2 receives these routes and installs them into the GRT. PE1 also allocates an MPLS label for the addresses mentioned above and distributes the bindings of this label via a label distribution protocol. PE2 receives these bindings and installs them into its tunnel table. Thus, PE2 can resolve all VPN routes that PE1 has sent. Suppose that AC2 between PE1 and CE2 has failed for some reason. When PE1 has noticed the failure it invalidates all routes inside VRF1 that were used to reach the CE2 addresses, 198.51.100.2/31 and 2001:DB8::/127. Other routes that recursively uses the routes to addresses of CE2 for look up their next-hops become inactive too. Because of that PE1 starts withdrawing the corresponding VPN routes, 203.0.113.128/25 and 2001:DB8:200::/64 (RD is omitted). PE2 must wait for these withdrawals before it stops sending traffic toward PE1 (traffic from CE3 to CE2). In another scenario, AC1 fails instead of AC2. Imagine, PE1 is configured to monitor the status of AC1 and in the case of the failure of AC1 PE1 immediately updates the routing protocol and the label distribution protocol. These updates include the withdrawal of the unicast routes for the addresses 192.0.2.100 and 192.0.2.200 (but not for 192.0.2.1) and the label bindings for them. In parallel with it, PE1 proceeds with the similar steps described previously for the case with the AC2 failure. PE2 eventually receives the updates either by the routing protocol or the label distribution protocol or both. Thanks to a hierarchical FIB it invalidates all VPN routes at once that use the failed routes (and tunnels) to their VPN next-hops. PE2 stops sending traffic to PE1 (traffic from CE3 to CE1) even if it has not received yet any withdrawals for the corresponding VPN routes. For the sake of brevity, both scenarios are discussed without alternative exit points for the routes inside VRF1 and just for a couple of such routes. In real deployments, CE can distribute much more routes to more than one PE. In that case, the mechanism described above can significantly improve the network convergence times. This document introduces the mechanism that helps notify VPN members about the AC failure that has happened to one of these members. The described solution expects the following:

• Hierarchical FIB MUST be supported and used among all VPN members.
• Any VPN member acting as an ingress PE MUST consider the status of a unicast route in the GRT toward the BGP next-hop (BGP next-hop tracking). This status MUST be considered during the BGP route resolution and after the route is placed into the appropriate routing table.
• It is RECOMMENDED for any VPN member acting as an ingress PE to consider the status of a tunnel toward the BGP next-hop also during the BGP VPN route resolution and after the route is placed into the appropriate routing table.

The solution described in this document modifies the behavior of egress PE routers only and can be deployed incrementally.

Abstract Next-Hop Address states:

• When a PE router distributes a VPN-IPv4 route via BGP, it uses its own address as the "BGP next hop".

In most cases, the "own address" is the address of a virtual interface (e.g., a loopback). This address usually acts as a tunnel endpoint for labeled traffic. The tunnel using it may be instantiated by different mechanisms and must be capable of forwarding MPLS traffic. The PE also uses this address as a source address of internal BGP sessions. Due to a virtual nature of the interface owning this address, it is nearly impossible to face the failure of this interface (except for artificial ways). Only the failure of a whole PE leads to it. The solution described in the document proposes using additional next-hops for VPN routes advertised by a single PE. This alters a behavior described in and that presupposes the advertising of a single next-hop address for all VPN routes of a PE. With regard to the described solution, additional next-hops advertised by a PE are named ANH addresses. An ANH address is an artificial IPv4 or IPv6 address that belongs to the GRT. An ANH acts as a proxy address for an actual address of a CE residing in a VRF. The status of the latter address influences the status of its ANH. A CE`s address selected for an ANH is named an LA. An LA may belong to a common subnet of a PE-CE pair in a VRF or can be any other address of the CE, it cannot belong to the GRT. An ANH and LA pair does not necessarily belong to the same address family. For example, it is possible to have an ANH of IPv4 and an LA of its ANH of IPv6, and vice versa. An LA can be a link-local IPv6 address, in this case, its ANH MUST be a proxy to a triplet (LA, AC, VRF) instead of (LA, VRF) where the LA belongs to the AC from the triplet. Addresses installed in different VRFs may be overlapped. Thus, values of ANHs may be arbitrary and do not have to be the same as their LAs. An operator is free to choose these values according to network address plans. To achieve goals stated in values of ANHs MUST be unique throughout the GRTs of the network. The case when several PE routers advertise the same value for the ANH (e.g., anycast) is out of the scope of this document. The ANH proxying is not a route leaking mechanism, it cannot be used for traffic forwarding between the GRT and a VRF in any direction. The ANH proxying creates a dependency between the statuses of an ANH and an LA (). An ANH MUST be bound to only one LA. An LA in turn MUST be bound to only one ANH. There is a strict one-to-one mapping between them. An operator may create the ANH proxying for any address in a VRF, but the solution expects that this address is used as a next-hop for routes in this VRF. These routes does not necessarily belong to the same CE that owns the LA (i.e., third-party next-hop). The ANH proxying can be described as a static host-specific route that is installed in the GRT. A destination address of this route is configured as a value selected for an ANH by an operator. A next-hop address of the static route is equal to an LA (selected for the ANH). Additionally, the operator configures a VRF (its name or index) directly for this static route. It points to where the next-hop of the route must be resolved. For unlabeled traffic coming to a PE via the GRT, the static route acts as a route to the bit bucket. This document does not restrict implementations by this mechanic.

Status of the Abstract Next-Hop The status of an ANH depends on the existence of a route to its LA. This route MUST be present in a VRF associated with the ANH. The ANH is considered active if and only if the route to its LA is active and is available for traffic forwarding. The proposed solution does not restrict the type of this route, but it MUST support at least direct routes and static routes. An implementation MAY filter the protocols used for resolution of LAs by a configuration policy. The status of an ANH is unidirectional, only the status of an LA defines the status of an ANH. An implementation MAY support the option of deactivation of an ANH manually by an operator. Besides the dependency on a route toward an LA, an ANH MAY be a client of any mechanism of active monitoring of the LA. It can be any next-hop tracking (ARP, ICMP probes if they are applicable to the LA) or a BFD session between a CE that owns the LA and a PE that owns the ANH.

Distribution of the Abstract Next-Hop In general, the distribution of ANHs by means of a routing protocol does not differ from the distribution of any other addresses that are considered to be BGP next-hops. An ANH SHOULD be advertised by a routing protocol. In this case, the next conditions MUST be met:

• The status of the ANH is active ().
• The ANH is advertised as a host-specific route.
• This route is reachable by at least a subset of PEs via the routing protocol.
• These PEs import VPN routes with a BGP next-hop address equal to the ANH (covered by the route) in appropriate VRFs and use these VPN routes for traffic forwarding.

This solution does not restrict the type of the routing protocol for ANH routes distribution. When the status of an ANH changes from active to inactive a PE MUST notify the other PEs receiving a route to this ANH. The speed of origination of such notification and its propagation is crucial. PEs that received a route to an ANH act according to the standard procedures that are applicable to the routing protocol. This solution does not modify this behavior.

Tunnels to the Abstract Next-Hop A PE may have one or several ANHs and distributes them as per . In that case, according to there MUST be a tunnel for every such address of the PE. This solution does not restrict the type of tunnels that point to ANHs, but these tunnels MUST forward MPLS traffic. However, an implementation of an egress tunnel endpoint may require some changes to support a point-to-point tunnel (e.g., RSVP-TE LSP or IP GRE ) to an ANH. These changes are out of the scope of this document. The solution does not consider in detail using tunneling technologies other than MPLS LSPs for transport of labeled VPN traffic. The rest of the section is applicable to MPLS LSPs only. For all ANHs with LAs that belong to the same VRF, a PE MUST allocate the same label. A PE MAY allocate a single label for all ANHs (e.g., implicit label). When a PE allocates a label for an ANH it MUST associate a release timer with this label. If the status of the ANH changes to inactive the PE starts the release timer for the label. While the timer is active if the PE is receiving traffic with this label it MUST continue to handle this traffic like the failure has not happened. When the timer reaches zero the PE starts freeing the resources associated with the label. This timer does not influence the generation and advertising of the failure notification via the label distribution protocol. An implementation SHOULD support a manual setting of the release timer (including zero). If a label is allocated for a group of ANHs a PE starts the timer if and only if the last active address of the group becomes inactive. When a PE advertises a label binding to an ANH it either MUST be accomplished by a label distribution protocol in parallel with the advertising of the ANH via a routing protocol (), or the ANH MUST be sent as a labeled route (e.g., BGP-LU ). When the status of an ANH () changes to inactive and a label binding to this ANH was advertised by a PE via the label distribution protocol the PE MUST notify other routers receiving the label for this ANH. The speed of origination of such notification and its propagation is also important, this notification may be received before the notification via the routing protocol, or it may be the only notification channel (). Routers that received a label binding for an ANH act according to the standard procedures that are applicable to the label distribution protocol. The proposed solution does not change the behavior of ingress LERs or LSRs.

Distribution of VPN Routes The solution that is proposed in this document is only applicable to VPN-IPv4 and VPN-IPv6 routes (i.e., SAFI 128). Using any other routes with ANHs is out of the scope of this document. For a group of routes installed in a VRF and united by a common next-hop address, an operator MAY set up an ANH as a next-hop of the corresponding VPN routes. The rest routes from the same VRF (if they are left) MUST be advertised by procedures or if it is supposed to advertise them. An ANH for VPN-IPv4 routes is encoded according to as a VPN-IPv4 address with an RD of 0. An ANH for VPN-IPv6 routes is encoded according to as a VPN-IPv6 address. This VPN-IPv6 address contains an RD of 0 and an IPv6 address which is equal to the ANH. In case when the ANH is the IPv4 address the VPN-IPv6 address is encoded as an IPv4-mapped IPv6 address. The procedures of including a link-local address are not altered by this solution. According to , routes that are installed in a VRF are converted to VPN routes (this statement is applicable to both address families), and "exported" to BGP. This solution assumes that all VPN routes are installed into the VPN Loc-RIB with a next-hop address that is equal to the own address of a PE where this VRF is configured. In the other words, the solution does not modify procedures for converting routes from VRFs to VPN routes. All routes in a Loc-RIB are processed into appropriate Adj-RIBs-Out according to configured policies . The solution expects that there MUST be a special export policy that is applicable to routes undergoing from the VPN Loc-RIB to VPN Adj-RIBs-Out and is processed in a chain before all policies that are configured by an operator (if there are such policies). This special export policy modifies next-hop addresses only for those routes that are supposed by a configuration to be sent with ANHs (or a single ANH). A PE does not check the presence of a route to an ANH in the GRT before copying VPN routes from a Loc-RIB into a corresponding Adj-RIB-Out and during the Update-send process (). When the status of an ANH () changes to inactive a PE does not start withdrawing VPN routes that use this ANH as their next-hop. It prevents churn in the case when an operator decides to maintain a network and manually disable the ANH. On the other hand, deleting a binding between an ANH and its LA MUST start changing the corresponding next-hop addresses in Adj-RIBs-Out to the default value (the value from the Loc-RIB). An implementation MAY support an option of selecting distinct Adj-RIBs-Out where VPN routes will be placed with ANHs.

Forwarding For an ingress PE, it is impossible to determine whether a next-hop address of received VPN routes is a regular address or an abstract one. The ingress PE considers every VPN next-hop address as the address of a standalone egress router even if a group of VPN next-hop addresses belongs to the same device. Having an active route and a tunnel to a BGP next-hop address the ingress PE encapsulates and sends traffic via the tunnel according to . If an egress PE receives MPLS traffic with a label that was allocated for one of its ANHs the solution expects the following (other cases are out of the scope of this document):

• This label MUST NOT contain a Bottom of Stack bit is set.
• At a bottom of the received stack there MUST be a label that was allocated by the egress PE.
• There MAY be other labels between these two labels (e.g., entropy labels ).

Failure Detection

Egress PE A PE detects the failure of a connected CE by different mechanisms. These mechanisms are not considered in this document. The net effect of the failure is the unreachability of routes to addresses (or a route to a single address) of the failed CE in a VRF where an AC to the CE resides. The PE usually uses these routes to recursively resolve next-hops for other routes in the VRF (are also usually distributed by the CE). All failed routes try to find new options to resolve their next-hops, if there are no such options the PE starts deleting the failed routes from the VRF. After the PE detected the CE had failed and if one of addresses of the CE is an LA the PE immediately deactivates an ANH of this LA. If a route to the ANH was distributed as per the PE notifies all neighbors of a routing protocol. If the ANH was also bound to a label and this label was distributed via a label distribution protocol, the PE notifies all neighbors of the label distribution protocol. The PE may start distributing updates via BGP VPN sessions notifying its peers that the routes in the VRF are no longer reachable. This process does not relate to the process described above and the solution does not modify it. However, if the route to ANH was distributed by BGP via the same set of sessions that are used for VPN routes distribution an implementation SHOULD schedule sending of the UPDATE message with the ANH`s withdrawal prior to UPDATE messages with the failed VPN routes.

Ingress PE As stated in , the proposed solution expects an ingress PE to consider the status of a tunnel toward a BGP VPN next-hop. Thus, when the status of the tunnel changes to inactive the ingress PE simultaneously deactivates all VPN routes with a next-hop equal to an address of the tunnel`s endpoint. If the ingress PE does not follow this logic, the solution expects that the status of a route toward a BGP VPN next-hop in the GRT is used the same way. The ingress PE can apply both procedures. In any case, the ingress PE can react to the failure of a remote CE (the CE connected to a remote PE in the same VPN) or an AC to the CE independently of the receiving of BGP UPDATE messages that withdraw VPN routes pointing to this CE. The ingress PE may activate backups for these routes and redirect traffic by them.

Deployment Considirations

Scalability A requirement to have a tunnel to every next-hop address that a PE uses to advertise VPN routes may pose scalability concerns. There are some thoughts on how to deploy the described solution from the scalability point of view:

• Use multipoint-to-point tunnels to reach VPN next-hop addresses. It helps to reduce state on a PE that advertises VPN routes with these next-hops avoiding dependence on the number of upstream routers. It also reduces state on intermediate routers when the tunnels are LSPs.
• Selective installation of routes and tunnels helps spend resources only for VPN next-hop addresses that an ingress PE will use. If the ingress PE does not import a VPN route it is not always necessary to have a tunnel towards a next-hop address of this route. In the case of ANHs, having such tunnels is even more questionable.
• Do not use the ANH proxying for every possible CE address in every possible VRF. There are a lot of cases when the traditional VPN convergence is good enough.
• A PE may advertise a common label for all its ANHs if tunnels towards them are supposed to be LSPs. In this case, it is expected that the ANHs also share a common value for the release timer (). Using different values for the release timer may require to deaggregate labels.

Using the Abstract Next-Hops Deploying of the ANH solution should be considered on a per-service basis. The following points may help to decide whether an ANH is appropriate:

• Most VPN services exchange a small number of routes, hundreds, or several thousand. Usually, any CE contributes a small portion of them, and its failure can be noticed and repaired by the network in a reasonable time. Imagine a situation when a CE advertises a significant number of routes, tens of thousands or more. In this case, the restoration after the failure of the CE may exceed the expected convergence time.
• Independently on the number of routes that are advertised by a CE existence of an extra exit point should be considered. Improving the switchover time requires a point where to switch.
• Sometimes it may be desirable to stop traffic flowing through a network after a destination CE fails, even if there is no extra exit point. For example, there is a cosiderable amount of traffic towards a failed CE.
• Some services require special treatment due to stricter SLAs, using ANH may help to achieve these SLAs.

Failure Detection It is worth noting the detection time of a CE failure or a failure of link (or an AC) to the CE. This time contributes much to overall convergence. For example, sometimes it is not possible to notice the link failure by a loss of a signal, and extra mechanisms are required for this task. Some of these mechanisms interact with a session of a PE-CE protocol. When these mechanisms detect the failure, routes distributed by an associated PE-CE protocol`s session will become inactive. At the same time routes toward addresses of the CE (or a single route) are usually not distributed by the PE-CE protocol`s session. They may be direct routes or statics. Thus, the routes toward the addresses of the CE are not affected by the detection mechanism described above and are staying alive. If one of the CE`s addresses is an LA the status of an ANH that is proxying to the LA will also be active. To prevent such behavior, it is recommended to use detection of the failure of an address of the CE or a route to this address (both on the PE and the CE, especially if the CE is multihomed). In the other words, it is better (in the described case) to monitor a next-hop for the routes distributed by the PE-CE protocol, but not the session of the PE-CE protocol.

Routes Aggregation Routes advertised by a routing protocol can be aggregated at some points of a network (e.g., ABRs). Such aggregation may lead to obscurity issues in the event of an ANH deactivation. The aggregation of routes removes a notification channel that is supplied by the routing protocol. A label distribution protocol can provide this notification channel when it is used for the distribution of labels for ANHs. But in this case, it requires all VPN members to consider the status of tunnels toward ANHs as described in . If LDP is used as the label distribution protocol for ANHs, the following steps should be considered:

• LDP extension for Inter-Area LSPs must be used through the network.
• If LDP is configured in Downstream Unsolicited mode it must also be configured in Ordered Control mode. LDP LSR with Independent Control mode on a path to ANH will break the notification channel.

Multicast Considirations introduces the VRF Route Import EC. describes a scenario when unicast VPN routes do not contain this community during the selection of Upstream PE:

• If a route does not have a VRF Route Import Extended Community, the route's Upstream PE is determined from the route's BGP Next Hop.

The solution described in this document expects that unicast VPN routes of a VPN service may be sent by a PE with different BGP next-hop addresses. It may create an issue with the importing of C-Multicast routes if this VPN service also acts as MVPN and does not mark its VPN routes with the VRF Route Import EC. It is not recommended to configure a new import Route Target EC for every ANH. Instead, there are two possible ways to mitigate the described problem:

• Using procedures described in .
• Do not use ANHs for unicast VPN routes that cover multicast sources or RP addresses.

Security Considerations This document specifies extensions for the advertisement of VPN routes with different next-hops by a signle PE. From this point of view, the security considirations described in and are equally applicable for the extensions described in this document.

IANA Considerations This document has no IANA actions.

References Normative References This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6. In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines an IPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP". This document defines support of the IPv6 VPN service over both an IPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic Routing Encapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. [STANDARDS-TRACK] Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] This document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK] The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK] To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS-TRACK] In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. [STANDARDS-TRACK] This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513. [STANDARDS-TRACK] Individual Contributor Cisco Systems Sproute Networks In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. In this document we proposed an architecture by which traffic can be re-routed to ECMP or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The proposed technique achieves prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup.

Acknowledgments The author would like to thank Roman Peshekhonov for his review and valuable input.