idnits 2.17.1 draft-psenak-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 24, 2014) is 3465 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-ospf-prefix-link-attr-01 == 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 (~~), 4 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 27, 2015 Cisco 6 A. Dolganow 7 Alcatel-Lucent 8 T. Przygienda 9 Ericsson 10 J. Zhang 11 Juniper Networks, Inc. 12 S. Aldrin 13 Huawei Technologies 14 October 24, 2014 16 OSPF Extensions For BIER 17 draft-psenak-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 27, 2015. 54 Copyright Notice 56 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 79 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 | BS Length | MT-ID | BFR-id | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Sub-TLVs (variable) | 138 +- -+ 139 | | 141 Type: TBD 143 Length: 4 bytes 144 BS Length: A 1 octet field encoding the supported BitString length 145 associated with this BFR-prefix. The values allowed in this field 146 are specified in section 3 of 147 [I-D.wijnands-mpls-bier-encapsulation]. 149 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 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 If multiple BIER Sub-TLVs are present, all having the same BS Length 157 and MT-ID values, first one MUST be used and subsequent ones MUST be 158 ignored. 160 2.2. The BIER MPLS Encapsulation Sub-TLV 162 BIER MPLS Encapsulation Sub-TLV is a sub-TLV of the BIER Sub-TLV. 163 BIER MPLS Encapsulation Sub-TLVIt is used in order to advertise MPLS 164 specific information used for BIER. It MUST appear only once in the 165 BIER Sub-TLV. 167 BIER MPLS Encapsulation Sub-TLV has the following format: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 |Lbl Range Size | Label Range Base | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Type: TBD 179 Length: 4 bytes 181 Label Range Size: A 1 octet field encoding the label range size of 182 the label range. 184 Label Range Base: A 3 octet field, where the 20 rightmost bits 185 represent the first label in the label range. 187 The "label range" is the set of labels beginning with the label 188 range base and ending with (label range base)+(label range size)- 189 1. A unique label range is allocated for each BitStream length 190 and Multi-Topology ID. These labels are used for BIER forwarding 191 as described in [I-D.wijnands-bier-architecture] and 192 [I-D.wijnands-mpls-bier-encapsulation]. 194 The size of the label range is determined by the number of Set 195 Identifiers (SI) (section 2 of [I-D.wijnands-bier-architecture]) 196 that are used in the network. Each SI maps to a single label in 197 the label range. The first label is for SI=0, the second label is 198 for SI=1, etc. 200 2.3. Flooding scope of BIER Information 202 Flooding scope of the OSPF Extended Prefix Opaque LSA 203 [I-D.ietf-ospf-prefix-link-attr] that is used for advertising BIER 204 Sub TLV is set to area. If (and only if) a single BIER domain 205 contains multiple OSPF areas, OSPF must propagate BIER information 206 between areas. The following procedure is used in order to propagate 207 BIER related information between areas: 209 When an OSPF ABR advertises a Type-3 Summary LSA from an intra- 210 area or inter-area prefix to all its connected areas, it will also 211 originate an Extended Prefix Opaque LSA, as described in 212 [I-D.ietf-ospf-prefix-link-attr]. The flooding scope of the 213 Extended Prefix Opaque LSA type will be set to area-scope. The 214 route-type in the OSPF Extended Prefix TLV is set to inter-area. 215 When determining whether a BIER Sub-TLV should be included in this 216 LSA ABR will: 218 - look at its best path to the prefix in the source area and 219 find the advertising router associated with the best path to 220 that prefix. 222 - determine if such advertising router advertised a BIER Sub- 223 TLV for the prefix. If yes, ABR will copy the information from 224 such BIER MPLS Sub-TLV when advertising BIER MPLS Sub-TLV to 225 each connected area. 227 3. Security Considerations 229 Implementations must assure that malformed TLV and Sub-TLV 230 permutations do not result in errors which cause hard OSPF failures. 232 4. IANA Considerations 234 The document requests two new allocations from the OSPF Extended 235 Prefix sub-TLV registry as defined in 236 [I-D.ietf-ospf-prefix-link-attr]. 238 BIER Sub-TLV: TBD 239 BIER MPLS Encapsulation Sub-TLV: TBD 241 5. Acknowledgments 243 The authors would like to thank Rajiv Asati, Christian Martin, Greg 244 Shepherd and Eric Rosen for their contribution. 246 6. Normative References 248 [I-D.ietf-ospf-prefix-link-attr] 249 Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 250 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 251 Advertisement", draft-ietf-ospf-prefix-link-attr-01 (work 252 in progress), September 2014. 254 [I-D.wijnands-bier-architecture] 255 Wijnands, I., Rosen, E., Dolganow, A., and T. Przygienda, 256 "Multicast using Bit Index Explicit Replication", draft- 257 wijnands-bier-architecture-00 (work in progress), 258 September 2014. 260 [I-D.wijnands-mpls-bier-encapsulation] 261 Wijnands, I., Rosen, E., Dolganow, A., and J. Tantsura, 262 "Encapsulation for Bit Index Explicit Replication in MPLS 263 Networks", draft-wijnands-mpls-bier-encapsulation-00 (work 264 in progress), September 2014. 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 270 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 271 4915, June 2007. 273 Authors' Addresses 275 Peter Psenak (editor) 276 Cisco 277 Apollo Business Center 278 Mlynske nivy 43 279 Bratislava 821 09 280 Slovakia 282 Email: ppsenak@cisco.com 283 Nagendra Kumar 284 Cisco 285 7200 Kit Creek Road 286 Research Triangle Park, NC 27709 287 US 289 Email: naikumar@cisco.com 291 IJsbrand Wijnands 292 Cisco 293 De Kleetlaan 6a 294 Diegem 1831 295 Belgium 297 Email: ice@cisco.com 299 Andrew Dolganow 300 Alcatel-Lucent 301 600 March Rd. 302 Ottawa, Ontario K2K 2E6 303 Canada 305 Email: andrew.dolganow@alcatel-lucent.com 307 Tony Przygienda 308 Ericsson 309 300 Holger Way 310 San Jose, CA 95134 311 USA 313 Email: antoni.przygienda@ericsson.com 315 Jeffrey Zhang 316 Juniper Networks, Inc. 317 10 Technology Park Drive 318 Westford, MA 01886 319 USA 321 Email: zzhang@juniper.net 322 Sam Aldrin 323 Huawei Technologies 324 2330 Central Expressway 325 Santa Clara, CA 95051 326 USA 328 Email: zzhang@juniper.net