| Network Working Group | J. Xie |
| Internet-Draft | Huawei Technologies |
| Intended status: Standards Track | M. McBride |
| Expires: July 17, 2020 | Futurewei |
| S. Dhanaraj | |
| Huawei Technologies | |
| L. Geng | |
| China Mobile | |
| January 14, 2020 |
Use of BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 networks
draft-xie-bier-ipv6-mvpn-02
This draft defines the procedures and messages for using Bit Index Explicit Replication (BIER) for Multicast VPN Services in IPv6 networks using the BIER IPv6 encapsulation. It provides a migration path for Multicast VPN service using BIER MPLS encapsulation in MPLS networks to multicast VPN service using BIER IPv6 encapsulation (BIERv6) in IPv6 networks.
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] and [RFC8174].
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 July 17, 2020.
Copyright (c) 2020 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] is an architecture that provides optimal multicast forwarding without requiring intermediate routers to maintain any per-flow state by using a multicast-specific BIER header. BIERv6 refers to the deployment of BIER in IPv6 networks using the BIER IPv6 encapsulation format defined in [I-D.xie-bier-ipv6-encapsulation].
This document describes a method to realize MVPN services using BIER as a P-tunnel in the IPv6 Networks (BIERv6 Networks). It defines a method to use an IPv6 address, called Src.DTx in this document, as source address of an IPv6 header, to identify the MVPN instance at the Egress PE. The Src.DTx address used as source address of a BIERv6 packet represent both the context and the upstream-assigned VPN Label in MVPN scenario defined in [RFC8556].
The Src.DTx address can be a normal IPv6 address of the BFR, for example, a loopback address of the BFR. The Src.DTx address can also be an IPv6 address allocated from an IPv6 address block, for example, an IPv6 address allocated from an SRv6 locator if BIERv6 MVPN is deployed in an SRv6 network.
In particular, MVPN deployment in IPv6 networks relies on L3VPN deployment on IPv6 networks firstly, thus the c-multicast routing procedure like UMH Selection can be done. As an example, the L3VPN deployment in SRv6 networks can be referred to [I-D.ietf-bess-srv6-services].
GTM defined in [RFC7716] is also covered in this document, as GTM shares the same BGP-MVPN signaling, while providing an approach of Non-VPN multicast over a service provider core with various P-tunnel type. For the same reason of UMH selection as a base of GTM, the Global IPv4/IPv6 over SRv6 networks can be referred to [I-D.ietf-bess-srv6-services].
Readers of this document are assumed to be familiar with the terminology and concepts of the documents listed as Normative References. Additionally the following terms are used through out the document.
The BGP-MVPN I-PMSI A-D (Type 1) or S-PMSI A-D (Type 3) route (called x-PMSI A-D route in this document), advertised by Ingress PE carries the BIER (Type 11) PTA as specified in [RFC8556]. The BIER PTA carried in the x-PMSI A-D route is used for explicitly tracking the receiver-site PEs which are interested in a specific multicast flow. It includes three BIER-specific fields, Sub-domain-id, BFR-id, and BFR-prefix. For BIER P-tunnel using the BIERv6 encapsulation in IPv6 networks, the BFR-prefix field in the PTA MUST be set to the BFIR IPv6 prefix and the MPLS Label field in the PTA MUST set to 0. For MVPN over BIERv6, the Src.DTx IPv6 address of the BFIR is used to identify the VRF instead of an MPLS Label. The Src.DTx IPv6 Address (Src.DT6 or Src.DT4 or Src.DT46) MUST be carried within an SRv6 L3 Service TLV [I-D.ietf-bess-srv6-services] of BGP Prefix-SID attribute in the x-PMSI A-D route.
The Ingress PE encapsulates the c-multicast IP packet with BIERv6 header and the source address in the outer IPv6 header will be set to the Src.DTx IPv6 address advertised in the BGP-MVPN x-PMSI A-D routes. See section 3 of [I-D.xie-bier-ipv6-encapsulation] for the detailed packet format.
Egress PE (BFER) receiving the x-PMSI A-D routes with BIER PTA and SRv6 L3 Service TLV learns the Src.DTx IPv6 address and uses it to identify the VRF of the c-multicast packet.
When Egress PE receives a BIERv6 packet and the self bfr-id is set in the bit-string field of the BIERv6 header, it retrieves the Src.DTx IPv6 address from the source address of the IPv6 header to determine the VRF and the Address Family (AF) of the c-multicast data packet, and performs the MFIB lookup in the corresponding table.
[RFC8556] specifies the protocol and procedures to be followed by the Ingress and Egress PEs to use BIER as a P-tunnel for MVPN in MPLS networks. This section specifies the required changes and procedures in addition to support BIER as a P-tunnel in IPv6 networks using BIERv6.
In a IPv6 service provider network, many of the IP address fields used in the BGP-MVPN routes are IPv6 address as specified in [RFC6515]. These are listed below.
On the Ingress PE (BFIR), the BGP-MVPN x-PMSI A-D route is constructed as per the procedures specified in [RFC8556] and with the following specifications.
If the MVPN is IPv4 MVPN, the Src.DTx can be either Src.DT4 or Src.DT46. If the MVPN is IPv6 MVPN, the Src.DTx can be either Src.DT6 or Src.DT46. The distribution of the x-PMSI A-D routes uses the Src.DTx according to the local configuration, and is independent to the use of End.DTx in VPN-IP unicast routes of this VPN. For example, one can use End.DT46 for VPNv4 and VPNv6 unicast routes, but use Src.DT4 for the MVPN routes for the same VPN. Another example, one can use End.DX for VPNv4 unicast routes, but use Src.DT46 for the MVPN routes for the same VPN.
BFIR MAY carry the BGP Prefix-SID attribute only in I-PMSI A-D route when I-PMSI A-D route is used, while other S-PMSI A-D routes do not carry the BGP Prefix-SID attribute.
BFIR MAY carry the BGP Prefix-SID attribute only in wildcard S-PMSI A-D routes when the "S-PMSI Only" mode as described in [RFC6625] is used, while other S-PMSI A-D routes do not carry the BGP Prefix-SID attribute.
On the Egress PE (BFER), the BGP-MVPN x-PMSI A-D route is processed as per the procedures specified in [RFC8556] and with the following specifications:
Valid BGP-MVPN x-PMSI A-D route received by an Egress PE (BFER) is stored locally, and the Src.DTx IPv6 Address carried in the SRv6 L3 service TLV is used to identify the VRF of a c-multicast data packet. This may be populated into forwarding table only when there is c-multicast flow state with UMH of the specific BFIR this Src.DTx located in.
If more than one x-PMSI A-D routes belonging to the same VRF has different Src.DTx value, the processing is determined by the local policy of the BFER.
If more than one x-PMSI A-D routes belonging to different VRF has the same Src.DTx value, the BFER must log an error, and a BIERv6 packet with this Src.DTx as the IPv6 source address MUST be dropped.
The BGP Prefix-SID attribute (which may include the Src.DTx in SRv6 L3 Service TLV) MUST NOT be carried in Leaf A-D route upon sending, and MUST be ignored upon reception.
As specified in [RFC7716], Global Table Multicast (GTM) uses the same Subsequent Address Family Identifier (SAFI) value, the same Network Layer Reachability Information (NLRI) format, and the same procedures of MVPN with only a few adaptions. It support for both IPv4 and IPv6 multicast flows over either an IPv4 or IPv6 SP infrastructure. GTM over BIERv6 core is obviously a case of IPv4/IPv6 multicast over an IPv6 SP infrastructure with BIERv6 data-plane.
The BIER (Type 11) PTA attribute and the BGP Prefix-SID attribute are carried in the x-PMSI A-D route in GTM cases. When the a BGP-MVPN x-PMSI A-D route is received by Egress PE, it is stored locally, and the Src.DTx IPv6 Address of the Ingress PE in the route is used to determine the VRF of a packet, which is the 'public' VRF in the case of GTM.
There are some other attributes listed below for GTM over a BIERv6 core:
GTM IPv4 multicast over an BIERv6 core may be considered an alternative to support IPv4 IPTV content delivery during transition to IPv6 period comparing to [RFC8114]. They both use IPv4-in-IPv6 encapsulation, while BIERv6 uses an additional BIER header within an IPv6 Extension header to support stateless core.
BIER IPv6 encapsulation (BIERv6) [I-D.xie-bier-ipv6-encapsulation] is used for forwarding the c-multicast traffic through an IPv6 core. The following diagram shows the progression of an MVPN c-multicast packet as it enters and leaves the intra-AS service-provider network.
+---------------+ +---------------+
| P-IPv6 Header | | P-IPv6 Header |
| (SA=Src.DTx | | (SA=Src.DTx |
| DA=End.BIER) | | DA=End.BIER) |
+---------------+ +---------------+
| P-IPv6 ExtHdr | | P-IPv6 ExtHdr |
| (BIER header) | | (BIER header) |
++=========++ ++=============++ ++=============++ ++=========++
||C-IP Hdr || || C-IP Hdr || || C-IP Hdr || ||C-IP Hdr ||
++=========++ >> ++=============++ >> ++=============++ >> ++=========++
||C-Payload|| || C-Payload || || C-Payload || ||C-Payload||
++=========++ ++=============++ ++=============++ ++=========++
CE1-----------PE1------------------P2------------------PE2-----------CE2
Figure 1: BIERv6 MVPN/GTM Intra-AS
In case of inter-AS scenario, BIERv6 packets may travel through unicast to a Boarder Router (BR), and then replicate in a single intra-AS BIERv6 domain. How such non-segmented BIERv6 scenario can be supported is outside the scope of this document.
How segmented MVPN, for example, between BIERv6 and BIERv6, or between BIERv6 and Ingress Replication(IR) in Non-MPLS IPv6 networks, is outside the scope of this document.
The Src.DTx SHOULD support as destination address of an ICMPv6 packet. If a loopback address of the BFR is used as Src.DTx address, this is supported. If an address from an SRv6 locator is used as Src.DTx address, the following pseudo-code describes how a packet with Src.DTx as destination address is handled:
1. IF Last_NH = ICMPv6 ;;Ref1
2. Send to CPU.
3. ELSE
4. Drop the packet.
Ref1: ICMPv6 packet using Src.DT4, Src.DT6 or Src.DT46 as destination address.
Each BFIR is expected to know the Maximum Transmission Unit (MTU) of the BIER domain. This may be known by provisioning, or by method specified in [draft-ietf-bier-mtud]. The section 3 of [RFC8296] applies.
The ingress PE (BFIR) should not copy the Time to Live (TTL) field from the payload IP header received from a CE router to the delivery IP header. Setting the TTL of the delivery IP header is determined by the local policy of the ingress PE (BFIR) router per section 3 of [RFC8296].
The security considerations SEC-1, SEC-2, SEC-3 defined in [I-D.ietf-spring-srv6-network-programming] apply equally to this document.
Allocation is expected from IANA for the following Src.DTx functions codepoints from the "SRv6 Endpoint Behaviors" sub-registry.
Values 68, 69, 70 is suggested for Src.DT6, Src.DT4, Src.DT46 respectively.
+-------+--------+--------------------------+------------+
| Value | Hex | Endpoint function | Reference |
+-------+--------+--------------------------+------------+
| TBD | TBD | Src.DT6 | This draft |
+-------+--------+--------------------------+------------+
| TBD | TBD | Src.DT4 | This draft |
+-------+--------+--------------------------+------------+
| TBD | TBD | Src.DT46 | This draft |
+-------+--------+--------------------------+------------+
Src.DT6 Source address indicating decapsulation and IPv6 table lookup
e.g. IPv6-MVPN (equivalent to per-VRF VPN label in RFC8556)
Src.DT4 Source address indicating decapsulation and IPv4 table lookup
e.g. IPv4-MVPN (equivalent to per-VRF VPN label in RFC8556)
Src.DT46 Source address indicating decapsulation and IP table lookup
e.g. IP-MVPN (equivalent to per-VRF VPN label)
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |