idnits 2.17.1 draft-przygienda-bier-migration-options-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 (Jun 21, 2018) is 2136 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 (-13) exists of draft-ietf-bier-bar-ipa-01 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) ** Downref: Normative reference to an Informational RFC: RFC 3906 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER A. Przygienda 3 Internet-Draft Z. Zhang 4 Intended status: Standards Track Juniper Networks 5 Expires: December 23, 2018 Jun 21, 2018 7 BIER Migration Frameworks 8 draft-przygienda-bier-migration-options-00 10 Abstract 12 BIER is a new architecture for the forwarding and replication of 13 multicast data packets. This document defines possible approaches to 14 introduce BIER into networks consisting of a mixture of BFRs and non- 15 BFRs and their respective preconditions and properties. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC2119. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 23, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. `Naked` MT . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. RFC8279 Section 6.9 . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. BIER Specific Algorithm Based Solutions . . . . . . . . . . . 6 65 4.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Controller Based Solutions . . . . . . . . . . . . . . . . . 7 68 5.1. Preconditions . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2. Properties . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 BIER [RFC8279] is a new architecture for the forwarding of multicast 78 data packets. It allows replication through a "multicast domain" and 79 it does not precondition construction of a multicast distribution 80 tree, nor does it precondition intermediate nodes to maintain any 81 per-flow state. 83 Given that BIER encompasses a novel switching path it can be 84 reasonably expected that in many deployment scenarios, at least 85 initially, a mixture of BFRs and non-BFR (i.e. routers having all or 86 some of the interfaces not being capable of BIER forwarding) will be 87 used and represent what we will call "mixed environments". [RFC8279] 88 offers several suggestions how a mixture of such routers can be 89 handled in the network. The purpose of this memo is to cover other 90 possible deployment options with explanation what preconditions are 91 necessary to apply each of those and what properties and requirements 92 they bring in operational considerations respectively. 94 The presented sequence of possible solutions follows very loosely an 95 ordering starting with the ones that use "least" amount of additional 96 technologies beside BIER to deploy a "mixed environment". This 97 serves subsequently to facilitate the introduction of consecutive, 98 more interdependent solutions. Nevertheless, this does not imply 99 that any of the solutions is better or simpler. The "optimal" 100 solution will depend every time on operational realities of the 101 network performing a migration towards BIER deployment. 103 Any tunnelling technology used when deploying BIER in a "mixed 104 environment" must ensure that in case the tunnel carries other types 105 of traffic beside BIER the tunnel termination point MUST be capable 106 of identifying BIER frames by some means. In case of tunnel carrying 107 only Ethernet frames or MPLS encapsulated traffic [RFC8296] allows to 108 distinguish BIER from other frames. 110 This document uses terminology defined in [RFC8279]. 112 2. `Naked` MT 114 Strictly speaking BIER can be deployed in "mixed environments" 115 without any additional extensions or new technologies in its basic 116 form. Proper use of multi-topology [RFC5120] configuration in IGPs 117 will allow separation of BIER capable routers and interfaces in the 118 topology, possibly connected via IGP tunnels to create at minimum a 119 graph of BFRs. 121 2.1. Preconditions 123 o BIER IGP signalling via [I-D.ietf-bier-ospf-bier-extensions] or 124 [RFC8401] and 126 o implementation of multi-topology and 128 o any kind of tunneling technology that can be viewed as adjacency 129 in IGP. 131 2.2. Properties 133 o Multi-topology has been standardized and used for many years in 134 IGPs and other signalling protocols. 136 o The use of multi-topology allows for multicast and unicast traffic 137 to follow (per subdomain) different paths if necessary in case 138 such a behavior is desired operationally. 140 o Normal IGP computation results are used as BIER nexthops, i.e. 141 normal SPF nexthops or even TE computation nexthops and techniques 142 like [RFC3906] are applicable. 144 o Reconfiguring multi-topology preconditions the touching of both 145 sides of a link in the multi-topology and recomputation of BIER 146 nexthops for the given topology on all routers. On changes in 147 topology the tunnels may need to be reprovisioned depending on 148 technology and protection scheme used. 150 o Physical links configured as members of several multi-topologies 151 can be "shared" between subdomains for e.g. protection purposes, 152 i.e. if multi topologies used for different sub-domains are using 153 same physical links, the links will be used by the according sub- 154 domains as well. By adjusting IGP metrics the traffic can be kept 155 separate per subdomain with the possiblity of a "fail-over" onto 156 the links with high IGP metric in case of failures. It is even 157 possible to use the same physical topology with each multi- 158 topology carrying different metrics to make different links having 159 different preference for each sub-domain and "separate" traffic 160 per sub-domain that way. 162 o Since multi-topology membership is a "per interface" property it 163 allows to manage "partial BFR" routers, i.e. routers where only a 164 subset of interfaces is BIER capable. 166 o Multi-topology solution can be combined in case of "mixed 167 environment" with any other solution described in this document 168 that is multi-topology aware. 170 o If tunnel metrics are chosen based on purely IGP metrics the 171 solution may load-balance between hop-by-hop BIER path and tunnels 172 which can lead to different timing behavior on each path albeit in 173 case of BIER entropy encompassing a logical flow this should be 174 benign. 176 o Multi-topology provides inherently separate routing tables and 177 according statistics. 179 3. RFC8279 Section 6.9 181 This section deals with the "re-parenting" solution outlined in 182 Section 6.9 of [RFC8279]. We will deal with the modified step 2) 183 solution in Section 4. 185 3.1. Preconditions 187 o BIER IGP signalling via [I-D.ietf-bier-ospf-bier-extensions] or 188 [RFC8401] and 190 o pre-provisioned "static" tunnels that allows "re-parenting" in any 191 possible failure scenario and/or 193 o a "dynamic tunneling" technology that can use a unicast tunnel 194 between any pair of nodes in the domain without configuration or 195 setup, e.g. "soft" GRE [RFC2784], LDP [RFC3036] in Downstream 196 Unsolicited mode or Segment Routing 197 [I-D.ietf-spring-segment-routing] are assumed to be deployed 198 through the whole BIER domain. 200 3.2. Properties 202 o When used with dynamic tunnels the solution can automatically 203 "bridge" disconnected areas without necessity to provision multi 204 topology or static tunnel configuration, i.e. this solution can 205 deal with any arbitrary breakage of topology as long the network 206 does not become partitioned. It is equivalent to node protection 207 [RFC5286]. 209 o IGPs do not have to be aware of the tunnels. 211 o BIER traffic strictly follows unicast path only (assuming that the 212 "dynamic tunnels" are following IGP unicast nexthops as well) and 213 with that 215 * all BIER capable routers MUST have enough scale to carry 216 unicast load and 218 * if the unicast next-hop is a non-BIER capable router the router 219 upstream will ingress replicate to all the children on the 220 unicast tree of that next-hop and 222 * BIER may load balance between tunneled and BIER native 223 forwarding paths which can lead to different timing behavior 224 albeit in case of BIER entropy encompassing a logical flow this 225 should be benign. 227 o All interfaces on BFRs MUST be capable of BIER forwarding. 229 o Dynamic tunneling topologies do not provide extensive OAM normally 230 albeit they may provide node and link failure protection. On the 231 other hand, some "dynamic tunnelling" technologies like segment 232 routing will hold minimum amount of state in the network, i.e. no 233 per-tunnel specific state while providing coverage for any non- 234 partitioning failure. 236 o If a tunnel is used to reach the next BFR, the tunnel's own node/ 237 link protection provides FRR. 239 o Each change in dynamic tunnel signalling (such as LDP) may lead to 240 recomputation of BIFT entries. 242 4. BIER Specific Algorithm Based Solutions 244 BIER can support a multitude of BIER Algorithms (BAR) as specified in 245 IGP drafts and [I-D.ietf-bier-bar-ipa] to operate in "mixed 246 environments" and take into consideration BIER specific constraints 247 and properties. While doing that BFRs signal which algorithm they 248 use so the distributed computation delivers consistent results on all 249 BFRs. In its simplest form BAR can defined an SPF where non-BFRs are 250 not being put on the candidate list which we denote for the moment as 251 BAR=1 and consider further. 253 4.1. Preconditions 255 o BIER IGP signalling via [I-D.ietf-bier-ospf-bier-extensions] or 256 [RFC8401] and 258 o Implementation of non-zero BAR values and 260 o any kind of tunneling technology that can be viewed as an 261 adjacency in IGP. 263 4.2. Properties 265 o BAR allows for multicast and unicast traffic to follow different 266 paths if necessary in case such a behavior is desired 267 operationally. 269 o BAR could take into accounts different limitations like e.g. 270 maximum possible fan-out degree on nodes or inter-dependency of 271 sub-domains in same BIER domain. 273 o Normal IGP computation can be used easily to compute BAR BIER 274 nexthops while preserving all unicast node and link-protection 275 schemes. 277 o Reconfiguring BAR preconditions the touching of all participating 278 BFR. 280 o BAR can allow to manage "partial BFR" routers, i.e. routers where 281 only a subset of interfaces is BIER capable if additional 282 information is advertised with BIER sub-TLVs. 284 o All interfaces on BFRs MUST be capable of BIER forwarding unless 285 the static tunnels can be "homed" on BIER capable interfaces only. 287 5. Controller Based Solutions 289 Ultimately, the according BIRTs and BIFTs can be precomputed by an 290 off-line controller via any algoirthm desirable (in a sense similar 291 to Section 4 but being able to take other metrics and constraints in 292 the computation than distributed by IGP possibly) and downloaded. 294 5.1. Preconditions 296 o Controller computing BIRTs and/or BIFTs and downloading them into 297 all BIER nodes and 299 o Preferrably signalling of a special BAR value on each router to 300 ensure that it is configured to use the according controller 301 downloaded tables. 303 5.2. Properties 305 o Controller based solution can take into account many constraints 306 and metrics that are not distributed network-wide such as 307 provisioning constraints depending on time of day. 309 o Centralized cntroller computation cannot normally react quickly to 310 node or link failures due to delays involved. It is possible that 311 a centralized computation precomputes and installs according link- 312 and node-protection BIER next-hops and installs those in the 313 forwarding path. Depending on delays two set of tables may be 314 necessary where after download to all routers a `fast switch-over` 315 is performed to minimize holes and traffic losses. 317 6. IANA Considerations 319 None. 321 7. Security Considerations 323 General BIER security considerations apply and this document does not 324 introduce any new security relevant topics. 326 Controller based solutions may introduce new security considerations. 328 8. Normative References 330 [I-D.ietf-bier-bar-ipa] 331 Zhang, Z., Przygienda, T., Dolganow, A., Bidgoli, H., 332 Wijnands, I., and A. Gulko, "BIER Underlay Path 333 Calculation Algorithm and Contraints", draft-ietf-bier- 334 bar-ipa-01 (work in progress), April 2018. 336 [I-D.ietf-bier-ospf-bier-extensions] 337 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 338 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 339 Extensions for BIER", draft-ietf-bier-ospf-bier- 340 extensions-18 (work in progress), June 2018. 342 [I-D.ietf-spring-segment-routing] 343 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 344 Litkowski, S., and R. Shakir, "Segment Routing 345 Architecture", draft-ietf-spring-segment-routing-15 (work 346 in progress), January 2018. 348 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 349 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 350 DOI 10.17487/RFC2784, March 2000, 351 . 353 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and 354 B. Thomas, "LDP Specification", RFC 3036, 355 DOI 10.17487/RFC3036, January 2001, 356 . 358 [RFC3906] Shen, N. and H. Smit, "Calculating Interior Gateway 359 Protocol (IGP) Routes Over Traffic Engineering Tunnels", 360 RFC 3906, DOI 10.17487/RFC3906, October 2004, 361 . 363 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 364 Topology (MT) Routing in Intermediate System to 365 Intermediate Systems (IS-ISs)", RFC 5120, 366 DOI 10.17487/RFC5120, February 2008, 367 . 369 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 370 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 371 DOI 10.17487/RFC5286, September 2008, 372 . 374 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 375 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 376 Explicit Replication (BIER)", RFC 8279, 377 DOI 10.17487/RFC8279, November 2017, 378 . 380 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 381 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 382 for Bit Index Explicit Replication (BIER) in MPLS and Non- 383 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 384 2018, . 386 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 387 Zhang, "Bit Index Explicit Replication (BIER) Support via 388 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 389 . 391 Authors' Addresses 393 Tony Przygienda 394 Juniper Networks 396 EMail: prz@juniper.net 398 Zhaohui Zhang 399 Juniper Networks 401 EMail: zzhang@juniper.net