| Network Working Group | L. Geng |
| Internet-Draft | L. Wang |
| Intended status: Standards Track | China Mobile |
| Expires: January 3, 2019 | J. Xie |
| M. McBride | |
| G. Yan | |
| Huawei Technologies | |
| July 2, 2018 |
MVPN using Segment Routing and BIER for High Reachability Multicast Deployment
draft-geng-pim-bier-sr-multicast-deployment-00
Bit Index Explicit Replication (BIER) introduces a stateless multicast approach for a specific IGP area. Segment Routing introduces an approach for end-to-end stateless deployment for both inter-area and inter-as scenarios. This document proposes a MVPN using Segment Routing and BIER for a high reachability multicast deployment.
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 [RFC2119].
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Bit Index Explicit Replication (BIER) [RFC8279] introduces a stateless multicast approach for a specific IGP area. Segment Routing [I-D.ietf-spring-segment-routing] introduces an approach for end-to-end stateless deployment for both inter-area and inter-as scenario. An end-to-end VPN deployment may benefit from the combination of this two technology in which the stateless nature can be maintained. This document proposes an MVPN deployment with high reachability in such scenario using both Segment Routing and BIER.
Readers of this document are assumed to be familiar with the terminology and concepts of the documents listed as Normative References.
In a BIER deployment in multi-area or multi-AS network, a segmented MVPN has to be used. As a result, multicast states are created at the segment boundary. The per-flow multicast states are maintained on the routers which are considered beyond of the "MVPN service" sites. This significant disadvantage for multicast service deployment is due to the poor reachability of BIER and is hard to solve solely by BIER itself.
Segment Routing, however, has high reachability for both multi-area and multi-as deployment. VPN services can use pre-defined Segments (SIDs) on the area boundary routers (ABR) or AS boundary routers (ASBR) for end-to-end deployment, without requiring such boundary routers to include per-vpn or per-flow states, or per-vpn or per-flow signaling to establish the end-to-end connection.
BIER and Segment Routing can be used for different partition of an end-to-end MVPN service deployment. A packet with BIER encapsulation is carried by Segment Routing to a boundary router. When reaching the boundary router, it is replicated according to the BitString in the BIER encapsulation to destination routers. Hence, the whole multicast deployment can be stateless end-to-end.
A typical scenario for this type of deployment is in a service-provider network for business L3VPN service with multicast as defined in [I-D.ietf-bier-use-cases]. Service provider network tends to be very heterogeneous with full-mesh backbone network, ring-shaped metro networks for sparse area coverage, and sometime a fabric for dense area coverage. A source router can send multicast packets to each of the boundary routers of each metro network, with a loose path selection in the full-mesh core network to avoid overloading by using Segment Routing. The boundary router or boundary routers replicate the packets to its own metro network according to the BIER encapsulation.
To achieve the end-to-end statelessness, the boundary router will not proxy any per-vpn or per-flow state. Instead, each of the edge routers, in a specific metro network, directly tell the interest of some multicast flow to the ingress edge router. This is the same as the L3VPN deployed end-to-end on Option-C style or SR style. For MVPN service, this can be done by the current BGP MVPN signaling. While for MVPN using Segment Routing and BIER, it is required to include the information of boundary router(s) of the area the egress edge router belongs to. The boundary router(s) can be thought as anchor(s) of the area for BIER replication.
Below is an example of end-to-end MVPN deployment on a simple network containing one ABR in each of the edge network area.
+------+ +------+ +------+ +------+
SRC---| PE11 | | ABR1 | | ABR2 | | PE21 |---RCV
+------+ +------+ +------+ +------+
|<--- Area 1--->|<--- Area 0--->|<--- Area 2--->|
| | | |
|---------- BIER in SR -------->|----- BIER --->|
| | |
|<------------ MVPN E2E Deployment ------------>|
Figure 1: MVPN using BIER and SR for E2E deployment
A more realistic network may contain two ABRs in each metro network area for realibility.
+------+ +------+
| ABR1a| | ABR2a|
+------+ +------+ +------+ +------+
SRC---| PE11 | | PE21 |---RCV
+------+ +------+ +------+ +------+
| | ABR1b| | ABR2b| |
| +------+ +------+ |
| | | |
|<--- Area 1--->|<--- Area 0--->|<--- Area 2 --->|
| (Metro) | (CORE) | (Metro) |
| | | |
|---------- BIER in SR -------->|----- BIER ---->|
| | |
|<------------ MVPN E2E Deployment ------------->|
Figure 2: MVPN using BIER and SR for E2E deployment and protection
In an area of the receiver side, the anchor router or routers advertise the BIER Label, the router IP, and the associated Sub-domain, BSL and SI. The egress edge routers receive this information accordingly. When an egress edge router advertiseing MVPN Leaf A-D routes to the ingress edge router at the sender side, it includes the anchor router IP, the anchor router BIER Label, together with the egress edge router's Sub-domain, BFR-prefix and BFR-id, just as the PTA defined in [I-D.ietf-bier-mvpn].
For a deployment where more than one (typically two) anchor routers exist in the area, it is expected to use only one BIER sub-domain for the ease of configuration, while supporting the anchor routers with different BIER labels or with same BIER label (anycast label). The BIER label of an anchor is selected from SRGB and called a BIER SRGB-label. Each of the routers in the area do not have to allocate a local label (from SRLB) for a specific (Sub-domain, BSL, SI) tuple when building the BIER forwarding table. Instead, it uses the BIER SRGB-label for building the BIER forwarding table of the BIER label itself. More than one BIER SRGB labels for the same (Sub-domain, BSL, SI) tuple are allowed, each forming a forwarding table, and the local-allocated (from SRLB) BIER label forwarding table of the same (Sub-domain, BSL, SI) tuple can coexist as well.
Procedures of building the BIER SRGB label forwarding table are outside the scope of this document.
For many areas, it is not required to have a universe-unique sub-domain number or same sub-domain with universe-unique SI number from 0 to 255. For example, it is allowed for area 2 having a sub-domain 0 and SI from 0 to 10, while area 3 having a sub-domain 0 and SI from 0 to 10 too, only if their anchor routers are not the same.
The anchor information of Hybird SR and BIER MPLS is carried in a specific PTA as below.
+------------------------------------+
| Flags (1 octet) |
+------------------------------------+
| Tunnel Type = TBD (1 octet) |
+------------------------------------+
| MPLS Label (3 octets) |
+------------------------------------+ ------+
| Sub-domain-id (1 octet) | |
+------------------------------------+ |
| BFR-id (2 octets) | |
+------------------------------------+ |
| BFR-prefix (4 or 16 octets) | Tunnel Identifier
+------------------------------------+ |
| Anchor BIER Label ( 3 octets) | |
+------------------------------------+ |
| Anchor Node IP ( 4 or 16 octets) | |
+------------------------------------+ ------+
Figure 3: PTA for Hybird SR and BIER MPLS Tunnel
Ingress edge router has a per-flow forwarding state, indicating forwarding to every anchor router(s) of an egress area, and a BitString representing the final egress edge routers.
Ingress edge router can have its own policy about how to reach some anchor router.
Each of the anchor router(s) has a per-SRGB-label BIER forwarding state, but don't have any per-VPN or per-flow state. When an anchor router receives a BIER packet encapsulated in the Segment Routing label, it pops the Segment Routing label, sees the BIER SRGB-label, and performs hop-by-hop BIER replication with BIER SRGB-label MPLS encapsulation. The hop-by-hop BIER forwarding can further change to on-hop replications directly to the egress edge routers over Segment Routing tunnels, by building BIER forwarding table over Segment Routing on anchar router(s) and egress edge routers only.
Each egress edge router has a per-flow forwarding state, indicating forwarding a packet to its interfaces connected to CE or receivers. Egress edge router can use the upstream-assigned vpnlabel to differentiate the local VRF.
MVPN service using SRv6 and BIER IPv6 Encapsulation is also possible by using the [I-D.xie-bier-6man-encapsulation], which allows BIER packets to run on a SRv6 tunnel.
Procedures of building the BIER IPv6 BIFT-ID forwarding table are outside the scope of this document.
The anchor information of Hybird SPv6 and BIER IPv6 is carried in a specific PTA as below.
+------------------------------------+
| Flags (1 octet) |
+------------------------------------+
| Tunnel Type = TBD (1 octet) |
+------------------------------------+
| MPLS Label (3 octets) |
+------------------------------------+ ------+
| Sub-domain-id (1 octet) | |
+------------------------------------+ |
| BFR-id (2 octets) | |
+------------------------------------+ |
| BFR-prefix (16 octets) | Tunnel Identifier
+------------------------------------+ |
| Anchor BIER BIFT-ID ( 3 octets) | |
+------------------------------------+ |
| Anchor Node BIER SID ( 16 octets) | |
+------------------------------------+ ------+
Figure 4: PTA for Hybird SRv6 and BIER IPv6 Tunnel
Ingress edge router has a per-flow forwarding state, indicating forwarding to every anchor router(s) of an egress area.
Ingress edge router can have its own policy about how to reach some anchor router.
Each of the anchor router(s) has a per-BIFT-ID BIER forwarding state, but doesn't have any per-VPN or per-flow state. When an anchor router receives a BIER packet encapsulated in the SRv6 SRH header, it first pops the SRH, and then sees the BIER specific Multicast address, and then performs the hop-by-hop BIER replication by using the BIFT-ID and other BIER header fields as described in [I-D.xie-bier-6man-encapsulation].
Egress edge router has a per-flow forwarding state, indicating forwarding a packet to its interfaces connected to CE or receivers. Egress edge router can use the upstream-assigned vpnlabel to differentating the local VRF.
The procedures of this document do not, in themselves, provide privacy, integrity, or authentication for the control plane or the data plane.
Allocation is expected from IANA for two new tunnel type codepoints for "Hybird SR-MPLS and BIER MPLS Tunnel" and "Hybird SRv6 and BIER IPv6 Tunnel" from the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |