2.1. Reasons for Tunnel Segmentation

Tunnel segmentation may be required and/or desired for administrative and/or technical reasons.¶

For example, an MVPN/VPLS/EVPN may span multiple providers, and the end-to-end provider tunnels have to be segmented at and stitched by the ASBRs. Different providers may use different tunnel technologies (e.g., provider A uses ingress replication [RFC7988], provider B uses RSVP-TE P2MP [RFC4875], and provider C uses Multipoint LDP (mLDP) [RFC6388]). Even if they use the same tunnel technology (e.g., RSVP-TE P2MP), it may be impractical to set up the tunnels across provider boundaries.¶

The same situations may apply between the ASes and/or areas of a single provider. For example, the backbone area may use RSVP-TE P2MP tunnels while non-backbone areas may use mLDP tunnels.¶

Segmentation can also be used to divide an AS/area into smaller regions, so that control plane state and/or forwarding plane state/burden can be limited to that of individual regions. For example, instead of ingress-replicating to 100 PEs in the entire AS, with inter-area segmentation [RFC7524], a PE only needs to replicate to local PEs and Area Border Routers (ABRs). The ABRs will further replicate to their downstream PEs and ABRs. This not only reduces the forwarding plane burden, but also reduces the leaf-tracking burden in the control plane.¶

In the case of tunnel aggregation, smaller regions provide the benefit of making it easier to find congruence among the segments of different constituent (service) tunnels and the resulting aggregation (base) tunnel in a region. This leads to better bandwidth efficiency, because the more congruent they are, the fewer leaves of the base tunnel need to discard traffic when a service tunnel's segment does not need to receive the traffic (yet it is receiving the traffic due to aggregation).¶

Another advantage of the smaller region is smaller Bit Index Explicit Replication (BIER) subdomains [RFC8279]. With BIER, packets carry a BitString, in which the bits correspond to edge routers that need to receive traffic. Smaller subdomains means that smaller BitStrings can be used without having to send multiple copies of the same packet.¶

3.1. Per-Region I-PMSI A-D Route

The per-region I-PMSI A-D route has the following format. Its usage is discussed in Section 6.2.¶

                +-----------------------------------+
                |       RD (8 octets)               |
                +-----------------------------------+
                |  Ethernet Tag ID (4 octets)       |
                +-----------------------------------+
                |  Region ID (8 octets)             |
                +-----------------------------------+

The Region ID identifies the region and is encoded in the same way that an EC is encoded, as detailed in Section 6.2.¶

3.3. Leaf A-D Route

The Route Type specific field of a Leaf A-D route consists of the following:¶

                +-----------------------------------+
                |      Route Key (variable)         |
                +-----------------------------------+
                |Originator's Addr Length (1 octet) |
                +-----------------------------------+
                |Originator's Addr (4 or 16 octets) |
                +-----------------------------------+

A Leaf A-D route is originated in response to a PMSI route, which could be an IMET A-D route, a per-region I-PMSI A-D route, an S-PMSI A-D route, or some other types of routes that may be defined in the future that trigger Leaf A-D routes. The Route Key is the NLRI of the route for which this Leaf A-D route is generated.¶

The general procedures for Leaf A-D routes were first specified in [RFC6514] for MVPNs. The principles therein apply to VPLSs and EVPNs as well. [RFC7117] provides details regarding VPLS multicast, and this document points out some specifics for EVPNs, e.g., in Section 5.¶

5.1. Differences from Section 7.2.2 of RFC 7117 when Applied to EVPNs

The first paragraph of Section 7.2.2.2 of [RFC7117] says:¶

... The best route procedures ensure that if multiple ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP neighbors, only one of these ASBRs propagates this route in Internal BGP (IBGP). This ASBR becomes the root of the intra-AS segment of the inter-AS tree and ensures that this is the only ASBR that accepts traffic into this AS from the inter-AS tree.¶

The above VPLS behavior requires complicated VPLS-specific procedures for the ASBRs to reach agreement. For EVPNs, a different approach is used; the above text from [RFC7117] is not applicable to EVPNs.¶

