idnits 2.17.1 draft-ietf-bier-mvpn-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 (December 28, 2015) is 3035 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-07) exists of draft-ietf-bess-mvpn-extranet-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Rosen, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track M. Sivakumar 5 Expires: June 30, 2016 Cisco Systems, Inc. 6 S. Aldrin 7 Google, Inc. 8 A. Dolganow 9 Alcatel-Lucent 10 T. Przygienda 11 Ericsson 12 December 28, 2015 14 Multicast VPN Using BIER 15 draft-ietf-bier-mvpn-02 17 Abstract 19 The Multicast Virtual Private Network (MVPN) specifications require 20 the use of multicast tunnels ("P-tunnels") that traverse a Service 21 Provider's backbone network. The P-tunnels are used for carrying 22 multicast traffic across the backbone. A variety of P-tunnel types 23 are supported. Bit Index Explicit Replication (BIER) is a new 24 architecture that provides optimal multicast forwarding through a 25 "multicast domain", without requiring intermediate routers to 26 maintain any per-flow state or to engage in an explicit tree-building 27 protocol. This document specifies the protocol and procedures that 28 allow MVPN to use BIER as the method of carrying multicast traffic 29 over an SP backbone network. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 30, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4 67 3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Using the LIR Flag . . . . . . . . . . . . . . . . . . . 7 69 3.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . . . 7 70 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8 72 4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 9 74 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 9 75 5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10 76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 [RFC6513] and [RFC6514] specify the protocols and procedures that a 87 Service Provider (SP) can use to provide Multicast Virtual Private 88 Network (MVPN) service to its customers. Multicast tunnels are 89 created through an SP's backbone network; these are known as 90 "P-tunnels". The P-tunnels are used for carrying multicast traffic 91 across the backbone. The MVPN specifications allow the use of 92 several different kinds of P-tunnel technology. 94 Bit Index Explicit Replication (BIER) ([BIER_ARCH]) is an 95 architecture that provides optimal multicast forwarding through a 96 "multicast domain", without requiring intermediate routers to 97 maintain any per-flow state or to engage in an explicit tree-building 98 protocol. The purpose of the current document is to specify the 99 protocols and procedures needed in order to provide MVPN service 100 using BIER to transport the multicast traffic over the backbone. 102 Although BIER does not explicitly build and maintain multicast 103 tunnels, one can think of BIER as using a number of implicitly 104 created tunnels through a "BIER domain". In particular, one can 105 think of there as being one Point-to-Multipoint (P2MP) tunnel from 106 each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit 107 Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER 108 domain is generally co-extensive with an IGP network. These 109 "tunnels" are not specific to any particular VPN. However, the MVPN 110 architecture provides protocols and procedures that allow the traffic 111 of multiple MVPNs to be aggregated on a single P-tunnel. In this 112 document, we specify how to use these multi-VPN aggregation 113 procedures to enable BIER to transport traffic from multiple MVPNs. 115 MVPN traffic must sometimes traverse more than one IGP domain, 116 whereas BIER only carries multicast traffic within a single IGP 117 domain. However, the MVPN specifications allow P-tunnels to be 118 "segmented", where the segmentation points may either be Autonomous 119 System Border Routers (ASBRs), as described in [RFC6514], or Area 120 Border Routers (ABRs), as described in [RFC7524]. As long as the 121 segmentation points are capable of acting as BFIRs and BFERs, BIER 122 can be used to provide some or all of the segments of a P-tunnel. 124 This revision of the document does not specify the procedures 125 necessary to support MVPN customers that are using BIDIR-PIM. Those 126 procedures will be added in a future revision. 128 This document uses the following terminology from [BIER_ARCH]: 130 o BFR: Bit-Forwarding Router. 132 o BFIR: Bit-Forwarding Ingress Router. 134 o BFER: Bit-Forwarding Egress Router. 136 This document uses the following terminology from [RFC6513]: 138 o MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in 139 which multicast service is offered. 141 o P-tunnel. A multicast tunnel through the network of one or more 142 SPs. P-tunnels are used to transport MVPN multicast data 144 o C-S: A multicast source address, identifying a multicast source 145 located at a VPN customer site. 147 o C-G: A multicast group address used by a VPN customer. 149 o C-flow: A customer multicast flow. Each C-flow is identified by 150 the ordered pair (source address, group address), where each 151 address is in the customer's address space. The identifier of a 152 particular C-flow is usually written as (C-S,C-G). 153 Sets of C-flows can be identified by the use of the "C-*" wildcard 154 (see [RFC6625]), e.g., (C-*,C-G). 156 o I-PMSI A-D Route: Inclusive Provider Multicast Service Interface 157 Auto-Discovery route. Carried in BGP Update messages, these 158 routes are used to advertise the "default" P-tunnel for a 159 particular MVPN. 161 o S-PMSI A-D route: Selective Provider Multicast Service Interface 162 Auto-Discovery route. Carried in BGP Update messages, these 163 routes are used to advertise the fact that particular C-flows are 164 bound to (i.e., are traveling through) particular P-tunnels. 166 o PMSI Tunnel attribute (PTA). This BGP attribute carried is used 167 to identify a particular P-tunnel. When C-flows of multiple VPNs 168 is carried in a single P-tunnel, this attribute also carries the 169 information needed to multiplex and demultiplex the C-flows. 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in RFC 2119 [RFC2119]. 175 2. Use of the PMSI Tunnel Attribute 177 As defined in [RFC6514], the PMSI Tunnel attribute is used to 178 identify the particular P-tunnel to which one or more multicast flows 179 are being assigned. 181 The PMSI Tunnel attribute (PTA)contains the following fields: 183 o "Tunnel Type". IANA is requested to assign a new tunnel type 184 codepoint for "BIER". This codepoint will be used to indicate 185 that the PMSI is instantiated by BIER. 187 o "Tunnel Identifier". When the "tunnel type" field is "BIER", this 188 field contains two subfields: 190 1. The first subfield is a single octet, containing the sub- 191 domain-id of the sub-domain to which the BFIR will assign the 192 packets that it transmits on the PMSI identified by the NLRI 193 of the BGP I-PMSI or S-PMSI A-D route that contains this PTA. 194 (How that sub-domain is chosen is outside the scope of this 195 document.) 197 2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the 198 originator of the route that is carrying this PTA. This will 199 either be a /32 IPv4 address or a /128 IPv6 address. Whether 200 the address is IPv4 or IPv6 can be inferred from the total 201 length of the PMSI Tunnel attribute. 203 o "MPLS label". This field contains an upstream-assigned MPLS 204 label. It is assigned by the router that originates the BGP route 205 to which the PTA is attached. Constraints on the way in which the 206 originating router selects this label are discussed below. 208 o "Flags". When the tunnel type is BIER, two of the bits in the PTA 209 Flags field are meaningful. Details about the use of these bits 210 can be found in Section 3. 212 * "Leaf Info Required per Flow (LIR-pF)". This bit is introduced 213 in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this bit UNLESS 214 it knows that all the BFERs in the BIER domain (or at least all 215 the BFERs to which it needs to transmit) support this bit. 216 (How this is known is outside the scope of this document.) 217 This bit MAY be set in a (C-*,C-*) S-PMSI A-D route, but MUST 218 NOT be set in I-PMSI A-D routes or in other S-PMSI A-D routes. 220 * "Leaf Info Required Bit". The setting of this bit depends upon 221 the type of route and the NLRI of the route that carries the 222 PTA. 224 + In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the 225 bit SHOULD be clear, unless the LIR-pF bit has also been set 226 (see above). This bit SHOULD also be clear in a (C-S,C-*) 227 or (C-*,C-G) S-PMSI A-D route. 229 + In other S-PMSI A-D routes, the bit SHOULD be set. 231 Note that if a PTA specifying "BIER" is attached to an I-PMSI or 232 S-PMSI A-D route, the route MUST NOT be distributed beyond the 233 boundaries of a BIER domain. That is, any routers that receive the 234 route must be in the same BIER domain as the originator of the route. 235 If the originator is in more than one BIER domain, the route must be 236 distributed only within the BIER domain in which the BFR-Prefix in 237 the PTA uniquely identifies the originator. As with all MVPN routes, 238 distribution of these routes is controlled by the provisioning of 239 Route Targets. 241 Suppose an ingress PE originates two x-PMSI A-D routes, where we use 242 the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes 243 carry a PTA, and the PTA of each route specifies"BIER". 245 o If the two routes do not carry the same set of Route Targets 246 (RTs), then their respective PTAs MUST contain different MPLS 247 label values. 249 o If the ingress PE is supporting MVPN extranet ([EXTRANET]) 250 functionality, and if the two routes originate from different 251 VRFs, then the respective PTAs of the two routes MUST contain 252 different MPLS label values. 254 o If the ingress PE is supporting the "Extranet Separation" feature 255 of MVPN extranet (see Section 7.3 of [EXTRANET], section ), and if 256 one of the routes carries the "Extranet Separation" extended 257 community and the other does not, then the respective PTAs of the 258 two routes MUST contain different MPLS label values. 260 o If segmented P-tunnels are being used, then the respective PTAs of 261 the two routes MUST contain different MPLS label values, as long 262 as the NLRIs are not identical. In this case, the MPLS label can 263 be used by the BFER to identify the particular C-flow to which a 264 data packet belongs, and this greatly simplifies the process of 265 forwarding a received packet to its next P-tunnel segment. This 266 is explained further in Section 4. 268 When segmented P-tunnels are being used, an ABR or ASBR may receive, 269 from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER". 270 This means that BIER is being used for one segment of a segmented 271 P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D 272 route whose PTA identifies the next segment of the P-tunnel. The 273 next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D 274 routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and 275 R4 respectively, where the PTAs of each of the four routes specify a 276 BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS 277 label, UNLESS both of the following conditions hold: 279 o R1 and R2 have the same "originating router" in their respective 280 NLRIs. 282 o R1 and R2 specify the same MPLS label in their respective PTAs. 284 3. Explicit Tracking 286 When using BIER to transport an MVPN data packet through a BIER 287 domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The 288 BFIR must determine the set of BFERs to which the packet needs to be 289 delivered. This can be done in either of two ways: 291 1. By using the explicit tracking mechanism based on the "Leaf Info 292 Required" flag, as specified in [RFC6513] and [RFC6514], or 294 2. By using the explicit tracking mechanism based on the LIR-pF flag 295 as specified in [EXPLICIT_TRACKING]. This mechanism MAY be used 296 if (and only if) segmented P-tunnels are not being used. 298 3.1. Using the LIR Flag 300 To determine the set of BFERs to which a given MVPN data packet needs 301 to be delivered, the BFIR originating an S-PMSI A-D route sets the 302 LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond 303 with Leaf A-D routes. By matching the received Leaf A-D routes to 304 the originated S-PMSI A-D routes, the originator of the S-PMSI A-D 305 route determines the set of BFERs that need to receive the multicast 306 data flow (or flows) that is (are) identified in the NLRI of the of 307 the S-PMSI A-D route. 309 This requires that each BFIR originate an S-PMSI A-D route for each 310 C-flow for which it serves as BFIR. The BFIR MAY include, in each 311 such route, a PTA as described in Section 2. However, if the BFIR 312 has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route 313 that "matches" (according to the rules of [RFC6625]) a particular 314 C-flow, then it may do explicit tracking for that C-flow by 315 originating an S-PMSI A-D route for that C-flow, but including a PTA 316 that specifies "no tunnel type". 318 3.2. Using the LIR-pF Flag 320 If segmented P-tunnels are not being used, the BFIR can determine the 321 set of BFERs to which a given MVPN data packet needs to be delivered 322 by originating a (C-*,C-*) S-PMSI A-D route, and by setting the LIR- 323 pF flag in the PTA of that route. Per [EXPLICIT_TRACKING], each BFER 324 will respond with one or more Leaf A-D routes, identifying the flows 325 that it is expecting to receive from the BFIR that originated the 326 (C-*,C-*) S-PMSI A-D route. 328 A BFIR MUST NOT use this method of finding the set of BFERs needing 329 to receive a given C-flow unless it knows that all those BFERs 330 support the LIR-pF flag. How this is known is outside the scope of 331 this document. 333 This option greatly reduces the number of S-PMSI A-D routes that a 334 BFIR needs to originate; it now needs to originate only one such 335 route, rather than one for each C-flow. However, it does not provide 336 a way for the BFIR to assign a distinct label to each C-flow. 337 Therefore it cannot be used when segmented P-tunnels are in use (see 338 Section 4 for an explanation). 340 4. Data Plane 342 The MVPN application plays the role of the "multicast flow layer" as 343 described in [BIER_ARCH]. 345 4.1. Encapsulation and Transmission 347 To transmit an MVPN data packet, an ingress PE follows the rules of 348 [RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a 349 "match for transmission" for that packet. (In applying the rules of 350 [RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel 351 information" is ignored.) If the matching route has a PTA specifying 352 a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed 353 on the packet's label stack. Then the packet is encapsulated in a 354 BIER header and forwarded, according to the procedures of [BIER_ARCH] 355 and [BIER_ENCAPS]. (See especially Section 4, "Imposing and 356 Processing the BIER Encapsulation", of [BIER_ENCAPS].) 358 In order to create the proper BIER header for a given packet, the 359 BFIR must know all the BFERs that need to receive that packet. It 360 determines this by finding all the Leaf A-D routes that correspond to 361 the S-PMSI A-D route that is the packet's match for transmission. 362 There are two different cases to consider: 364 1. The S-PMSI A-D route that is the match for transmission carries a 365 PTA that has the LIR flag set but does not have the LIR-pF flag 366 set. 368 In this case, the corresponding Leaf A-D routes are those whose 369 "route key" field is identical to the NLRI of the S-PMSI A-D 370 route. 372 2. The S-PMSI A-D route that is the match for transmission carries a 373 PTA that has the LIR-pF flag. 375 In this case, the corresponding Leaf A-D routes are those whose 376 "route key" field is derived from the NLRI of the S-PMSI A-D 377 route according to the procedures described in Section 5.2 of 378 [EXPLICIT_TRACKING]. 380 4.2. Disposition 382 The procedures for handling a received BIER packet at BFER depend on 383 whether the BFER is an egress PE for the packet. A BFER can tell 384 whether it is an egress PE for a given BIER packet by examining the 385 MPLS label that the packet is carrying immediately after the BIER 386 header. This will be an upstream-assigned label (from the BFIR) that 387 has been advertised in the PTA of an S-PMSI A-D route. 389 Note that if segmented P-tunnels are in use, a BFER might be a 390 P-tunnel segmentation border router rather than an egress PE, or a 391 BFER might be both an egress PE and a P-tunnel segmentation border 392 router. 394 Depending upon the role of the BFER for given packet, it may need to 395 follow the procedures of Section 4.2.1, the procedures of 396 Section 4.2.2, or both. 398 4.2.1. At a BFER that is an Egress PE 400 When a BFER receives an MVPN multicast data packet that has been 401 BIER-encapsulated, it determines from the MPLS label at the top of 402 the packet's label stack whether it is an egress PE for the packet or 403 not. If it is an egress PE, the BIER layer passes the following 404 information to the multicast flow layer: 406 o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in 407 the BIER header. 409 o The "payload", which is an MPLS packet whose top label is an 410 upstream-assigned label. The BFR-prefix provides the "context" in 411 which the upstream-assigned label is interpreted. 413 Note that per [RFC5331], the context for an upstream-assigned 414 label is the IP address of the label assigner, which in this case 415 is the BFR-prefix of the BFIR. 417 4.2.2. At a BFER that is a P-tunnel Segmentation Boundary 419 When segmented P-tunnels are being used, a BFER that receives a BIER- 420 encapsulated MVPN multicast data packet may need to be forwarded on 421 its next P-tunnel segment. The choice of the next P-tunnel segment 422 for the packet depends upon the C-flow to which the packet belongs. 423 Since the BFIR assigns a distinct upstream-assigned MPLS label for 424 each C-flow, the BFER can select the proper "next P-tunnel segment" 425 for a given packet simply by looking up the upstream-assigned label 426 that immediately follows the BIER header. (If the BFIR had not 427 assigned a distinct label to each C-flow, the BFER would need to 428 maintain all the state from the Multicast Flow Overlay in order to 429 select the next P-tunnel segment.) 431 5. Contributor Addresses 433 Below is a list of other contributing authors in alphabetical order: 435 IJsbrand Wijnands 436 Cisco Systems, Inc. 437 De Kleetlaan 6a 438 Diegem 1831 439 Belgium 441 Email: ice@cisco.com 443 6. Acknowledgments 445 The authors wish to thank Jeffrey Zhang for his ideas and 446 contributions to this work. 448 7. IANA Considerations 450 IANA is requested to assign a value for "BIER" from the "P-Multicast 451 Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The 452 reference should be this document. 454 8. Security Considerations 456 The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513] 457 and [RFC6514] are applicable. 459 9. References 461 9.1. Normative References 463 [BIER_ARCH] 464 Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T., 465 and S. Aldrin, "Multicast using Bit Index Explicit 466 Replication", internet-draft draft-ietf-bier-architecture- 467 02, July 2015. 469 [BIER_ENCAPS] 470 Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and 471 S. Aldrin, "Encapsulation for Bit Index Explicit 472 Replication in MPLS Networks", internet-draft draft-ietf- 473 bier-mpls-encapsulation-02.txt, August 2015. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 481 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 482 2006, . 484 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 485 Label Assignment and Context-Specific Label Space", 486 RFC 5331, DOI 10.17487/RFC5331, August 2008, 487 . 489 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 490 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 491 2012, . 493 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 494 Encodings and Procedures for Multicast in MPLS/BGP IP 495 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 496 . 498 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 499 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 500 RFC 6625, DOI 10.17487/RFC6625, May 2012, 501 . 503 9.2. Informative References 505 [EXPLICIT_TRACKING] 506 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 507 "Explicit Tracking with Wild Card Routes in Multicast 508 VPN", internet-draft draft-ietf-bess-mvpn-expl-track-01, 509 August 2015. 511 [EXTRANET] 512 Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. 513 Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet- 514 draft draft-ietf-bess-mvpn-extranet-05, December 2015. 516 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 517 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 518 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 519 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 520 . 522 Authors' Addresses 524 Eric C. Rosen (editor) 525 Juniper Networks, Inc. 526 10 Technology Park Drive 527 Westford, Massachusetts 01886 528 United States 530 Email: erosen@juniper.net 532 Mahesh Sivakumar 533 Cisco Systems, Inc. 534 510 McCarthy Blvd 535 Milpitas, California 95035 536 United States 538 Email: masivaku@cisco.com 540 Sam K Aldrin 541 Google, Inc. 542 1600 Amphitheatre Parkway 543 Mountain View, California 544 United States 546 Email: aldrin.ietf@gmail.com 548 Andrew Dolganow 549 Alcatel-Lucent 550 600 March Rd. 551 Ottawa, Ontario K2K 2E6 552 Canada 554 Email: andrew.dolganow@alcatel-lucent.com 556 Tony Przygienda 557 Ericsson 558 300 Holger Way 559 San Jose, California 95134 560 United States 562 Email: antoni.przygienda@ericsson.com