idnits 2.17.1 draft-ietf-pim-join-attributes-for-lisp-05.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 (October 10, 2016) is 2748 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: April 13, 2017 I. Kouvelas 6 Arista Networks Inc. 7 D. Farinacci 8 lispers.net 9 October 10, 2016 11 PIM Join Attributes for LISP Environments 12 draft-ietf-pim-join-attributes-for-lisp-05.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 April 13, 2017. 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The construction of multicast distribution trees where the root and 76 receivers are located in different LISP sites [RFC6830] is defined in 77 [RFC6831]. Creation of (root-EID,G) state in the root site requires 78 that unicast LISP-encapsulated Join/Prune messages be sent from an 79 ETR on the receiver site to an ITR on the root site. 81 [RFC6831] specifies that (root-EID,G) data packets are to be LISP- 82 encapsulated into (root-RLOC,G) multicast packets. However, a wide 83 deployment of multicast connectivity between LISP sites is unlikely 84 to happen any time soon. In fact, some implementations are initially 85 focusing on unicast transport with head-end replication between root 86 and receiver sites. 88 The unicast LISP-encapsulated Join/Prune message specifies the (root- 89 EID,G) state that needs to be established in the root site, but 90 conveys nothing about the receivers capability or desire to use 91 multicast as the underlying transport. This document specifies a 92 Join/Prune attribute that allows the receiver ETR to select the 93 desired transport. 95 Knowledge of the receiver ETR's RLOC address is also essential to the 96 control plane of the root ITR. It determines the downstream 97 destination for unicast head-end replication and identifies the 98 receiver ETR that needs to be notified should the root of the 99 distribution tree move to another site. 101 Service providers may implement uRPF policies requiring that the 102 outer source address of the LISP-encapsulated Join/Prune message be 103 the address of the receiver ETR's core-facing interface used to 104 physically transmit the message. However, due to policy and load 105 balancing considerations, the outer source address may not be the 106 RLOC on which the receiver site wishes to receive a particular flow. 107 This document specifies a Join/Prune attribute that conveys the 108 appropriate receiver ETR's RLOC address to the control plane of the 109 root ITR. 111 2. Requirements Notation 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. PIM Join/Prune Attributes 119 PIM Join/Prune attributes are defined in [RFC5384] by introducing a 120 new Encoded-Source type that, in addition to the Join/Prune source, 121 can carry multiple type-length-value (TLV) attributes. These 122 attributes apply to the individual Join/Prune sources on which they 123 are stored. 125 The attributes defined in this document conform to the format of the 126 encoding type defined in [RFC5384]. The attributes would typically 127 be the same for all the sources in the Join/Prune message. Hence we 128 RECOMMEND using the hierarchical Join/Prune attribute scheme defined 129 in [RFC7887]. This hirarchichal system allows attributes to be 130 conveyed on the Upstream Neighbor Address field, thus enabling the 131 efficient application of a single attribute instance to all the 132 sources in the Join/Prune message. 134 LISP xTRs do not exchange PIM Hello Messages and hence no Hello 135 option is defined to negotiate support for these attributes. Systems 136 that support unicast head-end replication are assumed to support 137 these attributes. 139 4. The Transport Attribute 141 It is essential that a mechanism be provided by which the desired 142 transport can be conveyed by receiver sites. Root sites with 143 multicast connectivity will want to leverage multicast replication. 144 However, not all receiver sites can be expected to have multicast 145 connectivity. It is thus desirable that root sites be prepared to 146 support (root-EID,G) state with a mixture of multicast and unicast 147 output state. This document specifies a Join/Prune attribute that 148 allows the receiver to select the desired underlying transport. 150 4.1. Transport Attribute Format 152 0 1 2 153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |F|E| Type = TBD| Length = 1 | Transport | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 F-bit: The Transitive bit. Specifies whether the attribute is 159 transitive or non-transitive. MUST be set to zero. This 160 attribute is ALWAYS non-transitive. 162 E-bit: End-of-Attributes bit. Specifies whether this attribute is 163 the last. Set to zero if there are more attributes. Set to 1 if 164 this is the last attribute. 166 Type: The Transport Attribute type is TBD. 168 Length: The length of the Transport Attribute value. MUST be set 169 to 1. 171 Transport: The type of transport being requested. Set to 0 for 172 multicast. Set to 1 for unicast. The values from 2 to 255 may be 173 assigned in the future. 175 4.2. Using the Transport Attribute 177 Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used 178 when the same Transport Attribute is to be applied to all the sources 179 within the Join/Prune message or all the sources within a group set. 180 The root ITR MUST accept Transport Attributes in the Upstream 181 Neighbor Encoded-Unicast address, Encoded-Group addresses, and 182 Encoded-Source addresses. 184 There MUST NOT be more than one Transport Attribute within the same 185 encoded address. If an encoded address has more than one instance of 186 the attribute, the root ITR MUST discard all affected Join/Prune 187 sources. The root ITR MUST also discard all affected Join/Prune 188 sources if the transport attribute value is unknown. 190 5. Receiver ETR RLOC Attribute 192 When a receiver ETR requests unicast head-end replication for a given 193 (root-EID,G) entry, the PIM control plane of the root ITR must 194 maintain an output interface list ("oif-list") entry for the receiver 195 ETR and its corresponding RLOC address. This allows the root ITR to 196 perform unicast LISP-encapsulation of multicast data packets to each 197 and every receiver ETR that has requested unicast head-end 198 replication. 200 The PIM control plane of the root ITR could potentially determine the 201 RLOC address of the receiver ETR from the outer source address field 202 of LISP-encapsulated Join/Prune message. However, receiver ETRs are 203 subject to uRPF checks by the network providers on each core-facing 204 interface. The outer source address must therefore be the RLOC of 205 the core-facing interface used to physically transmit the LISP- 206 encapsulated Join/Prune message. Due to policy and load balancing 207 considerations, that may not be the RLOC on which the receiver site 208 wishes to receive a particular flow. This document specifies a Join/ 209 Prune attribute that conveys the appropriate receiver RLOC address to 210 the PIM control plane of the root ITR. 212 To support root-EID mobility, receiver ETRs must also be tracked by 213 the LISP control plane of the root ITR, regardless of the underlying 214 transport. When the root-EID moves to a new root ITR in a different 215 LISP site, the receiver ETRs do not know the root-EID has moved and 216 therefore do not know the RLOC of the new root ITR. This is true for 217 both unicast and multicast transport modes. The new root ITR does 218 not have any receiver ETR state. Therefore, it is the responsability 219 of the old root ITR to inform the receiver ETRs that the root-EID has 220 moved. When the old root ITR detects that the root-EID has moved, it 221 sends a LISP SMR message to each receiver ETR. The receiver ETRs do 222 a mapping database lookup to retrieve the RLOC of the new root ITR. 223 The old root ITR detects that the root-EID has moved when it receives 224 a Map-Notify from the Map-Server. The transmission of the Map-Notify 225 is triggered when the new root ITR registers the root-EID 226 [I-D.portoles-lisp-eid-mobility]. When a receiver ETR determines 227 that the root ITR has changed it will send a LISP-encapsulated PIM 228 prune message to the old root XTR and a LISP-encapsulated PIM join 229 message to the new root XTR. 231 5.1. Receiver RLOC Attribute Format 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |F|E|Type=TBD+1 | Length | Addr Family | Receiver RLOC 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 238 F-bit: The Transitive bit. Specifies whether this attribute is 239 transitive or non-transitive. MUST be set to zero. This 240 attribute is ALWAYS non-transitive. 242 E-bit: End-of-Attributes bit. Specifies whether this attribute is 243 the last. Set to zero if there are more attributes. Set to 1 if 244 this is the last attribute. 246 Type: The Receiver RLOC Attribute type is TBD+1. 248 Length: The length in octets of the attribute value. MUST be set 249 to the length in octets of the receiver RLOC address plus one 250 octet to account for the Address Family field. 252 Addr Family: The PIM Address Family of the receiver RLOC as defined 253 in [RFC7761]. 255 Receiver RLOC: The RLOC address on which the receiver ETR wishes to 256 receiver the unicast-encapsulated flow. 258 5.2. Using the Receiver RLOC Attribute 260 Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used 261 when the same Receiver RLOC attribute is to be applied to all the 262 sources within the message or all the sources within a group set. 263 The root ITR MUST accept Transport Attributes in the Upstream 264 Neighbor Encoded-Unicast address, Encoded-Group addresses, and 265 Encoded-Source addresses. 267 There MUST NOT be more than one Receiver RLOC Attribute within the 268 same encoded address. If an encoded address has more than one 269 instance of the attribute, the root ITR MUST discard all affected 270 Join/Prune sources. The root ITR MUST also discard all affected 271 Join/Prune sources if the address family is unknown, or the address 272 length is incorrect for the specified address family. 274 6. Security Considerations 276 Security of Join/Prune Attributes is only guaranteed by the security 277 of the PIM packet. The attributes specified herein do not enhance or 278 diminish the privacy or authenticity of a Join/Prune message. A site 279 that legitimately or maliciously sends and delivers a Join/Prune 280 message to another site will equally be able to append these and any 281 other attributes it wishes. See [RFC5384] for general security 282 considerations for Join/Prune attributes. 284 7. IANA Considerations 286 Two new PIM Join/Prune attribute types need to be assigned. Type 5 287 is being requested for the Transport Attribute. Type 6 is being 288 requested for the Receiver RLOC Attribute. 290 A registry needs to be created for the Join/Prune Transport 291 attribute. The name of the registry should be PIM Join/Prune 292 Transport Types. The registration policy is IETF Review, and the 293 values are in the range 0-255. This document assigns the value 0 for 294 multicast and 1 for unicast. 296 8. References 298 8.1. Normative References 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 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 306 Independent Multicast (PIM) Join Attribute Format", 307 RFC 5384, DOI 10.17487/RFC5384, November 2008, 308 . 310 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 311 Locator/ID Separation Protocol (LISP)", RFC 6830, 312 DOI 10.17487/RFC6830, January 2013, 313 . 315 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 316 Locator/ID Separation Protocol (LISP) for Multicast 317 Environments", RFC 6831, DOI 10.17487/RFC6831, January 318 2013, . 320 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 321 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 322 Multicast - Sparse Mode (PIM-SM): Protocol Specification 323 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 324 2016, . 326 [RFC7887] Venaas, S., Arango, J., and I. Kouvelas, "Hierarchical 327 Join/Prune Attributes", RFC 7887, DOI 10.17487/RFC7887, 328 June 2016, . 330 8.2. Informative References 332 [I-D.portoles-lisp-eid-mobility] 333 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 334 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 335 Unified Control Plane", draft-portoles-lisp-eid- 336 mobility-01 (work in progress), October 2016. 338 Authors' Addresses 340 Jesus Arango 341 Cisco Systems 342 170 Tasman Drive 343 San Jose, CA 95134 344 USA 346 Email: jearango@cisco.com 348 Stig Venaas 349 Cisco Systems 350 170 Tasman Drive 351 San Jose, CA 95134 352 USA 354 Email: stig@cisco.com 356 Isidor Kouvelas 357 Arista Networks Inc. 358 5453 Great America Parkway 359 Santa Clara, CA 95054 360 USA 362 Email: kouvelas@arista.com 364 Dino Farinacci 365 lispers.net 366 San Jose, CA 367 USA 369 Email: farinacci@gmail.com