idnits 2.17.1 draft-ietf-bier-tether-01.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 (January 4, 2021) is 1207 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-20 == 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: July 8, 2021 Deutsche Telekom 6 I. Wijnands 7 Cisco Systems 8 D. Awduche 9 Verizon 10 January 4, 2021 12 Tethering A BIER Router To A BIER incapable Router 13 draft-ietf-bier-tether-01 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 July 8, 2021. 46 Copyright Notice 48 Copyright (c) 2021 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. Egress Protection . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. IGP Signaling . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 Consider the scenario in Figure 1 where router X does not support 79 BIER. 81 ------ BFR2 ------- BFER2 82 / 83 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 84 ......... 85 \ 86 ------ BFRn ------- BFERn 88 Figure 1: Deployment with BIER incapable routers 90 For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to 91 tunnel individual copies through X. This degrades to "ingress" 92 replication to those BFRs. If X's connections to BFRs are long 93 distance or bandwidth limited, and n is large, it becomes very 94 inefficient. 96 A solution to the inefficient tunneling from BFRs is to attach 97 (tether) a BFRx to X as depicted in Figure 2: 99 ------ BFR2 ------- BFER2 100 / 101 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 102 / \ ......... 103 / \ 104 BFRx ------ BFRn ------- BFERn 106 Figure 2: Tethered BFRx 108 Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get 109 BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn. There 110 could be fat and local pipes between the tethered BFRx and X, so 111 ingress replication from BFRx is acceptable. 113 For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to 114 be announced in Interior Gateway Protocol (IGP) as a forwarding 115 adjacency so that BFRx will appear on the Shortest Path First (SPF) 116 tree. This needs to happen in a BIER specific topology so that 117 unicast traffic would not be tunneled to BFRx. Obviously this is 118 operationally cumbersome. 120 Section 6.9 of BIER architecture specification [RFC8279] describes a 121 method that tunnels BIER packets through incapable routers without 122 the need to announce tunnels. However that does not work here, 123 because BFRx will not appear on the SPF tree of BFR1. 125 There is a simple solution to the problem though. BFRx could 126 advertise that it is X's helper and other BFRs will use BFRx (instead 127 of X's children on the SPF tree) to replace X during its post-SPF 128 processing as described in section 6.9 of BIER architecture 129 specification [RFC8279]. 131 2. Additional Considerations 133 While the example shows a local connection between BFRx and X, it 134 does not have to be like that. As long as packets can arrive at BFRx 135 without requiring X to do BIER forwarding, it should work. 137 Additionally, the helper BRFx can be a transit helper, i.e., it has 138 other connections (instead of being a stub helper that is only 139 connected to X), as long as BFRx won't send BIER packets tunneled to 140 it back towards the tunnel ingress. Figure 3 below is a simple case: 142 ------ BFR2 ------- BFER2 143 / 144 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 145 | 146 | 147 BFRx ------ BFR4 ------- BFER4 148 \ 149 ------ BFR5 ------- BFER5 151 Figure 3: A Safe Transit Helper 153 In the example of Figure 4, there is a connection between BFR1 and 154 BFRx. If the link metrics are all 1 on the three sides of 155 BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3 156 while other two sides of the triangle has metric 1 then BFRx will 157 send BIER packets tunneled to it from BFR1 back to BFR1, causing a 158 loop. 160 ------ BFR2 ------- BFER2 161 / 162 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 163 \ / \ ......... 164 \ / \ 165 BFRx ------ BFRn ------- BFERn 167 Figure 4: Potential looping situation 169 This can easily be prevented if BFR1 does an SPF calculation with the 170 helper BFRx as the root. For any BFERn reached via X from BFR1, if 171 BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the 172 helper. Instead, BFR1 must directly tunnel packets for BFERn to X's 173 BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of 174 [RFC8279]. 176 Notice that this SPF calculation on BFR1 with BFRx as the root is not 177 different from the SPF done for a neighbor as part of Loop-Free 178 Alternate (LFA) calculation. In fact, BFR1 tunneling packets to X's 179 helper is not different from sending packets to a LFA backup. 181 Also notice that, instead of a dedicated helper BFRx, any one or 182 multiple ones of BFR2..N can also be the helper (as long as the 183 connection between that BFR and X has enough bandwidth for 184 replication to multiple helpers through X). To allow multiple 185 helpers to help the same non-BFR, the "I am X's helper" advertisement 186 carries a priority. BFR1 will choose the helper advertising the 187 highest priority among those satisfying the loop-free condition 188 described above. When there are multiple helpers advertising the 189 same priority and satisfying the loop-free condition, any one or 190 multiple ones could be used solely at the discretion of BFR1. 191 However, if multiple ones are used, it means that multiple copies may 192 be tunneled through X. 194 The situation in Figure 5 where a helper BFRxy helps two different 195 non-BFRs X and Y also works. It's just a special situation of a 196 transit helper. 198 ----- BFR2 ------- BFER2 199 / 200 X ------- BFR3 ------- BFER3 201 / | \ 202 / \ ----- BFR4 ------- BFER4 203 / \ 204 BFER1 -- BFR1 BFRxy ------------- BFERxy 205 \ / 206 \ / ----- BFR5 ------- BFER5 207 \ | / 208 Y ------- BFR6 ------- BFER6 209 \ 210 ----- BFRn ------- BFERn 212 Figure 5: One Helper for multiple helped 214 3. Egress Protection 216 The same principal can be used for egress protection. Consider the 217 following: 219 ------------ BFER1 ------ ce1 220 / ____ / 221 --- BFR1 --------------BFER2 ____ 222 \ 223 ce2 225 Figure 6: Egress Protection 227 ce1 is multi-homed to BFER1 and BFER2. Suppose both ce1 and ce2 need 228 to receive certain multicast traffic and the copy for ce1 in normal 229 situation follows the BFR1-BFER1-ce1 path while the copy for for ce2 230 follows the BFR1-BFER2-ce2 path (i.e. the packet that BFR1 receives 231 has two bits set for BFER1 and BFER2 respectively). If BFR1 detects 232 the node failure of BFER1, in-flight traffic with BFER1 bit set is 233 redirected to BFER2, who will then deliver to ce1 only. Note that 234 for the same multicast payload, BFER2 would receive two copies 235 (before the BFIR converges), one with the BFER1 bit set and one with 236 the BFER2 bit set. BFER2 will deliver the copy with the BFER1 bit to 237 ce1 upon detection of node failure of BFER1, but will not deliver the 238 same to ce2. 240 If ce2 is also multi-homed to BFER1 and BFER2, then BFER1 and BFER2 241 could egress-pretect each other. Each announces that it is the 242 helper node of the other, and the fact that each is capable of BIER 243 indicates that it is for egress protection only. 245 4. Specification 247 The procedures in this document apply when a BFRx is tethered to a 248 BIER incapable router X as X's helper for BIER forwarding. 250 4.1. IGP Signaling 252 Suppose that the BIER domain uses BIER signaling extensions to ISIS 253 [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise 254 one or more BIER Helped Node sub-sub-TLVs (one for each helped node). 255 The value is BIER prefix of the helped node (X) followed by a one- 256 octet priority field, and one-octet reserved field. The length is 6 257 for IPv4 and 18 for IPv6 respectively. 259 The post-SPF processing procedures in Section 6.9 of the BIER 260 architecture specification [RFC8279] are modified as following for 261 BIER tethering purpose. 263 At step 2, the removed node is added to an ordered list maintained 264 with each child that replaces the node. If the removed node already 265 has a non-empty list maintained with itself, add the removed node to 266 the tail of the list and copy the list to each child. 268 At the end, the calculating node BFR-B would use a unicast tunnel to 269 reach next hop BFRs for some BFERs. The next hop BFR has an ordered 270 list created at step 2 above, recording each BIER incapable node 271 replaced by their children along the way. For a particular BFER to 272 be reached via a tunnel to the next hop BFR, additional procedures 273 are performed as following. 275 o Starting with the first node in the ordered list of incapable 276 nodes, say N1, check if there is one or more helper nodes for N1. 277 If not, go the next node in the list. 279 o Order all the helper nodes of N1 based descending (priority, BIER 280 prefix). Starting with the first one, say H1, check if BFR-B 281 could use H1 as LFA next hop to reach the BFER. If yes, H1 is 282 used as the next hop BFR for the BFER and the procedure stops. If 283 not, go to the next helper in order. 285 o If none of the helper nodes of N1 can be used, go to the next node 286 in the list of incapable nodes. 288 If the above procedure finishes without finding any helper, then the 289 original BFR next hop via a tunnel is used to reach the BFER. 291 4.2. BGP Signaling 293 Suppose that the BIER domain uses BGP signaling 294 [I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises 295 BIER prefixes that are reachable through them, with BIER Path 296 Attributes (BPA) attached. There are three situations regarding X's 297 involvement: 299 (1) X does not participate in BGP peering at all 301 (2) X re-advertises the BIER prefixes but does not do next-hop-self 303 (3) X re-advertises the BIER prefixes and does next-hop-self 305 With (1) and (2), the BFR1..N will tunnel BIER packets directly to 306 each other. It works but not efficiently as explained earlier. With 307 (3), BIER forwarding will not work, because BFR1..N would try to send 308 BIER packets to X though X does not advertise any BIER information. 309 If Tunnel Encapsulation Attribute (TEA) [I-D.ietf-idr-tunnel-encaps] 310 is used as specified in [I-D.zzhang-bier-multicast-as-a-service] with 311 (3), then it becomes similar to (2) - works but still not 312 efficiently. 314 To make tethering work well with BGP signaling, the following can be 315 done: 317 o Configure a BGP session between X and its helper BFRx. X re- 318 advertises BIER prefixes (with BPA) to BFRx without changing the 319 tunnel destination address in the TEA. 321 o BFRx advertises its own BIER prefix with BPA to X, and sets the 322 tunnel destination address in the TEA to itself. X then re- 323 advertises BFRx's BIER prefix to BFR1..N, without changing the 324 tunnel destination address in the TEA. 326 o For BIER prefixes (with BIER Path Attribute) that X re-advertises 327 to other BFRs, the tunnel destination in the TEA is changed to the 328 helper BFRx. 330 With the above, BFR1..N will tunnel BIER packets to BFRx (following 331 the tunnel destination address in the TEA), who will then tunnel 332 packets to other BFRs (again following the tunnel destination address 333 in the TEA). Notice that what X does is not specific to BIER at all. 335 5. Security Considerations 337 This specification does not introduce additional security concerns 338 beyond those already discussed in BIER architecture and OSPF/ISIS/BGP 339 extensions for BIER signaling. 341 6. IANA Considerations 343 This document requests a new sub-sub-TLV type value from the "Sub- 344 sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV 345 Codepoints" registry: 347 Type Name 348 ---- ---- 349 TBD1 BIER Helped Node 351 This document also requests a new sub-TLV type value from the OSPFv2 352 Extended Prefix TLV Sub-TLV registry: 354 Type Name 355 ---- ---- 356 TBD2 BIER Helped Node 358 7. Contributors 360 The following also contributed to this document. 362 Zheng(Sandy) Zhang 363 ZTE Corporation 365 EMail: zzhang_ietf@hotmail.com 367 Hooman Bidgoli 368 Nokia 369 EMail: hooman.bidgoli@nokia.com 371 8. Acknowledgements 373 The author wants to thank Eric Rosen and Antonie Przygienda for their 374 review, comments and suggestions. 376 9. Normative References 378 [I-D.ietf-bier-idr-extensions] 379 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 380 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 381 idr-extensions-07 (work in progress), September 2019. 383 [I-D.ietf-idr-tunnel-encaps] 384 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 385 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 386 encaps-20 (work in progress), November 2020. 388 [I-D.zzhang-bier-multicast-as-a-service] 389 Zhang, Z., Rosen, E., Awduche, D., and L. Geng, 390 "Multicast/BIER As A Service", draft-zzhang-bier- 391 multicast-as-a-service-01 (work in progress), May 2020. 393 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 394 Requirement Levels", BCP 14, RFC 2119, 395 DOI 10.17487/RFC2119, March 1997, 396 . 398 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 399 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 400 May 2017, . 402 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 403 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 404 Explicit Replication (BIER)", RFC 8279, 405 DOI 10.17487/RFC8279, November 2017, 406 . 408 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 409 Zhang, "Bit Index Explicit Replication (BIER) Support via 410 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 411 . 413 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 414 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 415 Extensions for Bit Index Explicit Replication (BIER)", 416 RFC 8444, DOI 10.17487/RFC8444, November 2018, 417 . 419 Authors' Addresses 421 Zhaohui Zhang 422 Juniper Networks 424 EMail: zzhang@juniper.net 426 Nils Warnke 427 Deutsche Telekom 429 EMail: Nils.Warnke@telekom.de 431 IJsbrand Wijnands 432 Cisco Systems 434 EMail: ice@cisco.com 436 Daniel Awduche 437 Verizon 439 EMail: daniel.awduche@verizon.com