idnits 2.17.1 draft-brevigcia-ccamp-mpls-upstream-node-cap-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 350. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 363. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([TE-NODE-CAP], [MPLS-UPSTREAM]), 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 (November 19, 2007) is 5974 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) == Missing Reference: 'RFC3031' is mentioned on line 79, but not defined == Missing Reference: 'RFC3209' is mentioned on line 79, but not defined == Missing Reference: 'RFC4461' is mentioned on line 80, but not defined == Missing Reference: 'RFC2119' is mentioned on line 85, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-03 == Outdated reference: A later version (-02) exists of draft-ietf-mpls-p2mp-te-bypass-01 -- Possible downref: Normative reference to a draft: ref. 'P2MP-FRR' == Outdated reference: A later version (-05) exists of draft-ietf-mpls-rsvp-upstream-02 -- Possible downref: Normative reference to a draft: ref. 'RSVP-UPSTREAM' Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Brehon 3 Internet-Draft M. Vigoureux 4 Intended status: Standards Track L. Ciavaglia 5 Expires: May 22, 2008 Alcatel-Lucent 6 M. Chaitou 7 France Telecom 8 Z. Ali 9 Cisco Systems, Inc. 10 November 19, 2007 12 IGP Routing Protocol Extensions for Discovery of Upstream Label 13 Assignment Node Capability 14 draft-brevigcia-ccamp-mpls-upstream-node-cap-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 22, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 This document proposes an extension to [TE-NODE-CAP] in order to 48 support additional TE node capabilities in the context of Point-to- 49 MultiPoint (P2MP) LSP routing and fast reroute protection. As for 50 point-to-point LSP, nesting P2MP LSPs, i.e., MPLS P2MP hierarchy, is 51 a desirable traffic-engineering feature. However, nesting P2MP LSPs 52 requires a mechanism to coordinate the label allocation of the inner 53 P2MP LSP between the egress nodes of the P2MP Tunnel as described in 54 [MPLS-UPSTREAM]. To solve this issue, a new label allocation scheme 55 called Upstream Label Assignment (ULA) is defined. Network elements 56 responsible for the route computation of P2MP LSP should be aware of 57 the nodes that support this functionality. For that purpose, we 58 define a new bit flag to the TE Node Capability Descriptor as defined 59 in [TE-NODE-CAP]. The bit flag (U) enables a node to advertise its 60 capability to accept Upstream Label Assignment. 62 Table of Contents 64 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Advantages of the solution . . . . . . . . . . . . . . . . . . 7 67 4. New value to the TE Node Capability Descriptor . . . . . . . . 9 68 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 10 69 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 72 8.1. Capability Registry . . . . . . . . . . . . . . . . . . . 13 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . . . . 16 77 1. Terminology 79 This document uses terminologies defined in [RFC3031], [RFC3209] and 80 [RFC4461]. 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Introduction 88 This document proposes an extension to [TE-NODE-CAP] in order to 89 support additional TE node capabilities in the context of Point-to- 90 MultiPoint (P2MP) LSP routing and Fast ReRoute protection. As for 91 point-to-point LSP, nesting P2MP LSPs, i.e., MPLS P2MP hierarchy, is 92 a desirable traffic-engineering feature. P2MP Fast ReRoute (FRR) 93 [P2MP-FRR] is a typical application of P2MP LSPs nesting that is 94 likely to be deployed in MPLS-TE networks transporting multicast 95 traffic. 97 However, nesting P2MP LSPs requires a mechanism to coordinate the 98 label allocation of the inner P2MP LSP between the egress nodes of 99 the P2MP Tunnel as described in [MPLS-UPSTREAM]. To solve this 100 issue, a new label allocation scheme called Upstream Label Assignment 101 (ULA) is defined where the ingress node of the P2MP Tunnel allocates 102 a single label to the egress nodes of the P2MP Tunnel for the nested 103 P2MP LSP. Use of this technique raises an additional issue: as the 104 upstream neighbor now assigns the label, two different upstream nodes 105 may allocate the same label value to the same receiver(s) for two 106 different P2MP LSPs nested in different P2MP Tunnels. The egress 107 nodes cannot anymore distinguish the LSPs based on the incoming label 108 value. To overcome this issue, [MPLS-UPSTREAM] defines a Context- 109 specific Label Space (CLS). The egress node must now disambiguate 110 the label of the inner LSP by defining a per-upstream-neighbour label 111 space. As defined in [MPLS-UPSTREAM], downstream LSRs maintain 112 separate label space for each unique root (a P2MP Tunnel head-end) 113 and MUST be able to determine the root of the P2MP Tunnels. The root 114 is identified by the head-end IP address of the Tunnel. If the same 115 upstream node uses different head-end IP addresses for different 116 tunnels then the downstream nodes MUST maintain a different Upstream 117 Neighbor Label Space for each such head-end IP address. 119 [RSVP-UPSTREAM] defines extensions to [RFC4875] to support the 120 advertisement of the ULA capability between adjacent nodes - i.e., 121 between nodes which have a signaling adjacency. Unfortunately, when 122 nesting P2MP LSPs in P2MP Tunnels, the ingress nodes and the egress 123 nodes usually do not have such a signaling adjacency. Nevertheless, 124 the knowledge of this capability is crucial when calculating the 125 routes of nested P2MP LSPs over P2MP tunnels (either by the ingress 126 node or by a Path Computation Element, PCE). If the ingress of the 127 (nested) P2MP LSP or the PCE does not have a control adjacency with 128 the egress nodes of the P2MP Tunnel, LSP setup will be tried and will 129 fail if at least one egress node does not support the ULA capability. 130 This is a trial-and-error approach, which can reveal inefficient and 131 time and resource consuming. 133 The idea is thus to extend the MPLS/GMPLS routing protocols (OSPF-TE 134 and IS-IS-TE) to allow LSRs to inform all nodes within a network 135 domain of a node's capability to receive upstream-assigned labels and 136 process them accordingly. Using the routing protocol guarantees this 137 information will be distributed to all nodes, which should perform 138 route calculations, independently of the signaling protocol used for 139 establishing the LSPs (e.g. RSVP-TE). 141 For that purpose, this document defines a new bit flag to the TE Node 142 Capability Descriptor as defined in [TE-NODE-CAP]. The bit flag (U) 143 enables a node to advertise its capability to accept Upstream Label 144 Assignment. 146 3. Advantages of the solution 148 The advertisement of the ULA capability across the network brings 149 additional Traffic Engineering possibilities to better manage P2MP TE 150 LSPs. 152 A first advantage of the proposed solution concerns P2MP TE path 153 computation. When transporting multicast traffic over their MPLS 154 networks, service providers and operators will often establish P2MP 155 TE Tunnels and nest the client P2MP LSPs into them in order to keep 156 control of the planning and resource allocation in their networks. 158 As described briefly above, remote nodes at the endpoints of tunnels 159 do not usually establish signaling adjacency because this would 160 result in a fully connected graph where each node would have a 161 control adjacency with all other nodes in the network. Similarly, if 162 the network operator uses a PCE to calculate P2MP TE paths, the 163 knowledge of the ULA capability cannot be advertised by the signaling 164 protocols. Therefore, in order to avoid these blocking situations 165 and to allow remote nodes to efficiently calculate TE P2MP paths with 166 all the relevant information, disseminating the node capability to 167 accept upstream-assigned labels through IGP routing protocols appears 168 as a desirable feature and seems a scalable and efficient approach. 170 Moreover, if an operator wishes to setup P2MP tunnels to transport 171 P2MP LSPs, the egress nodes of the P2MP tunnel will have to support 172 ULA. Therefore, it is pointless to setup a P2MP tunnel to only 173 afterwards fail in all nested P2MP LSP establishments; it is much 174 more efficient to have the relevant information for the P2MP tunnel 175 setup right from the start. 177 A second advantage of the proposed solution concerns P2MP fast 178 reroute protection. As described in [P2MP-FRR], in the P2MP Facility 179 Backup method, a P2MP Bypass Tunnel can be used to protect a set of 180 P2MP TE LSPs. During failure, the same backup label MUST be used for 181 all S2L sub-LSPs of a given backup P2MP LSP, tunneled within the same 182 P2MP Bypass Tunnel to avoid data replication and traffic mis-routing 183 in the Merge Points (MP). The Point of Local Repair (PLR) assigns 184 the same label to all the Merge Points (MP) using the Upstream Label 185 Assignment procedure. 187 The backup P2MP LSPs and the P2MP Bypass tunnel have to be 188 established prior to the failure and to work properly, the mechanism 189 needs to know the capability of the remote nodes to accept upstream- 190 assigned labels. If some egress nodes do not support ULA, then the 191 PLR will establish dedicated P2P Tunnels towards them. 193 In P2MP FRR protection, the knowledge of the ULA capability is vital 194 and particularly important in order to limit the number of trials 195 before the appropriate backup LSP(s) are found and established. 197 Globally, the proposed solution to transport the ULA capability bit 198 in IGP routing protocols enables: 200 o a scalable dissemination of the P2MP node capabilities, 202 o a workable fast reroute protection mechanism, 204 o a higher reliability/robustness of the signaling phase. 206 4. New value to the TE Node Capability Descriptor 208 The TE Node Capability Descriptor contains a variable length set of 209 bit flags, where each bit corresponds to a given TE node capability. 211 Currently, five TE Node Capabilities are defined in [TE-NODE-CAP]. 212 This document defines a new TE Node Capability: 214 - U bit: when set, this flag indicates that the LSR accepts Upstream 215 Label Assignment ([RSVP-UPSTREAM]); 217 The following bit is added to the OSPF TE Node Capability Descriptor 218 TLV: 220 Bit Capabilities 221 5 U bit: If set this indicates that the LSR accepts 222 Upstream Label Assignment ([RSVP-UPSTREAM]). 224 The following bit is added to IS-IS TE Node Capability Descriptor 225 sub-TLV: 227 Bit Capabilities 228 5 U bit: If set this indicates that the LSR accepts 229 Upstream Label Assignment ([RSVP-UPSTREAM]). 231 5. Elements of procedure 233 *** no new element introduced by this draft *** 235 6. Backward Compatibility 237 *** no new element introduced by this draft *** 239 7. Security Considerations 241 *** no new element introduced by this draft *** 243 8. IANA considerations 245 8.1. Capability Registry 247 [OSPF-CAP] defines a new code point registry for TLVs carried in the 248 Router Information LSA defined in [OSPF-CAP]. 250 IANA is requested to make assignments for the TE node capability 251 defined in this document (see Section 4) using the following 252 suggested values, in the Link State Routing TE Capabilities registry: 254 Bit No. Name Reference 255 ------+-----------------------------------------------------+---------- 256 5 U bit: Upstream Label Assignment capability [This.I-D] 258 9. References 260 [TE-NODE-CAP] J.P. Vasseur, J.L. Le Roux et al., "IGP Routing 261 Protocol Extensions for Discovery of Traffic Engineering Node 262 Capabilities", draft-ietf-ccamp-te-node-cap-05, work in progress. 264 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 265 Label Assignment and Context Specific Label Space", 266 draft-ietf-mpls-upstream-label-03, work in progress. 268 [P2MP-FRR] J. L. Le Roux, R. Aggarwal, J.P. Vasseur, M. Vigoureux, 269 "P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels", 270 draft-ietf-mpls-p2mp-te-bypass-01, work in progress. 272 [RSVP-UPSTREAM] R. Aggarwal, J. L. Le Roux, "MPLS Upstream Label 273 Assignment for RSVP-TE", draft-ietf-mpls-rsvp-upstream-02, work in 274 progress. 276 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al. 277 "Extensions to RSVP-TE for point-to-multipoint TE LSPs", RFC 4875. 279 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 280 J.P., "Extensions to OSPF for advertising Optional Router 281 Capabilities", draft-ietf-ospf-cap, work in progress. 283 Authors' Addresses 285 Yannick Brehon 286 Alcatel-Lucent 287 Route de Villejust 288 Nozay 91620 289 France 291 Email: Yannick.Brehon@alcatel-lucent.fr 293 Martin Vigoureux 294 Alcatel-Lucent 295 Route de Villejust 296 Nozay 91620 297 France 299 Email: Martin.Vigoureux@alcatel-lucent.fr 301 Laurent Ciavaglia 302 Alcatel-Lucent 303 Route de Villejust 304 Nozay 91620 305 France 307 Email: Laurent.ciavaglia@alcatel-lucent.fr 309 Mohamad Chaitou 310 France Telecom 311 2, avenue Pierre-Marzin 312 Lannion 22307 313 France 315 Email: Mohamad.Chaitou@orange-ftgroup.com 317 Zafar Ali 318 Cisco Systems, Inc. 319 100 South Main St. #200 320 Ann Arbor MI 48104 321 USA 323 Email: zali@cisco.com 325 Full Copyright Statement 327 Copyright (C) The IETF Trust (2007). 329 This document is subject to the rights, licenses and restrictions 330 contained in BCP 78, and except as set forth therein, the authors 331 retain all their rights. 333 This document and the information contained herein are provided on an 334 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 335 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 336 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 337 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 338 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 339 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 341 Intellectual Property 343 The IETF takes no position regarding the validity or scope of any 344 Intellectual Property Rights or other rights that might be claimed to 345 pertain to the implementation or use of the technology described in 346 this document or the extent to which any license under such rights 347 might or might not be available; nor does it represent that it has 348 made any independent effort to identify any such rights. Information 349 on the procedures with respect to rights in RFC documents can be 350 found in BCP 78 and BCP 79. 352 Copies of IPR disclosures made to the IETF Secretariat and any 353 assurances of licenses to be made available, or the result of an 354 attempt made to obtain a general license or permission for the use of 355 such proprietary rights by implementers or users of this 356 specification can be obtained from the IETF on-line IPR repository at 357 http://www.ietf.org/ipr. 359 The IETF invites any interested party to bring to its attention any 360 copyrights, patents or patent applications, or other proprietary 361 rights that may cover technology that may be required to implement 362 this standard. Please address the information to the IETF at 363 ietf-ipr@ietf.org. 365 Acknowledgment 367 Funding for the RFC Editor function is provided by the IETF 368 Administrative Support Activity (IASA).