idnits 2.17.1 draft-ietf-bier-ospf-bier-extensions-03.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 14, 2016) is 2773 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 (-05) exists of draft-wijnands-bier-architecture-00 == Outdated reference: A later version (-02) exists of draft-wijnands-mpls-bier-encapsulation-00 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF P. Psenak, Ed. 3 Internet-Draft N. Kumar 4 Intended status: Standards Track IJ. Wijnands 5 Expires: March 18, 2017 Cisco 6 A. Dolganow 7 Alcatel-Lucent 8 T. Przygienda 9 J. Zhang 10 Juniper Networks, Inc. 11 S. Aldrin 12 Google, Inc. 13 September 14, 2016 15 OSPF Extensions for BIER 16 draft-ietf-bier-ospf-bier-extensions-03.txt 18 Abstract 20 Bit Index Explicit Replication (BIER) is an architecture that 21 provides multicast forwarding through a "BIER domain" without 22 requiring intermediate routers to maintain multicast related per-flow 23 state. Neither does BIER require an explicit tree-building protocol 24 for its operation. A multicast data packet enters a BIER domain at a 25 "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at 26 one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router 27 adds a BIER header to the packet. Such header contains a bit-string 28 in which each bit represents exactly one BFER to forward the packet 29 to. The set of BFERs to which the multicast packet needs to be 30 forwarded is expressed by the according set of bits switched on in 31 BIER packet header. 33 This document describes the OSPF protocol extension required for BIER 34 with MPLS encapsulation. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 18, 2017. 53 Copyright Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Flooding of the BIER Information in OSPF . . . . . . . . . . 3 72 2.1. The BIER Sub-TLV . . . . . . . . . . . . . . . . . . . . 3 73 2.2. The BIER MPLS Encapsulation Sub-TLV . . . . . . . . . . . 4 74 2.3. Optional BIER Tree Type Sub-TLV . . . . . . . . . . . . . 5 75 2.4. Flooding scope of BIER Information . . . . . . . . . . . 6 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 79 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 Bit Index Explicit Replication (BIER) is an architecture that 85 provides optimal multicast forwarding through a "BIER domain" without 86 requiring intermediate routers to maintain any multicast related per- 87 flow state. Neither does BIER explicitly require a tree-building 88 protocol for its operation. A multicast data packet enters a BIER 89 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 90 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 91 The BFIR router adds a BIER header to the packet. The BIER header 92 contains a bit-string in which each bit represents exactly one BFER 93 to forward the packet to. The set of BFERs to which the multicast 94 packet needs to be forwarded is expressed by setting the bits that 95 correspond to those routers in the BIER header. 97 BIER architecture requires routers participating in BIER to exchange 98 BIER related information within a given domain. BIER architecture 99 permits link-state routing protocols to perform distribution of such 100 information. This document describes extensions to OSPF necessary to 101 carry BIER specific information in the case where BIER uses MPLS 102 encapsulation as described in [I-D.wijnands-mpls-bier-encapsulation]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 2. Flooding of the BIER Information in OSPF 110 All BIER specific information that a BFR needs to advertise to other 111 BFRs is associated with a BFR-Prefix. BFR prefix is a unique (within 112 a given BIER domain), routable IP address that is assigned to each 113 BFR as described in more detail in section 2 of 114 [I-D.wijnands-bier-architecture]. 116 Given that BIER information must be associated with a BFR prefix, the 117 OSPF Extended Prefix Opaque LSA [I-D.ietf-ospf-prefix-link-attr] has 118 been chosen to flood it. 120 2.1. The BIER Sub-TLV 122 A new Sub-TLV of the Extended Prefix TLV (defined in 123 [I-D.ietf-ospf-prefix-link-attr]) is defined for distributing BIER 124 information. The new Sub-TLV is called BIER Sub-TLV. Multiple BIER 125 Sub-TLVs may be included in the Extended Prefix TLV. 127 BIER Sub-TLV has the following format: 129 0 1 2 3 130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Type | Length | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Sub-domain-ID | MT-ID | BFR-id | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Sub-TLVs (variable) | 137 +- -+ 138 | | 140 Type: TBD 142 Length: variable 143 Sub-domain-ID: Unique value identifying the BIER sub-domain within 144 the BIER domain, as described in section 1 of 145 [I-D.wijnands-bier-architecture]. 147 MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies 148 the topology that is associated with the BIER sub-domain. 150 BFR-id: A 2 octet field encoding the BFR-id, as documented in 151 section 2 [I-D.wijnands-bier-architecture]. If the BFR is not 152 locally configured with a valid BFR-id, the value of this field is 153 set to invalid BFR-id per [I-D.wijnands-bier-architecture]. 155 Each BFR sub-domain MUST be associated with one and only one OSPF 156 topology that is identified by the MT-ID. If the association between 157 BIER sub-domain and OSPF topology advertised in the BIER sub-TLV by 158 other BFRs is in conflict with the association locally configured on 159 the receiving router, whole BIER sub-TLV of the advertising routers 160 MUST be ignored. 162 If a BFR advertises the same Sub-domain-ID in multiple BIER sub-TLVs, 163 the BRF MUST be treated as if it did not advertise a BIER sub-TLV for 164 such sub-domain. 166 All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a 167 given MT-ID and Sub-domain-ID. When such duplication is detected all 168 BFRs advertising duplicates MUST be treated as if they did not 169 advertise a valid BFR-id. 171 2.2. The BIER MPLS Encapsulation Sub-TLV 173 BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV. 174 BIER MPLS Encapsulation Sub-TLV is used in order to advertise MPLS 175 specific information used for BIER. It MAY appear multiple times in 176 the BIER Sub-TLV. 178 BIER MPLS Encapsulation Sub-TLV has the following format: 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |Lbl Range Size | Label Range Base | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | BS Length | Reserved | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Type: TBD 191 Length: 4 bytes 193 Label Range Size: A 1 octet field encoding the label range size of 194 the label range. It MUST be greater then 0, otherwise the 195 advertising router MUST be treated as if it did not advertise a 196 BIER sub-TLV. 198 Label Range Base: A 3 octet field, where the 20 rightmost bits 199 represent the first label in the label range. 201 BS Length: A 1 octet field encoding the supported BitString length 202 associated with this BFR-prefix. The values allowed in this field 203 are specified in section 3 of 204 [I-D.wijnands-mpls-bier-encapsulation]. 206 The "label range" is the set of labels beginning with the label 207 range base and ending with (label range base)+(label range size)- 208 1. A unique label range is allocated for each BitStream length 209 and Sub-domain-ID. These labels are used for BIER forwarding as 210 described in [I-D.wijnands-bier-architecture] and 211 [I-D.wijnands-mpls-bier-encapsulation]. 213 The size of the label range is determined by the number of Set 214 Identifiers (SI) (section 2 of [I-D.wijnands-bier-architecture]) 215 that are used in the network. Each SI maps to a single label in 216 the label range. The first label is for SI=0, the second label is 217 for SI=1, etc. 219 If same BS length is repeated in multiple BIER MPLS Encapsulation 220 Sub-TLV inside the same BIER Sub-TLV, the advertising router MUST be 221 treated as if it did not advertise a BIER sub-TLV. 223 Label ranges within all BIER MPLS Encapsulation Sub-TLV inside the 224 same BIER Sub-TLV MUST NOT overlap. If the overlap is detected, the 225 advertising router MUST be treated as if it did not advertise a BIER 226 sub-TLV. 228 All advertised labels MUST be valid, otherwise the advertising router 229 MUST be treated as if it did not advertise a BIER sub-TLV. 231 2.3. Optional BIER Tree Type Sub-TLV 233 This Sub-TLV carries the information associated with the supported 234 BIER tree type for a subdomain. This Sub-TLV is optional and its 235 absence has the same semantics as its presence with Tree Type value 0 236 (SPF). When Tree Type 0 is used it is recommended that this Sub-TLV 237 is omitted in order to reduce the space consumed in the parent TLV. 239 This Sub-TLV MAY occur no more than once in a BIER sub-TLV. If 240 multiple occurences of this Sub-TLV are present in a single BIER Sub- 241 TLV the advertising router MUST be treated as if it did not advertise 242 a BIER sub-TLV. 244 If the tree type (implied or explicitly advertised) does not match 245 the locally configured tree type associated with the matching 246 subdomain the advertising router MUST be treated as if it did not 247 advertise a BIER sub-TLV. 249 0 1 2 3 250 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Tree Type | 255 +-+-+-+-+-+-+-+-+ 257 Type: value of 1 indicating BIER Tree Type. 259 Length: 1 octet. 261 Tree Type: 1 octet 263 2.4. Flooding scope of BIER Information 265 Flooding scope of the OSPF Extended Prefix Opaque LSA 266 [I-D.ietf-ospf-prefix-link-attr] that is used for advertising BIER 267 Sub TLV is set to area. To allow BIER deployment in a multi-area 268 environment, OSPF must propagate BIER information between areas. The 269 following procedure is used in order to propagate BIER related 270 information between areas: 272 When an OSPF ABR advertises a Type-3 Summary LSA from an intra- 273 area or inter-area prefix to all its connected areas, it will also 274 originate an Extended Prefix Opaque LSA, as described in 275 [I-D.ietf-ospf-prefix-link-attr]. The flooding scope of the 276 Extended Prefix Opaque LSA type will be set to area-scope. The 277 route-type in the OSPF Extended Prefix TLV is set to inter-area. 278 When determining whether a BIER Sub-TLV should be included in this 279 LSA ABR will: 281 - look at its best path to the prefix in the source area and 282 find the advertising router associated with the best path to 283 that prefix. 285 - determine if such advertising router advertised a BIER Sub- 286 TLV for the prefix. If yes, ABR will copy the information from 287 such BIER MPLS Sub-TLV when advertising BIER MPLS Sub-TLV to 288 each connected area. 290 3. Security Considerations 292 Implementations must assure that malformed TLV and Sub-TLV 293 permutations do not result in errors which cause hard OSPF failures. 295 4. IANA Considerations 297 The document requests three new allocations from the OSPF Extended 298 Prefix sub-TLV registry as defined in 299 [I-D.ietf-ospf-prefix-link-attr]. 301 BIER Sub-TLV: TBD 303 BIER MPLS Encapsulation Sub-TLV: TBD 305 BIER Tree Type Sub-TLV: TBD 307 5. Acknowledgments 309 The authors would like to thank Rajiv Asati, Christian Martin, Greg 310 Shepherd and Eric Rosen for their contribution. 312 6. Normative References 314 [I-D.ietf-ospf-prefix-link-attr] 315 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 316 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 317 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 318 in progress), August 2015. 320 [I-D.wijnands-bier-architecture] 321 Wijnands, I., Rosen, E., Dolganow, A., and T. Przygienda, 322 "Multicast using Bit Index Explicit Replication", draft- 323 wijnands-bier-architecture-00 (work in progress), 324 September 2014. 326 [I-D.wijnands-mpls-bier-encapsulation] 327 Wijnands, I., Rosen, E., Dolganow, A., and J. Tantsura, 328 "Encapsulation for Bit Index Explicit Replication in MPLS 329 Networks", draft-wijnands-mpls-bier-encapsulation-00 (work 330 in progress), September 2014. 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, 334 DOI 10.17487/RFC2119, March 1997, 335 . 337 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 338 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 339 RFC 4915, DOI 10.17487/RFC4915, June 2007, 340 . 342 Authors' Addresses 344 Peter Psenak (editor) 345 Cisco 346 Apollo Business Center 347 Mlynske nivy 43 348 Bratislava 821 09 349 Slovakia 351 Email: ppsenak@cisco.com 353 Nagendra Kumar 354 Cisco 355 7200 Kit Creek Road 356 Research Triangle Park, NC 27709 357 US 359 Email: naikumar@cisco.com 361 IJsbrand Wijnands 362 Cisco 363 De Kleetlaan 6a 364 Diegem 1831 365 Belgium 367 Email: ice@cisco.com 369 Andrew Dolganow 370 Alcatel-Lucent 371 600 March Rd. 372 Ottawa, Ontario K2K 2E6 373 Canada 375 Email: andrew.dolganow@alcatel-lucent.com 376 Tony Przygienda 377 Juniper Networks, Inc. 378 10 Technology Park Drive 379 Westford, MA 01886 380 USA 382 Email: prz@juniper.net 384 Jeffrey Zhang 385 Juniper Networks, Inc. 386 10 Technology Park Drive 387 Westford, MA 01886 388 USA 390 Email: zzhang@juniper.net 392 Sam Aldrin 393 Google, Inc. 394 1600 Amphitheatre Parkway 395 Mountain View, CA 396 USA 398 Email: aldrin.ietf@gmail.com