idnits 2.17.1 draft-ietf-pim-jp-extensions-lisp-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (19 April 2022) is 732 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7761' is defined on line 204, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force V. Govindan 3 Internet-Draft S. Venaas 4 Intended status: Experimental Cisco 5 Expires: 21 October 2022 19 April 2022 7 PIM Join/ Prune Attributes for LISP Environments using Underlay 8 Multicast 9 draft-ietf-pim-jp-extensions-lisp-01 11 Abstract 13 This document specifies an extension to PIM Receiver RLOC Join/ Prune 14 attribute that supports the construction of multicast distribution 15 trees where the root and receivers are located in different Locator/ 16 ID Separation Protocol (LISP) sites and are connected using underlay 17 IP Multicast. This attribute allows the receiver site to signal the 18 underlay multicast group to the control plane of the root ITR 19 (Ingress Tunnel Router). 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 21 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. The case for extending the Received ETR RLOC Attribute of RFC 57 8059 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 The construction of multicast distribution trees where the root and 68 receivers are located in different LISP sites [RFC6830] is defined in 69 [RFC6831]. 71 [RFC6831] specifies that (root-EID, G) data packets are to be LISP- 72 encapsulated into (root-RLOC, G) multicast packets. [RFC8059] 73 defines PIM J/P attribute extensions to construct multicast 74 distribution trees. This document extends the Receiver ETR RLOC PIM 75 J/P attribute [RFC8059] to facilitate the construction of underlay 76 multicast trees for (root-RLOC, G). 78 Specifically, the assignment of the underlay multicast group needs to 79 be done in consonance with the downstream xTR nodes and avoid 80 unnecessary replication or traffic hairpinning. 82 Since the Receiver RLOC Attribute defined in [RFC8059] only addresses 83 the Ingress Replication case, an extension of the scope of that PIM 84 J/P attribute is defined by this draft to include scenarios where the 85 underlay uses Multicast transport. The scope extension proposed here 86 complies with the base specification [RFC5384]. 88 This document uses terminology defined in [RFC6830], such as EID, 89 RLOC, ITR, and ETR. 91 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. The case for extending the Received ETR RLOC Attribute of RFC 8059 99 When LISP based Multicast trees can be built using IP Multicast in 100 the underlay, the mapping between the overlay group address and the 101 underlay group address becomes a very crucial engineering decision: 103 Flexible mapping of overlay to underlay group ranges: 104 Three different types of overlay to underlay group mappings are 105 possible: Many to one mapping: Many (root-EID, G) flows originating 106 from a RLOC can be mapped to the same underlay (root-RLOC, G-u) 107 flow. One to many mapping: Conversely the same overlay flow can be 108 mapped to two or more flows e.g. (root-RLOC, G-u1) and (root-RLOC, 109 G-u2) to cater to the requirements of downstream xTR nodes. One to 110 one mapping: Every (root-EID, G) flow is mapped to a different 111 (root-RLOC, G-u) flow. The overlay can use ASM while the underlay 112 can use SSM ranges. 114 Multicast Address Range constraints: 115 It is possible that under certain circumstances, differnt subsets of 116 xTRs subscribing to the same overlay multicast stream would be 117 constrained to use different underlay multicast mapping ranges. 118 This definitely involves a trade-off between replication and the 119 flexibility in assigning address ranges and could be required in 120 certain situations further below. 122 Inter-site PxTR: 123 When multiple LISP sites are connected through a LISP based transit, 124 the site border node interconnects the site-facing interfaces and 125 the external LISP based core. Under such circumstances, there could 126 be different ranges of multicast group addresses used for building 127 the (S-RLOC, G) trees inside the LISP site and the external LISP 128 based core. This is desired for various reasons: 130 Hardware resource restrictions: 131 Platform limitations could force engineering decisions to be made on 132 restricting multicast address ranges in the underlay. 134 Other Use-cases: 135 TBD 137 Editorial Note: Comments from Stig: There should be some text 138 indicating that the group address used should ideally only be used 139 for LISP encapsulation (if ASM), and perhaps that it is preferrable 140 to use an SSM group. Also, that the group obviously must be a group 141 that the underlay supports/allows. I think it is also worth noting 142 that ideally, different ETRs should request the same group. 144 3. Acknowledgements 146 The authors would like to thank Dino Farinacci and Victor Moreno for 147 their valuable comments. 149 4. Contributors 151 Sankaralingam 152 Cisco 153 Email: sankt@cisco.com 155 Amit Kumar 156 Cisco 157 Email: kumaram3@cisco.com 159 5. IANA Considerations 161 No new requests to IANA 163 6. Security Considerations 165 There is perhaps a new attack vector where an attacker can send a 166 bunch of joins with different group addresses. It may interfere with 167 other multicast traffic if those group addresses overlap. Also, it 168 may take up a lot of resources if replication for thousands of groups 169 are requested. However PIM authentication (?) should come to the 170 rescue here. TBD Since explicit tracking would be done, perhaps it 171 is worth enforcing that for each ETR RLOC (the RLOC used as the 172 source of the overlay join), there could be a configurable number of 173 maximum permissible group(s). TBD 175 Ed Note: To be addressed - Comments from Stig: Regarding security 176 considerations and PIM authentication. The only solution we have 177 here is to use IP-Sec to sign the J/P messages. I don't know if 178 anyone has tried to us IPSec between LISP RLOCs. Are there any LISP 179 security mechanisms that would help here for authenticating LISP 180 encapsulated messages between xTRs? 182 7. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, 186 DOI 10.17487/RFC2119, March 1997, 187 . 189 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 190 Independent Multicast (PIM) Join Attribute Format", 191 RFC 5384, DOI 10.17487/RFC5384, November 2008, 192 . 194 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 195 Locator/ID Separation Protocol (LISP)", RFC 6830, 196 DOI 10.17487/RFC6830, January 2013, 197 . 199 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 200 Locator/ID Separation Protocol (LISP) for Multicast 201 Environments", RFC 6831, DOI 10.17487/RFC6831, January 202 2013, . 204 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 205 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 206 Multicast - Sparse Mode (PIM-SM): Protocol Specification 207 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 208 2016, . 210 [RFC8059] Arango, J., Venaas, S., Kouvelas, I., and D. Farinacci, 211 "PIM Join Attributes for Locator/ID Separation Protocol 212 (LISP) Environments", RFC 8059, DOI 10.17487/RFC8059, 213 January 2017, . 215 Authors' Addresses 217 Vengada Prasad Govindan 218 Cisco 219 Email: venggovi@cisco.com 221 Stig Venaas 222 Cisco 223 Email: svenaas@cisco.com