idnits 2.17.1 draft-ietf-pim-join-attributes-for-lisp-02.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 (July 6, 2015) is 3215 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'AFI' is defined on line 271, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arango 3 Internet-Draft S. Venaas 4 Intended status: Experimental Cisco Systems 5 Expires: January 7, 2016 I. Kouvelas 6 Arista Networks Inc. 7 July 6, 2015 9 PIM Join Attributes for LISP Environments 10 draft-ietf-pim-join-attributes-for-lisp-02.txt 12 Abstract 14 This document defines two PIM Join/Prune attributes that support the 15 construction of multicast distribution trees where the root and 16 receivers are located in different LISP sites. These attributes 17 allow the receiver site to select between unicast and multicast 18 transport and to convey the receiver RLOC address to the control 19 plane of the root xTR. 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 7, 2016. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 57 3. PIM Join/Prune Attributes . . . . . . . . . . . . . . . . . . 3 58 4. The Transport Attribute . . . . . . . . . . . . . . . . . . . 3 59 4.1. Transport Attribute Format . . . . . . . . . . . . . . . 4 60 4.2. Using the Transport Attribute . . . . . . . . . . . . . . 4 61 5. Receiver RLOC Attribute . . . . . . . . . . . . . . . . . . . 4 62 5.1. Receiver RLOC Attribute Format . . . . . . . . . . . . . 5 63 5.2. Using the Receiver RLOC Attribute . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 The construction of multicast distribution trees where the root and 72 receivers are located in different LISP sites [RFC6830] is defined in 73 [RFC6831]. Creation of (root-EID,G) state in the root site requires 74 that unicast LISP-encapsulated Join/Prune messages be sent from an 75 xTR on the receiver site to an xTR on the root site. 77 [RFC6831] specifies that (root-EID,G) data packets are to be LISP- 78 encapsulated into (root-RLOC,G) multicast packets. However, a wide 79 deployment of multicast connectivity between LISP sites is unlikely 80 to happen any time soon. In fact, some implementations are initially 81 focusing on unicast transport with head-end replication between root 82 and receiver sites. 84 The unicast LISP-encapsulated Join/Prune message specifies the (root- 85 EID,G) state that needs to be established in the root site, but 86 conveys nothing about the receivers capability or desire to use 87 multicast as the underlying transport. This document specifies a 88 Join/Prune attribute that allows the receiver to select the desired 89 transport. 91 Knowledge of the receiver RLOC is also essential to the control plane 92 of the root xTR. It determines the downstream destination for 93 unicast head-end replication and identifies the receiver xTR that 94 needs to be notified should the root of the distribution tree move to 95 another site. 97 The outer source address field of the encapsulated Join/Prune message 98 contains an RLOC address of the receiver xTR. This source address is 99 message to the root xTR RLOC destination. Due to policy and load 100 balancing considerations, the selected source address may not be the 101 RLOC on which the receiver site wishes to receive a particular flow. 102 This document specifies a Join/Prune attribute that conveys the 103 appropriate receiver RLOC address to the control plane of the root 104 xTR. 106 2. Requirements Notation 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. PIM Join/Prune Attributes 114 PIM Join/Prune attributes are defined in [RFC5384] by introducing a 115 new Encoded-Source type that, in addition to the Join/Prune source, 116 can carry multiple type-length-value (TLV) attributes. These 117 attributes apply to the individual Join/Prune sources on which they 118 are stored. 120 The attributes defined in this document conform to the format of the 121 encoding type defined in [RFC5384]. The attributes would typically 122 be the same for all the sources in the Join/Prune message. Hence we 123 RECOMMEND using the hierarchical Join/Prune attribute scheme defined 124 in [I-D.venaas-pim-hierarchicaljoinattr]. This hirarchichal system 125 allows attributes to be conveyed on the Upstream Neighbor Address 126 field, thus enabling the efficient application of a single attribute 127 instance to all the sources in the Join/Prune message. 129 LISP xTRs do not exchange PIM Hello Messages and hence no Hello 130 option is defined to negotiate support for these attributes. Systems 131 that support unicast head-end replication are assumed to support 132 these attributes. 134 4. The Transport Attribute 136 It is essential that a mechanism be provided by which the desired 137 transport can be conveyed by receiver sites. Root sites with 138 multicast connectivity will want to leverage multicast replication. 139 However, not all receiver sites can be expected to have multicast 140 connectivity. It is thus desirable that root sites be prepared to 141 support (root-EID,G) state with a mixture of multicast and unicast 142 output state. This document specifies a Join/Prune attribute that 143 allows the receiver to select the desired underlying transport. 145 4.1. Transport Attribute Format 147 0 1 2 148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 |F|E| Type = 5 | Length = 1 | Transport | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 F-bit: The Transitive bit. Specifies whether the attribute is 154 transitive or non-transitive. MUST be set to zero. This 155 attribute is ALWAYS non-transitive. 157 E-bit: End-of-Attributes bit. Specifies whether this attribute is 158 the last. Set to zero if there are more attributes. Set to 1 if 159 this is the last attribute. 161 Type: The Transport Attribute type is 5. 163 Length: The length of the Transport Attribute value. MUST be set 164 to 1. 166 Transport: The type of transport being requested. Set to 0 for 167 multicast. Set to 1 for unicast. 169 4.2. Using the Transport Attribute 171 Hierarchical Join/Prune attribute instances 172 [I-D.venaas-pim-hierarchicaljoinattr] SHOULD be used when the same 173 Transport Attribute is to be applied to all the sources within the 174 Join/Prune message or all the sources within a group set. The root 175 xTR MUST accept Transport Attributes in the Upstream Neighbor 176 Encoded-Unicast address, Encoded-Group addresses, and Encoded-Source 177 addresses. 179 There MUST NOT be more than one Transport Attribute within the same 180 encoded address. If an encoded address has more than one instance of 181 the attribute, the root xTR MUST discard all affected Join/Prune 182 sources. 184 5. Receiver RLOC Attribute 186 The root xTR must know the receiver RLOC addresses of all receiver 187 sites for a given (root-EID,G) so that it can perform unicast LISP- 188 encapsulation of multicast data packets to each and every receiver 189 site that has requested unicast head-end replication. 191 To support mobility of EIDs, the root xTR must keep track of ALL 192 receiver RLOCs even when the corresponding downstream site has not 193 requested unicast replication. The root xTR may detect that a local 194 multicast source "root-EID" has moved to a remote LISP site. Under 195 such circumstances LISP sends a SMR message to all receiver xTRs, 196 prompting them to update their map cache. This is only possible if 197 LISP can obtain from PIM the set of all receiver RLOCS that have 198 active Join state for the root-EID. 200 The outer source address field of the encapsulated Join/Prune message 201 contains an RLOC address of the receiver xTR. LISP xTRs, as edge 202 devices, are commonly subject to URPF checks by the network providers 203 on each core-facing interface. The source address for the 204 encapsulation header must therefore be the RLOC of the core-facing 205 interface used to physically transmit the encapsulated Join/Prune 206 message. Due to policy and load balancing considerations, that may 207 not be the RLOC on which the receiver site wishes to receive a 208 particular flow. This document specifies a Join/Prune attribute that 209 conveys the appropriate receiver RLOC address to the control plane of 210 the root xTR. 212 5.1. Receiver RLOC Attribute Format 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |F|E| Type = 6 | Length | Addr Family | Receiver RLOC 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 220 F-bit: The Transitive bit. Specifies whether this attribute is 221 transitive or non-transitive. MUST be set to zero. This 222 attribute is ALWAYS non-transitive. 224 E-bit: End-of-Attributes bit. Specifies whether this attribute is 225 the last. Set to zero if there are more attributes. Set to 1 if 226 this is the last attribute. 228 Type: The Receiver RLOC Attribute type is 6. 230 Length: The length in octets of the attribute value. MUST be set 231 to the length in octets of the receiver RLOC address plus one 232 octet to account for the Address Family field. 234 Addr Family: The PIM Address Family of the receiver RLOC as defined 235 in [RFC4601]. 237 Receiver RLOC: The RLOC address on which the receiver xTR wishes to 238 receiver the unicast-encapsulated flow."> 240 5.2. Using the Receiver RLOC Attribute 242 Hierarchical Join/Prune attribute instances 243 [I-D.venaas-pim-hierarchicaljoinattr] SHOULD be used when the same 244 Receiver RLOC attribute is to be applied to all the sources within 245 the message or all the sources within a group set. The root xTR MUST 246 accept Transport Attributes in the Upstream Neighbor Encoded-Unicast 247 address, Encoded-Group addresses, and Encoded-Source addresses. 249 There MUST NOT be more than one Receiver RLOC Attribute within the 250 same encoded address. If an encoded address has more than one 251 instance of the attribute, the root xTR MUST discard all affected 252 Join/Prune sources. 254 6. Security Considerations 256 Security of the Join Attribute is only guaranteed by the security of 257 the PIM packet. The attributes specified herein do not enhance or 258 diminish the privacy or authenticity of a Join/Prune message. A site 259 that legitimately or maliciously sends and delivers a Join/Prune 260 message to another site will equally be able to append these and any 261 other attributes it wishes. 263 7. IANA Considerations 265 Two new PIM Join/Prune attribute types need to be assigned. Type 5 266 is being requested for the Transport Attribute. Type 6 is being 267 requested for the Receiver RLOC Attribute. 269 8. Normative References 271 [AFI] IANA, , "Address Family Numbers", 272 http://www.iana.org/assignments/address-family-numbers. 274 [I-D.venaas-pim-hierarchicaljoinattr] 275 Venaas, S., Kouvelas, I., and J. Arango, "Hierarchical 276 Join/Prune Attributes", draft-venaas-pim- 277 hierarchicaljoinattr-00 (work in progress), February 2013. 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 283 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 284 Protocol Specification (Revised)", RFC 4601, August 2006. 286 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 287 Independent Multicast (PIM) Join Attribute Format", RFC 288 5384, November 2008. 290 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 291 Locator/ID Separation Protocol (LISP)", RFC 6830, January 292 2013. 294 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 295 Locator/ID Separation Protocol (LISP) for Multicast 296 Environments", RFC 6831, January 2013. 298 Authors' Addresses 300 Jesus Arango 301 Cisco Systems 302 170 Tasman Drive 303 San Jose, CA 95134 304 USA 306 Email: jearango@cisco.com 308 Stig Venaas 309 Cisco Systems 310 170 Tasman Drive 311 San Jose, CA 95134 312 USA 314 Email: stig@cisco.com 316 Isidor Kouvelas 317 Arista Networks Inc. 318 5453 Great America Parkway 319 Santa Clara, CA 95054 320 USA 322 Email: kouvelas@arista.com