idnits 2.17.1 draft-ietf-bier-bar-ipa-06.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 draft header indicates that this document updates RFC8401, but the abstract doesn't seem to directly say this. It does mention RFC8401 though, so this could be OK. -- The draft header indicates that this document updates RFC8444, but the abstract doesn't seem to directly say this. It does mention RFC8444 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1633 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER Z. Zhang 3 Internet-Draft A. Przygienda 4 Updates: 8401,8444 (if approved) Juniper Networks 5 Intended status: Standards Track A. Dolganow 6 Expires: May 7, 2020 Individual 7 H. Bidgoli 8 Nokia 9 I. Wijnands 10 Cisco Systems 11 A. Gulko 12 Thomson Reuters 13 November 4, 2019 15 BIER Underlay Path Calculation Algorithm and Constraints 16 draft-ietf-bier-bar-ipa-06 18 Abstract 20 This document specifies general rules for interaction between the BAR 21 (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/ 22 OSPFv2 Extensions for BIER. The semantics for the BAR and IPA fields 23 (when both or any of them is non-zero) defined in this document 24 updates the semantics defined in RFC8444/RFC8401. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in BCP 31 14 [RFC2119] [RFC8174] when, and only when, they appear in all 32 capitals, as shown here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 7, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. General Rules for the BAR and IPA fields . . . . . . . . . . 3 69 2.1. When BAR Is Not Used . . . . . . . . . . . . . . . . . . 4 70 2.2. Exceptions/Extensions to the General Rules . . . . . . . 4 71 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 7.2. Informative References . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 80 1. Introduction 82 In Bit Index Explicit Replication (BIER) architecture [RFC8279], 83 packets with a BIER encapsulation header are forwarded to the 84 neighbors on the underlay paths towards the BFERs. For each sub- 85 domain, the paths are calculated in the underlay topology for the 86 sub-domain, following a calculation algorithm specific to the sub- 87 domain. The could be congruent or incongruent 88 with unicast. The topology could be a default or non-default 89 topology [RFC5120]. The algorithm could be a generic IGP algorithm 90 (e.g. SPF) or could be a BIER specific one defined in the future. 92 In [RFC8401] and [RFC8444], an 8-bit BAR (BIER Algorithm) field and 93 8-bit IPA (IGP Algorithm) field are defined to signal the BIER 94 specific algorithm and generic IGP Algorithm respectively and only 95 value 0 is allowed for both fields in those two documents. This 96 document specifies the general rules for the two fields and their 97 interaction when either or both fields are not 0, and updates their 98 semantics defined in [RFC8444] and [RFC8401]. 100 2. General Rules for the BAR and IPA fields 102 For a particular sub-domain, all routers SHOULD be provisioned with 103 and signal the same BAR and IPA values. When a BFR discovers another 104 BFR advertising different BAR or IPA value from its own provisioned, 105 it MUST treat the advertising BFR as incapable of supporting BIER for 106 the sub-domain. How incapable routers are handled is outside the 107 scope of this document. 109 It is expected that both the BAR and IPA values could have both 110 algorithm and constraints semantics. To generalize, we introduce the 111 following terms: 113 o BC: BIER-specific Constraints 115 o BA: BIER-specific Algorithm 117 o RC: Generic Routing Constraints 119 o RA: Generic Routing Algorithm 121 o BCBA: BC + BA 123 o RCRA: RC + RA 125 A BAR value corresponds to a BCBA, and a IPA value corresponds to a 126 RCRA. Any of the RC/BC/BA could be "NULL", which means there are no 127 corresponding constraints or algorithm. 129 When a new BAR value is defined, its corresponding BC/BA semantics 130 MUST be specified. For a new IGP Algorithm to be used as a BIER IPA, 131 its RC/RA semantics MUST also be clear. 133 For a particular topology X (which could be a default topology or 134 non-default topology) that a sub-domain is associated with, a router 135 calculates the underlay paths according to its provisioned BCBA and 136 RCRA the following way: 138 1. Apply the BIER constraints, resulting in BC(X). 140 2. Apply the routing constraints, resulting in RC(BC(X)). 142 3. Select the algorithm AG as following: 144 A. If BA is NULL, AG is set to RA. 146 B. If BA is not NULL, AG is set to BA. 148 4. Run AG on RC(BC(X)). 150 2.1. When BAR Is Not Used 152 The BIER Algorithm registry established by [RFC8401] and also used in 153 [RFC8444] has value 0 for "No BIER specific algorithm is used". That 154 translates to NULL BA and NULL BC. Following the rules defined 155 above, the IPA value alone identifies the calculation algorithm and 156 constraints to be used for a particular sub-domain when BAR is 0. 158 2.2. Exceptions/Extensions to the General Rules 160 Exceptions or extensions to the above general rules may be specified 161 in the future for specific BAR and/or IPA values. When that happens, 162 compatibility with defined BAR and/or IPA values and semantics need 163 to be specified. 165 3. Examples 167 As an example, one may define BAR=x with semantics of "excluding BIER 168 incapable routers". That BIER specific constraint can go with any 169 IPA: whatever RCRA defined by the IPA are augmented with "excluding 170 BIER incapable routers", i.e., BIER incapable routers are not put 171 onto the candidate list during SPF calculation. 173 Note that if the BC and RC happen to conflict and lead to an empty 174 topology, then no native BIER forwarding path will be found. That is 175 a network design issue that an operator need to avoid when choosing 176 BAR/IPA. 178 4. IANA Considerations 180 No IANA Consideration is requested in this document. 182 5. Security Considerations 184 This document does not change the secuity aspects as discussed in 185 [RFC8279]. 187 6. Acknowledgements 189 The authors thanks Alia Atlas, Eric Rosen, Senthil Dhanaraj and many 190 others for their suggestions and comments. In particular, the BCBA/ 191 RCRA representation for the interaction rules is based on Alia's 192 write-up. 194 7. References 196 7.1. Normative References 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, 200 DOI 10.17487/RFC2119, March 1997, 201 . 203 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 204 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 205 May 2017, . 207 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 208 Zhang, "Bit Index Explicit Replication (BIER) Support via 209 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 210 . 212 [RFC8444] Psenak, P., Ed., Kumar, N., Wijnands, IJ., Dolganow, A., 213 Przygienda, T., Zhang, J., and S. Aldrin, "OSPFv2 214 Extensions for Bit Index Explicit Replication (BIER)", 215 RFC 8444, DOI 10.17487/RFC8444, November 2018, 216 . 218 7.2. Informative References 220 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 221 Topology (MT) Routing in Intermediate System to 222 Intermediate Systems (IS-ISs)", RFC 5120, 223 DOI 10.17487/RFC5120, February 2008, 224 . 226 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 227 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 228 Explicit Replication (BIER)", RFC 8279, 229 DOI 10.17487/RFC8279, November 2017, 230 . 232 Authors' Addresses 234 Zhaohui Zhang 235 Juniper Networks 237 EMail: zzhang@juniper.net 238 Antoni Przygienda 239 Juniper Networks 241 EMail: prz@juniper.net 243 Andrew Dolganow 244 Individual 246 EMail: adolgano@gmail.com 248 Hooman Bidgoli 249 Nokia 251 EMail: hooman.bidgoli@nokia.com 253 IJsbrand Wijnands 254 Cisco Systems 256 EMail: ice@cisco.com 258 Arkadiy Gulko 259 Thomson Reuters 261 EMail: arkadiy.gulko@thomsonreuters.com