idnits 2.17.1 draft-ietf-bier-php-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7716], [RFC7432], [RFC6514]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 29, 2019) is 1793 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7716' is mentioned on line 13, but not defined == Missing Reference: 'I-D.ietf-bier-ospf-bier-extensions' is mentioned on line 146, but not defined == Missing Reference: 'RFC3032' is mentioned on line 155, but not defined == Unused Reference: 'I-D.ietf-bier-idr-extensions' is defined on line 215, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 220, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'RFC8444' is defined on line 242, but no explicit reference was found in the text == Unused Reference: 'I-D.keyupate-bess-evpn-virtual-hub' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 262, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-02 == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-06 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-optimized-ir-06 == Outdated reference: A later version (-02) exists of draft-keyupate-bess-evpn-virtual-hub-01 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track May 29, 2019 5 Expires: November 30, 2019 7 BIER Penultimate Hop Popping 8 draft-ietf-bier-php-02 10 Abstract 12 Bit Index Explicit Replication (BIER) can be used as provider tunnel 13 for MVPN/GTM [RFC6514] [RFC7716] or EVPN BUM [RFC7432]. It is 14 possible that not all routers in the provider network support BIER 15 and there are various methods to handle BIER incapable transit 16 routers. However the MVPN/EVPN PEs are assumed to be BIER capable - 17 they are BFIRs/BFERs. This document specifies a method to allow BIER 18 incapable routers to act as MVPN/EVPN PEs with BIER as the transport, 19 by having the upstream BFR (connected directly or indirectly via a 20 tunnel) of a PE remove the BIER header and send the payload to the 21 PE. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC2119. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 30, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 3. Specifications . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 7.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Terminologies 76 Familiarity with BIER/MVPN/EVPN protocols and procedures is assumed. 77 Some terminologies are listed below for convenience. 79 [To be added]. 81 2. Introduction 83 The BIER architecture includes three layers: the "routing underlay", 84 the "BIER layer", and the "multicast flow overlay". The multicast 85 flow overlay is responsible for the BFERs to signal to BFIRs that 86 they are interested in receiving certain multicast flows so that 87 BFIRs can encode the correct bitstring for BIER forwarding by the 88 BIER layer. 90 MVPN and EVPN are two similar overlays where BGP Auto-Discovery 91 routes for MVPN/EVPN are exchanged among all PEs to signal which PEs 92 need to receive multicast traffic for all or certain flows. 94 Typically the same provider tunnel type is used for traffic to reach 95 all receiving PEs. 97 Consider an MVPN/EVPN deployment where enough P/PE routers are BIER 98 capable for BIER to become the preferred the choice of provider 99 tunnel. However, some PEs cannot be upgraded to support BIER 100 forwarding. While there are ways to allow an ingress PE to send 101 traffic to some PEs with one type of tunnel and send traffic to some 102 other PEs with a different type of tunnel, the procedure becomes 103 complicated and forwarding is not optimized. 105 One way to solve this problem is to use Penultimate Hop Popping (PHP) 106 so that the upstream BFR can pop the BIER header and send the payload 107 "natively" (note that the upstream BFR can be connected directly or 108 indiretly via a tunnel to the PE). This is similar to MPLS PHP 109 though it is the BIER header that is popped. In case of MPLS 110 encapsulation, even the signaling is similar - a BIER incapable 111 router signals as if it supported BIER, but to request PHP at the 112 penultimate hop, it signals an Implicit Null label instead of a 113 regular BIER label as the Label Range Base in its BIER MPLS 114 Encapsulation sub-TLV. 116 The transition of an existing MVPN/EVPN deployment with traditional 117 provider tunnels to using BIER with some PEs not capable of receiving 118 BIER packets can be incremental. All PEs are first upgraded to 119 support BIER at least in the control plane, with those not capable of 120 BIER forwarding requesting PHP. Then BIER capable ingress PEs 121 independently and incrementally switch to BIER transport. 123 While the above text uses MVPN/EVPN as example, BIER PHP is 124 applicable to any scenario where the multicast flow overlay edge 125 router does not support BIER. 127 This works well if a BIER incapable PE only needs to receive 128 multicast traffic. If it needs to send multicast traffic as well, 129 then it must Ingress Replicate to a BIER capable helper PE, who will 130 in turn relay the packet to other PEs. The helper PE is either a 131 Virtual Hub as specified in [RFC7024] for MVPN and [I-D.keyupate- 132 bess-evpn-virtual-hub] for EVPN, or an AR-Replicator as specified in 133 [I-D.ietf-bess-evpn-optimized-ir] for EVPN. 135 3. Specifications 137 The procedures in this section apply only if, by means outside the 138 scope of this document, it is known that the payload after BIER 139 header is MPLS packet with downstream-assigned label at top of stack 140 (i.e., the Proto field in the BIER header is 1). For example, a 141 label from a Domain-wide Common Block (DCB) is used as specified in 142 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 144 A BIER incapable router, if acting as a multicast flow overlay 145 router, MUST signal its BIER information as specified in [RFC8401] or 146 [I-D.ietf-bier-ospf-bier-extensions] or [I-D.ietf-bier-idr- 147 extensions], with a PHP sub-sub-TLV included in the BIER sub-TLV 148 attached to the BIER incapable router's BIER prefix to request BIER 149 PHP from other BFRs. The sub-sub-TLV's type is TBD, and the length 150 is 0. 152 With MPLS encapsulation, the BIER incapable multicast flow overlay 153 router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set 154 the Label Range Base in BIER MPLS Encapsulation sub-sub-TLV to 155 Implicit Null Label [RFC3032]. 157 With MPLS encapsulation, if a BFER does not support certain BSL, it 158 MAY still advertise a corresponding BIER MPLS Encapsulation sub-TLV 159 but set the Label Range Base to Implicit Null Label. 161 If a BFR follows section 6.9 of [RFC8279] to handle BIER incapable 162 routers, it must treat a router as BIER incapable if the Label Range 163 Base dvertised by the router is Implicit Null, or if the router 164 advertises a PHP sub-sub-TLV, so that the router is not used as a 165 transit BFR. 167 If the downstream neighbor for a BIER prefix is the one advertising 168 the prefix with a PHP sub-sub-TLV or with an Implicit Null Label as 169 the Label Range Base in its BIER MPLS Encapsulation sub-sub-TLV, then 170 when the corresponding BIRT or BIFT entry is created/updated, the 171 forwarding behavior MUST be that the BIER header is removed and the 172 payload be sent to the downstream router without the BIER header, 173 either directly or over a tunnel. 175 4. Security Considerations 177 This specification does not introduce additional security concerns 178 beyond those already discussed in BIER architecture and OSPF/ISIS/BGP 179 exentions for BIER signaling. 181 5. IANA Considerations 183 This document requests a new sub-sub-TLV type value from the "Sub- 184 sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV 185 Codepoints" registry: 187 Type Name 188 ---- ---- 189 TBD BIER PHP Request 191 This document also requests a new sub-TLV type value from the OSPFv2 192 Extended Prefix TLV Sub-TLV registry: 194 Type Name 195 ---- ---- 196 TBD BIER PHP Request 198 6. Acknowledgements 200 The author wants to thank Eric Rosen and Antonie Przygienda for their 201 review, comments and suggestions. The author also wants to thank 202 Senthil Dhanaraj for his suggestion of requesting PHP if a BFER does 203 not support certain BSL. 205 7. References 207 7.1. Normative References 209 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 210 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 211 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 212 ietf-bess-mvpn-evpn-aggregation-label-02 (work in 213 progress), December 2018. 215 [I-D.ietf-bier-idr-extensions] 216 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 217 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 218 idr-extensions-06 (work in progress), January 2019. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 226 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 227 Explicit Replication (BIER)", RFC 8279, 228 DOI 10.17487/RFC8279, November 2017, 229 . 231 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 232 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 233 for Bit Index Explicit Replication (BIER) in MPLS and Non- 234 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 235 2018, . 237 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 238 Zhang, "Bit Index Explicit Replication (BIER) Support via 239 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 240 . 242 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 243 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 244 Extensions for Bit Index Explicit Replication (BIER)", 245 RFC 8444, DOI 10.17487/RFC8444, November 2018, 246 . 248 7.2. Informative References 250 [I-D.ietf-bess-evpn-optimized-ir] 251 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 252 Sajassi, "Optimized Ingress Replication solution for 253 EVPN", draft-ietf-bess-evpn-optimized-ir-06 (work in 254 progress), October 2018. 256 [I-D.keyupate-bess-evpn-virtual-hub] 257 Patel, K., Sajassi, A., Drake, J., Zhang, Z., and W. 258 Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft- 259 keyupate-bess-evpn-virtual-hub-01 (work in progress), 260 October 2018. 262 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 263 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 264 2012, . 266 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 267 Encodings and Procedures for Multicast in MPLS/BGP IP 268 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 269 . 271 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 272 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 273 VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, 274 . 276 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 277 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 278 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 279 2015, . 281 Author's Address 283 Zhaohui Zhang 284 Juniper Networks 286 EMail: zzhang@juniper.net