idnits 2.17.1 draft-ietf-pim-join-attributes-for-lisp-04.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 (June 14, 2016) is 2866 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'AFI' is defined on line 286, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-portoles-lisp-eid-mobility-00 ** 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 (~~), 3 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: December 16, 2016 I. Kouvelas 6 Arista Networks Inc. 7 D. Farinacci 8 lispers.net 9 June 14, 2016 11 PIM Join Attributes for LISP Environments 12 draft-ietf-pim-join-attributes-for-lisp-04.txt 14 Abstract 16 This document defines two PIM Join/Prune attributes that support the 17 construction of multicast distribution trees where the root and 18 receivers are located in different LISP sites. These attributes 19 allow the receiver site to select between unicast and multicast 20 underlay transport and to convey the receiver ETR's RLOC address to 21 the control plane of the root ITR. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 16, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 59 3. PIM Join/Prune Attributes . . . . . . . . . . . . . . . . . . 3 60 4. The Transport Attribute . . . . . . . . . . . . . . . . . . . 3 61 4.1. Transport Attribute Format . . . . . . . . . . . . . . . 4 62 4.2. Using the Transport Attribute . . . . . . . . . . . . . . 4 63 5. Receiver ETR RLOC Attribute . . . . . . . . . . . . . . . . . 5 64 5.1. Receiver RLOC Attribute Format . . . . . . . . . . . . . 5 65 5.2. Using the Receiver RLOC Attribute . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The construction of multicast distribution trees where the root and 74 receivers are located in different LISP sites [RFC6830] is defined in 75 [RFC6831]. Creation of (root-EID,G) state in the root site requires 76 that unicast LISP-encapsulated Join/Prune messages be sent from an 77 ETR on the receiver site to an ITR on the root site. 79 [RFC6831] specifies that (root-EID,G) data packets are to be LISP- 80 encapsulated into (root-RLOC,G) multicast packets. However, a wide 81 deployment of multicast connectivity between LISP sites is unlikely 82 to happen any time soon. In fact, some implementations are initially 83 focusing on unicast transport with head-end replication between root 84 and receiver sites. 86 The unicast LISP-encapsulated Join/Prune message specifies the (root- 87 EID,G) state that needs to be established in the root site, but 88 conveys nothing about the receivers capability or desire to use 89 multicast as the underlying transport. This document specifies a 90 Join/Prune attribute that allows the receiver ETR to select the 91 desired transport. 93 Knowledge of the receiver ETR's RLOC address is also essential to the 94 control plane of the root ITR. It determines the downstream 95 destination for unicast head-end replication and identifies the 96 receiver ETR that needs to be notified should the root of the 97 distribution tree move to another site. 99 Service providers may implement URPF policies requiring that the 100 outer source address of the LISP-encapsulated Join/Prune message be 101 the address of the receiver ETR's core-facing interface used to 102 physically transmit the message. However, due to policy and load 103 balancing considerations, the outer source address may not be the 104 RLOC on which the receiver site wishes to receive a particular flow. 105 This document specifies a Join/Prune attribute that conveys the 106 appropriate receiver ETR's RLOC address to the control plane of the 107 root ITR. 109 2. Requirements Notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. PIM Join/Prune Attributes 117 PIM Join/Prune attributes are defined in [RFC5384] by introducing a 118 new Encoded-Source type that, in addition to the Join/Prune source, 119 can carry multiple type-length-value (TLV) attributes. These 120 attributes apply to the individual Join/Prune sources on which they 121 are stored. 123 The attributes defined in this document conform to the format of the 124 encoding type defined in [RFC5384]. The attributes would typically 125 be the same for all the sources in the Join/Prune message. Hence we 126 RECOMMEND using the hierarchical Join/Prune attribute scheme defined 127 in [I-D.ietf-pim-hierarchicaljoinattr]. This hirarchichal system 128 allows attributes to be conveyed on the Upstream Neighbor Address 129 field, thus enabling the efficient application of a single attribute 130 instance to all the sources in the Join/Prune message. 132 LISP xTRs do not exchange PIM Hello Messages and hence no Hello 133 option is defined to negotiate support for these attributes. Systems 134 that support unicast head-end replication are assumed to support 135 these attributes. 137 4. The Transport Attribute 139 It is essential that a mechanism be provided by which the desired 140 transport can be conveyed by receiver sites. Root sites with 141 multicast connectivity will want to leverage multicast replication. 142 However, not all receiver sites can be expected to have multicast 143 connectivity. It is thus desirable that root sites be prepared to 144 support (root-EID,G) state with a mixture of multicast and unicast 145 output state. This document specifies a Join/Prune attribute that 146 allows the receiver to select the desired underlying transport. 148 4.1. Transport Attribute Format 150 0 1 2 151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |F|E| Type = TBD| Length = 1 | Transport | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 F-bit: The Transitive bit. Specifies whether the attribute is 157 transitive or non-transitive. MUST be set to zero. This 158 attribute is ALWAYS non-transitive. 160 E-bit: End-of-Attributes bit. Specifies whether this attribute is 161 the last. Set to zero if there are more attributes. Set to 1 if 162 this is the last attribute. 164 Type: The Transport Attribute type is TBD. 166 Length: The length of the Transport Attribute value. MUST be set 167 to 1. 169 Transport: The type of transport being requested. Set to 0 for 170 multicast. Set to 1 for unicast. 172 4.2. Using the Transport Attribute 174 Hierarchical Join/Prune attribute instances 175 [I-D.ietf-pim-hierarchicaljoinattr] SHOULD be used when the same 176 Transport Attribute is to be applied to all the sources within the 177 Join/Prune message or all the sources within a group set. The root 178 ITR MUST accept Transport Attributes in the Upstream Neighbor 179 Encoded-Unicast address, Encoded-Group addresses, and Encoded-Source 180 addresses. 182 There MUST NOT be more than one Transport Attribute within the same 183 encoded address. If an encoded address has more than one instance of 184 the attribute, the root ITR MUST discard all affected Join/Prune 185 sources. 187 5. Receiver ETR RLOC Attribute 189 When a receiver ETR requests unicast head-end replication for a given 190 (root-EID,G) entry, the PIM control plane of the root ITR must 191 maintain an output interface list ("oif-list") entry for the receiver 192 ETR and its corresponding RLOC address. This allows the root ITR to 193 perform unicast LISP-encapsulation of multicast data packets to each 194 and every receiver ETR that has requested unicast head-end 195 replication. 197 The PIM control plane of the root ITR could potentially determine the 198 RLOC address of the receiver ETR from the outer source address field 199 of LISP-encapsulated Join/Prune message. However, receiver ETRs are 200 subject to URPF checks by the network providers on each core-facing 201 interface. The outer source address must therefore be the RLOC of 202 the core-facing interface used to physically transmit the LISP- 203 encapsulated Join/Prune message. Due to policy and load balancing 204 considerations, that may not be the RLOC on which the receiver site 205 wishes to receive a particular flow. This document specifies a Join/ 206 Prune attribute that conveys the appropriate receiver RLOC address to 207 the PIM control plane of the root ITR. 209 To support root-EID mobility, receiver ETRs must also be tracked by 210 the LISP control plane of the root ITR, regardless of the underlying 211 transport. When the root-EID moves to a new root ITR in a different 212 LISP site, the receiver ETRs do not know the root-EID has moved and 213 therefore do not know the RLOC of the new root ITR. This is true for 214 both unicast and multicast transport modes. The new root ITR does 215 not have any receiver ETR state. Therefore, it is the responsability 216 of the old root ITR to inform the receiver ETRs that the root-EID has 217 moved. When the old root ITR detects that the root-EID has moved, it 218 sends a LISP SMR message to each receiver ETR. The receiver ETRs do 219 a mapping database lookup to retrieve the RLOC of the new root ITR. 220 The old root ITR detects that the root-EID has moved when it receives 221 a Map-Notify from the Map-Server. The transmission of the Map-Notify 222 is triggered when the new root ITR registers the root-EID 223 [I-D.portoles-lisp-eid-mobility]. When a receiver ETR determines 224 that the root ITR has changed it will send a LISP-encapsulated PIM 225 prune message to the old root XTR and a LISP-encapsulated PIM join 226 message to the new root XTR. 228 5.1. Receiver RLOC Attribute Format 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |F|E|Type=TBD+1 | Length | Addr Family | Receiver RLOC 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 235 F-bit: The Transitive bit. Specifies whether this attribute is 236 transitive or non-transitive. MUST be set to zero. This 237 attribute is ALWAYS non-transitive. 239 E-bit: End-of-Attributes bit. Specifies whether this attribute is 240 the last. Set to zero if there are more attributes. Set to 1 if 241 this is the last attribute. 243 Type: The Receiver RLOC Attribute type is TBD+1. 245 Length: The length in octets of the attribute value. MUST be set 246 to the length in octets of the receiver RLOC address plus one 247 octet to account for the Address Family field. 249 Addr Family: The PIM Address Family of the receiver RLOC as defined 250 in [RFC4601]. 252 Receiver RLOC: The RLOC address on which the receiver ETR wishes to 253 receiver the unicast-encapsulated flow."> 255 5.2. Using the Receiver RLOC Attribute 257 Hierarchical Join/Prune attribute instances 258 [I-D.ietf-pim-hierarchicaljoinattr] SHOULD be used when the same 259 Receiver RLOC attribute is to be applied to all the sources within 260 the message or all the sources within a group set. The root ITR MUST 261 accept Transport Attributes in the Upstream Neighbor Encoded-Unicast 262 address, Encoded-Group addresses, and Encoded-Source addresses. 264 There MUST NOT be more than one Receiver RLOC Attribute within the 265 same encoded address. If an encoded address has more than one 266 instance of the attribute, the root ITR MUST discard all affected 267 Join/Prune sources. 269 6. Security Considerations 271 Security of the Join Attribute is only guaranteed by the security of 272 the PIM packet. The attributes specified herein do not enhance or 273 diminish the privacy or authenticity of a Join/Prune message. A site 274 that legitimately or maliciously sends and delivers a Join/Prune 275 message to another site will equally be able to append these and any 276 other attributes it wishes. 278 7. IANA Considerations 280 Two new PIM Join/Prune attribute types need to be assigned. Type 5 281 is being requested for the Transport Attribute. Type 6 is being 282 requested for the Receiver RLOC Attribute. 284 8. Normative References 286 [AFI] IANA, , "Address Family Numbers", 287 http://www.iana.org/assignments/address-family-numbers. 289 [I-D.ietf-pim-hierarchicaljoinattr] 290 Venaas, S., Arango, J., and I. Kouvelas, "Hierarchical 291 Join/Prune Attributes", draft-ietf-pim- 292 hierarchicaljoinattr-08 (work in progress), April 2016. 294 [I-D.portoles-lisp-eid-mobility] 295 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 296 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 297 Unified Control Plane", draft-portoles-lisp-eid- 298 mobility-00 (work in progress), April 2016. 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, 302 DOI 10.17487/RFC2119, March 1997, 303 . 305 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 306 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 307 Protocol Specification (Revised)", RFC 4601, 308 DOI 10.17487/RFC4601, August 2006, 309 . 311 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 312 Independent Multicast (PIM) Join Attribute Format", 313 RFC 5384, DOI 10.17487/RFC5384, November 2008, 314 . 316 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 317 Locator/ID Separation Protocol (LISP)", RFC 6830, 318 DOI 10.17487/RFC6830, January 2013, 319 . 321 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 322 Locator/ID Separation Protocol (LISP) for Multicast 323 Environments", RFC 6831, DOI 10.17487/RFC6831, January 324 2013, . 326 Authors' Addresses 328 Jesus Arango 329 Cisco Systems 330 170 Tasman Drive 331 San Jose, CA 95134 332 USA 334 Email: jearango@cisco.com 336 Stig Venaas 337 Cisco Systems 338 170 Tasman Drive 339 San Jose, CA 95134 340 USA 342 Email: stig@cisco.com 344 Isidor Kouvelas 345 Arista Networks Inc. 346 5453 Great America Parkway 347 Santa Clara, CA 95054 348 USA 350 Email: kouvelas@arista.com 352 Dino Farinacci 353 lispers.net 354 San Jose, CA 355 USA 357 Email: farinacci@gmail.com