idnits 2.17.1 draft-zzhang-bier-algorithm-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2018) is 2262 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) == Unused Reference: 'RFC1925' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 225, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1925 == Outdated reference: A later version (-11) exists of draft-ietf-bier-isis-extensions-07 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-12 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-00 Summary: 2 errors (**), 0 flaws (~~), 6 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 A. Dolganow 5 Expires: August 19, 2018 Nokia 6 A. Przygienda 7 Juniper Networks 8 February 15, 2018 10 BIER Algorithms 11 draft-zzhang-bier-algorithm-00 13 Abstract 15 This document specifies signaling and procedures for non-SPF BIER 16 tree computation covering several practical use cases discussed in 17 deployment scenarios. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC2119. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 19, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. BIER Tree Computation Algorithms . . . . . . . . . . . . . . 2 62 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4.1. Handling BIER Incapable Routers via a different SPF Tree 3 64 4.2. Computing Maximum Disjoint Trees for Subdomains Sharing a 65 Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.3. Dealing with Ingress Replication Degradation . . . . . . 4 67 4.4. Scaling up BIER with Traffic Engineering . . . . . . . . 5 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 72 7.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Terminologies 77 Familiarity with BIER protocols and procedures is assumed. Some 78 terminologies are listed below for convenience. 80 2. Introduction 82 In the BIER architecture, a multicast specific routing underlay (not 83 necessarily congruent with the unicast topology), or multiple routing 84 underlays (again not necessarily congruent with the unicast 85 topologies) could be used for forwarding BIER packets. A routing 86 underlay used for BIER is specified today as combination of a routing 87 topology [RFC5120] and a calculation algorithm (BAR 88 [I-D.ietf-bier-isis-extensions]) per sub-domain. Currently, BAR is 89 unspecified beside a single codepoint taken for basic unicast SPF 90 alignment. 92 3. BIER Tree Computation Algorithms 94 OSPF Extensions for BIER [I-D.ietf-bier-ospf-bier-extensions] and 95 ISIS Extensions for BIER [I-D.ietf-bier-isis-extensions] specify 96 currently an BIER AlgoRithm (BAR, originally Tree-ID) field in the 97 BIER sub-TLV: 99 """ BAR: ... 0 is the only supported value defined in this 100 document and represents Shortest Path First (SPF) 101 algorithm based on IGP link metric. This is the 102 standard shortest path algorithm as computed by 103 the OSPF protocol. ... """ 105 This document proposes to define codepoints for additional algorithms 106 outlined in the architecture document to handle BIER incapable 107 routers within BIER topologies and solve other challenges that BIER 108 faces when deployed over standard SPF. Moreover we describe the need 109 for an algorithm that deals with computations where subdomains can 110 share the same multi topology for protection purposes while computing 111 disjoint trees. We also mention a more difficult fanout limitation 112 problem that can benefit from a new algorithm and quickly mention 113 possible traffic engineering implications. 115 Whatever the computation algorithm used, all routers in the same area 116 are recommended to use the same method to prevent blackholes or 117 stable loops. If a mix is used (for example by using different BAR 118 for different stream forwarding or using different BAR on different 119 BFIRs), a special care must be given to prevent blackholes and/or 120 loops. 122 If an alternative method to BAR 0 is used, then the routers MUST 123 signal that method by the means of a different BAR value. The method 124 is expected to specify compatibility to other BAR values if so 125 desired. 127 In case where multiple BAR values are present in the same routing 128 underlay each set of routers with same BAR may split from the routers 129 with a different BAR value, effectively partitioning the network for 130 a given multicast stream forwarding. 132 4. Specification 134 4.1. Handling BIER Incapable Routers via a different SPF Tree 136 Section 6.9 of the BIER Architecture Specification [RFC8279] touches 137 on possible methods of dealing with BIER incapable routers. As most 138 practical alternative BIER incapable routers can be simply pruned 139 during the SPF calculation from the candidate list. This case 140 presents itself if multi topology cannot be deployed due to some 141 considerations or it is desired to cross non BIER routers via 142 tunneling. 144 To be exact, in the rest of the document, a BIER incapable router 145 refers to any of the following: 147 o A router that does not support BIER at all. 149 o A BFR that does not advertise the specific for which a particular 151 calculation is being performed. We denote this for simplicity as 152 combination in further discourse. 154 A new BAR value (suggested value of 1) is defined in this document to 155 specify the method of pruning BIER incapable routers (not putting 156 them onto the candidate list when encountered during SPF). Any 157 router supporting this method and provisioned to use this method MUST 158 signal this BAR value. 160 Observe further that this allows to use in brown field deployments 161 routers that do not support BIER at all but can easily tunnel it. 162 The modification of the algorithm will use any forwarding adjacency 163 to a BIER capable router then. 165 4.2. Computing Maximum Disjoint Trees for Subdomains Sharing a Topology 167 For certain class of multicast deployments it is desirable to send 168 data across two BIER subdomains that are maximally disjoint. While 169 this can be addressed by using multiple completely disjoint 170 topologies, such a method has to basically partition the network and 171 precondition multi topology deployments or multiple IGPs. A more 172 efficient method is to compute the tree for a subdomain while 173 avoiding another subdomain on the same multi-topology. Future 174 version of this document will provide a detailed algorithm to 175 calculate the tree and claim a BAR registry value. 177 4.3. Dealing with Ingress Replication Degradation 179 BIER, when following strict SPF unicast routing is bound to degrade 180 into ingress replication in certain topologies when it follows SPF or 181 the fanout may overwhelm the replication capacity of a specific 182 system. One possibility is to prune the topology using multi 183 topology deployment which may limit the recovery potential on link 184 failures, a better one is obviously to compute a specialized tree 185 that limits the fanout. Future version of this document will provide 186 a detailed algorithm to calculate the tree and claim a BAR registry 187 value. 189 4.4. Scaling up BIER with Traffic Engineering 191 Suggested traffic engineering architecture for BIER 192 [I-D.ietf-bier-te-arch] offers a very limited scalability only. It 193 would be desirable to subject BIER to proper TE point-to-multipoint 194 computation. Albeit BIER results can be shaped with multi topology 195 again, a computation including TE metrics and constraints and maybe 196 even multicast specific metrics like node fanouts could introduce a 197 distributed, scalable TE for BIER. Such a computation could be 198 performed in a centralized fashion of course and resulting BIFTs 199 downloaded to routers as well but such an approach is outside the 200 scope of this document. 202 5. IANA Considerations 204 This document proposes to create BIER AlgoRithm registry with the 205 following initial values. 207 0: Default SPF calculation that includes all nodes. 209 1: SPF calculation that prunes routers that do not support the 210 combination for which the calculation is 211 performed before putting them on the candidate list. 213 6. Acknowledgements 215 To be provided. 217 7. References 219 7.1. Normative References 221 [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, 222 DOI 10.17487/RFC1925, April 1996, 223 . 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, 227 DOI 10.17487/RFC2119, March 1997, 228 . 230 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 231 Topology (MT) Routing in Intermediate System to 232 Intermediate Systems (IS-ISs)", RFC 5120, 233 DOI 10.17487/RFC5120, February 2008, 234 . 236 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 237 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 238 Explicit Replication (BIER)", RFC 8279, 239 DOI 10.17487/RFC8279, November 2017, 240 . 242 7.2. Informative References 244 [I-D.ietf-bier-isis-extensions] 245 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 246 "BIER support via ISIS", draft-ietf-bier-isis- 247 extensions-07 (work in progress), February 2018. 249 [I-D.ietf-bier-ospf-bier-extensions] 250 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 251 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 252 for BIER", draft-ietf-bier-ospf-bier-extensions-12 (work 253 in progress), February 2018. 255 [I-D.ietf-bier-te-arch] 256 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 257 Engineering for Bit Index Explicit Replication (BIER-TE)", 258 draft-ietf-bier-te-arch-00 (work in progress), January 259 2018. 261 Authors' Addresses 263 Zhaohui Zhang 264 Juniper Networks 266 EMail: zzhang@juniper.net 268 Andrew Dolganow 269 Nokia 271 EMail: andrew.dolganow@nokia.com 273 Antoni Przygienda 274 Juniper Networks 276 EMail: prz@juniper.net