idnits 2.17.1 draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 374. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4726], [RFC4875]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 07, 2008) is 5765 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) ** Downref: Normative reference to an Informational RFC: RFC 4726 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group Z. Ali 3 Internet Draft Cisco Systems, Inc. 4 Intended status: Standard Track July 07, 2008 5 Expires: January 06, 2008 7 Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment 8 draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that 13 any applicable patent or other IPR claims of which he or she is 14 aware have been or will be disclosed, and any of which he or she 15 becomes aware will be disclosed, in accordance with Section 6 of 16 BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on January 06, 2009. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 Point-to-MultiPoint (P2MP) Multiprotocol Label Switching 44 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label 45 Switched Paths (TE LSPs) may be established using signaling 46 techniques described in [RFC4875]. However, [RFC4875] does not 47 address many issues that comes when a P2MP-TE LSP is signaled in 48 a multi-domain networks. Specifically, one of the issues in 49 multi-domain networks is how to allow computation of a loosely 50 routed P2MP-TE LSP such that it is remerge free. This document 51 provides a framework and required protocol extensions needed for 52 establishing and controlling P2MP MPLS and GMPLS TE LSPs in 53 multi-domain networks. 55 This document borrows inter-domain TE terminology from 56 [RFC4726], e.g., for the purposes of this document, a domain is 57 considered to be any collection of network elements within a 58 common sphere of address management or path computational 59 responsibility. Examples of such domains include Interior 60 Gateway Protocol (IGP) areas and Autonomous Systems (ASes). 62 Conventions used in this document 64 In examples, "C:" and "S:" indicate lines sent by the client and 65 server respectively. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 68 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 69 "OPTIONAL" in this document are to be interpreted as described in 70 RFC-2119. 72 Table of Contents 74 1. Introduction...............................................2 75 2. Framework..................................................4 76 3. RSVP-TE signaling extensions...............................4 77 3.1. Multiple S2L Sub-LSPs in One Path Message.............4 78 3.2. Single S2L Sub-LSPs in One Path Message...............4 79 3.3. Grafting..............................................7 80 3.4. Reoptimization........................................7 81 4. Security Considerations....................................7 82 5. IANA Considerations........................................7 83 6. References.................................................7 84 6.1. Normative References..................................7 85 6.2. Informative References................................8 86 Author's Addresses............................................8 87 Intellectual Property Statement...............................8 88 Disclaimer of Validity........................................8 90 1. Introduction 92 [RFC4875] describes how to set up point-to-multipoint (P2MP) 93 Traffic Engineering Label Switched Paths (TE LSPs) for use in 94 MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 95 networks. 97 As with all other RSVP controlled LSPs, P2MP LSP state is 98 managed using RSVP messages. While the use of RSVP messages is 99 mostly similar to their P2P counterpart, P2MP LSP state differs 100 from P2P LSP in a number of ways. E.g., the P2MP LSP must also 101 handle the state "re-merge" problem, see [RFC4875]. The term "re- 102 merge" refers to the case of an ingress or transit node that 103 creates a branch of a P2MP LSP, a re-merge branch that intersects 104 the P2MP LSP at another node farther down the tree. This may 105 occur due to such events as an error in path calculation, an 106 error in manual configuration, or network topology changes during 107 the establishment of the P2MP LSP. Consequently one of the 108 requirements for signaling P2MP LSP is for the Ingress node to 109 compute a P2MP path that is re-merge free. In some deployments, 110 it may also be requires to signal P2MP LSPs that are both remerge 111 and crossover free [RFC4875]. 113 This requirement becomes more acute to address when P2MP LSP 114 spans multiple domains. For the purposes of this document, a 115 domain is considered to be any collection of network elements 116 within a common sphere of address management or path 117 computational responsibility. Examples of such domains include 118 Interior Gateway Protocol (IGP) areas and Autonomous Systems 119 (ASes). This is because in an inter-domain environment, the 120 ingress node may not have topological visibility into other 121 domains to be able to compute and signal a re-merge free P2MP 122 LSP. In an inter-domain environment, signaling for a given 123 (Source-to-Leaf) S2L or a set of S2Ls may contain MPLS Traffic 124 Engineering loosely routed explicit LSPs. A loosely routed 125 explicit LSP path is a path specified as a combination of strict 126 and loose hop(s) that contains at least one loose hop and zero or 127 more strict hop(s). When a border node is presented with a loose 128 ERO (for a given S2L or a subset of S2Ls), it may not have full 129 visibility on the P2MP LSP destinations to be able to expend the 130 ERO such that overall P2MP LSP is remerge free. The issue becomes 131 even more acute when one path message per S2L is used. 133 The document propose a simple extension to allow border nodes 134 with just enough information about the P2MP LSP so that they can 135 expand EROs for individual S2Ls such that overall P2MP LSP is 136 remerge free. Specifically, this document proposes a notion of 137 passing a list of addresses to a border node, for all S2Ls of a 138 P2MP LSP that transits from that border node. This list of 139 addresses contains addresses for which the given border node 140 needs to expend the EROs to, for all S2L of the P2MP LSP that 141 transit through the border router. The knowledge of other IP 142 addresses w.r.t. which the route has to be re-merge free allows 143 for the border node to expend route for a given P2MP LSP in a re- 144 merge free manner. This also allows a border node to find an 145 overall better P2MP path for the LSP. However, two independent 146 border routers may still expend routes for a given P2MP LSP that 147 may result in a re-merge. This is because a border router is only 148 given information about the s2l of the P2MP LSP that transit 149 through it, and not the information about P2MP routes that are 150 expend by the other border nodes. Passing around the information 151 about route expended by the other border routers requires much 152 more complex signaling mechanism. On the other hand, passing 153 along addresses for which the given border node needs to expend 154 the EROs to, for all S2L of the P2MP LSP that transit through the 155 border router is petty easy and straight forward (as can be seen 156 from the following section). Furthermore, it covers most of the 157 remerge issue associated with signaling P2MP LSPs in a multi- 158 domain environment. Furthermore, the solution also does not 159 guarantee w.r.t. optimization of the overall P2MP tree. PCE 160 should be used, instead, to address optimization of the overall 161 P2MP tree [PCE-P2MP]. 163 2. Framework 165 TBA 167 3. RSVP-TE signaling extensions 169 This section describes the signaling extensions required to 170 address the above-mentioned functionality. 172 3.1. Multiple S2L Sub-LSPs in One Path Message 174 When multiple S2Ls are carried in the single Path messages it is 175 RECOMMENDED that P2MP LSP is partitioned in such a way that the 176 Path message to a border node, where ERO expansion is desired, 177 contains all S2Ls of the P2MP LSP that transit through that 178 border router. This enabled border node to get the information 179 about all nodes this border node needs to expend EROs to. Hence, 180 the border node to expend all routes in a re-merged free and a 181 more cost effective manner without any protocol expansion. 183 When multiple S2Ls are carried in the single Path messages but 184 the above mentioned criteria cannot be or is not satisfied, is to 185 be addressed in a later version of the document. 187 3.2. Single S2L Sub-LSPs in One Path Message 189 When a Path message contains only one S2L sub-LSP, the following 190 extension MAY be followed to achieve ERO expansion in a remerge 191 free and a more cost effective manner. As specified in [RFC3209], 192 loose hops are listed in the ERO object of the RSVP Path message 193 with the L flag of the IPv4 or the IPv6 prefix sub-object set. 194 When ERO in the Path message of a P2MP LSP contains a loose hop, 195 the Path message MAY (optionally) contain a "Related Addresses 196 for Sibling S2L sub-LSP" object for each loose hop specified in 197 the ERO. 198 Class = TBA, C_Type = TBA 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type | Length | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | IPv4 address of the border node | 206 | IPv4 address from related sibling S2L sub-LSP 1 | 207 | IPv4 address from related sibling S2L sub-LSP 2 | 208 | IPv4 address from related sibling S2L sub-LSP 1 | 209 // // 210 | IPv4 address from related sibling S2L sub-LSP last | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Type 215 0x01 IPv4 address 217 Length 219 The Length contains the total length of the object in bytes, 220 including the Type and Length fields. The Length is variable 221 depending on the addresses in the list. 223 IPv4 address of the border node 225 IPv4 address of the target border node, where ERO extension 226 for this and related S2L sub-LSPs of the P2MP LSP is desired. 227 This address MUST match with on of the IPv4 addresses contained 228 in the ERO with L flag. 230 IPv4 address from related sibling S2L sub-LSP x 232 IPv4 address of a node on another sibling S2L sub-LSP x, which 233 is signaled in a separate Path message but which also require ERO 234 extension at the border node contained in IPv4 address of the 235 border node field. Together this list contains all addresses on a 236 given P2MP LSP to which the border node needs to expend the EROs. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length | Reserved | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | IPv6 address of the border node | 244 | | 245 | | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | IPv6 address from related sibling S2L sub-LSP 1 | 249 | | 250 | | 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | IPv6 address from related sibling S2L sub-LSP 2 | 254 | | 255 | | 256 | | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | IPv6 address from related sibling S2L sub-LSP 1 | 259 | | 260 | | 261 | | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 // // 264 | IPv6 address from related sibling S2L sub-LSP last | 265 | | 266 | | 267 | | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Type 272 0x02 IPv6 address 274 Length 276 The Length contains the total length of the object in bytes, 277 including the Type and Length fields. The Length is variable 278 depending on the addresses in the list. 280 IPv6 address of the border node 282 IPv6 address of the target border node, where ERO extension 283 for this and related S2L sub-LSPs of the P2MP LSP is desired. 284 This address MUST match with on of the IPv6 addresses contained 285 in the ERO with L flag. 287 IPv6 address from related sibling S2L sub-LSP x 288 IPv6 address of a node on another sibling S2L sub-LSP x, which 289 is signaled in a separate Path message but which also require ERO 290 extension at the border node contained in IPv6 address of the 291 border node field. Together this list contains all addresses on a 292 given P2MP LSP to which the border node needs to expend the EROs. 294 3.3. Grafting 296 Grafting for an S2L sub-LSP achieved by the Ingress node 297 signaling it with the same P2MP ID and LSP ID, via existing or 298 new border nodes with loose hop expansion. If an existing border 299 node is used along the path, the border node locally finds how 300 ERO expansions for other siblings of the P2MP LSP transiting 301 through this border node is done and expends the route of new S2L 302 such that it's remerge free. 304 3.4. Reoptimization 306 TBA 308 4. Security Considerations 310 Security considerations and requirements from [RFC3209] and 311 [RFC4875] apply equally to this document. Furthermore, there are 312 some additional security considerations that may be induced by 313 the use of "Related Addresses for Sibling S2L sub-LSP" object 314 defined in this document. These security considerations will be 315 added in a later version of the draft. 317 5. IANA Considerations 319 Code points for "Related Addresses for Sibling S2L sub-LSP" 320 object defined in this document will be required. Much of the 321 details here are TBA. 323 6. References 325 6.1. Normative References 327 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, 328 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 329 Tunnels", RFC 3209, December 2001. 331 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al, 332 "Extensions to RSVP-TE for Point-to-Multipoint TE 333 LSPs", RFC4875. 335 [RFC4726] A. Farrel, J.-P. Vasseur, A. Ayyangar, "A Framework for 336 Inter-Domain Multiprotocol Label Switching Traffic 337 Engineering", RFC 4726, November 2006. 339 6.2. Informative References 341 [PCE-P2MP] Quintin Zhao, et al, "Extensions to the Path 342 Computation Element Communication Protocol (PCEP) for Point-to- 343 Multipoint Traffic Engineering Label Switched Paths", draft-zhao- 344 pcep-p2mp-extension-00.txt, work in progress. 346 Author's Addresses 348 Zafar Ali 349 Cisco Systems, Inc. 350 Email: zali@cisco.com 352 Intellectual Property Statement 354 The IETF takes no position regarding the validity or scope of any 355 Intellectual Property Rights or other rights that might be 356 claimed to pertain to the implementation or use of the technology 357 described in this document or the extent to which any license 358 under such rights might or might not be available; nor does it 359 represent that it has made any independent effort to identify any 360 such rights. Information on the procedures with respect to 361 rights in RFC documents can be found in BCP 78 and BCP 79. 363 Copies of IPR disclosures made to the IETF Secretariat and any 364 assurances of licenses to be made available, or the result of an 365 attempt made to obtain a general license or permission for the 366 use of such proprietary rights by implementers or users of this 367 specification can be obtained from the IETF on-line IPR 368 repository at http://www.ietf.org/ipr. 370 The IETF invites any interested party to bring to its attention 371 any copyrights, patents or patent applications, or other 372 proprietary rights that may cover technology that may be required 373 to implement this standard. Please address the information to 374 the IETF at ietf-ipr@ietf.org. 376 Disclaimer of Validity 378 This document and the information contained herein are provided 379 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 380 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 381 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 382 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 383 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 384 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 385 FITNESS FOR A PARTICULAR PURPOSE. 387 Copyright Statement 389 Copyright (C) The IETF Trust (2008). 391 This document is subject to the rights, licenses and restrictions 392 contained in BCP 78, and except as set forth therein, the authors 393 retain all their rights.