idnits 2.17.1 draft-ietf-bier-php-07.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]), 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 (December 7, 2021) is 876 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 14, but not defined == Missing Reference: 'RFC3032' is mentioned on line 158, but not defined == Unused Reference: 'I-D.ietf-bess-mvpn-evpn-aggregation-label' is defined on line 212, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-evpn' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 228, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-optimized-ir' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-virtual-hub' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 270, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 284, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-06 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-05 == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-07 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-optimized-ir-11 Summary: 1 error (**), 0 flaws (~~), 16 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 December 7, 2021 5 Expires: June 10, 2022 7 BIER Penultimate Hop Popping 8 draft-ietf-bier-php-07 10 Abstract 12 Bit Index Explicit Replication (BIER) can be used as provider tunnel 13 for Multicast Virtual Private Network (MVPN). Global Table Multicast 14 [RFC7716] or Ethernet Virtual Private Network (EVPN). It is possible 15 that not all routers in the provider network support BIER and there 16 are various methods to handle BIER-incapable transit routers. 17 However those methods assume the MVPN/EVPN Provider Edges (PEs) are 18 BIER-capable. This document specifies a method to allow BIER- 19 incapable routers to act as MVPN/EVPN PEs with BIER as the transport, 20 by having the upstream BIER Forwarding Router (BFR) that is connected 21 directly or indirectly via a tunnel to a BIER-incapable PE remove the 22 BIER header and send the payload to the PE. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC2119. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on June 10, 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 6.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The BIER architecture includes three layers: the "routing underlay", 77 the "BIER layer", and the "multicast flow overlay". The multicast 78 flow overlay is responsible for the BIER Forwarding Egress Routers 79 (BFERs) to signal to BIER Forwarding Ingress Routers (BFIRs) that 80 they are interested in receiving certain multicast flows so that 81 BFIRs can encode the correct bitstring for BIER forwarding by the 82 BIER layer. 84 MVPN and EVPN are two similar overlays where BGP Auto-Discovery 85 routes for MVPN/EVPN are exchanged among all PEs to signal which PEs 86 need to receive multicast traffic for all or certain flows. 87 Typically the same provider tunnel type is used for traffic to reach 88 all receiving PEs. 90 Consider an MVPN/EVPN deployment where enough provider routers are 91 BIER-capable for BIER to become the preferred choice of provider 92 tunnel. However, some PEs cannot be upgraded to support BIER 93 forwarding. While there are ways to allow an ingress PE to send 94 traffic to some PEs with one type of tunnel and send traffic to some 95 other PEs with a different type of tunnel, the procedure becomes 96 complicated and forwarding is not optimized. 98 One way to solve this problem is to use Penultimate Hop Popping (PHP) 99 so that the upstream BFR can pop the BIER header and send the payload 100 "natively" (note that the upstream BFR can be connected directly or 101 indirectly via any type of tunnel to the PE). This is similar to 102 Multi-Protocol Label Switching (MPLS) PHP though it is the BIER 103 header that is popped. 105 The transition of an existing MVPN/EVPN deployment with traditional 106 provider tunnels to using BIER with some PEs not capable of receiving 107 BIER packets can be incremental. All PEs are first upgraded to 108 support BIER at least in the control plane, with those not capable of 109 BIER forwarding requesting PHP. Then BIER-capable ingress PEs 110 independently and incrementally switch to BIER transport. 112 While the above text uses MVPN/EVPN as example, BIER PHP is 113 applicable to any scenario where the multicast flow overlay edge 114 router does not support BIER, as long as the edge router does not 115 need to know the transmitting BFIR or participate in BIER OAM 116 procedures. 118 This works well if a BIER-incapable PE only needs to receive 119 multicast traffic. If it needs to send multicast traffic as well, 120 then it must Ingress Replicate to a BIER-capable helper PE, who will 121 in turn relay the packet to other PEs. The helper PE is either a 122 Virtual Hub as specified in [RFC7024] for MVPN and [I-D.ietf-bess- 123 evpn-virtual-hub] for EVPN, or an AR-Replicator as specified in [I- 124 D.ietf-bess-evpn-optimized-ir] for EVPN. 126 2. Specifications 128 The BIER Penultimate Hop Popping is intended only for the scenario 129 where a multicast flow overlay router for a BIER domain does not 130 support BIER forwarding, either entirely or just for some particular 131 BitStringLengths. In the latter case, PHP is only for BIER packets 132 with those BitStringLengths. The flow overlay router would be a BFER 133 if it did support BIER forwarding, and PHP would not be done by its 134 penultimate hop. 136 The procedures in this section apply only if, by means outside the 137 scope of this document, it is known that the payload after BIER 138 header is one of the following: 140 o MPLS packets with downstream-assigned label at top of stack (i.e., 141 the Proto field in the BIER header is 1). For example, a label 142 from a Domain-wide Common Block (DCB) is used as specified in [I- 143 D.ietf-bess-mvpn-evpn-aggregation-label]. 145 o IPv4/IPv6 multicast packets for which Reverse Path Forwarding 146 check is disabled. 148 A BIER-incapable router, if acting as a multicast flow overlay 149 router, MUST signal its BIER information as specified in [RFC8401] or 150 [RFC8444] or [I-D.ietf-bier-idr-extensions], with a PHP sub-sub-TLV 151 included in the BIER sub-TLV attached to the BIER-incapable router's 152 BIER prefix to request BIER PHP from other BFRs. The sub-sub-TLV's 153 type is TBD, and the length is 0. 155 With MPLS encapsulation, the BIER-incapable multicast flow overlay 156 router MAY omit the BIER MPLS Encapsulation sub-sub-TLV, or MUST set 157 the Label field in BIER MPLS Encapsulation sub-sub-TLV to Implicit 158 Null Label [RFC3032]. 160 With MPLS encapsulation, if a BFER does not support certain BSL, it 161 MAY still advertise a corresponding BIER MPLS Encapsulation sub-TLV 162 but set the Label field to Implicit Null Label. 164 If a BFR follows section 6.9 of [RFC8279] to handle BIER-incapable 165 routers, it must treat a router as BIER-incapable if the label 166 advertised by the router is Implicit Null, or if the router 167 advertises a PHP sub-sub-TLV, so that the router is not used as a 168 transit BFR. 170 If the downstream neighbor for a BIER prefix is the one advertising 171 the prefix with a PHP sub-sub-TLV or with an Implicit Null Label in 172 the Label field in its BIER MPLS Encapsulation sub-sub-TLV, then when 173 the corresponding BIRT or BIFT entry is created/updated, the 174 forwarding behavior MUST be that the BIER header is removed and the 175 payload be sent to the downstream router without the BIER header, 176 either directly or over any type of tunnel. 178 3. Security Considerations 180 This specification does not introduce additional security concerns 181 beyond those already discussed in BIER architecture and OSPF/ISIS/BGP 182 extensions for BIER signaling. 184 4. IANA Considerations 186 This document requests a new sub-sub-TLV type value from the "Sub- 187 sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV 188 Codepoints" registry: 190 Type Name 191 ---- ---- 192 TBD BIER PHP Request 194 This document also requests a new sub-TLV type value from the OSPFv2 195 Extended Prefix TLV Sub-TLV registry: 197 Type Name 198 ---- ---- 199 TBD BIER PHP Request 201 5. Acknowledgements 203 The author wants to thank Eric Rosen and Antonie Przygienda for their 204 review, comments and suggestions. The author also wants to thank 205 Senthil Dhanaraj for his suggestion of requesting PHP if a BFER does 206 not support certain BSL. 208 6. References 210 6.1. Normative References 212 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 213 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 214 "MVPN/EVPN Tunnel Aggregation with Common Labels", draft- 215 ietf-bess-mvpn-evpn-aggregation-label-06 (work in 216 progress), April 2021. 218 [I-D.ietf-bier-evpn] 219 Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan, 220 "EVPN BUM Using BIER", draft-ietf-bier-evpn-05 (work in 221 progress), December 2021. 223 [I-D.ietf-bier-idr-extensions] 224 Xu, X., Chen, M., Patel, K., Wijnands, I., and A. 225 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 226 idr-extensions-07 (work in progress), September 2019. 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, 230 DOI 10.17487/RFC2119, March 1997, 231 . 233 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 234 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 235 Explicit Replication (BIER)", RFC 8279, 236 DOI 10.17487/RFC8279, November 2017, 237 . 239 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 240 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 241 for Bit Index Explicit Replication (BIER) in MPLS and Non- 242 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 243 2018, . 245 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 246 Zhang, "Bit Index Explicit Replication (BIER) Support via 247 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 248 . 250 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 251 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 252 Extensions for Bit Index Explicit Replication (BIER)", 253 RFC 8444, DOI 10.17487/RFC8444, November 2018, 254 . 256 6.2. Informative References 258 [I-D.ietf-bess-evpn-optimized-ir] 259 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 260 Sajassi, "Optimized Ingress Replication Solution for 261 Ethernet VPN (EVPN)", draft-ietf-bess-evpn-optimized-ir-11 262 (work in progress), November 2021. 264 [I-D.ietf-bess-evpn-virtual-hub] 265 Patel, K., Sajassi, A., Drake, J. E., Zhang, Z., and W. 266 Henderickx, "Virtual Hub-and-Spoke in BGP EVPNs", draft- 267 ietf-bess-evpn-virtual-hub-00 (work in progress), January 268 2020. 270 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 271 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 272 2012, . 274 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 275 Encodings and Procedures for Multicast in MPLS/BGP IP 276 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 277 . 279 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 280 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 281 VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, 282 . 284 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 285 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 286 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 287 2015, . 289 Author's Address 291 Zhaohui Zhang 292 Juniper Networks 294 EMail: zzhang@juniper.net