idnits 2.17.1 draft-ietf-pim-join-attributes-for-lisp-06.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 (December 5, 2016) is 2696 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-02) exists of draft-portoles-lisp-eid-mobility-01 Summary: 1 error (**), 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: June 8, 2017 I. Kouvelas 6 Arista Networks Inc. 7 D. Farinacci 8 lispers.net 9 December 5, 2016 11 PIM Join Attributes for LISP Environments 12 draft-ietf-pim-join-attributes-for-lisp-06.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 RLOC (Routing Locator) address 21 of the receiver ETR (Egress Tunnel Router) to the control plane of 22 the root ITR (Ingress Tunnel Router). 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 8, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 60 3. PIM Join/Prune Attributes . . . . . . . . . . . . . . . . . . 3 61 4. The Transport Attribute . . . . . . . . . . . . . . . . . . . 4 62 4.1. Transport Attribute Format . . . . . . . . . . . . . . . 4 63 4.2. Using the Transport Attribute . . . . . . . . . . . . . . 5 64 5. Receiver ETR RLOC Attribute . . . . . . . . . . . . . . . . . 5 65 5.1. Receiver RLOC Attribute Format . . . . . . . . . . . . . 6 66 5.2. Using the Receiver RLOC Attribute . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The construction of multicast distribution trees where the root and 77 receivers are located in different LISP sites [RFC6830] is defined in 78 [RFC6831]. Creation of (root-EID,G) state in the root site requires 79 that unicast LISP-encapsulated Join/Prune messages be sent from an 80 ETR on the receiver site to an ITR on the root site. The term EID is 81 short for Endpoint ID. 83 [RFC6831] specifies that (root-EID,G) data packets are to be LISP- 84 encapsulated into (root-RLOC,G) multicast packets. However, a wide 85 deployment of multicast connectivity between LISP sites is unlikely 86 to happen any time soon. In fact, some implementations are initially 87 focusing on unicast transport with head-end replication between root 88 and receiver sites. 90 The unicast LISP-encapsulated Join/Prune message specifies the (root- 91 EID,G) state that needs to be established in the root site, but 92 conveys nothing about the receivers capability or desire to use 93 multicast as the underlying transport. This document specifies a 94 Join/Prune attribute that allows the receiver ETR to select the 95 desired transport. 97 The term transport in this document is intentionally somewhat vague. 98 Currently it is used just to indicate whether multicast or head-end 99 replication is used. Which means that the outer destination address 100 is either a unicast or multicast address. Future documents may 101 specify how other types of delivery, encapsulation or underlay are 102 used. 104 Knowledge of the receiver ETR's RLOC address is also essential to the 105 control plane of the root ITR. The RLOC address determines the 106 downstream destination for unicast head-end replication and 107 identifies the receiver ETR that needs to be notified should the root 108 ITR of the distribution tree move to another site. The root ITR can 109 change when the source EID is roaming to another LISP site. 111 Service providers may implement uRPF policies requiring that the 112 outer source address of the LISP-encapsulated Join/Prune message be 113 the address of the receiver ETR's core-facing interface used to 114 physically transmit the message. However, due to policy and load 115 balancing considerations, the outer source address may not be the 116 RLOC on which the receiver site wishes to receive a particular flow. 117 This document specifies a Join/Prune attribute that conveys the 118 appropriate receiver ETR's RLOC address to the control plane of the 119 root ITR. 121 This document uses terminology defined in [RFC6830], such as EID, 122 RLOC, ITR and ETR. 124 2. Requirements Notation 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. PIM Join/Prune Attributes 132 PIM Join/Prune attributes are defined in [RFC5384] by introducing a 133 new Encoded-Source type that, in addition to the Join/Prune source, 134 can carry multiple type-length-value (TLV) attributes. These 135 attributes apply to the individual Join/Prune sources on which they 136 are stored. 138 The attributes defined in this document conform to the format of the 139 encoding type defined in [RFC5384]. The attributes would typically 140 be the same for all the sources in the Join/Prune message. Hence we 141 RECOMMEND using the hierarchical Join/Prune attribute scheme defined 142 in [RFC7887]. This hirarchichal system allows attributes to be 143 conveyed on the Upstream Neighbor Address field, thus enabling the 144 efficient application of a single attribute instance to all the 145 sources in the Join/Prune message. 147 LISP xTRs do not exchange PIM Hello Messages and hence no Hello 148 option is defined to negotiate support for these attributes. Systems 149 that support unicast head-end replication are assumed to support 150 these attributes. 152 4. The Transport Attribute 154 It is essential that a mechanism be provided by which the desired 155 transport can be conveyed by receiver sites. Root sites with 156 multicast connectivity will want to leverage multicast replication. 157 However, not all receiver sites can be expected to have multicast 158 connectivity. It is thus desirable that root sites be prepared to 159 support (root-EID,G) state with a mixture of multicast and unicast 160 output state. This document specifies a Join/Prune attribute that 161 allows the receiver to select the desired underlying transport. 163 4.1. Transport Attribute Format 165 0 1 2 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |F|E| Type = TBD| Length = 1 | Transport | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 F-bit: The Transitive bit. Specifies whether the attribute is 172 transitive or non-transitive. MUST be set to zero. This 173 attribute is ALWAYS non-transitive. 175 E-bit: End-of-Attributes bit. Specifies whether this attribute is 176 the last. Set to zero if there are more attributes. Set to 1 if 177 this is the last attribute. 179 Type: The Transport Attribute type is TBD. 181 Length: The length of the Transport Attribute value. MUST be set 182 to 1. 184 Transport: The type of transport being requested. Set to 0 for 185 multicast. Set to 1 for unicast. The values from 2 to 255 may be 186 assigned in the future. 188 4.2. Using the Transport Attribute 190 Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used 191 when the same Transport Attribute is to be applied to all the sources 192 within the Join/Prune message or all the sources within a group set. 193 The root ITR MUST accept Transport Attributes in the Upstream 194 Neighbor Encoded-Unicast address, Encoded-Group addresses, and 195 Encoded-Source addresses. 197 There MUST NOT be more than one Transport Attribute within the same 198 encoded address. If an encoded address has more than one instance of 199 the attribute, the root ITR MUST discard all affected Join/Prune 200 sources. The root ITR MUST also discard all affected Join/Prune 201 sources if the transport attribute value is unknown. 203 5. Receiver ETR RLOC Attribute 205 When a receiver ETR requests unicast head-end replication for a given 206 (root-EID,G) entry, the PIM control plane of the root ITR must 207 maintain an output interface list ("oif-list") entry for the receiver 208 ETR and its corresponding RLOC address. This allows the root ITR to 209 perform unicast LISP-encapsulation of multicast data packets to each 210 and every receiver ETR that has requested unicast head-end 211 replication. 213 The PIM control plane of the root ITR could potentially determine the 214 RLOC address of the receiver ETR from the outer source address field 215 of LISP-encapsulated Join/Prune message. However, receiver ETRs are 216 subject to uRPF checks by the network providers on each core-facing 217 interface. The outer source address must therefore be the RLOC of 218 the core-facing interface used to physically transmit the LISP- 219 encapsulated Join/Prune message. Due to policy and load balancing 220 considerations, that may not be the RLOC on which the receiver site 221 wishes to receive a particular flow. This document specifies a Join/ 222 Prune attribute that conveys the appropriate receiver RLOC address to 223 the PIM control plane of the root ITR. 225 To support root-EID mobility, receiver ETRs must also be tracked by 226 the LISP control plane of the root ITR, regardless of the underlying 227 transport. When the root-EID moves to a new root ITR in a different 228 LISP site, the receiver ETRs do not know the root-EID has moved and 229 therefore do not know the RLOC of the new root ITR. This is true for 230 both unicast and multicast transport modes. The new root ITR does 231 not have any receiver ETR state. Therefore, it is the responsability 232 of the old root ITR to inform the receiver ETRs that the root-EID has 233 moved. When the old root ITR detects that the root-EID has moved, it 234 sends a LISP SMR message to each receiver ETR. The receiver ETRs do 235 a mapping database lookup to retrieve the RLOC of the new root ITR. 237 The old root ITR detects that the root-EID has moved when it receives 238 a Map-Notify from the Map-Server. The transmission of the Map-Notify 239 is triggered when the new root ITR registers the root-EID 240 [I-D.portoles-lisp-eid-mobility]. When a receiver ETR determines 241 that the root ITR has changed it will send a LISP-encapsulated PIM 242 prune message to the old root XTR and a LISP-encapsulated PIM join 243 message to the new root XTR. 245 5.1. Receiver RLOC Attribute Format 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 |F|E|Type=TBD+1 | Length | Addr Family | Receiver RLOC 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 253 F-bit: The Transitive bit. Specifies whether this attribute is 254 transitive or non-transitive. MUST be set to zero. This 255 attribute is ALWAYS non-transitive. 257 E-bit: End-of-Attributes bit. Specifies whether this attribute is 258 the last. Set to zero if there are more attributes. Set to 1 if 259 this is the last attribute. 261 Type: The Receiver RLOC Attribute type is TBD+1. 263 Length: The length in octets of the attribute value. MUST be set 264 to the length in octets of the receiver RLOC address plus one 265 octet to account for the Address Family field. 267 Addr Family: The PIM Address Family of the receiver RLOC as defined 268 in [RFC7761]. 270 Receiver RLOC: The RLOC address on which the receiver ETR wishes to 271 receiver the unicast-encapsulated flow. 273 5.2. Using the Receiver RLOC Attribute 275 Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used 276 when the same Receiver RLOC attribute is to be applied to all the 277 sources within the message or all the sources within a group set. 278 The root ITR MUST accept Transport Attributes in the Upstream 279 Neighbor Encoded-Unicast address, Encoded-Group addresses, and 280 Encoded-Source addresses. 282 There MUST NOT be more than one Receiver RLOC Attribute within the 283 same encoded address. If an encoded address has more than one 284 instance of the attribute, the root ITR MUST discard all affected 285 Join/Prune sources. The root ITR MUST also discard all affected 286 Join/Prune sources if the address family is unknown, or the address 287 length is incorrect for the specified address family. 289 6. Security Considerations 291 Security of Join/Prune Attributes is only guaranteed by the security 292 of the PIM packet. The attributes specified herein do not enhance or 293 diminish the privacy or authenticity of a Join/Prune message. A site 294 that legitimately or maliciously sends and delivers a Join/Prune 295 message to another site will equally be able to append these and any 296 other attributes it wishes. See [RFC5384] for general security 297 considerations for Join/Prune attributes. 299 7. IANA Considerations 301 Two new PIM Join/Prune attribute types need to be assigned. Type 5 302 is being requested for the Transport Attribute. Type 6 is being 303 requested for the Receiver RLOC Attribute. 305 A registry needs to be created for the Join/Prune Transport 306 attribute. The name of the registry should be PIM Join/Prune 307 Transport Types. The registration policy is IETF Review, and the 308 values are in the range 0-255. This document assigns the value 0 for 309 multicast and 1 for unicast. 311 8. References 313 8.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 321 Independent Multicast (PIM) Join Attribute Format", 322 RFC 5384, DOI 10.17487/RFC5384, November 2008, 323 . 325 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 326 Locator/ID Separation Protocol (LISP)", RFC 6830, 327 DOI 10.17487/RFC6830, January 2013, 328 . 330 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 331 Locator/ID Separation Protocol (LISP) for Multicast 332 Environments", RFC 6831, DOI 10.17487/RFC6831, January 333 2013, . 335 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 336 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 337 Multicast - Sparse Mode (PIM-SM): Protocol Specification 338 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 339 2016, . 341 [RFC7887] Venaas, S., Arango, J., and I. Kouvelas, "Hierarchical 342 Join/Prune Attributes", RFC 7887, DOI 10.17487/RFC7887, 343 June 2016, . 345 8.2. Informative References 347 [I-D.portoles-lisp-eid-mobility] 348 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 349 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 350 Unified Control Plane", draft-portoles-lisp-eid- 351 mobility-01 (work in progress), October 2016. 353 Authors' Addresses 355 Jesus Arango 356 Cisco Systems 357 170 Tasman Drive 358 San Jose, CA 95134 359 USA 361 Email: jearango@cisco.com 363 Stig Venaas 364 Cisco Systems 365 170 Tasman Drive 366 San Jose, CA 95134 367 USA 369 Email: stig@cisco.com 370 Isidor Kouvelas 371 Arista Networks Inc. 372 5453 Great America Parkway 373 Santa Clara, CA 95054 374 USA 376 Email: kouvelas@arista.com 378 Dino Farinacci 379 lispers.net 380 San Jose, CA 381 USA 383 Email: farinacci@gmail.com