idnits 2.17.1 draft-vgovindan-pim-jp-extensions-lisp-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 : ---------------------------------------------------------------------------- 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 date (21 February 2021) is 1153 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Cisco 4 Intended status: Experimental 21 February 2021 5 Expires: 25 August 2021 7 PIM Join/ Prune Attributes for LISP Environments using Underlay 8 Multicast 9 draft-vgovindan-pim-jp-extensions-lisp-00 11 Abstract 13 This document specifies an extension to PIM Join/ Prune messages. 14 This document defines one PIM Join/ Prune attribute that support the 15 construction of multicast distribution trees where the root and 16 receivers are located in different Locator/ID Separation Protocol 17 (LISP) sites using underlay IP Multicast. This attribute allows the 18 receiver site to signal the underlay multicast group to the control 19 plane of the root ITR (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 25 August 2021. 38 Copyright Notice 40 Copyright (c) 2021 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 Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. The case for requiring a new PIM Join/ Prune Extension . . . 3 57 3. Receiver ETR Group Address Attribute . . . . . . . . . . . . 3 58 3.1. Receiver Group Address Attribute Format . . . . . . . . . 3 59 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The construction of multicast distribution trees where the root and 69 receivers are located in different LISP sites [RFC6830] is defined in 70 [RFC6831]. 72 [RFC6831] specifies that (root-EID,G) data packets are to be LISP- 73 encapsulated into (root-RLOC,G) multicast packets. This document 74 defines a TLV that facilitates the construction of trees for (root- 75 RLOC, G). 77 Specifically, the assignment of the underlay multicast group needs to 78 be done in consonance with the downstream xTR nodes and avoid 79 unnecessary replication or traffic hairpinning. 81 Since the Receiver RLOC Attribute TLV defined in [RFC8059] only 82 addresses the Ingress Replication case, an additional TLV is defined 83 by this draft to include scenarios where the underlay uses Multicast 84 transport. The TLV definition proposed here complies with the base 85 specification [RFC5384]. 87 This document uses terminology defined in [RFC6830], such as EID, 88 RLOC, ITR, and ETR. 90 1.1. Requirements Language 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 2. The case for requiring a new PIM Join/ Prune Extension 98 When LISP based Multicast trees are built using IP Multicast in the 99 underlay, the mapping between the overlay group address and the 100 underlay group address becomes a very crucial. It is possible that 101 under certain circumstances, differnt subsets of xTRs subscribing to 102 the same overlay multicast stream would be constrained to use 103 different underlay multicast mapping ranges. This definitely 104 involves a trade-off between replication and the flexibility in 105 assigning address ranges and could be required in certain situations 106 as below: 108 Inter-site PxTR: 109 When multiple LISP sites are connected through a LISP based transit, 110 the site border node interconnects the site-facing interfaces and 111 the external LISP based core. Under such circumstances, there could 112 be different ranges of multicast group addresses used for building 113 the (S-RLOC, G) trees inside the LISP site and the external LISP 114 based core. This is desired for various reasons: 116 Other Use-cases: 117 TBD 119 Editorial Note: Comments from Stig: There should be some text 120 indicating that the group address used should ideally only be used 121 for LISP encapsulation (if ASM), and perhaps that it is preferrable 122 to use an SSM group. Also, that the group obviously must be a group 123 that the underlay supports/allows. I think it is also worth noting 124 that ideally, different ETRs should request the same group. 126 3. Receiver ETR Group Address Attribute 128 3.1. Receiver Group Address Attribute Format 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |F|E|Type=TBD | Length | Addr Family | Receiver Group 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 136 Figure 1 138 F-bit: 139 The Transitive bit. Specifies whether this attribute is 140 transitive or non-transitive. MUST be set to zero. This 141 attribute is ALWAYS non-transitive. 143 E-bit: 144 End-of-Attributes bit. Specifies whether this attribute is 145 the last. Set to zero if there are more attributes. Set to 146 1 if this is the last attribute. 148 Type: 149 The Receiver Group Attribute type is TBD. 151 Length: 152 The length in octets of the attribute value. MUST be set to 153 the length in octets of the receiver group address plus one 154 octet to account for the Address Family field. 156 Addr Family: 157 The PIM Address Family of the receiver group as defined in 158 [RFC7761]. 160 Receiver Group: 161 The Multicast Group address on which the receiver ETR wishes 162 to receive the IP multicast encapsulated flow. 164 4. Acknowledgements 166 The authors would like to thank Stig Venaas for his valuable 167 comments. 169 5. Contributors 171 Sankaralingam 172 Cisco 174 Email: sankt@cisco.com 176 Amit Kumar 177 Cisco 179 Email: kumaram3@cisco.com 181 6. IANA Considerations 183 This memo includes the following request to IANA: One new PIM Join/ 184 Prune attribute types have been requested: value TBD for the Receiver 185 Group Attribute. 187 7. Security Considerations 189 There is perhaps a new attack vector where an attacker can send a 190 bunch of joins with different group addresses. It may interfere with 191 other multicast traffic if those group addresses overlap. Also, it 192 may take up a lot of resources if replication for thousands of groups 193 are requested. However PIM authentication (?) should come to the 194 rescue here. TBD Since explicit tracking would be done, perhaps it 195 is worth enforcing that for each ETR RLOC (the RLOC used as the 196 source of the overlay join), there should be only one group, whatever 197 is in the last join would override what was there earlier? Or is it 198 to strict to only allow a single group? Might there be reasons to 199 maybe split different LISP payload into different groups in some 200 cases. TBD. 202 Ed Note: To be addressed - Comments from Stig: Regarding security 203 considerations and PIM authentication. The only solution we have 204 here is to use IP-Sec to sign the J/P messages. I don't know if 205 anyone has tried to us IPSec between LISP RLOCs. Are there any LISP 206 security mechanisms that would help here for authenticating LISP 207 encapsulated messages between xTRs? 209 8. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, 213 DOI 10.17487/RFC2119, March 1997, 214 . 216 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 217 Independent Multicast (PIM) Join Attribute Format", 218 RFC 5384, DOI 10.17487/RFC5384, November 2008, 219 . 221 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 222 Locator/ID Separation Protocol (LISP)", RFC 6830, 223 DOI 10.17487/RFC6830, January 2013, 224 . 226 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 227 Locator/ID Separation Protocol (LISP) for Multicast 228 Environments", RFC 6831, DOI 10.17487/RFC6831, January 229 2013, . 231 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 232 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 233 Multicast - Sparse Mode (PIM-SM): Protocol Specification 234 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 235 2016, . 237 [RFC8059] Arango, J., Venaas, S., Kouvelas, I., and D. Farinacci, 238 "PIM Join Attributes for Locator/ID Separation Protocol 239 (LISP) Environments", RFC 8059, DOI 10.17487/RFC8059, 240 January 2017, . 242 Author's Address 244 Vengada Prasad Govindan 245 Cisco 247 Email: venggovi@cisco.com