idnits 2.17.1 draft-zzhang-bier-tether-04.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 (September 30, 2019) is 1663 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-13 == Outdated reference: A later version (-04) exists of draft-zzhang-bier-multicast-as-a-service-00 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: April 2, 2020 Deutsche Telekom 6 I. Wijnands 7 Cisco Systems 8 D. Awduche 9 Verizon 10 September 30, 2019 12 Tethering A BIER Router To A BIER incapable Router 13 draft-zzhang-bier-tether-04 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 April 2, 2020. 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. 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Consider the scenario in Figure 1 where router X does not support 77 BIER. 79 ------ BFR2 ------- BFER2 80 / 81 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 82 ......... 83 \ 84 ------ BFRn ------- BFERn 86 Figure 1: Deployment with BIER incapable routers 88 For BFR1 to forward BIER traffic towards BFR2...BFRn, it needs to 89 tunnel individual copies through X. This degrades to "ingress" 90 replication to those BFRs. If X's connections to BFRs are long 91 distance or bandwidth limited, and n is large, it becomes very 92 inefficient. 94 A solution to the inefficient tunneling from BFRs is to attach 95 (tether) a BFRx to X as depicted in Figure 2: 97 ------ BFR2 ------- BFER2 98 / 99 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 100 / \ ......... 101 / \ 102 BFRx ------ BFRn ------- BFERn 104 Figure 2: Tethered BFRx 106 Instead of BFR1 tunneling to BFR2, ..., BFRn directly, BFR1 will get 107 BIER packets to BFRx, who will then tunnel to BFR2, ..., BFRn. There 108 could be fat and local pipes between the tethered BFRx and X, so 109 ingress replication from BFRx is acceptable. 111 For BFR1 to tunnel BIER packets to BFRx, the BFR1-BFRx tunnel need to 112 be announced in Interial Gateway Protocol (IGP) as a forwarding 113 adjacency so that BFRx will appear on the Shortest Path First (SPF) 114 tree. This needs to happen in a BIER specific topology so that 115 unicast traffic would not be tunneled to BFRx. Obviously this is 116 operationally cumbersome. 118 Section 6.9 of BIER architecture specification [RFC8279] describes a 119 method that tunnels BIER packets through incapable routers without 120 the need to announce tunnels. However that does not work here, 121 because BFRx will not appear on the SPF tree of BFR1. 123 There is a simple solution to the problem though. BFRx could 124 advertise that it is X's helper and other BFRs will use BFRx (instead 125 of X's children on the SPF tree) to replace X during its post-SPF 126 processing as described in section 6.9 of BIER architecture 127 specification [RFC8279]. 129 2. Additional Considerations 131 While the example shows a local connection between BFRx and X, it 132 does not have to be like that. As long as packets can arrive at BFRx 133 without requiring X to do BIER forwarding, it should work. 135 Additionally, the helper BRFx can be a transit helper, i.e., it has 136 other connections (instead of being a stub helper that is only 137 connected to X), as long as BFRx won't send BIER packets tunneled to 138 it back towards the tunnel ingress. Figure 3 below is a simple case: 140 ------ BFR2 ------- BFER2 141 / 142 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 143 | 144 | 145 BFRx ------ BFR4 ------- BFER4 146 \ 147 ------ BFR5 ------- BFER5 149 Figure 3: A Safe Transit Helper 151 In the example of Figure 4, there is a connection between BFR1 and 152 BFRx. If the link metrics are all 1 on the three sides of 153 BFR1-X-BFRx triangle, loop won't happen but if the BFRx-X metric is 3 154 while other two sides of the triangle has metric 1 then BFRx will 155 send BIER packets tunneled to it from BFR1 back to BFR1, causing a 156 loop. 158 ------ BFR2 ------- BFER2 159 / 160 BFER1 --- BFR1 ---- X ------- BFR3 ------- BFER3 161 \ / \ ......... 162 \ / \ 163 BFRx ------ BFRn ------- BFERn 165 Figure 4: Potential looping situation 167 This can easily be prevented if BFR1 does an SPF calculation with the 168 helper BFRx as the root. For any BFERn reached via X from BFR1, if 169 BFRx's SPF path to BFERn includes BFR1 then BFR1 must not use the 170 helper. Instead, BFR1 must directly tunnel packets for BFERn to X's 171 BFR (grand-)child on BFR1's SPF path to BFERn, per section 6.9 of 172 [RFC8279]. 174 Notice that this SPF calculation on BFR1 with BFRx as the root is not 175 different from the SPF done for a neighbor as part of Loop-Free 176 Alternate (LFA) calculation. In fact, BFR1 tunneling packets to X's 177 helper is not different from sending packets to a LFA backup. 179 Also notice that, instead of a dedicated helper BFRx, any one or 180 multiple ones of BFR2..N can also be the helper (as long as the 181 connection between that BFR and X has enough bandwidth for 182 replication to multiple helpers through X). To allow multiple 183 helpers to help the same non-BFR, the "I am X's helper" advertisement 184 carries a priority. BFR1 will choose the helper advertising the 185 highest priority among those satisfying the loop-free condition 186 described above. When there are multiple helpers advertising the 187 same priority and satisfying the loop-free condition, any one or 188 multiple ones could be used solely at the discretion of BFR1. 189 However, if multiple ones are used, it means that multiple copies may 190 be tunneled through X. 192 The situation in Figure 5 where a helper BFRxy helps two different 193 non-BFRs X and Y also works. It's just a special situation of a 194 transit helper. 196 ----- BFR2 ------- BFER2 197 / 198 X ------- BFR3 ------- BFER3 199 / | \ 200 / \ ----- BFR4 ------- BFER4 201 / \ 202 BFER1 -- BFR1 BFRxy ------------- BFERxy 203 \ / 204 \ / ----- BFR5 ------- BFER5 205 \ | / 206 Y ------- BFR6 ------- BFER6 207 \ 208 ----- BFRn ------- BFERn 210 Figure 5: One Helper for multiple helped 212 3. Specification 214 The procedures in this document apply when a BFRx is tethered to a 215 BIER incapable router X as X's helper for BIER forwarding. 217 3.1. IGP Signaling 219 Suppose that the BIER domain uses BIER signaling extensions to ISIS 220 [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise 221 one or more BIER Helped Node sub-sub-TLVs (one for each helped node). 222 The value is BIER prefix of the helped node (X) followed by a one- 223 octet priority field, and one-octet reserved field. The length is 6 224 for IPv4 and 18 for IPv6 respectively. 226 The post-SPF processing procedures in Section 6.9 of the BIER 227 architecture specification [RFC8279] are modified as following for 228 BIER tethering purpose. 230 At step 2, the removed node is added to an ordered list maintained 231 with each child that replaces the node. If the removed node already 232 has a non-empty list maintained with itself, add the removed node to 233 the tail of the list and copy the list to each child. 235 At the end, the calculating node BFR-B would use a unicast tunnel to 236 reach next hop BFRs for some BFERs. The next hop BFR has an ordered 237 list created at step 2 above, recording each BIER incapable node 238 replaced by their children along the way. For a particular BFER to 239 be reached via a tunnel to the next hop BFR, additional procedures 240 are performed as following. 242 o Starting with the first node in the ordered list of incapable 243 nodes, say N1, check if there is one or more helper nodes for N1. 244 If not, go the next node in the list. 246 o Order all the helper nodes of N1 based descending (priority, BIER 247 prefix). Starting with the first one, say H1, check if BFR-B 248 could use H1 as LFA next hop to reach the BFER. If yes, H1 is 249 used as the next hop BFR for the BFER and the procedure stops. If 250 not, go to the next helper in order. 252 o If none of the helper nodes of N1 can be used, go to the next node 253 in the list of incapable nodes. 255 If the above procedure finishes without finding any helper, then the 256 original BFR next hop via a tunnel is used to reach the BFER. 258 3.2. BGP Signaling 260 Suppose that the BIER domain uses BGP signaling 261 [I-D.ietf-bier-idr-extensions] instead of IGP. BFR1..N advertises 262 BIER prefixes that are reachable through them, with BIER Path 263 Attributes (BPA) attached. There are three situations regarding X's 264 involvement: 266 (1) X does not participate in BGP peering at all 268 (2) X re-advertises the BIER prefixes but does not do next-hop-self 270 (3) X re-advertises the BIER prefixes and does next-hop-self 272 With (1) and (2), the BFR1..N will tunnel BIER packets directly to 273 each other. It works but not efficiently as explained earlier. With 274 (3), BIER forwarding will not work, because BFR1..N would try to send 275 BIER packets to X though X does not advertise any BIER information. 276 If Tunnel Encapsulation Attribute (TEA) [I-D.ietf-idr-tunnel-encaps] 277 is used as specified in [I-D.zzhang-bier-multicast-as-a-service] with 278 (3), then it becomes similar to (2) - works but still not 279 efficiently. 281 To make tethering work well with BGP signaling, the following can be 282 done: 284 o Configure a BGP session between X and its helper BFRx. X re- 285 advertises BIER prefixes (with BPA) to BFRx without changing the 286 tunnel destination address in the TEA. 288 o BFRx advertises its own BIER prefix with BPA to X, and sets the 289 tunnel destination address in the TEA to itself. X then re- 290 advertises BFRx's BIER prefix to BFR1..N, without changing the 291 tunnel destination address in the TEA. 293 o For BIER prefixes (with BIER Path Attribute) that X re-advertises 294 to other BFRs, the tunnel destination in the TEA is changed to the 295 helper BFRx. 297 With the above, BFR1..N will tunnel BIER packets to BFRx (following 298 the tunnel destination address in the TEA), who will then tunnel 299 packets to other BFRs (again following the tunnel destination address 300 in the TEA). Notice that what X does is not specific to BIER at all. 302 4. Security Considerations 304 This specification does not introduce additional security concerns 305 beyond those already discussed in BIER architecture and OSPF/ISIS/BGP 306 extensions for BIER signaling. 308 5. IANA Considerations 310 This document requests a new sub-sub-TLV type value from the "Sub- 311 sub-TLVs for BIER Info Sub-TLV" registry in the "IS-IS TLV 312 Codepoints" registry: 314 Type Name 315 ---- ---- 316 TBD1 BIER Helped Node 318 This document also requests a new sub-TLV type value from the OSPFv2 319 Extended Prefix TLV Sub-TLV registry: 321 Type Name 322 ---- ---- 323 TBD2 BIER Helped Node 325 6. Acknowledgements 327 The author wants to thank Eric Rosen and Antonie Przygienda for their 328 review, comments and suggestions. 330 7. Normative References 332 [I-D.ietf-bier-idr-extensions] 333 Xu, X., Chen, M., Patel, K., Wijnands, I., and T. 334 Przygienda, "BGP Extensions for BIER", draft-ietf-bier- 335 idr-extensions-07 (work in progress), September 2019. 337 [I-D.ietf-idr-tunnel-encaps] 338 Patel, K., Velde, G., Ramachandra, S., and E. Rosen, "The 339 BGP Tunnel Encapsulation Attribute", draft-ietf-idr- 340 tunnel-encaps-13 (work in progress), July 2019. 342 [I-D.zzhang-bier-multicast-as-a-service] 343 Zhang, Z., Rosen, E., and L. Geng, "Multicast/BIER As A 344 Service", draft-zzhang-bier-multicast-as-a-service-00 345 (work in progress), October 2018. 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 354 May 2017, . 356 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 357 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 358 Explicit Replication (BIER)", RFC 8279, 359 DOI 10.17487/RFC8279, November 2017, 360 . 362 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 363 Zhang, "Bit Index Explicit Replication (BIER) Support via 364 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 365 . 367 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 368 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 369 Extensions for Bit Index Explicit Replication (BIER)", 370 RFC 8444, DOI 10.17487/RFC8444, November 2018, 371 . 373 Authors' Addresses 375 Zhaohui Zhang 376 Juniper Networks 378 EMail: zzhang@juniper.net 380 Nils Warnke 381 Deutsche Telekom 383 EMail: Nils.Warnke@telekom.de 385 IJsbrand Wijnands 386 Cisco Systems 388 EMail: ice@cisco.com 390 Daniel Awduche 391 Verizon 393 EMail: daniel.awduche@verizon.com