idnits 2.17.1 draft-ietf-bier-tether-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2020) is 1342 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) == Outdated reference: A later version (-10) exists of draft-ietf-bier-idr-extensions-07 == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-17 == Outdated reference: A later version (-04) exists of draft-zzhang-bier-multicast-as-a-service-01 Summary: 0 errors (**), 0 flaws (~~), 4 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 N. Warnke 5 Expires: February 21, 2021 Deutsche Telekom 6 I. Wijnands 7 Cisco Systems 8 D. Awduche 9 Verizon 10 August 20, 2020 12 Tethering A BIER Router To A BIER incapable Router 13 draft-ietf-bier-tether-00 15 Abstract 17 This document specifies optional procedures to optimize the handling 18 of Bit Index Explicit Replication (BIER) incapable routers, by 19 attaching (tethering) a BIER router to a BIER incapable router. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 25 "OPTIONAL" in this document are to be interpreted as described in BCP 26 14 [RFC2119] [RFC8174] when, and only when, they appear in all 27 capitals, as shown here. 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 February 21, 2021. 46 Copyright Notice 48 Copyright (c) 2020 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Additional Considerations . . . . . . . . . . . . . . . . . . 3 65 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. IGP Signaling . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 6 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Consider the scenario in Figure 1 where router X does not support 78 BIER. 80 ------ BFR2 ------- BFER2 81 / 82 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 83 ......... 84 \ 85 ------ BFRn ------- BFERn 87 Figure 1: Deployment with BIER incapable routers 89 For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to 90 tunnel individual copies through X. This degrades to "ingress" 91 replication to those BFRs. If X's connections to BFRs are long 92 distance or bandwidth limited, and n is large, it becomes very 93 inefficient. 95 A solution to the inefficient tunneling from BFRs is to attach 96 (tether) a BFRx to X as depicted in Figure 2: 98 ------ BFR2 ------- BFER2 99 / 100 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 101 / \ ......... 102 / \ 103 BFRx ------ BFRn ------- BFERn 105 Figure 2: Tethered BFRx 107 Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get 108 BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn. There 109 could be fat and local pipes between the tethered BFRx and X, so 110 ingress replication from BFRx is acceptable. 112 For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to 113 be announced in Interial Gateway Protocol (IGP) as a forwarding 114 adjacency so that BFRx will appear on the Shortest Path First (SPF) 115 tree. This needs to happen in a BIER specific topology so that 116 unicast traffic would not be tunneled to BFRx. Obviously this is 117 operationally cumbersome. 119 Section 6.9 of BIER architecture specification [RFC8279] describes a 120 method that tunnels BIER packets through incapable routers without 121 the need to announce tunnels. However that does not work here, 122 because BFRx will not appear on the SPF tree of BFR1. 124 There is a simple solution to the problem though. BFRx could 125 advertise that it is X's helper and other BFRs will use BFRx (instead 126 of X's children on the SPF tree) to replace X during its post-SPF 127 processing as described in section 6.9 of BIER architecture 128 specification [RFC8279]. 130 2. Additional Considerations 132 While the example shows a local connection between BFRx and X, it 133 does not have to be like that. As long as packets can arrive at BFRx 134 without requiring X to do BIER forwarding, it should work. 136 Additionally, the helper BRFx can be a transit helper, i.e., it has 137 other connections (instead of being a stub helper that is only 138 connected to X), as long as BFRx won't send BIER packets tunneled to 139 it back towards the tunnel ingress. Figure 3 below is a simple case: 141 ------ BFR2 ------- BFER2 142 / 143 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 144 | 145 | 146 BFRx ------ BFR4 ------- BFER4 147 \ 148 ------ BFR5 ------- BFER5 150 Figure 3: A Safe Transit Helper 152 In the example of Figure 4, there is a connection between BFR1 and 153 BFRx. If the link metrics are all 1 on the three sides of 154 BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3 155 while other two sides of the triangle has metric 1 then BFRx will 156 send BIER packets tunneled to it from BFR1 back to BFR1, causing a 157 loop. 159 ------ BFR2 ------- BFER2 160 / 161 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 162 \ / \ ......... 163 \ / \ 164 BFRx ------ BFRn ------- BFERn 166 Figure 4: Potential looping situation 168 This can easily be prevented if BFR1 does an SPF calculation with the 169 helper BFRx as the root. For any BFERn reached via X from BFR1, if 170 BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the 171 helper. Instead, BFR1 must directly tunnel packets for BFERn to X's 172 BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of 173 [RFC8279]. 175 Notice that this SPF calculation on BFR1 with BFRx as the root is not 176 different from the SPF done for a neighbor as part of Loop-Free 177 Alternate (LFA) calculation. In fact, BFR1 tunneling packets to X's 178 helper is not different from sending packets to a LFA backup. 180 Also notice that, instead of a dedicated helper BFRx, any one or 181 multiple ones of BFR2..N can also be the helper (as long as the 182 connection between that BFR and X has enough bandwidth for 183 replication to multiple helpers through X). To allow multiple 184 helpers to help the same non-BFR, the "I am X's helper" advertisement 185 carries a priority. BFR1 will choose the helper advertising the 186 highest priority among those satisfying the loop-free condition 187 described above. When there are multiple helpers advertising the 188 same priority and satisfying the loop-free condition, any one or 189 multiple ones could be used solely at the discretion of BFR1. 190 However, if multiple ones are used, it means that multiple copies may 191 be tunneled through X. 193 The situation in Figure 5 where a helper BFRxy helps two different 194 non-BFRs X and Y also works. It's just a special situation of a 195 transit helper. 197 ----- BFR2 ------- BFER2 198 / 199 X ------- BFR3 ------- BFER3 200 / | \ 201 / \ ----- BFR4 ------- BFER4 202 / \ 203 BFER1 -- BFR1 BFRxy ------------- BFERxy 204 \ / 205 \ / ----- BFR5 ------- BFER5 206 \ | / 207 Y ------- BFR6 ------- BFER6 208 \ 209 ----- BFRn ------- BFERn 211 Figure 5: One Helper for multiple helped 213 3. Specification 215 The procedures in this document apply when a BFRx is tethered to a 216 BIER incapable router X as X's helper for BIER forwarding. 218 3.1. IGP Signaling 220 Suppose that the BIER domain uses BIER signaling extensions to ISIS 221 [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise 222 one or more BIER Helped Node sub-sub-TLVs (one for each helped node). 223 The value is BIER prefix of the helped node (X) followed by a one- 224 octet priority field, and one-octet reserved field. The length is 6 225 for IPv4 and 18 for IPv6 respectively. 227 The post-SPF processing procedures in Section 6.9 of the BIER 228 architecture specification [RFC8279] are modified as following for 229 BIER tethering purpose. 231 At step 2, the removed node is added to an ordered list maintained 232 with each child that replaces the node. If the removed node already 233 has a non-empty list maintained with itself, add the removed node to 234 the tail of the list and copy the list to each child. 236 At the end, the calculating node BFR-B would use a unicast tunnel to 237 reach next hop BFRs for some BFERs. The next hop BFR has an ordered 238 list created at step 2 above, recording each BIER incapable node 239 replaced by their children along the way. For a particular BFER to 240 be reached via a tunnel to the next hop BFR, additional procedures 241 are performed as following. 243 o Starting with the first node in the ordered list of incapable 244 nodes, say N1, check if there is one or more helper nodes for N1. 245 If not, go the next node in the list. 247 o Order all the helper nodes of N1 based descending (priority, BIER 248 prefix). Starting with the first one, say H1, check if BFR-B 249 could use H1 as LFA next hop to reach the BFER. If yes, H1 is 250 used as the next hop BFR for the BFER and the procedure stops. If 251 not, go to the next helper in order. 253 o If none of the helper nodes of N1 can be used, go to the next node 254 in the list of incapable nodes. 256 If the above procedure finishes without finding any helper, then the 257 original BFR next hop via a tunnel is used to reach the BFER. 259 3.2. BGP Signaling 261 Suppose that the BIER domain uses BGP signaling 262 [I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises 263 BIER prefixes that are reachable through them, with BIER Path 264 Attributes (BPA) attached. There are three situations regarding X's 265 involvement: 267 (1) X does not participate in BGP peering at all 269 (2) X re-advertises the BIER prefixes but does not do next-hop-self 271 (3) X re-advertises the BIER prefixes and does next-hop-self 273 With (1) and (2), the BFR1..N will tunnel BIER packets directly to 274 each other. It works but not efficiently as explained earlier. With 275 (3), BIER forwarding will not work, because BFR1..N would try to send 276 BIER packets to X though X does not advertise any BIER information. 277 If Tunnel Encapsulation Attribute (TEA) [I-D.ietf-idr-tunnel-encaps] 278 is used as specified in [I-D.zzhang-bier-multicast-as-a-service] with 279 (3), then it becomes similar to (2) - works but still not 280 efficiently. 282 To make tethering work well with BGP signaling, the following can be 283 done: 285 o Configure a BGP session between X and its helper BFRx. X re- 286 advertises BIER prefixes (with BPA) to BFRx without changing the 287 tunnel destination address in the TEA. 289 o BFRx advertises its own BIER prefix with BPA to X, and sets the 290 tunnel destination address in the TEA to itself. X then re- 291 advertises BFRx's BIER prefix to BFR1..N, without changing the 292 tunnel destination address in the TEA. 294 o For BIER prefixes (with BIER Path Attribute) that X re-advertises 295 to other BFRs, the tunnel destination in the TEA is changed to the 296 helper BFRx. 298 With the above, BFR1..N will tunnel BIER packets to BFRx (following 299 the tunnel destination address in the TEA), who will then tunnel 300 packets to other BFRs (again following the tunnel destination address 301 in the TEA). Notice that what X does is not specific to BIER at all. 303 4. Security Considerations 305 This specification does not introduce additional security concerns 306 beyond those already discussed in BIER architecture and OSPF/ISIS/BGP 307 extensions for BIER signaling. 309 5. IANA Considerations 311 This document requests a new sub-sub-TLV type value from the "Sub- 312 sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV 313 Codepoints" registry: 315 Type Name 316 ---- ---- 317 TBD1 BIER Helped Node 319 This document also requests a new sub-TLV type value from the OSPFv2 320 Extended Prefix TLV Sub-TLV registry: 322 Type Name 323 ---- ---- 324 TBD2 BIER Helped Node 326 6. Contributors 328 The following also contributed to this document. 330 Zheng(Sandy) Zhang 331 ZTE Corporation 333 EMail: zzhang_ietf@hotmail.com 335 Hooman Bidgoli 336 Nokia 337 EMail: hooman.bidgoli@nokia.com 339 7. Acknowledgements 341 The author wants to thank Eric Rosen and Antonie Przygienda for their 342 review, comments and suggestions. 344 8. Normative References 346 [I-D.ietf-bier-idr-extensions] 347 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 348 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 349 idr-extensions-07 (work in progress), September 2019. 351 [I-D.ietf-idr-tunnel-encaps] 352 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 353 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 354 encaps-17 (work in progress), July 2020. 356 [I-D.zzhang-bier-multicast-as-a-service] 357 Zhang, Z., Rosen, E., Awduche, D., and L. Geng, 358 "Multicast/BIER As A Service", draft-zzhang-bier- 359 multicast-as-a-service-01 (work in progress), May 2020. 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 367 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 368 May 2017, . 370 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 371 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 372 Explicit Replication (BIER)", RFC 8279, 373 DOI 10.17487/RFC8279, November 2017, 374 . 376 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 377 Zhang, "Bit Index Explicit Replication (BIER) Support via 378 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 379 . 381 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 382 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 383 Extensions for Bit Index Explicit Replication (BIER)", 384 RFC 8444, DOI 10.17487/RFC8444, November 2018, 385 . 387 Authors' Addresses 389 Zhaohui Zhang 390 Juniper Networks 392 EMail: zzhang@juniper.net 394 Nils Warnke 395 Deutsche Telekom 397 EMail: Nils.Warnke@telekom.de 399 IJsbrand Wijnands 400 Cisco Systems 402 EMail: ice@cisco.com 404 Daniel Awduche 405 Verizon 407 EMail: daniel.awduche@verizon.com