idnits 2.17.1 draft-ietf-bier-ospf-bier-extensions-01.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 (October 19, 2015) is 3113 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: April 21, 2016 Cisco 6 A. Dolganow 7 Alcatel-Lucent 8 T. Przygienda 9 Ericsson 10 J. Zhang 11 Juniper Networks, Inc. 12 S. Aldrin 13 Google, Inc. 14 October 19, 2015 16 OSPF Extensions For BIER 17 draft-ietf-bier-ospf-bier-extensions-01.txt 19 Abstract 21 Bit Index Explicit Replication (BIER) is an architecture that 22 provides optimal multicast forwarding through a "BIER domain" without 23 requiring intermediate routers to maintain any multicast related per- 24 flow state. BIER also does not require any explicit tree-building 25 protocol for its operation. A multicast data packet enters a BIER 26 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 27 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 28 The BFIR router adds a BIER header to the packet. The BIER header 29 contains a bit-string in which each bit represents exactly one BFER 30 to forward the packet to. The set of BFERs to which the multicast 31 packet needs to be forwarded is expressed by setting the bits that 32 correspond to those routers in the BIER header. 34 This document describes the OSPF protocol extension required for BIER 35 with MPLS encapsulation. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 21, 2016. 54 Copyright Notice 56 Copyright (c) 2015 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Flooding of the BIER Information in OSPF . . . . . . . . . . 3 73 2.1. The BIER Sub-TLV . . . . . . . . . . . . . . . . . . . . 3 74 2.2. The BIER MPLS Encapsulation Sub-TLV . . . . . . . . . . . 4 75 2.3. Flooding scope of BIER Information . . . . . . . . . . . 5 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 79 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 within a 98 given BIER domain to exchange some BIER specific information among 99 themselves. BIER architecture allows link-state routing protocols to 100 perform the distribution of these information. In this document we 101 describe extensions to OSPF to distribute BIER specific information 102 for the case where BIER uses MPLS encapsulation as described in 103 [I-D.wijnands-mpls-bier-encapsulation]. 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Flooding of the BIER Information in OSPF 111 All the BIER specific information that a BIER router needs to 112 advertise to other BIER routers are associated with the BFR-Prefix, a 113 unique (within a given BIER domain), routable IP address that is 114 assign to each BIER router as described in section 2 of 115 [I-D.wijnands-bier-architecture]. 117 Given that the BIER information is associated with the prefix, the 118 OSPF Extended Prefix Opaque LSA [I-D.ietf-ospf-prefix-link-attr] is 119 used to flood BIER related information. 121 2.1. The BIER Sub-TLV 123 A new Sub-TLV of the Extended Prefix TLV (defined in 124 [I-D.ietf-ospf-prefix-link-attr]) is defined for distributing BIER 125 information. The new Sub-TLV is called BIER Sub-TLV. Multiple BIER 126 Sub-TLVs may be included in the Extended Prefix TLV. 128 BIER Sub-TLV has the following format: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Sub-domain-ID | MT-ID | BFR-id | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Sub-TLVs (variable) | 138 +- -+ 139 | | 141 Type: TBD 143 Length: variable 144 Sub-domain-ID: Unique value identifying the BIER sub-domain within 145 the BIER domain, as described in section 1 of 146 [I-D.wijnands-bier-architecture]. 148 MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies 149 the topology that is associated with the BIER sub-domain. 151 BFR-id: A 2 octet field encoding the BFR-id, as documented in 152 section 2 [I-D.wijnands-bier-architecture]. If the BFR-id is 153 zero, it means, the advertising router is not advertising any 154 BIER-id. 156 Each BFR sub-domain MUST be associate with a single OSPF topology 157 that is identified by the MT-ID. If the association between BEIR 158 sub-domain and OSPF topology advertised in the BIER sub-TLV is in 159 conflict with the association locally configured on the receiving 160 router, BIER sub-TLV SHOULD be ignored. 162 2.2. The BIER MPLS Encapsulation Sub-TLV 164 BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV. 165 BIER MPLS Encapsulation Sub-TLV is used in order to advertise MPLS 166 specific information used for BIER. It MAY appear multiple times in 167 the BIER Sub-TLV. 169 BIER MPLS Encapsulation Sub-TLV has the following format: 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |Lbl Range Size | Label Range Base | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | BS Length | Reserved | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Type: TBD 183 Length: 4 bytes 185 Label Range Size: A 1 octet field encoding the label range size of 186 the label range. It MUST be greater then 0, otherwise the TLV 187 MUST be ignored. 189 Label Range Base: A 3 octet field, where the 20 rightmost bits 190 represent the first label in the label range. 192 BS Length: A 1 octet field encoding the supported BitString length 193 associated with this BFR-prefix. The values allowed in this field 194 are specified in section 3 of 195 [I-D.wijnands-mpls-bier-encapsulation]. 197 The "label range" is the set of labels beginning with the label 198 range base and ending with (label range base)+(label range size)- 199 1. A unique label range is allocated for each BitStream length 200 and Sub-domain-ID. These labels are used for BIER forwarding as 201 described in [I-D.wijnands-bier-architecture] and 202 [I-D.wijnands-mpls-bier-encapsulation]. 204 The size of the label range is determined by the number of Set 205 Identifiers (SI) (section 2 of [I-D.wijnands-bier-architecture]) 206 that are used in the network. Each SI maps to a single label in 207 the label range. The first label is for SI=0, the second label is 208 for SI=1, etc. 210 If same BS length is repeated in multiple BIER MPLS Encapsulation 211 Sub-TLV inside the same BIER Sub-TLV, the first BIER MPLS 212 Encapsulation Sub-TLV with such BS length MUST be used and any 213 subsequent BIER MPLS Encapsulation Sub-TLVs with the same BS length 214 MUST be ignored. 216 Label ranges within all BIER MPLS Encapsulation Sub-TLV inside the 217 same BIER Sub-TLV SHOULD NOT overlap. If the overlap is detected, 218 overlapping BIER MPLS Encapsulation Sub-TLV SHOULD be ignored. 220 2.3. Flooding scope of BIER Information 222 Flooding scope of the OSPF Extended Prefix Opaque LSA 223 [I-D.ietf-ospf-prefix-link-attr] that is used for advertising BIER 224 Sub TLV is set to area. To allow BIER deployment in a multi-area 225 environment, OSPF must propagate BIER information between areas. The 226 following procedure is used in order to propagate BIER related 227 information between areas: 229 When an OSPF ABR advertises a Type-3 Summary LSA from an intra- 230 area or inter-area prefix to all its connected areas, it will also 231 originate an Extended Prefix Opaque LSA, as described in 232 [I-D.ietf-ospf-prefix-link-attr]. The flooding scope of the 233 Extended Prefix Opaque LSA type will be set to area-scope. The 234 route-type in the OSPF Extended Prefix TLV is set to inter-area. 235 When determining whether a BIER Sub-TLV should be included in this 236 LSA ABR will: 238 - look at its best path to the prefix in the source area and 239 find the advertising router associated with the best path to 240 that prefix. 242 - determine if such advertising router advertised a BIER Sub- 243 TLV for the prefix. If yes, ABR will copy the information from 244 such BIER MPLS Sub-TLV when advertising BIER MPLS Sub-TLV to 245 each connected area. 247 3. Security Considerations 249 Implementations must assure that malformed TLV and Sub-TLV 250 permutations do not result in errors which cause hard OSPF failures. 252 4. IANA Considerations 254 The document requests two new allocations from the OSPF Extended 255 Prefix sub-TLV registry as defined in 256 [I-D.ietf-ospf-prefix-link-attr]. 258 BIER Sub-TLV: TBD 260 BIER MPLS Encapsulation Sub-TLV: TBD 262 5. Acknowledgments 264 The authors would like to thank Rajiv Asati, Christian Martin, Greg 265 Shepherd and Eric Rosen for their contribution. 267 6. Normative References 269 [I-D.ietf-ospf-prefix-link-attr] 270 Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., 271 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 272 Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work 273 in progress), August 2015. 275 [I-D.wijnands-bier-architecture] 276 Wijnands, I., Rosen, E., Dolganow, A., and T. Przygienda, 277 "Multicast using Bit Index Explicit Replication", draft- 278 wijnands-bier-architecture-00 (work in progress), 279 September 2014. 281 [I-D.wijnands-mpls-bier-encapsulation] 282 Wijnands, I., Rosen, E., Dolganow, A., and J. Tantsura, 283 "Encapsulation for Bit Index Explicit Replication in MPLS 284 Networks", draft-wijnands-mpls-bier-encapsulation-00 (work 285 in progress), September 2014. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 293 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 294 RFC 4915, DOI 10.17487/RFC4915, June 2007, 295 . 297 Authors' Addresses 299 Peter Psenak (editor) 300 Cisco 301 Apollo Business Center 302 Mlynske nivy 43 303 Bratislava 821 09 304 Slovakia 306 Email: ppsenak@cisco.com 308 Nagendra Kumar 309 Cisco 310 7200 Kit Creek Road 311 Research Triangle Park, NC 27709 312 US 314 Email: naikumar@cisco.com 316 IJsbrand Wijnands 317 Cisco 318 De Kleetlaan 6a 319 Diegem 1831 320 Belgium 322 Email: ice@cisco.com 324 Andrew Dolganow 325 Alcatel-Lucent 326 600 March Rd. 327 Ottawa, Ontario K2K 2E6 328 Canada 330 Email: andrew.dolganow@alcatel-lucent.com 331 Tony Przygienda 332 Ericsson 333 300 Holger Way 334 San Jose, CA 95134 335 USA 337 Email: antoni.przygienda@ericsson.com 339 Jeffrey Zhang 340 Juniper Networks, Inc. 341 10 Technology Park Drive 342 Westford, MA 01886 343 USA 345 Email: zzhang@juniper.net 347 Sam Aldrin 348 Google, Inc. 349 1600 Amphitheatre Parkway 350 Mountain View, CA 351 USA 353 Email: aldrin.ietf@gmail.com