With the different approach for EVPNs/MVPNs, each ASBR will re-advertise its received Inter-AS A-D route to its IBGP peers and becomes the root of an intra-AS segment of the inter-AS tree. The intra-AS segment rooted at one ASBR is disjoint from another intra-AS segment rooted at another ASBR. This is the same as the procedures for S-PMSI routes in [RFC7117] itself.¶

The following bullet in Section 7.2.2.2 of [RFC7117] does not apply to EVPNs.¶

• If the ASBR uses ingress replication to instantiate the intra-AS segment of the inter-AS tunnel, the re-advertised route MUST NOT carry the PMSI Tunnel attribute.¶

The following bullet in Section 7.2.2.2 of [RFC7117]:¶

• If the ASBR uses a P-multicast tree to instantiate the intra-AS segment of the inter-AS tunnel, the PMSI Tunnel attribute MUST contain the identity of the tree that is used to instantiate the segment (note that the ASBR could create the identity of the tree prior to the actual instantiation of the segment). If, in order to instantiate the segment, the ASBR needs to know the leaves of the tree, then the ASBR obtains this information from the A-D routes received from other PEs/ASBRs in the ASBR's own AS.¶

is changed to the following when applied to EVPNs:¶

• The PTA MUST specify the tunnel for the segment. If and only if, in order to establish the tunnel, the ASBR needs to know the leaves of the tree, then the ASBR MUST set the L flag to 1 in the PTA to trigger Leaf A-D routes from egress PEs and downstream ASBRs. It MUST be (auto-)configured with an import RT, which controls acceptance of Leaf A-D routes by the ASBR.¶

Accordingly, the following paragraph in Section 7.2.2.4 of [RFC7117]:¶

If the received Inter-AS A-D route carries the PMSI Tunnel attribute with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR that originated the route MUST establish an RSVP-TE P2MP LSP with the local PE/ASBR as a leaf. This LSP MAY have been established before the local PE/ASBR receives the route, or it MAY be established after the local PE receives the route.¶

is changed to the following when applied to EVPNs:¶

If the received Inter-AS A-D route has the L flag set in its PTA, then a receiving PE MUST originate a corresponding Leaf A-D route. A receiving ASBR MUST originate a corresponding Leaf A-D route if and only if one of the following conditions is met: (1) it received and imported one or more corresponding Leaf A-D routes from its downstream IBGP or EBGP peers or (2) it has non-null downstream forwarding state for the PIM/mLDP tunnel that instantiates its downstream intra-AS segment. The targeted ASBR for the Leaf A-D route, which (re-)advertised the Inter-AS A-D route, MUST establish a tunnel to the leaves discovered by the Leaf A-D routes.¶

5.2. I-PMSI Leaf Tracking

An ingress PE does not set the L flag in its IMET A-D route's PTA, even with Ingress Replication tunnels or RSVP-TE P2MP tunnels. It does not rely on the Leaf A-D routes to discover leaves in its AS, and Section 11.2 of [RFC7432] explicitly states that the L flag must be set to 0.¶

An implementation of [RFC7432] might have used the Originating Router's IP Address field of the IMET A-D routes to determine the leaves or might have used the Next Hop field instead. Within the same AS, both will lead to the same result.¶

With segmentation, an ingress PE MUST determine the leaves in its AS from the BGP next hops in all its received IMET A-D routes, so it does not have to set the L flag to request Leaf A-D routes. PEs within the same AS will all have different next hops in their IMET A-D routes (and hence will all be considered as leaves), and PEs from other ASes will have the next hop in their IMET A-D routes set to addresses of ASBRs in this local AS; hence, only those ASBRs will be considered as leaves (as proxies for those PEs in other ASes). Note that in the case of ingress replication, when an ASBR re-advertises IMET A-D routes to IBGP peers, it MUST advertise the same label for all those routes for the same Ethernet Tag ID and the same EVI. Otherwise, duplicated copies will be sent by the ingress PE and received by egress PEs in other regions. For the same reason, when an ingress PE builds its flooding list, if multiple routes have the same (nexthop, label) tuple, they MUST only be added as a single branch in the flooding list.¶

