idnits 2.17.1 draft-zhang-bier-flooding-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 an Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '... The address SHOULD be the same with...' RFC 2119 keyword, line 228: '... TLV MUST be ignored and not forw...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 30, 2017) is 2394 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) == Missing Reference: 'BIER-arch' is mentioned on line 226, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-bier-isis-extensions-05 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-07 == Outdated reference: A later version (-12) exists of draft-ietf-pim-source-discovery-bsr-06 ** Downref: Normative reference to an Experimental draft: draft-ietf-pim-source-discovery-bsr (ref. 'I-D.ietf-pim-source-discovery-bsr') Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BIER WG Zheng. Zhang 3 Internet-Draft BenChong. Xu 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 3, 2018 September 30, 2017 7 BIER Flooding Mechanism 8 draft-zhang-bier-flooding-00.txt 10 Abstract 12 This document introduces a method to flood BIER information in hybrid 13 network to build BIER forwarding plane. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 3, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Scheduled Update . . . . . . . . . . . . . . . . . . . . 4 52 2.2. Triggered Update . . . . . . . . . . . . . . . . . . . . 4 53 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. PFM message . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. BIER information TLV . . . . . . . . . . . . . . . . . . 5 56 3.3. BIER MPLS Encapsulation sub-TLV . . . . . . . . . . . . . 6 57 3.4. Optional BIER sub-domain BSL conversion sub-TLV . . . . . 7 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Problem Statement 65 Some networks have been deployed widely are hybrid networks. There 66 are different dynamic routing protocols running in the hybrid 67 networks. Multicast services can also be provided in these kinds of 68 networks because of the protocol independent feature of PIM. 70 BIER [I-D.ietf-bier-architecture] provides a new architecture for the 71 forwarding of multicast data packets. It does not require a protocol 72 for explicitly building multicast distribution trees, nor does it 73 require intermediate nodes to maintain any per-flow state. 74 [I-D.ietf-bier-isis-extensions] and 75 [I-D.ietf-bier-ospf-bier-extensions] are good at establishing BIER 76 forwarding plane in network which uses OSPF or IS-IS as BIER underlay 77 protocol. 79 | | 80 .........|................|......... 81 . ISIS | | . 82 . | | . 83 . MR1--------------MR2 . 84 . | . . | . 85 . | . . | . 86 . | . . | . 87 . | .. | . 88 . | . . | . 89 . | . . | . 90 . | . . | . 91 . MR3 MR4 . 92 . / \ / \ . 93 .................................... 94 / \ / \ 95 / \ / \ 96 / \ / \ 97 ................... ................ 98 . B1--------B2 . .B3--------B4 . 99 . . . . 100 . Rm . . Rx . 101 . ... . . ... . 102 . Rn . . Ry . 103 . . . . 104 . OSPF . . OSPF . 105 ................... ................ 106 Figure 1: An typical hybrid network 108 In the mentioned networks, there are more than one dynamic routing 109 protocols running in the networks. For example in figure 1, this is 110 a partial typical network in actually deployment. Two different 111 dynamic routing protocols and are used in the network. Sometimes 112 static configured routes also are used in some parts of the network. 113 In order to deploy BIER multicast, we can divide the network into 114 several BIER domains. Obviously the efficiency slows down due to 115 multiple encapsulating/ decapsulating executions. 117 2. Solution 119 The Bootstrap Router mechanism (BSR) [RFC5059] is a commonly used 120 mechanism for distributing dynamic Group to RP mappings in PIM. It 121 is responsible for flooding information about such mappings 122 throughout a PIM domain, so that all routers in the domain can have 123 the same information. [I-D.ietf-pim-source-discovery-bsr] defines a 124 mechanism that can flood any kind of information throughout a PIM 125 domain. This document borrows the idea from the two drafts, 126 introduces a mechanism to flood BIER node's information throughout a 127 BIER domain to build BIER forwarding plane. Nodes can use unicast 128 forwarding table directly to establish BIER forwarding plane. 130 The validation processing of PFM messages is the same as the 131 definition in [I-D.ietf-pim-source-discovery-bsr] section 3.2. 133 BIER node originates BIER information TLV and optional associated 134 sub-TLVs in PFM message. The PFM messages are flooded by throughout 135 the BIER domain. BFR gets routing information from the unicast 136 forwarding table directly, and computes BIER forwarding table. Then 137 BIER forwarding plane is established. 139 2.1. Scheduled Update 141 Because PIM advertisement is scheduled, the node's BIER information 142 is refreshed periodically. In case one node's BIER information 143 changes or expires, the other nodes recompute the BIER forwarding 144 table. The holdtime in the BIER information TLV is used to make the 145 item expired. 147 2.2. Triggered Update 149 If the BIER node's configuration changes, such as BFR-id, the node 150 should send update PFM messages immediately. Then other nodes can 151 recompute the new BIER forwarding table. 153 3. Message Format 155 3.1. PFM message 157 New TLVs are defined in PFM message to flood node's BIER information, 158 such as BFR-id, BFR-prefix and so on. The new TLVs align exactly 159 with the definition and restrictions in 160 [I-D.ietf-bier-isis-extensions] and 161 [I-D.ietf-bier-ospf-bier-extensions]. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |PIM Ver| Type |N| Reserved | Checksum | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Originator Address (Encoded-Unicast format) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Type 1 | Length 1 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Value 1 | 173 | . | 174 | . | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | . | 177 | . | 178 | Type n | Length n | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Value n | 181 | . | 182 | . | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: PFM message format 186 The format of PFM message is defined in 187 [I-D.ietf-pim-source-discovery-bsr]. 189 Originator Address: The router's address that originate the message. 190 The address SHOULD be the same with the node's BFR-prefix. 192 The other fields is the same as definition in 193 [I-D.ietf-pim-source-discovery-bsr]. 195 3.2. BIER information TLV 197 A new type of TLV is defined in PFM message. This new type TLV is 198 named by BIER information TLV. Two types of sub-TLV are associated 199 with it. There is no optional BIER tree type sub-TLV in PFM message 200 because of the independence of routing protocol. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type = 1 | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Reserved | subdomain-id | BFR-id | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Holdtime | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | BFR-prefix (Encoded-Unicast format) | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 3: BIER information TLV 215 o Type: The value of type should be assigned by IANA. 217 o Length: The total length of the BIER information TLV except for 218 the first two fields. 220 o Reserved: Must be 0 on transmission, ignored on reception. May be 221 used in future version. 1 octets. 223 o Subdomain-id: Unique value identifying the BIER sub-domain. 1 224 octet. 226 o BFR-id: The value of BFR-id defined in [BIER-arch], 2 octets. 0 is 227 invalid value. If the value of this field is set to 0, the whole 228 TLV MUST be ignored and not forwarded. 230 o Holdtime: The life cycle of the BIER information. The default 231 value is 60s. 233 o BFR-prefix: The BFR-prefix of the node in this sub-domain. The 234 format for this address is given in the Encoded-Unicast address in 235 [RFC7761]. 237 A node may belong to several BIER sub-domains, so it is possible that 238 there are multiple BIER information TLVs in the PFM message. 240 3.3. BIER MPLS Encapsulation sub-TLV 242 In case the nodes in the network support MPLS forwarding, BIER MPLS 243 encapsulation sub-TLV can be advertised for a specific bitstring 244 length for a certain (MT,subdomain). This sub-TLV may appear 245 multiple times within single BIER information TLV. The format and 246 restriction is the same as the definition in 247 [I-D.ietf-bier-isis-extensions] and 248 [I-D.ietf-bier-ospf-bier-extensions]. 250 The type value of this sub-TLV should be assigned by IANA. The 251 suggestion value is 1. 253 3.4. Optional BIER sub-domain BSL conversion sub-TLV 255 The format and restriction is the same as the definition in 256 [I-D.ietf-bier-isis-extensions] and 257 [I-D.ietf-bier-ospf-bier-extensions]. The type value of this sub-TLV 258 should be assigned by IANA. The suggestion value is 2. 260 4. Security Considerations 262 The security considerations are mainly similar to what is documented 263 in [I-D.ietf-pim-source-discovery-bsr]. 265 5. IANA Considerations 267 This document requires the assignment of a new PFM TLV type for the 268 BIER information Flooding Mechanism. IANA is also requested to 269 create two sub-TLV types for BIER MPLS encapsulation sub-TLV and BIER 270 sub-domain BSL conversion sub-TLV. 272 6. Normative References 274 [I-D.ietf-bier-architecture] 275 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 276 S. Aldrin, "Multicast using Bit Index Explicit 277 Replication", draft-ietf-bier-architecture-08 (work in 278 progress), September 2017. 280 [I-D.ietf-bier-isis-extensions] 281 Ginsberg, L., Przygienda, T., Aldrin, S., and Z. Zhang, 282 "BIER support via ISIS", draft-ietf-bier-isis- 283 extensions-05 (work in progress), July 2017. 285 [I-D.ietf-bier-ospf-bier-extensions] 286 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 287 Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF Extensions 288 for BIER", draft-ietf-bier-ospf-bier-extensions-07 (work 289 in progress), July 2017. 291 [I-D.ietf-pim-source-discovery-bsr] 292 Wijnands, I., Venaas, S., Brig, M., and A. Jonasson, "PIM 293 flooding mechanism and source discovery", draft-ietf-pim- 294 source-discovery-bsr-06 (work in progress), March 2017. 296 [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, 297 "Bootstrap Router (BSR) Mechanism for Protocol Independent 298 Multicast (PIM)", RFC 5059, DOI 10.17487/RFC5059, January 299 2008, . 301 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 302 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 303 Multicast - Sparse Mode (PIM-SM): Protocol Specification 304 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 305 2016, . 307 Authors' Addresses 309 Zheng(Sandy) Zhang 310 ZTE Corporation 311 No. 50 Software Ave, Yuhuatai Distinct 312 Nanjing 313 China 315 Email: zhang.zheng@zte.com.cn 317 BenChong Xu 318 ZTE Corporation 319 No. 68 Zijinghua Road, Yuhuatai Distinct 320 Nanjing 321 China 323 Email: xu.benchong@zte.com.cn