idnits 2.17.1 draft-zzhang-mpls-rmr-multicast-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.zzhang-teas-rmr-rsvp-p2mp]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2019) is 1929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6514' is mentioned on line 232, but not defined == Missing Reference: 'RFC7432' is mentioned on line 184, but not defined == Missing Reference: 'RFC7716' is mentioned on line 185, but not defined == Missing Reference: 'RFC6826' is mentioned on line 213, but not defined == Missing Reference: 'RFC7246' is mentioned on line 213, but not defined == Missing Reference: 'RFC7438' is mentioned on line 213, but not defined == Missing Reference: 'RFC7024' is mentioned on line 232, but not defined == Missing Reference: 'I-D.ietf-bess-evpn-bum-procedure-updates' is mentioned on line 232, but not defined == Unused Reference: 'RFC2119' is defined on line 281, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-mpls-rmr-09 == Outdated reference: A later version (-02) exists of draft-zzhang-teas-rmr-rsvp-p2mp-00 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Z. Zhang 3 Internet-Draft Juniper Networks 4 Intended status: Informational S. Esale 5 Expires: July 18, 2019 Juniper Networks, Inc. 6 January 14, 2019 8 Resilient MPLS Rings and Multicast 9 draft-zzhang-mpls-rmr-multicast-01 11 Abstract 13 With Resilient MPLS Rings (RMR), although all existing multicast 14 procedures and solutions can work as is, there are optimizations that 15 could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting 16 for both mLDP and RSVP-TE P2MP tunnels. This document describes that 17 in high level (detailed protocol procedure is specified in 18 [I-D.zzhang-teas-rmr-rsvp-p2mp]), and also discusses end to end 19 multicast when there are RMRs. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 18, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. P2MP/MP2MP Tunnels on a Ring . . . . . . . . . . . . . . . . 3 57 2.1. Tunnel Protection and FRR . . . . . . . . . . . . . . . . 3 58 3. End to End Tunnels with Rings . . . . . . . . . . . . . . . . 4 59 4. End to End Native Multicast with Rings . . . . . . . . . . . 5 60 4.1. Native Multicast in the Global Routing Table . . . . . . 5 61 4.2. mLDP Inband Signaling . . . . . . . . . . . . . . . . . . 5 62 4.3. Overlay Multicast Services . . . . . . . . . . . . . . . 5 63 4.3.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . 5 64 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 This document discusses how multicast works with Resilient MPLS Rings 76 [I-D.ietf-mpls-rmr]. It is expected that readers are familiar with 77 the concept and terms in [I-D.ietf-mpls-rmr]. 79 All existing multicast procedures and solutions can work as is. This 80 include both mpls multicast tunnels and end-to-end multicast that 81 makes use of multicast tunnels. Ring topology is just a special case 82 of general topologies so all existing RSVP-TE P2MP [RFC4875] and mLDP 83 [RFC6388] tunnels can be set up using existing protocols and 84 procedures. An Ingress Replication (IR) tunnel [RFC7988] consists a 85 bunch of P2P LSPs, and it does not matter whether a component LSP is 86 a plain old LSP or a Ring LSP. 88 On the other hand, there are optimizations that could be done for 89 RSVP-TE P2MP tunnel signaling and Fast-ReRouting (FRR) for both mLDP 90 and RSVP-TE P2MP tunnels. This document describes that on a high 91 level (detailed protocol procedure will be specified in a separate 92 draft), and also discusses end to end multicast when there are RMRs 93 even though RMR could be transparent to multicast. 95 2. P2MP/MP2MP Tunnels on a Ring 97 Because mLDP label mapping messages are merged as they propagate from 98 the leaves towards the root, ring topology does not lead to any 99 further optimization. 101 For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR 102 discovers leaves and signals one sub-LSP for each leaf. Even though 103 the forwarding state is merged at each hop (i.e, one incoming label 104 mapping to multiple outgoing entries), the control plane maintains 105 individual sub-LSP state. This leads to lots of redundant state on 106 routers close to the ingress. With RMR, this can be optimized such 107 that only a single LSP is signaled, with all the leaves listed in the 108 PATH message. As the PATH message passes along the ring, the leaves 109 send RESV messages, but only one RESV message reaches the tunnel 110 ingress. 112 The ingress LSR may also send PATH messages in both directions, so 113 that the tunnel is set up in such a way that minimum delay is 114 incurred for traffic to reach all leaves. Alternatively, the ingress 115 may send PATH message only in one direction for best bandwidth 116 utilization. For example, a leaf D is three hops away from the 117 ingress A in clockwise direction (A,B,C,D) and four hops away in the 118 other direction (A,E,F,G,D), but G is also a leaf so it may be better 119 to just send the PATH message in the anticlockwise direction. 121 Each router establishes forwarding state accordingly. Transit 122 routers switches traffic towards downstream. A transit router could 123 also be a leaf router and in that case it does "drop and continue" - 124 sends traffic off the ring and switches traffic downstream. 126 MP2MP RSVP-TE tunnel can also be easily achieved. The PATH message 127 could carry a label for the downstream router to send traffic to its 128 upstream. Then the ingress and each leaf can use the same tunnel to 129 send traffic to each other. 131 The PATH message does not need to list all leaves. As long as a leaf 132 somehow determines that it is a leaf, it can send RESV message when 133 it receives the PATH message. This makes it leaf-initiated like mLDP 134 P2MP tunnels, which may have advantages in certain situations. 136 2.1. Tunnel Protection and FRR 138 Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to 139 itself. As these LSPs are self-signaled after the discovery of the 140 ring, they can be used to protect P2MP LSPs on ring. So neither mLDP 141 nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node 142 protection. For instance, consider a ring with 8 nodes. 144 Root 145 R0 . . . R1 146 . . 148 R7 R2 Leaf 149 | . . | 150 Anti- | . RingID=17 . | 151 Clockwise v . . v Clockwise 152 Leaf R6 R3 153 . . 154 R5 . . . R4 Leaf 156 Figure 1: Ring with 8 nodes 158 Further, suppose a P2MP LSP is signaled with R0 as a root and R2, R4 159 and R6 as leafs. The P2MP LSP is formed as follows: 161 R0 162 . . 163 . . 164 . . 165 R6 R2 166 . 167 . 168 R4 170 Figure 2: P2MP LSP 172 In the event of a link failure between R2 and R3, R2 the Point of 173 Local Repair (PLR) tunnels P2MP LSP traffic on a anti-clockwise ring 174 LSP to R3 the Merge Point (MP). Once the traffic is out of the ring 175 LSP on R3, it uses the regular P2MP LSP to reach R4. Similarly in 176 the event of a node failure R3, R2 the PLR tunnels P2MP LSP traffic 177 to R4 (the MP), which is also the leaf. Thus, the P2MP LSP uses the 178 existing RSVP-TE ring LSPs for link and node protection. 180 3. End to End Tunnels with Rings 182 Consider a provider network that consists of one or more rings, 183 optionally with a general topology connecting the rings. Multicast 184 VPN [RFC6514], Ethernet VPN [RFC7432], VPLS [RFC4761] [RFC4762], or 185 Global Table Multicast (GTM) via MVPN [RFC7716] overlay services are 186 provided where end-to-end multipoint tunnels are needed across the 187 entire network. 189 If the end to end tunnels are established by RSVP-TE P2MP, there is 190 not much optimization that can be done for RMR, unless overlay- 191 assisted tunnel segmentation is used. That is described in 192 Section 4.3.1. 194 If the end to end tunnels are established by mLDP and RSVP-TE 195 signaling is desired on part of the network, mLDP Over Targeted 196 Sessions [RFC7060] can be used (without the help from the overlay 197 service) to stack part of an mLDP tunnel over a RSVP-TE P2MP tunnel. 198 If the RSVP-TE P2MP tunnel is over a ring, then the optimization 199 described earlier can be used. 201 4. End to End Native Multicast with Rings 203 Consider a network that consists of some rings. In this network, 204 end-to-end native multicast can take various forms described below. 206 4.1. Native Multicast in the Global Routing Table 208 This is typically signaled by PIM [RFC7761] end to end. This works 209 for any topology and RMR does not make any difference. 211 4.2. mLDP Inband Signaling 213 This is specified in [RFC6826] [RFC7246] [RFC7438]. When part of a 214 native (s,g) or (*,g) multicast tree needs to go over an mLDP domain, 215 an mLDP tunnel is created for each multicast tree for the domain. 216 RMR does not make any differences here. 218 4.3. Overlay Multicast Services 220 Overlay multicast services provided by MVPN/GTM/EVPN/VPLS use overlay 221 multicast signaling to signal customer multicast state and tunnel 222 binding. PE-PE multipoint underlay tunnels are used to distribute 223 multicast packets among PEs. Any kind of tunnel can be used, whether 224 the provider network has rings or not, with or without the RMR 225 related optimizations (Section 3). 227 4.3.1. Tunnel Segmentation 229 The MVPN/GTM/EVPN/VPLS PEs could span across ASes or areas. When the 230 PE-PE multipoint tunnels cannot be signaled across AS/area 231 boundaries, segmentation procedures can be used, as specified in 232 [RFC6514, RFC7024] and [I-D.ietf-bess-evpn-bum-procedure-updates]. 233 With the base MVPN/GTM/EVPN/VPLS procedures, PEs advertise I/S-PMSI 234 A-D routes to signal traffic to tunnel binding, and the routes carry 235 type and identification of multi-point tunnels used to carry 236 corresponding traffic. With segmentation, the ASBRs/ABRs become 237 segmentation points and they change the tunnel type/identification 238 when they re-advertise the routes to the next AS/area. With this, 239 each AS/area has its own tunnel of different type/identification, 240 stitched together by the ASBRs/ABRs. 242 With segmentation, different RMRs could have their own tunnels, and 243 RSVP-TE P2MP optimizations for RMRs could be applied. Notice that 244 this is different from Section 3 in that overlay signaling is 245 involved. 247 5. Summary 249 As described above, multicast in the presence of RMRs can work as is. 250 RSVP-TE P2MP tunnel signaling can be optimized (to be specified 251 separately). Tunnel protection/FRR can also be optimized for mLDP/ 252 RSVP-TE P2MP tunnels. 254 6. Security Considerations 256 This is an informational document that describes how existing 257 multicast protocols can be used with RMR, as well as possible RMR 258 specific enhancements that will be specified separately. There are 259 no security concerns to be discussed here, as they are already 260 discussed in existing protocols or will be discussed in the 261 specification for the enhancements. 263 7. IANA Considerations 265 This document does not request any allocations from IANA. The RFC 266 Editor is requested to remove this section before publication. 268 8. Acknowledgements 270 The authors sincerely thank Loa Anderson for his careful review, 271 comments and suggestions. 273 9. References 275 9.1. Normative References 277 [I-D.ietf-mpls-rmr] 278 Kompella, K. and L. Contreras, "Resilient MPLS Rings", 279 draft-ietf-mpls-rmr-09 (work in progress), January 2019. 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 9.2. Informative References 288 [I-D.zzhang-teas-rmr-rsvp-p2mp] 289 Zhang, Z., Deshmukh, A., and R. Singh, "RSVP-TE P2MP 290 Tunnels on RMR", draft-zzhang-teas-rmr-rsvp-p2mp-00 (work 291 in progress), July 2018. 293 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 294 LAN Service (VPLS) Using BGP for Auto-Discovery and 295 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 296 . 298 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 299 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 300 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 301 . 303 [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. 304 Yasukawa, Ed., "Extensions to Resource Reservation 305 Protocol - Traffic Engineering (RSVP-TE) for Point-to- 306 Multipoint TE Label Switched Paths (LSPs)", RFC 4875, 307 DOI 10.17487/RFC4875, May 2007, 308 . 310 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 311 Thomas, "Label Distribution Protocol Extensions for Point- 312 to-Multipoint and Multipoint-to-Multipoint Label Switched 313 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 314 . 316 [RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP 317 Multipoint Extensions on Targeted LDP Sessions", RFC 7060, 318 DOI 10.17487/RFC7060, November 2013, 319 . 321 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 322 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 323 Multicast - Sparse Mode (PIM-SM): Protocol Specification 324 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 325 2016, . 327 [RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress 328 Replication Tunnels in Multicast VPN", RFC 7988, 329 DOI 10.17487/RFC7988, October 2016, 330 . 332 Authors' Addresses 334 Zhaohui Zhang 335 Juniper Networks 337 EMail: zzhang@juniper.net 339 Santosh Esale 340 Juniper Networks, Inc. 342 EMail: sesale@juniper.net