BGP-MVPN Inter-AS Option B Overview

This topic provides an overview of Junos support for Inter-Autonomous System (AS) Option B, which is achieved by extending Border Gateway Protocol Multicast Virtual Private Network (BGP-MVPN) to support Inter-AS scenarios using segmented provider tunnels (p-tunnels). Junos OS also support Option A and Option C unicast with non-segmented p-tunnels, support for which was introduced in Junos OS 12.1. See the links below for more information on these options.

Inter-AS support for multicast traffic is required when an L3VPN results in two or more ASes that are using BGP-MVPN. The ASes may be administered by the same authority or by different authorities. When using BGP-MVPN Inter-AS Option B with segmented p-tunnels, the p-tunnel segmentation is performed at the Autonomous System Border Router (ASBRs). The ASBRs also perform BGP-MVPN signaling and form the data plane.

Setting up Inter-AS Option B with segmented p-tunnels can be complex, but the configuration does provide the following advantages:

• Independence. Different administrative authorities can choose whether or not to allow topology discovery of their AS by the other ASes. That is, each AS can be separately controlled by a different independent authority.

• Heterogeneity. Different p-tunnel technologies can be used within a given AS (as might be the case when working with heterogeneous networks that now must be combined).

• Scale. Inter-AS Option B with segmented p-tunnels avoids the potential for ASBR bottleneck that can happen when Intra-AS p-tunnels are set up across ASes using non-segmented p-tunnels. (Unicast branch LSPs with inclusive p-tunnels can all have to transit through the ASBRs. In this case, for IR, the pinch point becomes data-plane scale. For RSVP-TE it becomes P2MP control-plane scale, due to the high number of RSVP refresh messages passing through the ASBRs).

The supported Junos implementation of Option B uses RSVP-TE p-tunnels for all segments, and MVPN Inter-AS signaling procedures. Multicast traffic is forwarded across AS boundaries over a single-hop labeled LSP. Inter-AS p-tunnels have two segments: an ASBR-ASBR segment, called Inter-AS segment and the ASBR-PE segment called Intra-AS segment. (Static RSVP-TE, IR , PIM-ASM, and PIM-SSM p-tunnels are not supported.)

MVPN Intra-AS AD routes are not propagated across the AS boundary. The Intra-AS inclusive p-tunnels advertised in Type-1 routes are terminated at the ASBRs within each AS. Route learning for both unicast and multicast traffic occurs only through Option B.

The ASBR originates an Inter-AS AD (Type-2) route into eBGP, which may include tunnel attributes for an Inter-AS p-tunnel (called an Inter-AS, or ASBR-ASBR p-tunnel segment). The Type-2 route contains the ASBR's route distinguisher (RD), which is unique per VPN and per ASBR, and its AS number. The tunnel is set up between two directly connected ASBRs in neighboring ASes, and it is always a single-hop point-topoint (P2P) LSP.

An ASBR in the originating AS forwards all multicast traffic received over the inclusive p-tunnel into the Inter-AS p-tunnel. An ASBR in the adjacent AS propagates the received Inter-AS route into its own AS over iBGP, but only after rewriting the Provider Multicast Service Interface (PMSI) tunnel attributes and modifying the next-hop of the Multiprotocol Reachable (MP_REACH_NRLI) attribute with a reachable address of the ASBR (next-hop self rewrite). When an ASBR propagates the Type-2 route over iBGP, it can choose any p-tunnel type supported within its AS, although the supported Junos implementation of Option B uses RSVP-TE p-tunnels only for all segments.

At the ASBRs, traffic received over the upstream p-tunnel segment is forwarded over the downstream p-tunnel segment. This process is repeated at each AS boundary. The resulting Inter-AS p-tunnel is comprised of alternating Inter-AS and Intra-AS p-tunnel segments (thus the name, “segmented p-tunnel”).

Option B with segmented p-tunnels is not without drawbacks.:

• The ASBRs distribute both VPN routes and routes in the master instance. They may thus become a bottleneck.

• With a large number of VPNs, the ASBR can run out of labels because each unicast VPN route requires one.

• Per VPN packet flow accounting cannot be performed at the ASBR.

• Unless route-targets are rewritten at the AS boundaries, the different service providers must agree on VPN route-targets (this is that same as for option-C)

• The ASBRs must be capable of MVPN signaling and support Inter-AS MVPN procedures.