5.3. Backward Compatibility

The above procedures assume that all PEs are upgraded to support the segmentation procedures:¶

• An ingress PE uses the Next Hop and not the Originating Router's IP Address to determine leaves for the I-PMSI tunnel.¶
• An egress PE sends Leaf A-D routes in response to I-PMSI routes, if the PTA has the L flag set by the re-advertising ASBR.¶
• In the case of ingress replication, when an ingress PE builds its flooding list, multiple I-PMSI routes may have the same (nexthop, label) tuple, and only a single branch for those routes will be added in the flooding list.¶

If a deployment has legacy PEs that do not support the above, then a legacy ingress PE would include all PEs (including those in remote ASes) as leaves of the inclusive tunnel and try to send traffic to them directly (no segmentation), which is either undesirable or impossible; a legacy egress PE would not send Leaf A-D routes so the ASBRs would not know to send external traffic to them.¶

If this backward-compatibility problem needs to be addressed, the following procedure MUST be used (see Section 6.2 for per-PE/AS/region I-PMSI A-D routes):¶

• An upgraded PE indicates in its per-PE I-PMSI A-D route that it supports the new procedures. This is done by setting a flag bit in the EVPN Multicast Flags Extended Community.¶
• All per-PE I-PMSI A-D routes are restricted to the local AS and not propagated to external peers.¶
• The ASBRs in an AS originate per-region I-PMSI A-D routes and advertise them to their external peers to specify tunnels used to carry traffic from the local AS to other ASes. Depending on the types of tunnels being used, the L flag in the PTA may be set, in which case the downstream ASBRs and upgraded PEs will send Leaf A-D routes to pull traffic from their upstream ASBRs. In a particular downstream AS, one of the ASBRs is elected, based on the per-region I-PMSI A-D routes for a particular source AS, to send traffic from that source AS to legacy PEs in the downstream AS. The traffic arrives at the elected ASBR on the tunnel announced in the best per-region I-PMSI A-D route for the source AS, as selected by the ASBR from all the routes that it received over EBGP or IBGP sessions. The election procedure is described in Section 5.3.1.¶
• In an ingress/upstream AS, if and only if an ASBR has active downstream receivers (PEs and ASBRs), which are learned either explicitly via Leaf A-D routes or implicitly via PIM Join or mLDP label mapping, the ASBR originates a per-PE I-PMSI A-D route (i.e., a regular IMET route) into the local AS and stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI tunnel. Via this process, it gets traffic from local PEs and sends the traffic to other ASes via the tunnel announced in its per-region I-PMSI A-D route.¶

Note that even if there are no backward-compatibility issues, the use of per-region I-PMSI A-D routes provides the benefit of keeping all per-PE I-PMSI A-D routes in their local ASes, greatly reducing the flooding of the routes and their corresponding Leaf A-D routes (when needed) and reducing the number of inter-AS tunnels.¶

6.1. Area/AS vs. Region

[RFC7524] addresses MVPN/VPLS inter-area segmentation and does not explicitly cover EVPNs. However, if "area" is replaced by "region" and "ABR" is replaced by "RBR" (Regional Border Router), then everything still works and can be applied to EVPNs as well.¶

A region can be a sub-area, or it can be an entire AS, including its external links. Instead of automatically defining a region based on IGP areas, a region would be defined as a BGP peer group. In fact, even with a region definition based on an IGP area, a BGP peer group listing the PEs and ABRs in an area is still needed.¶

Consider the following example diagram for inter-AS segmentation:¶

          ---------           ------             ---------
         /         \         /      \           /         \
        /           \       /        \         /           \
       | PE1 o    ASBR1 -- ASBR2    ASBR3 -- ASBR4    o PE2 |
        \           /       \        /         \           /
         \         /         \      /           \         /
          ---------           ------             ---------
          AS 100              AS 200              AS 300
       |-----------|--------|---------|--------|------------|
          segment1  segment2 segment3  segment4  segment5

