BIER Workgroup H. Bidgoli, Ed. Internet Draft A. Dolganow Intended status: Standard Track Nokia Fengman Xu Verizon Expires: December 23, 2017 June 21, 2017 PIM Tunneling Through BIER Core draft-hfa-bier-pim-tunneling-00 Abstract Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for PIM to be tunneled through a BIER core. Allowing access CEs or PEs to run traditional PIM multicast services including draft rosen multicast MVPN through a core of BIER. Status of this Memo 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list Bidgoli, Xu et al. Expires December 23, 2017 [Page 1] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 8, 2017. Copyright Notice Copyright (c) 2017 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 (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PIM Tunneling Through BIER domain . . . . . . . . . . . . . . . 5 3.1. PIM-BFIR procedure . . . . . . . . . . . . . . . . . . . . 6 3.1.1. BIER packet construction at PIM BFIR . . . . . . . . . 6 3.2. Tunneling PIM through the BIER domain procedure . . . . . . 7 3.3. PIM-BFER procedure . . . . . . . . . . . . . . . . . . . . 7 4. Datapath Forwarding . . . . . . . . . . . . . . . . . . . . . . 8 4.1. BIER reverse path forwarding table . . . . . . . . . . . . 8 4.2. Datapath traffic flow . . . . . . . . . . . . . . . . . . . 9 5. PIM-ASM behavior . . . . . . . . . . . . . . . . . . . . . . . 9 6. Draft Rosen multicast vpn behavior . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Bidgoli, Xu et al. Expires December 23, 2017 [Page 2] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 Most Service Providers understand the benefit of BIER and would like a Core network that supports scalable multicast solution by removing the multicast states and deploying BIER. That said greenfield deployment of BIER might not be possible for providers that deploy MVPN technology, or have more than 256 PEs in their network. Consider the following: 1.Most service providers deploy MVPN technology for multicast today. Their network structure typically is a Core network, which connects edge networks containing PEs. These PEs run MVPN services like draft rosen multicast vpns. In a typical tier one provider the number of PEs is well beyond 1K of routers. As the edge network expands the scale of multicast states in the core could test the routers limits. As such it is attractive to create a stateless BIER core which can transport MVPN technology. By deploying BIER in the core of the network the bottle necks for multicast states is removed. By pushing the multicast states to the edge provider (P) routers, a more manageable multicast state can be achieved. 2.Deploying greenfield BIER services for most providers could be a challenge. It might be attractive to deploy bier in multiple phases. Starting from the core of the network to remove the massive multicast state generated by traditional MVPN services is an ideal evolution path. By tunneling traditional MVPN technology through a BIER core an scalable and manageable network can be created. 3.Most vendors support 256 bits in the BIER header. Identifying only 256 PEs or CEs via a single BIER packet. Scaling beyond 256 PEs or CEs "might" require packet duplation depending on network topology. This packet duplication will be done via BIER Set Index (SI) which is explained in draft-ietf-bier-architecture. In the cases that packet duplication can't be avoid it might be desirable to segment the network to traditional MVPN technology at the access and BIER in the core. By moving the Bier in the core all core routers could be presented via the 256 bits in the BIER header. In all above cases it might be attractive to be able to tunnel traditional MVPN services over a BIER core. This draft explains the procedure to tunnel PIM through a BIER core, as such enable tunneling of traditional MVPN services like draft- rosen multicast vpns through a core of BIER. The procedures of PIM tunneling should be used at the BIER edge routers. The BIER edge routers (BER) are connected to legacy PIM routers on one side and BIER routers on the other side. PIM routers continue to send PIM state messages to the BER but the BER does not Bidgoli, Xu et al. Expires December 23, 2017 [Page 3] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 propagate PIM packets natively into the BIER sub-domain. Instead it will tunnel the PIM through BIER network. In this draft the BFIR and BFER are the BER from multicast traffic point of view and not PIM signaling. That said the PIM BFIR (P-BFIR) and PIM (P-BFER) are BER from PIM signaling point of view. As such a P-BFIR would be a BFER of the multicast traffic and a P- BFER would be a BFIR of the multicast traffic. 2. Conventions used in this document 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 RFC 2119 [RFC2119]. 2.1. Definitions Some of the terminology specified in [I-D.draft-ietf-bier- architecture-05] is replicated here and extended by necessary definitions: BIER: Bit Index Explicit Replication (The overall architecture of forwarding multicast using a Bit Position). BFR: Bit Forwarding Router (A router that participates in Bit Index Multipoint Forwarding). A BFR is identified by a unique BFR- prefix in a BIER domain. BFIR: Bit Forwarding Ingress Router (The ingress border router that inserts the BM into the packet). Each BFIR must have a valid BFR-id assigned. In this draft BIER will be used for forwarding and tunneling of control plain packet (i.e. PIM) and forwarding dataplain packets. BFIR is term used for dataplain packet forwarding. BFER: Bit Forwarding Egress Router. A router that participates in Bit Index Forwarding as leaf. Each BFER must be a BFR. Each BFER must have a valid BFR-id assigned. In this draft BIER will be used for forwarding and tunneling of control plain Bidgoli, Xu et al. Expires December 23, 2017 [Page 4] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 packet (i.e. PIM) and forwarding dataplain packets. BFIR is term used for dataplain packet forwarding. P-BFIR: PIM-Bit Forwarding ingress router. Ingress boundary router between PIM domain and BIER domain. It tunnels PIM packet through a BIER domain toward the source. P-BFER: PIM-Bit Forwarding egress router. Egress boundary router between BIER domain and PIM domain. It decapsulates PIM packet from a BIER tunnel and forwards it to the PIM domain. BRT: BIER RPF Table, is built on the P-BFER. It tracks which P-BFIR is interested in a group. It is used to map the group to the P-BFIR BIER prefix. BFT: Bit Forwarding Tree used to reach all BFERs in a domain. BIFT: Bit Index Forwarding Table. BIER sub-domain: A further distinction within a BIER domain identified by its unique sub-domain identifier. A BIER sub-domain can support multiple BitString Lengths. BFR-id: An optional, unique identifier for a BFR within a BIER sub- domain. 3. PIM Tunneling Through BIER domain Suppose BIER sub-domain is to be an IGP area or instance. The BIER edge routers (BER) can be ABRs that are connected to edge network via IGP or BGP, or they can be any provider (P) router that is selected to act as the BER in that BIER sub-domain. Bidgoli, Xu et al. Expires December 23, 2017 [Page 5] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 Each BER is configured as per BIER requirements explained in draft- ietf-bier-architecture. The BERs receive PIM joins from the downstream routers because they are on the path toward the source. Additionally, on these BERs all interfaces which are PIM enabled are configured to tunnel PIM over BIER. 3.1. PIM-BFIR procedure When PIM joins for a certain (S,G) arrives on a BER, in this case the P-BFIR (BFIR from PIM signaling point of view). This router first find the route to the source. The route to the source is assumed to be an IGP route. The BER tries to resolve the source (S), in the process it of resolving the source the SPF calculation can return the P-BFER that is in the path to the source. The procedure to find the P-BFER (BFER from PIM signaling point of view) can be via 2 mechanism and is beyond the scope of this draft. 1.The P-BFER can be an ABR or ASBR router which is summarizing the route to the source, and as such is the source of this route. 2.The P-BFER can be resolved via SPF calculation and finding the first BFIR in the path the source. The P-BFIR will become the BFER for multicast traffic point of view. This P-BFIR will track all the PIM interfaces that are interested in the (S,G) and create multicast states for all PIM routers attach to it. This BFER route will have incoming interface (RPF) as BIER "tunnel" interface and outgoing interface as the interface on which PIM Join was received. If there is another PIM Join for the same multicast (S,G) entry on some other interface, that interface gets added in the outgoing interface list. The P-BFIR after discovering the P-BFER and its BFR-ID (flooded via IGP BIER extension) will construct the BIER header via the BIFT. The PIM packet is encapsulated in the BIER header and transported through BIER domain to P-BFER. 3.1.1. BIER packet construction at PIM BFIR The BIER header will be encoded with the BFR-id of the P-BFER(with appropriate bit set in the bitstring) and PIM Join is then encapsulated in the packet. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Bidgoli, Xu et al. Expires December 23, 2017 [Page 6] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BIFT-id | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Nibble | Ver | BSL | Entropy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OAM|Rsv| DSCP | Proto | BFIR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BitString (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ BitString (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BIERHeader.Proto = PIM BIERHeader.BitString= Bit corresponding to the BFR-ID of the P-BFER BIERHeader.BFIR-id = BFR-Id of the BER originating the encapsulated PIM packet, i.e. the P-BFIR. Rest of the values in the BIER header are determined based on the network (MPLS/non-MPLS), capabilities (BSL), and network configuration. 3.2. Tunneling PIM through the BIER domain procedure Throughout the BIER domain the BIER forwarding procedure is in par with draft-ietf-bier-architecture. No BIER router will examine the tunnel PIM packet. As such there is no multicast state build in the BIER domain. The packet will be forwarded through the BIER domain until it reaches the BER with matching BFR-ID as in the BIERHeader.Bitstring. This BER (P-BFER) will examine the packet and know that it is a PIM packet from BIERHeader.Proto field and farther processing is needed. 3.3. PIM-BFER procedure After receiving the BIER packet and processing the PIM payload encapsulated in BIER packet the P-BFER will remove the BIER header from PIM packet and lookup the route to the source, if the source is in PIM domain, it forwards the PIM packet toward the source. With same token the P-BFER creates a multicast state with incoming interface as same interface that PIM join packet was forwarded and outgoing interfaces of BIER-Header.BFIR-id. Bidgoli, Xu et al. Expires December 23, 2017 [Page 7] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 The P-BFER will also build a BIER reverse path forwarding table (BRT) table, using the BIERHeader.BFIR-id and the Group specified in the arriving PIM packet (S,G). BRT will be used by BFIR for datapath forwarding. The router keeps track of all BFIR-ids interested in the Group specified in the (S,G) and updates the multicast state and populates the BRT accordingly. It should be noted this router can also receive and forward PIM packet from other routers in the PIM domain and update the muticast state accordingly. At this point the end-to-end multicast traffic flow setup is complete. 4. Datapath Forwarding 4.1. BIER reverse path forwarding table The BIER RPF table (BRT) is needed on the BFIR so the multicast traffic can find the P-BFIR ID and append the correct BIT index to the BIER header for the multicast traffic before forwarding to BIER domain. This table is built on the P-BFER buy using info from PIM packet and its corresponding BIER header. The PIM packet can provide the specific Group (G) address, meanwhile its corresponding BIER header can provide the originating P-BFIR ID. The P-BFIR is the last BIER router in the BIER domain or the BFER from datapath point of view. These two pieces of information will be used to build BRT. It should be noted that a single group can be associated with multiple P-BFIR IDs, as an example multiple MVPN leaf routers behind BIER domain are interested in the same group. These LEAF PEs are reachable via different P-BFIRs. When the correct P-BFIR(s) (BFER(s)) are found in this table their P- BFIR ID can be used to do a lookup in BIFT and appropriate BIT indexes appended to the BIER header before forwarding the packet to BIER domain. As an example in the network below: Bidgoli, Xu et al. Expires December 23, 2017 [Page 8] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 (BFIR) (BFER) S--(P-BFER)---BIER-DOMAIN---(P-BFIR)--A (join (S,G1),(S,G2)) |-----C (join (S,G1),(S,G3)) |-----E (join (S,G3)) The BRT is as follow: ------------------------ | Group | P-BFIR | ======================== | (G1) | C,A | ------------------------ | (G2) | A | ------------------------ | (G3) | E,C | ------------------------ And the BIFT is as follow: ---------------------------- | BFR-id | BFR-NBR | | (SI:Bitstring) | | ============================ | 1 (0:0001) | C | ---------------------------- | 3 (0:0100) | E | ---------------------------- | 4 (0:1000) | A | ---------------------------- As such a multicast dataplain packet arriving with destination G1 will have the BITs (0:1001) and a packet arriving with destination of G3 will have the BITs of (0:0101) 4.2. Datapath traffic flow When the multicast data traffic arrives on the BFIR (P-BFER) the router will find the destination IP of the traffic (i.e. group address) in the BRT. The BFIR then finds all the P-BFIR (BFER) that are interested in this group from the BRT table. The router then constructs the BIERHeader.BitString with all the BFIR interested in the group and will forward the packet to the BIER domain. The BFER(s) will accept the packets and remove the BIER header and forward the multicast packet as per pre-build multicast state for (G) and its outgoing interfaces. 5. PIM-ASM behavior In case of PIM ASM the procedure for LEAFs joining RP or the source Bidgoli, Xu et al. Expires December 23, 2017 [Page 9] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 is same as above. The unicast (source registration) traffic from source to RP will be flooded throughout the BIER domain as regular unicast traffic without BIER involvement. 6. Draft Rosen multicast vpn behavior Over the years draft rosen mvpn has evolved with many different type of signaling. As an example, with AD and C-Multicast signaling of PIM or C- Multicast of PIM and AD of BGP. The above mechanism works with draft rosen mvpn as long the C- multicast signaling is done via PIM. The provider PIM for MVPN can be forwarded from Root and LEAF PE with above explained mechanism. The multicast traffic has to be forwarded via GRE tunnel. That said the AD signaling can be done via MP-BGP. Future drafts will address the NG-MVPN and MPLS tunneling. 7. Security Considerations TBD 7.1. Normative References [BIER_ARCH] Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast using Bit Index Explicit Replication", internet-draft draft-ietf-bier-architecture-05, October 2016. [DRAFT ROSEN] E. Rosen, Y. Cai, I. Wijnands, draft-rosen-vpn.mcast- 15, June 2010 (RFC 6037) 7.2. Informative References [BGP_BIER_EXTENSIONS] Xu, X., Chen, M., Patel, K., Wijnands, I., and A. Przygienda, "BGP Extensions for BIER", internet-draft draft-ietf- bier-idr-extensions-02.txt, June 2017. [BIER-OAM] Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., and G. Mirsky, "BIER Ping and Trace", internet-draft draft-ietf-bier- ping-01.txt, January 2017. [BIER_MVPN] Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using Bier", internet-draft draft-ietf-bier-mvpn-05, January 2017. Bidgoli, Xu et al. Expires December 23, 2017 [Page 10] Internet-Draft PIM Tunneling Through BIER Core June 21, 2017 [ISIS_BIER_EXTENSIONS] Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, "BIER Support via ISIS", internet-draft draft-ietf-bier- isis-extensions-04.txt, March 2017. [OSPF_BIER_EXTENSIONS] Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions for Bit Index Explicit Replication", internet-draft draft- ietf-ospf-bier-extensions-05.txt, March 2017. 8. Acknowledgments Authors' Addresses Hooman Bidgoli (editor) Nokia 600 March Rd. Ottawa, Ontario K2K 2E6 Canada Email: hooman.bidgoli@nokia.com Fengman Xu Verizon 400 International PKWY Richardson, Tx 75081 US Email: fengman.xu@verizon.com Andrew Dolganow Nokia 750D Chai Chee Rd 06-06, Viva Business Park Singapore 469004 Email: Andrew.dolganow@nokia.com Bidgoli, Xu et al. Expires December 23, 2017 [Page 11]