idnits 2.17.1 draft-zzhang-mpls-rmr-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 2, 2018) is 2096 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 182, but not defined == Missing Reference: 'RFC7716' is mentioned on line 218, but not defined == Missing Reference: 'RFC7060' is mentioned on line 191, but not defined == Missing Reference: 'RFC6826' is mentioned on line 211, but not defined == Missing Reference: 'RFC7246' is mentioned on line 211, but not defined == Missing Reference: 'RFC7438' is mentioned on line 211, 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 268, but no explicit reference was found in the text == Unused Reference: 'RFC6388' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC7761' 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-03 Summary: 1 error (**), 0 flaws (~~), 15 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: January 3, 2019 Juniper Networks, Inc. 6 July 2, 2018 8 Resilient MPLS Rings and Multicast 9 draft-zzhang-mpls-rmr-multicast-00 11 Abstract 13 This document discusses multicast with resilient mpls rings. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC2119. 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 http://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 January 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. P2MP/MP2MP Tunnels on a Ring . . . . . . . . . . . . . . . . . 3 57 2.1. Tunnel Protoction and FRR . . . . . . . . . . . . . . . . . 4 58 3. End to End Tunnels with Rings . . . . . . . . . . . . . . . . . 5 59 4. End to End Multicast with Rings . . . . . . . . . . . . . . . . 5 60 4.1. End-to-end Native (x,g) Signaling/Forwarding in the 61 Global Table . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. mLDP Inband Signaling in the Global Table or VRFs . . . . . 6 63 4.3. MVPN/GTM/EVPN/VPLS . . . . . . . . . . . . . . . . . . . . 6 64 4.3.1. MVPN/GTM/EVPN/VPLS Tunnel Segmentation . . . . . . . . 6 65 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 [I-D.ietf-mpls-rmr] describes ... 76 This document discusses how multicast works with RMRs. 78 All existing multicast procedures and solutions can work as is. This 79 include both mpls multicast tunnels and end-to-end multicast that 80 makes use of multicast tunnels. Ring topology is just a special case 81 of general topologies so all existing RSVP-TE P2MP and mLDP tunnel 82 can be set up the same way. An Ingress Replication (IR) tunnel 83 consists a bunch of p2p LSPs, and it does not matter whether a 84 component LSP is a plain old LSP or a Ring LSP. 86 On the other hand, there are optimizations that could be done for 87 RSVP-TE P2MP tunnel signaling (and perhaps FRR for both mLDP and 88 RSVP-TE P2MP tunnels). This document describes that in high level 89 (detailed protocol procedure will be specified in a separate draft), 90 and also discusses end to end multicast when there are RMRs (even 91 though the two are independent). 93 2. P2MP/MP2MP Tunnels on a Ring 95 Because mLDP label mapping messages are merged as they propagate from 96 the leaves towards the root, ring topology does not lead to any 97 further optimization. 99 For a conventionally signaled RSVP-TE P2MP tunnel, the ingress 100 discovers the leaves and signals one sub-LSP for each leaf. Even 101 though the forwarding state is merged at each hop (i.e, one incoming 102 label mapping to multiple outgoing entries), the control plane 103 maintains individual sub-LSP state. This leads to lots of redundant 104 state on routers close to the ingress. With RMR, this can be 105 optimized such that only a single LSP is signaled, with all the 106 leaves listed in the PATH message. As the PATH message passes along 107 the ring, the leaves send RESV messages, but only one RESV message 108 reaches the tunnel ingress in each direction. 110 The ingress may send PATH messages in both directions, so that the 111 tunnel is set up in such a way that minimum delay is incurred for 112 traffic to reach all leaves. Alternatively, the ingress may send 113 PATH message only in one direction for best bandwidth utilization. 114 For example, a leaf D is three hops away from the ingress A in 115 clockwise direction (A,B,C,D) and four hops away in the other 116 direction (A,E,F,G,D), but G is also a leaf so it may be better to 117 just send the PATH message in the anticlockwise direction. 119 Each router establishes forwarding state accordingly. Transit 120 routers switches traffic towards downstream. A transit router could 121 also be a leaf router and in that case it does "drop and continue" - 122 sends traffic off the ring and swtiches traffic downstream. 124 MP2MP RSVP-TE tunnel can also be easily achieved. The PATH message 125 could carry a label for the dowstream router to send traffic to its 126 upstream. Then the ingress and each leaf can use the same tunnel to 127 send traffic to each other. 129 The PATH message does not need to list all leaves. As long as a leaf 130 somehow determines that it is a leaf, it can send RESV message when 131 it receives the PATH message. This makes it a leaf-initiated, which 132 may have advantages in certain situations. 134 2.1. Tunnel Protoction and FRR 136 Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to 137 itself. As these LSPs are self-signaled after the discovery of the 138 ring, they can be used to protect P2MP LSPs on ring. So neither mLDP 139 nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node 140 protection. For instance, consider a ring with 8 nodes. 142 Root 143 R0 . . . R1 144 . . 146 R7 R2 Leaf 147 | . . | 148 Anti- | . RID =17 . | 149 Clockwise v . . v Clockwise 150 Leaf R6 R3 151 . . 152 R5 . . . R4 Leaf 154 Figure 1: Ring with 8 nodes 156 Further, suppose a P2MP LSP is signaled with R0 as a root and R2, R4 157 and R6 as leafs. The P2MP LSP is formed as follows: 159 R0 160 . . 161 . . 162 . . 163 R6 R2 164 . 165 . 166 R4 168 Figure 2: P2MP LSP 170 In the event of a link failure between R2 and R3, R2, the PLR, 171 tunnels P2MP LSP traffic on a anti-clockwise ring LSP to R3. Once 172 the traffic is out of a tunnel on R3, it uses the regular P2MP LSP to 173 reach R4. Similarly in the event of a node failure R3, R2, the PLR, 174 tunnels P2MP LSP traffic to R4, the MP, which is also the leaf. 175 Thus, the P2MP LSP uses the existing RSVP-TE ring lsps for link and 176 node protection. 178 3. End to End Tunnels with Rings 180 Consider a provider network that consists of one or more rings, 181 optionally with a general topology connecting the rings. MVPN 182 [RFC6514], EVPN [RFC7432], or GTM [RFC7716] services are provided 183 where end-to-end multipoint tunnels are needed across the entire 184 network. 186 If the end to end tunnels are RSVP-TE P2MP tunnels, there is not much 187 optimization that can be done for RMR, unless overlay-assisted tunnel 188 segmentation is used. That is described in Section 4.3.1. 190 If the end to end tunnels are mLDP tunnels and RSVP-TE signaling is 191 desired on part of the network, mLDP Over Targeted Sessions [RFC7060] 192 can be used without the help from the overlay, and that works even 193 for genereral topologies. If RSVP-TE signaling is used on the rings, 194 then the optimization for settting up the P2MP tunnel on the ring as 195 described earlier can be used. 197 4. End to End Multicast with Rings 199 Consider a network that consists of one or more rings, optionally 200 with a general topology connecting the rings. In this network, end- 201 to-end multicast can take various forms described below. 203 4.1. End-to-end Native (x,g) Signaling/Forwarding in the Global Table 205 This is typically signaled by PIM end to end. Optionally IGMP/MLD 206 proxy could be used. This works for any topology and RMR does not 207 make any difference. 209 4.2. mLDP Inband Signaling in the Global Table or VRFs 211 This is specified in [RFC6826,RFC7246,RFC7438]. An mLDP tunnel is 212 created for each (x,g) multicast tree. RMR does not make any 213 differences here. 215 4.3. MVPN/GTM/EVPN/VPLS 217 GTM here sepcifically refers to using BGP-MVPN procedures for 218 multicast in the global table, as specified in [RFC7716]. The 219 difference from the earlier described global table multicast is that 220 the global table is treated as a VRF for signaling purpose. MVPN/ 221 GTM/EVPN/VPLS uses overlay multicast signaling to signal customer 222 multicast state and tunnel binding. PE-PE multipoint underlay 223 tunnels are used to distribute multicast packets among PEs. Any kind 224 of tunnel can be used, whether the provider network has rings or not, 225 with or without the RMR related optimizations. 227 4.3.1. MVPN/GTM/EVPN/VPLS 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 To be added. 258 7. Acknowledgements 260 8. References 262 8.1. Normative References 264 [I-D.ietf-mpls-rmr] Kompella, K. and L. Contreras, "Resilient MPLS 265 Rings", draft-ietf-mpls-rmr-03 (work in 266 progress), October 2016. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to 269 Indicate Requirement Levels", BCP 14, RFC 2119, 270 March 1997. 272 8.2. Informative References 274 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, 275 K., and B. Thomas, "Label Distribution Protocol 276 Extensions for Point-to-Multipoint and 277 Multipoint-to-Multipoint Label Switched Paths", 278 RFC 6388, DOI 10.17487/RFC6388, November 2011, 279 . 281 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, 282 I., Parekh, R., Zhang, Z., and L. Zheng, 283 "Protocol Independent Multicast - Sparse Mode 284 (PIM-SM): Protocol Specification (Revised)", 285 STD 83, RFC 7761, DOI 10.17487/RFC7761, 286 March 2016, 287 . 289 Authors' Addresses 291 Zhaohui Zhang 292 Juniper Networks 294 EMail: zzhang@juniper.net 296 Santosh Esale 297 Juniper Networks, Inc. 299 EMail: sesale@juniper.net