The inter-AS segmentation procedures specified so far ([RFC6513], [RFC6514], [RFC7117], and Section 5 of this document) require all ASBRs to be involved, and ingress replication is used between two ASBRs in different ASes.¶

In the above diagram, it's possible that ASBR1/4 does not support segmentation, and the provider tunnels in AS 100/300 can actually extend across the external link. In this case, the inter-region segmentation procedures can be used instead -- a region is the entire AS100 plus the ASBR1-ASBR2 link or the entire AS300 plus the ASBR3-ASBR4 link. ASBR2/3 would be the RBRs, and ASBR1/4 will just be a transit core router with respect to provider tunnels.¶

As illustrated in the diagram below, ASBR2/3 will establish a multihop EBGP session, either with a Route Reflector (RR) or directly with PEs in the neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be processed by ASBR1/4. When ASBR2 re-advertises the routes into AS 200, it changes the next hop to its own address and changes its PTA to specify the tunnel type/identification in its own AS. When ASBR3 re-advertises I/S-PMSI A-D routes into the neighboring AS 300, it changes the next hop to its own address and changes its PTA to specify the tunnel type/identification in the neighboring region. Now, the segment is rooted at ASBR3 and extends across the external link to PEs.¶

          ---------           ------             ---------
         /   RR....\.mh-ebpg /      \    mh-ebgp/....RR   \
        /    :      \    `. /        \ .'      /      :    \
       | PE1 o    ASBR1 -- ASBR2    ASBR3 -- ASBR4    o PE2 |
        \           /       \        /         \           /
         \         /         \      /           \         /
          ---------           ------             ---------
          AS 100              AS 200              AS 300
       |-------------------|----------|---------------------|
          segment 1          segment 2         segment 3

6.2. Per-Region Aggregation

Notice that every I/S-PMSI route from each PE will be propagated throughout all the ASes or regions. They may also trigger corresponding Leaf A-D routes, depending on the types of tunnels used in each region. This may result in too many routes and corresponding tunnels. To address this concern, the I-PMSI routes from all PEs in an AS/region can be aggregated into a single I-PMSI route originated from the RBRs, and traffic from all those individual I-PMSI tunnels will be switched into the single I-PMSI tunnel. This is like the MVPN Inter-AS I-PMSI route originated by ASBRs.¶

The MVPN Inter-AS I-PMSI A-D route can be better called a "per-AS I-PMSI A-D route", to be compared against the (per-PE) Intra-AS I-PMSI A-D routes originated by each PE. In this document, we will call it a "per-region I-PMSI A-D route" in cases where we want to apply aggregation at the regional level. The per-PE I-PMSI routes will not be propagated to other regions. If multiple RBRs are connected to a region, then each will advertise such a route, with the same Region ID and Ethernet Tag ID (Section 3.1). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs in a downstream region will each select the best route from all those re-advertised by the upstream RBRs and hence will only receive traffic injected by one of them.¶

MVPNs do not aggregate S-PMSI routes from all PEs in an AS like they do for I-PMSI routes, because the number of PEs that will advertise S-PMSI routes for the same (S,G) or (*,G) is small. This is also the case for EVPNs, i.e., there are no per-region S-PMSI routes.¶

Notice that per-region I-PMSI routes can also be used to address backward-compatibility issues, as discussed in Section 5.3.¶

The Region ID in the per-region I-PMSI route's NLRI is encoded like an EC. For example, the Region ID can encode an AS number or area ID in the following EC format:¶

• For a two-octet AS number, a Transitive Two-Octet AS-specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub-field set to the AS number and the Local Administrator sub-field set to 0.¶
• For a four-octet AS number, a Transitive Four-Octet AS-specific EC of sub-type 0x09 (Source AS), with the Global Administrator sub-field set to the AS number and the Local Administrator sub-field set to 0.¶
• For an area ID, a Transitive IPv4-Address-specific EC of any sub-type, with the Global Administrator sub-field set to the area ID and the Local Administrator sub-field set to 0.¶

The use of other EC encodings MAY be allowed as long as they uniquely identify the region and the RBRs for the same region use the same Region ID.¶