idnits 2.17.1 draft-vandenbosch-mpls-fa-considerations-01.txt: -(111): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(143): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(144): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(194): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing revision: the document name given in the document, 'draft-vandenbosch-mpls-fa-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-vandenbosch-mpls-fa-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-vandenbosch-mpls-fa-', but the file name used is 'draft-vandenbosch-mpls-fa-considerations-01' == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 236 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [R1], [R2], [R3], [R4], [R5], [R6], [R7], [R8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 163 has weird spacing: '...V. This infor...' == Line 293 has weird spacing: '... during the...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Exclude-All, represents a set of resource classes, all of which, the links in the path taken by the FA-LSP MUST not contain. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (July 2002) is 7956 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 section? '1' on line 15 looks like a reference -- Missing reference section? '2' on line 269 looks like a reference -- Missing reference section? '3' on line 52 looks like a reference -- Missing reference section? '4' on line 203 looks like a reference -- Missing reference section? '5' on line 219 looks like a reference -- Missing reference section? '6' on line 298 looks like a reference Summary: 8 errors (**), 1 flaw (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group 2 Internet Draft S. Van den Bosch 3 D. Papadimitriou 4 Document: draft-vandenbosch-mpls-fa- Alcatel 5 considerations-01.txt 6 Expires: January 2003 July 2002 8 Further considerations for Forwarding Adjacency LSPs 9 draft-vandenbosch-mpls-fa-considerations-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC 2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 Forwarding adjacencies (FA) as described in [2] are a useful tool 34 for improving the scalability of Generalized MPLS (GMPLS) Traffic 35 Engineering (TE). Through the aggregation of TE LSPs this concept 36 enables the creation of a TE-LSP Hierarchy. Forwarding adjacency 37 LSPs (FA-LSP or simply FA) may be advertised as TE link into the 38 same instance of ISIS/OSPF as the one that was used to create the 39 LSP, allowing other LSRs to use FAs as TE-links for their path 40 computation. As such, forwarding adjacency LSP have characteristics 41 of both links and LSPs. 43 This document list a number of topics for further study regarding 44 forwarding adjacencies in an attempt to identify what future work 45 may result in the MPLS WG (or other) from the link/LSP duality. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 51 this document are to be interpreted as described in RFC 2119 [3]. 53 Table of Contents 55 Status of this Memo................................................1 56 Abstract...........................................................1 57 Conventions used in this document..................................1 58 1. Introduction....................................................2 59 2. Topics for further study........................................3 60 2.1. Establishment and teardown of FA for PSC interfaces..........3 61 2.2. Dynamic recomputation of paths for FA-LSPs...................4 62 2.3. Protection of FA-LSPs........................................4 63 2.4. Interworking with fast reroute techniques....................4 64 2.5. Traffic engineering attributes of FA-LSPs....................5 65 3. A Step Further..................................................5 66 3.1. A new resource class sub TLV.................................6 67 4. Security Considerations.........................................7 68 References.........................................................8 69 Acknowledgments....................................................8 70 Author's Addresses.................................................8 71 Full Copyright Statement...........................................9 73 1. Introduction 75 In its successful attempt to extend MPLS for non-packet oriented TE- 76 attributes within the scope of an integrated model encompassing 77 several layers, , GMPLS has been rapidly confronted to mapping of 78 the several data plane layers within the control plane. 80 As such, and from the control plane viewpoint a transport plane 81 layer is mapped to an LSP region (see [2]). Following this approach, 82 a TE-link (at the control plane) maps exactly the definition the one 83 proposed in the canonical layered model where a link is a link 84 bundle (using the IETF terminology). The TE Link concept opens the 85 door for a clear separation between the routing adjacencies and data 86 plane bearer links. Furthermore, TE Links have been extended to non 87 adjacent devices by introducing the Forwarding Adjacency (FA) 88 concept enabling in turn to decrease the number of control plane 89 instances to control N transport layers. 91 Using the Forwarding Adjacency a node may (under its local control 92 policy configuration) advertise an LSP as a TE link into the same 93 ISIS/OSPF instance as the one that determines the path taken for 94 this LSP. Such a link is referred to as a "forwarding adjacency" 95 (FA) and the corresponding LSP to as a "forwarding adjacency LSP", 96 or simply FA-LSP. Since the advertised entity appears as a TE link 97 in ISIS/OSPF, both end-point nodes of the FA-LSP must belong to the 98 same ISIS level/OSPF area (intra-area improvement of scalability). 99 Afterwards, ISIS/OSPF floods the link-state information about FAs 100 just as it floods the information about any other TE Link. This 101 allows other nodes (belonging to the same region) to use FAs as any 102 other TE Links for path computation purposes. 104 While this definition is in perfect alignment for non-packet LSP 105 regions and boundaries, the same concept(s) can be re-used in the 106 MPLS LSP context but with a major difference. The mapping goes in 107 the opposite direction from the control to the IP/MPLS forwarding 108 plane since FA-LSP in the packet domain are purely abstract concept 109 that would if well tailored, provide additional scalability within a 110 routing plane instance (in particular, an area). Indeed, the use of 111 FA�s provides a mechanism for improving bandwidth utilization when 112 its dynamic allocation can be performed in discrete units; it also 113 enables aggregating forwarding state, and in turn, reducing 114 significantly the number of required labels. Therefore, FAs may 115 significantly improve the scalability of GMPLS TE-capable control 116 planes, and allow the creation of a TE-LSP hierarchy. 118 In this context, the present document tries to identify and briefly 119 address some of the issues for FA-LSP in a packet-switching (PSC) 120 context that could require further effort from the Sub-IP Area 121 community. 123 2. Topics for further study 125 This section list some topics, this might be extended in future 126 release of this document. 128 2.1. Establishment and teardown of FA for PSC interfaces 130 A LSR can have multiple interface Switching Capabilities (SC). This 131 aspect is of particular importance with packet switch capable (PSC) 132 interfaces that can simultaneously belong to four PSC regions. These 133 effectively constitute a logical hierarchy that can be exploited 134 through label stacking in order to provide scalable TE in large 135 single area networks. 137 However, combining such an approach with constraint-based TE-routing 138 would imply the need for dynamic modification of an interface's 139 switching capability in order to promote/demote it in the logical 140 hierarchy (corresponding to the creation/deletion of a layer in the 141 hierarchy). The other way is to advertise multiple PSC capabilities, 142 and so let the network dynamically build-up this hierarchy. In such 143 an eventuality, the increasing complexity comes up from the �dynamic 144 modification� that would arise from such policy since each Switching 145 Capability value can be assigned independently to each ingress LSR 146 (when initiating the packet LSP Path/Label Request message). 148 It is unclear if the setup of a FA-LSP should be done by 149 provisioning or whether it can be triggered by the setup of client 150 LSPs. A FA-LSP that is set up needs to be advertised with a certain 151 bandwidth and priority. If an FA-LSP triggered by other LSP setup 152 requests is allowed, this could lead to the advertisement of FA-LSPs 153 with zero available bandwidth. If several levels of such LSPs exist, 154 it is also unclear if their priorities should all be updated when a 155 new LSP arrives with a higher priority (lower priority value). 156 Finally, it is not specified what should happen with existing LSPs 157 that could potentially use the FA-LSP but were set up prior to its 158 establishment. 160 2.2. Dynamic recomputation of paths for FA-LSPs 162 The path information regarding the FA-LSP may be available to other 163 nodes by means of the PATH TLV. This information may be used by 164 other nodes for their own path computations. They could for instance 165 take it into account when computing a backup path. Then if the FA- 166 LSP changes path, primary and backup path of the client LSPs may no 167 longer be disjoint. 169 Therefore, it may be necessary to foresee the possibility to 170 restrict the re-routability of the FA-LSP and advertise this in the 171 PATH TLV. In this way, ingress LSR that use this information would 172 know whether it is subject to any change at a lower LSP region or 173 not. 175 2.3. Protection of FA-LSPs 177 Four packet interface switching capabilities (PSC-1 to PSC-4) are 178 defined (see [2]). When FA-LSPs are protected, it means that SRLG 179 information needs to propagate to the upper LSP region(s) for 180 consistency. It is not obvious how the SRLG information and 181 disjointness of FA-LSPs can be treated in an efficient way with a 182 label stack of potentially depth four (PSC-1 -4) or even more if 183 regions do not delimit LSP tunnel diameter. 185 In particular, it is not obvious to determine to which region(s) 186 this information should be made available, in absence of any 187 specific rules, one can assume for instance that only interfaces 188 belonging to the initiating region should be have this information 189 available. However, nothing precludes that other PSC regions may use 190 existing FA�s for their own purposes. 192 For instance, consider an FA-LSP established within PSC-4 region, 193 the LSR interfaces surrounding this FA belongs either to PSC-1 or �2 194 or �3 or any combination of these values. It becomes then a key 195 issue to know if an upper region LSP can be link protected by 196 component links referring to a single or multiple regions. 198 2.4. Interworking with fast reroute techniques 200 An FA-LSP is at the same time a path to the server layer and a link 201 to the client layer. In this context, link protection techniques 202 such as the ones proposed for fast local restoration may be 203 applicable [4]. 205 More specifically, one could for instance envisage the establishment 206 of FA-LSPs for the intra-area sections of a multi-area LSP. In that 207 case, fast local reroute techniques applied at the FA-LSP level 208 could provide inter-area protection of multi-area LSPs. Inter-area 209 protection would be provided by means of a backup LSP using 210 different Area Border Routers (ABRs) than the primary LSP. 212 In addition, this would require a fast failure detection and 213 notification mechanism for the FA-LSP. 215 Another interworking aspect is related to the re-routing of backup 216 LSPs with local protection techniques. This might be interesting for 217 resource sharing between backup paths or between primary and backup 218 paths. A mechanism for providing feedback about downstream detour 219 LSPs is proposed in [5] and can potentially find a use for FA-LSP as 220 well. 222 2.5. Traffic engineering attributes of FA-LSPs 224 It is not clear how the TE attributes (defined as Sub-TLVs of the 225 Opaque LSA TE-Link TLV), such as link color (aka resource class) and 226 metric, of a FA-LSP should be set. The current specification [2], 227 for instance, proposes to treat FA-LSP as uncolored links. This may 228 create ambiguity with local policy decisions. It may also hinder the 229 efficient establishment of LSPs with resource requirements over FA- 230 LSPs. 232 In general, we want the following functionality to be available: 234 Include-Any: represents a set of resource classes, at least one 235 of which, the links in the path taken by the FA-LSP MUST contain. 237 Include-All: represents a set of resource classes, all of which, 238 the links in the path taken by the FA-LSP MUST contain. 240 Exclude-All, represents a set of resource classes, all of which, 241 the links in the path taken by the FA-LSP MUST not contain. 243 Note: Include-Any can be rephrased as Exclude-All with appropriate 244 changes to the list of resource classes. Hence, we need a solution 245 for Exclude-Any and Include-All. 247 Moreover, since the maximum reservable bandwidth can be larger than 248 the real Maximum LSP bandwidth for each region to which the 249 interface belongs, the per-region allocation of the over- 250 provisioning capacity is unknown making over-provisioning (by 251 default) a cross-region process. As such one can assume that this 252 capacity can be shared by all PSC regions. 254 Note: the bandwidth of the FA-LSP must be at least as big as the LSP 255 that induced it, but may be bigger if only discrete bandwidths are 256 available for the FA-LSP. 258 3. A Step Further 260 As a matter of fact, the FA concept is more than mature to achieve a 261 first set of features, we propose here to enlarge the scope to 262 achieve better scalability in (G)MPLS-TE networks keeping in mind 263 the trade-off between functionality and complexity. 265 3.1. A new resource class sub TLV 267 The traffic engineering attributes for a FA-LSP are described in 268 [2], according to the sub-TLV structure defined in [6]. It is 269 mentioned in [2] that the default behavior of a FA-LSP (no resource 270 class) may be overridden by local policy. 272 In the example of Figure 1, the links may be one or more of five 273 resource classes: Gold (G), Silver (S), Bronze (B), Owned (O) and 274 Leased (L). 276 [R6]---S,O---[R7]---S,O---[R8] 277 | | 278 S,O B,O 279 | | 280 [R1]---G,O---[R2]---G,O---[R3]---G,L---[R4]---G,O---[R5] 282 Figure 1. Resource class definition 284 Suppose [R2]-[R3]-[R4] has been made into a FA-LSP. If the default 285 value (no resource class) is overridden, the operator has two 286 options: include the union or the largest common denominator of all 287 resource classes on any of the links of the FA-LSP. The former 288 approach would cause {G,L,O} to be announced as resource class. Not 289 only would this be meaningless semantically in this case, it also 290 causes problems when setting up an LSP specifying 'include O'. Such 291 an LSP would be allowed to use the FA-LSP, even though it passes a 292 link which is not 'Owned'. In the latter case, {G} would be 293 announced as resource class which would cause a problem during the 294 setup of an LSP specifying 'exclude Leased'. Such an LSP would 295 incorrectly be allowed to use the FA-LSP. 297 As a solution to this problem, we propose the introduction of an 298 additional resource class sub TLV, sub TLV 10, in [6]. 300 10 - Exclude resource class/color (4 octets) 302 with exactly the same format as sub TLV 9. 304 9 - Resource class/color (4 octets) 306 The application of the new sub TLV would be as following: 308 1. sub TLV 10 can only be present together with sub TLV 9 309 2. If both are present, sub TLV 9 MUST be used for resource class 310 operations with 'include' lists. In case of an FA-LSP, it must 311 therefore be the result of an AND operation on the resource class 312 bit masks of all links of the FA-LSP. Sub TLV 10 MUST be used for 313 resource class operations with 'exclude' lists and must therefore be 314 constructed by means of an OR operation on the bit masks of all 315 links of an FA-LSP. 316 3. If only sub TLV 9 is present, it can be used both for 'include' 317 and 'exclude' list operations. This allows for backward 318 compatibility. 320 4. Security Considerations 322 The approach outlined in this document poses no new security 323 problems. 325 References 327 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 328 9, RFC 2026, October 1996. 330 2 K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized MPLS 331 TE", work in progress, draft-ietf-mpls-lsp-hierarchy-06.txt 333 3 S. Bradner, "Key words for use in RFCs to Indicate Requirement 334 Levels," BCP 14, RFC2119. 336 4 P. Pan, Ed. , D. Gan, G. Swallow, J. Vasseur, D. Cooper, A. Atlas, 337 M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels," 338 work in progress, draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt 340 5 S. De Cnodder, R. Cetin, S. Van den Bosch, A. Atlas, "Backup 341 Record Route for Fast Reroute Techniques in RSVP-TE," work in 342 progress, draft-decnodder-mpls-ero-rro-fastreroute-00.txt 344 6 Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 345 Extensions to OSPF", work in progress, draft-katz-yeung-ospf- 346 traffic-06.txt 348 Acknowledgments 350 The authors wish to thank Stefaan De Cnodder for his comments on the 351 draft. 353 Author's Addresses 355 Sven Van den Bosch (Alcatel) 356 Francis Wellesplein 1 Phone: 32-3-240-8103 357 B-2018 Antwerpen Email: sven.van_den_bosch@alcatel.be 358 Belgium 360 Dimitri Papadimitriou (Alcatel) 361 Francis Wellesplein 1 Phone: 32-3-240-8491 362 B-2018 Antwerpen Email: dimitri.papadimitriou@alcatel.be 363 Belgium 364 Full Copyright Statement 366 "Copyright (C) The Internet Society (date). All Rights Reserved. 367 This document and translations of it may be copied and furnished to 368 others, and derivative works that comment on or otherwise explain it 369 or assist in its implementation may be prepared, copied, published 370 and distributed, in whole or in part, without restriction of any 371 kind, provided that the above copyright notice and this paragraph 372 are included on all such copies and derivative works. However, this 373 document itself may not be modified in any way, such as by removing 374 the copyright notice or references to the Internet Society or other 375 Internet organizations, except as needed for the purpose of 376 developing Internet standards in which case the procedures for 377 copyrights defined in the Internet Standards process must be 378 followed, or as required to translate it into languages other than 379 English. 381 The limited permissions granted above are perpetual and will not be 382 revoked by the Internet Society or its successors or assigns. This 383 document and the information contained herein is provided on an "AS 384 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 385 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 386 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 387 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 388 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.