idnits 2.17.1 draft-zzhang-pim-sr-multicast-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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2018) is 2074 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 1584' is mentioned on line 194, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-bier-pim-signaling-03 == Outdated reference: A later version (-03) exists of draft-voyer-spring-sr-p2mp-policy-00 == Outdated reference: A later version (-03) exists of draft-zzhang-bess-bgp-multicast-01 == Outdated reference: A later version (-02) exists of draft-zzhang-bess-bgp-multicast-controller-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Informational IJ. Wijnands 5 Expires: February 16, 2019 Cisco Systems 6 A. Dolganow 7 Nokia 8 L. Geng 9 China Mobile 10 August 15, 2018 12 Multicast in SR Networks 13 draft-zzhang-pim-sr-multicast-00 15 Abstract 17 With Segment Routing (SR) architecture [rfc8402], a unicast flow can 18 be routed through an SR network following an explicit path specified 19 in the packet, w/o the need for per-flow state in the network. As a 20 result, the otherwise needed protocols to signal the per-flow unicast 21 state can also be removed from the network. This document discusses 22 options for multicast in an SR network. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 16, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Traditional Multicast Technologies . . . . . . . . . . . . . 2 60 3. Bit Index Explicit Replication . . . . . . . . . . . . . . . 3 61 4. Multicast Trees Set up by Other Means . . . . . . . . . . . . 4 62 5. SR Specific Solutions . . . . . . . . . . . . . . . . . . . . 4 63 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 9. Informative References . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 With Segment Routing (SR) architecture [RFC8402], a unicast flow can 72 be routed through an SR network following an explicit path specified 73 in the packet, w/o the need for per-flow state in the network. As a 74 result, the otherwise needed protocols to signal the per-flow unicast 75 state can also be removed from the network. 77 This document summarizes options for multicast in an SR network, 78 including traditional multicast technologies, BIER, and various SR 79 specific proposals. The pros and cons of each solution are listed 80 for considerations by operators and vendors. 82 2. Traditional Multicast Technologies 84 Traditional multicast technologies include PIM [RFC7761], RSVP-TE 85 P2MP [RFC4875], and mLDP [RFC6388]. They all require per-tree state 86 on nodes on the tree, and the corresponding protocols to signal and 87 maintain the state. An incoming packet's IP header or MPLS label is 88 looked up, and the packet is forwarded according to the matched 89 state. 91 While SR allows simplification of state, protocols and centralized 92 SDN-control, the traditional methods of delivering multicast traffic 93 run contrary to those SR goals. 95 An alternative is Ingress Replication (IR) - an upstream node of a 96 multicast packet tunnels individual copies to some downstream nodes 97 across some intermediate nodes. In an SR network, the unicast 98 tunnels used for IR could be traditional IP/MPLS tunnels or could be 99 SR tunnels. 101 While with IR there is no per-tree state on those intermediate nodes, 102 multiple copies of the same packet may be sent over the same link. 103 If efficient replication is required, PIM/mLDP/RSVP-TE P2MP can still 104 be used for multicast even in an SR network. Deploying SR in the 105 network does not mandate changing the solution that is in place for 106 Multicast. 108 While mLDP uses the same LDP Session (and packet encoding) as is used 109 by unicast and there is code sharing between LDP and mLDP with 110 regards to neighbor discovery, session setup and Label allocation 111 management, the protocol logic for setting up mLDP tunnel is 112 completely different. It is understood that there is a desire to 113 remove LDP from the network when SR is deployed, but there is really 114 no problem to continue to run mLDP for Multicast. RFC7473 documents 115 a solution where LDP can be run in mLDP-Only mode by simply not 116 exchanging any Unicast bindings. 118 Similarly, RSVP-TE P2MP tunnel setup is orthogonal from P2P tunnel 119 setup as well. It can be used for multicast even in an SR network if 120 bandwidth reservation and/or per-tunnel explicit path are required. 122 3. Bit Index Explicit Replication 124 Bit Index Explicit Replication (BIER) [RFC8279] is a new multicast 125 technology that achieves efficient replication as with PIM tree or 126 mLDP/RSVP-TE P2MP tunnels but without requiring per-tree/tunnel state 127 in the transit nodes as with IR. 129 BIER is a perfect fit for an SR network. A BIER domain can be used 130 as provider/underlay tunnels for MVPN/EVPN-BUM (just as traditional 131 PIM tree or mLDP/RSVP P2MP tunnels), or can be part of end-to-end PIM 132 trees [I-D.ietf-bier-pim-signaling] (similiar to mLDP inband 133 signaling [RFC6826]). 135 However, BIER uses a new forwarding plane that cannot be implemented 136 on many deployed routers. On the other hand, the entry point barrier 137 is decreasing and BIER is becoming more realistic with the following 138 developments: 140 o Several major router vendors have wide deployment of platforms 141 capable of BIER (with a software upgrade) 143 o Several ASIC vendors have BIER support on their latest/upcoming 144 ASIC offering 146 o There have been very good discussions in BIER WG for methods of 147 brown field deployments ( [I-D.przygienda-bier-migration-options] 148 [I-D.zzhang-bier-php]) 150 o More and more customers now have concrete plans and requirements 151 for BIER deployment in their networks 153 4. Multicast Trees Set up by Other Means 155 Some operators may accept that they need to maintain per-tree state 156 in their SR network for efficient multicast, and their applications 157 do not require too much per-tree multicast state. However, since 158 unicast no longer needs LDP or RSVP-TE protocol in an SR network, 159 they really want to remove PIM/LDP/RSVP-TE protocol from their 160 networks, and make use of controllers. In that case, the multicast 161 trees could be set up statically from management plane (e.g., 162 netconf), or dynamically via BGP [I-D.zzhang-bess-bgp-multicast]. 163 [I-D.zzhang-bess-bgp-multicast-controller]. 165 5. SR Specific Solutions 167 There are two multicast solutions that are specifically tied to SR 168 technologies - "TreeSID" and "Spray" 169 [I-D.voyer-spring-sr-p2mp-policy]. There is also a proposal 170 [I-D.allan-pim-sr-mpls-multicast-framework] that uses calculated 171 multicast trees based on flooded membership information. 173 1. TreeSID essentially refers to P2MP tunnels setup not by mLDP or 174 RSVP-TE. It could be statically configured, or instantiated from 175 a controller. 177 2. Spray is Ingress Replication. In particular, in case of SRv6, 178 instead of regular IP/MPLS tunneling, an SRv6 header encodes the 179 "tunnel end" and the original destination multicast address. 180 When the packet arrives at the tunnel end, the original multicast 181 address is restored from the SRv6 header. 183 3. In [I-D.allan-pim-sr-mpls-multicast-framework], multicast 184 membership information is flooded, and each node will calculate 185 if it plays a role (as a root, leaf, or a branching point) for 186 each multicast tree. If yes, corresponding forwarding state is 187 installed to forward incoming multicast traffic accordingly. 189 The above three methods are really no different from existing 190 technologies. 1 and 3 do not use existing tree signaling protocol but 191 still require per-tree forwarding state on roots, leaves and 192 branching points (for comparison, existing technologies does have 193 per-tree state on all nodes on a tree - including those non-branching 194 points). 3 is similar to MOSPF [RFC 1584] and requires flooded 195 receiver information throughout the domain. 2 is just IR with a 196 different encapsulation (e.g. SRv6). 198 6. Summary 200 There is no one-for-all option when it comes to multicast in an SR 201 network. Depending on specific deployment scenarios and 202 requirements, the following could be considered in order: 204 o If most of nodes can support it, BIER is the best choice, because 205 it removes state from the network and simplifies the control-plane 206 (like SR). 208 o If efficient multicast replication is required, then run mLDP/ 209 RSVP-TE/PIM for multicast purpose if that is acceptable. 211 o If there is a strong desire to create multicast forwarding state 212 without relying on mLDP and/or RSVP-TE, one can use static 213 configuration or controller signaling (e.g. SR specific TreeSID, 214 generic BGP based signaling or netconf based provisioning). 216 o Use Ingress Replication with SR unicast tunnels. This includes 217 Spray Multicast if SRv6 is desired. 219 In case of MPLS based P2MP, a Binding SID could be optionally used to 220 direct traffic to the root of the tunnel. 222 Notice that there are already many protocols defined (PIM, mLDP, 223 RSVP-TE, BGP, MOSPF) that can be used to create multicast forwarding 224 state. When designing a new protocol to do the same, we need to be 225 sure the benefits are significant enough and out-weight the cost of 226 developing it. 228 7. Security Considerations 230 This document does not seem to introduce new security risks. 232 8. Acknowledgements 234 The authors thank Eric Rosen, Tony Przygienda, and John Drake for 235 their reviews, comments and suggestions. 237 9. Informative References 239 [I-D.allan-pim-sr-mpls-multicast-framework] 240 Allan, D., Tantsura, J., and I. Duncan, "A Framework for 241 Computed Multicast Applied to SR-MPLS", draft-allan-pim- 242 sr-mpls-multicast-framework-00 (work in progress), June 243 2018. 245 [I-D.ietf-bier-pim-signaling] 246 Bidgoli, H., Dolganow, A., Kotalwar, J., Xu, F., mishra, 247 m., and Z. Zhang, "PIM Signaling Through BIER Core", 248 draft-ietf-bier-pim-signaling-03 (work in progress), June 249 2018. 251 [I-D.przygienda-bier-migration-options] 252 Przygienda, T. and Z. Zhang, "BIER Migration Frameworks", 253 draft-przygienda-bier-migration-options-00 (work in 254 progress), June 2018. 256 [I-D.voyer-spring-sr-p2mp-policy] 257 daniel.voyer@bell.ca, d., Hassen, C., Gillis, K., 258 Filsfils, C., and A. Venkateswaran, "SR Replication Policy 259 for P2MP Service Delivery", draft-voyer-spring-sr-p2mp- 260 policy-00 (work in progress), June 2018. 262 [I-D.zzhang-bess-bgp-multicast] 263 Zhang, Z., Patel, K., Wijnands, I., and a. 264 arkadiy.gulko@thomsonreuters.com, "BGP Based Multicast", 265 draft-zzhang-bess-bgp-multicast-01 (work in progress), 266 March 2017. 268 [I-D.zzhang-bess-bgp-multicast-controller] 269 Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko, 270 "Controller Based BGP Multicast Signaling", draft-zzhang- 271 bess-bgp-multicast-controller-00 (work in progress), 272 September 2017. 274 [I-D.zzhang-bier-php] 275 Zhang, Z., "BIER Penultimate Hop Popping", draft-zzhang- 276 bier-php-01 (work in progress), August 2018. 278 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 279 Yasukawa, Ed., "Extensions to Resource Reservation 280 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 281 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 282 DOI 10.17487/RFC4875, May 2007, 283 . 285 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 286 Thomas, "Label Distribution Protocol Extensions for Point- 287 to-Multipoint and Multipoint-to-Multipoint Label Switched 288 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 289 . 291 [RFC6826] Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. 292 Napierala, "Multipoint LDP In-Band Signaling for Point-to- 293 Multipoint and Multipoint-to-Multipoint Label Switched 294 Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013, 295 . 297 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 298 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 299 Multicast - Sparse Mode (PIM-SM): Protocol Specification 300 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 301 2016, . 303 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 304 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 305 Explicit Replication (BIER)", RFC 8279, 306 DOI 10.17487/RFC8279, November 2017, 307 . 309 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 310 Decraene, B., Litkowski, S., and R. Shakir, "Segment 311 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 312 July 2018, . 314 Authors' Addresses 316 Zhaohui Zhang 317 Juniper Networks 319 EMail: zzhang@juniper.net 321 IJsbrand Wijnands 322 Cisco Systems 324 EMail: ice@cisco.com 326 Andrew Dolganow 327 Nokia 329 EMail: andrew.dolganow@nokia.com 330 Liang Geng 331 China Mobile 333 EMail: gengliang@chinamobile.com