BIER Z. Zhang Internet-Draft Juniper Networks Intended status: Standards TrackMay 29,October 3, 2019 Expires:November 30, 2019April 5, 2020 BIER Penultimate Hop Poppingdraft-ietf-bier-php-02draft-ietf-bier-php-03 Abstract Bit Index Explicit Replication (BIER) can be used as provider tunnel forMVPN/GTM [RFC6514]Multicast Virtual Private Network (MVPN) [RFC6514], Global Table Multicast [RFC7716] orEVPN BUMEthernet Virtual Private Network (EVPN) [RFC7432]. It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER incapable transit routers. However those methods assume theMVPN/EVPN PEsMVPN/ EVPN Provider Edges (PEs) areassumed to beBIERcapable - they are BFIRs/BFERs.capable. This document specifies a method to allow BIER incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstreamBFR (connectedBIER Forwarding Router (BFR) that is connected directly or indirectly via atunnel) oftunnel to a BIER incapable PE remove the BIER header and send the payload to the PE. Requirements Language 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. 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). 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 onNovember 30, 2019.April 5, 2020. Copyright Notice Copyright (c) 2019 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. Table of Contents 1.Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 2.Introduction . . . . . . . . . . . . . . . . . . . . . . . . 23.2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 34.3. Security Considerations . . . . . . . . . . . . . . . . . . . 45.4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57.6. References . . . . . . . . . . . . . . . . . . . . . . . . . 57.1.6.1. Normative References . . . . . . . . . . . . . . . . . . 57.2.6.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1.Terminologies Familiarity with BIER/MVPN/EVPN protocols and procedures is assumed. Some terminologies are listed below for convenience. [To be added]. 2.Introduction The BIER architecture includes three layers: the "routing underlay", the "BIER layer", and the "multicast flow overlay". The multicast flow overlay is responsible for theBFERsBIER Forwarding Egress Routers (BFERs) to signal toBFIRsBIER Forwarding Ingress Routers (BFIRs) that they are interested in receiving certain multicast flows so that BFIRs can encode the correct bitstring for BIER forwarding by the BIER layer. MVPN and EVPN are two similar overlays where BGP Auto-Discovery routes for MVPN/EVPN are exchanged among all PEs to signal which PEs need to receive multicast traffic for all or certain flows. Typically the same provider tunnel type is used for traffic to reach all receiving PEs. Consider an MVPN/EVPN deployment where enoughP/PEprovider routers are BIER capable for BIER to become the preferred the choice of provider tunnel. However, some PEs cannot be upgraded to support BIER forwarding. While there are ways to allow an ingress PE to send traffic to some PEs with one type of tunnel and send traffic to some other PEs with a different type of tunnel, the procedure becomes complicated and forwarding is not optimized. One way to solve this problem is to use Penultimate Hop Popping (PHP) so that the upstream BFR can pop the BIER header and send the payload "natively" (note that the upstream BFR can be connected directly orindiretlyindirectly viaaany type of tunnel to the PE). This is similar toMPLSMulti-Protocol Label Switching (MPLS) PHP though it is the BIER header that is popped.In case of MPLS encapsulation, even the signaling is similar - a BIER incapable router signals as if it supported BIER, but to request PHP at the penultimate hop, it signals an Implicit Null label instead of a regular BIER label as the Label Range Base in its BIER MPLS Encapsulation sub-TLV.The transition of an existing MVPN/EVPN deployment with traditional provider tunnels to using BIER with some PEs not capable of receiving BIER packets can be incremental. All PEs are first upgraded to support BIER at least in the control plane, with those not capable of BIER forwarding requesting PHP. Then BIER capable ingress PEs independently and incrementally switch to BIER transport. While the above text uses MVPN/EVPN as example, BIER PHP is applicable to any scenario where the multicast flow overlay edge router does not supportBIER.BIER, as long as the edge router does not need to know the transmitting BFIR. This works well if a BIER incapable PE only needs to receive multicast traffic. If it needs to send multicast traffic as well, then it must Ingress Replicate to a BIER capable helper PE, who will in turn relay the packet to other PEs. The helper PE is either a Virtual Hub as specified in [RFC7024] for MVPN and [I-D.keyupate- bess-evpn-virtual-hub] for EVPN, or an AR-Replicator as specified in [I-D.ietf-bess-evpn-optimized-ir] for EVPN.3.2. Specifications The procedures in this section apply only if, by means outside the scope of this document, it is known that the payload after BIER header is one of the following: o MPLSpacketpackets with downstream-assigned label at top of stack (i.e., the Proto field in the BIER header is 1). For example, a label from a Domain-wide Common Block (DCB) is used as specified in[I-D.ietf-bess-mvpn-evpn-aggregation-label].[I- D.ietf-bess-mvpn-evpn-aggregation-label]. o Packets with VXLAN/NVGRE/GENEVE header [I-D.ietf-bier-evpn] (i.e. the Proto field in the BIER header specifies VXLAN/NVGRE/GENEVE per IANA assignments to be done for [I-D.ietf-bier-evpn]). A BIER incapable router, if acting as a multicast flow overlay router, MUST signal its BIER information as specified in [RFC8401] or[I-D.ietf-bier-ospf-bier-extensions][RFC8444] or[I-D.ietf-bier-idr- extensions],[I-D.ietf-bier-idr-extensions], with a PHP sub-sub-TLV included in the BIER sub-TLV attached to the BIER incapable router's BIER prefix to request BIER PHP from other BFRs. The sub-sub-TLV's type is TBD, and the length is 0. With MPLS encapsulation, the BIER incapable multicast flow overlay router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set the LabelRange Basefield in BIER MPLS Encapsulation sub-sub-TLV to Implicit Null Label [RFC3032]. With MPLS encapsulation, if a BFER does not support certain BSL, it MAY still advertise a corresponding BIER MPLS Encapsulation sub-TLV but set the LabelRange Basefield to Implicit Null Label. If a BFR follows section 6.9 of [RFC8279] to handle BIER incapable routers, it must treat a router as BIER incapable if theLabel Range Base dvertisedlabel advertised by the router is Implicit Null, or if the router advertises a PHP sub-sub-TLV, so that the router is not used as a transit BFR. If the downstream neighbor for a BIER prefix is the one advertising the prefix with a PHP sub-sub-TLV or with an Implicit Null Labelasin the LabelRange Basefield in its BIER MPLS Encapsulation sub-sub-TLV, then when the corresponding BIRT or BIFT entry is created/updated, the forwarding behavior MUST be that the BIER header is removed and the payload be sent to the downstream router without the BIER header, either directly or overaany type of tunnel.4.3. Security Considerations This specification does not introduce additional security concerns beyond those already discussed in BIER architecture and OSPF/ISIS/BGPexentionsextensions for BIER signaling.5.4. IANA Considerations This document requests a new sub-sub-TLV type value from the "Sub- sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV Codepoints" registry: Type Name ---- ---- TBD BIER PHP Request This document also requests a new sub-TLV type value from the OSPFv2 Extended Prefix TLV Sub-TLV registry: Type Name ---- ---- TBD BIER PHP Request6.5. Acknowledgements The author wants to thank Eric Rosen and Antonie Przygienda for their review, comments and suggestions. The author also wants to thank Senthil Dhanaraj for his suggestion of requesting PHP if a BFER does not support certain BSL.7.6. References7.1.6.1. Normative References [I-D.ietf-bess-mvpn-evpn-aggregation-label] Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- ietf-bess-mvpn-evpn-aggregation-label-02 (work in progress), December 2018. [I-D.ietf-bier-evpn] Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, "EVPN BUM Using BIER", draft-ietf-bier-evpn-01 (work in progress), April 2018. [I-D.ietf-bier-idr-extensions] Xu, X., Chen, M., Patel, K., Wijnands, I., and T. Przygienda, "BGP Extensions for BIER", draft-ietf-bier-idr-extensions-06idr-extensions-07 (work in progress),JanuarySeptember 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>. [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non- MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 2018, <https://www.rfc-editor.org/info/rfc8296>. [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. Zhang, "Bit Index Explicit Replication (BIER) Support via IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, <https://www.rfc-editor.org/info/rfc8401>. [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 Extensions for Bit Index Explicit Replication (BIER)", RFC 8444, DOI 10.17487/RFC8444, November 2018, <https://www.rfc-editor.org/info/rfc8444>.7.2.6.2. Informative References [I-D.ietf-bess-evpn-optimized-ir] Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. Sajassi, "Optimized Ingress Replication solution for EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in progress), October 2018. [I-D.keyupate-bess-evpn-virtual-hub] Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W. Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft-keyupate-bess-evpn-virtual-hub-01keyupate-bess-evpn-virtual-hub-02 (work in progress),October 2018.September 2019. [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>. [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, <https://www.rfc-editor.org/info/rfc7024>. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>. Author's Address Zhaohui Zhang Juniper Networks EMail: zzhang@juniper.net