idnits 2.17.1 draft-ietf-mpls-bundle-04.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == 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: If one of the component links goes down, the associated bundled link remains up and continues to be advertised, provided that at least one component link associated with the bundled link is up. The unreserved bandwidth of the component link that is down is set to zero, and the unreserved bandwidth and maximum LSP bandwidth of the bundle must be recomputed. If all the component links associated with a given bundled link are down, the bundled link MUST not be advertised into OSPF/IS-IS. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'UNNUM-CRLDP' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'UNNUM-RSVP' is defined on line 336, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-11 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-08 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-04 -- No information found for draft-ietf-generalized-mpls-signalling - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SIG' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-06 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-04 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-crldp-unnum-01 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-01 == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-03 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Kireeti Kompella 3 Internet Draft Juniper Networks 4 Expiration Date: January 2003 Yakov Rekhter 5 Juniper Networks 6 Lou Berger 7 Movaz Networks 9 Link Bundling in MPLS Traffic Engineering 11 draft-ietf-mpls-bundle-04.txt 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) 36 signaling in certain cases a combination of 37 is not sufficient to unambiguously identify the appropriate resource 38 used by a Label Switched Path (LSP). Such cases are handled by using 39 the link bundling construct which is described in this document. 41 3. Specification of Requirements 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [RFC2119]. 47 4. Link Bundling 49 As defined in [GMPLS-ROUTING], a TE link is a logical construct that 50 represents a way to group/map the information about certain physical 51 resources (and their properties) that interconnect LSRs into the 52 information that is used by Constrained SPF for the purpose of path 53 computation, and by GMPLS signaling. 55 As further stated in [GMPLS-ROUTING], depending on the nature of 56 resources that form a particular TE link, for the purpose of GMPLS 57 signaling in some cases a combination of is 58 sufficient to unambiguously identify the appropriate resource used by 59 an LSP. In other cases, a combination of is 60 not sufficient. Such cases are handled by using the link bundling 61 construct which is described in this document. 63 Consider a TE link such that for the purpose of GMPLS signaling a 64 combination of is not sufficient to 65 unambiguously identify the appropriate resources used by an LSP. In 66 this situation the link bundling construct assumes that the set of 67 resources that form the TE link could be partitioned into disjoint 68 subsets, such that (a) the partition is minimal, and (b) within each 69 subset a label is sufficient to unambiguously identify the 70 appropriate resources used by an LSP. We refer to such subsets as 71 "component links", and to the whole TE link as a "bundled link". On 72 a bundled link a combination of <(bundled) link identifier, component 73 link identifier, label> is sufficient to unambiguously identify the 74 appropriate resources used by an LSP. 76 Since within each component link a label is sufficient to 77 unambiguously identify the resources used by an LSP, one could also 78 say that a component link is a TE link, and a bundled link is a 79 collection of TE links. 81 The partition of resources that form a bundled link into component 82 links has to be done consistently at both ends of the bundled link. 84 The purpose of link bundling is to improve routing scalability by 85 reducing the amount of information that has to be handled by OSPF 86 and/or IS-IS. This reduction is accomplished by performing 87 information aggregation/abstraction. As with any other information 88 aggregation/abstraction, this results in losing some of the 89 information. To limit the amount of losses one need to restrict the 90 type of the information that can be aggregated/abstracted. 92 4.1. Restrictions on Bundling 94 All component links in a bundle must begin and end on the same pair 95 of LSRs, have the same Link Type (i.e., point-to-point or multi- 96 access), the same Traffic Engineering metric, and the same set of 97 resource classes at each end of the links. 99 A Forwarding Adjacency may be a component link; in fact, a bundle can 100 consist of a mix of point-to-point links and FAs. 102 If the component links are all multi-access links, the set of IS-IS 103 or OSPF routers connected to each component link must be the same, 104 and the Designated Router for each component link must be the same. 105 If these conditions cannot be enforced, multi-access links must not 106 be bundled. 108 4.2. Routing Considerations 110 A component link may be either numbered or unnumbered. A bundled link 111 may itself be numbered or unnumbered independent of whether the 112 component links of that bundled link are numbered or not. 114 Handling identifiers for unnumbered component links, including the 115 case where a link is formed by a Forwarding Adjacency, follows the 116 same rules as for an unnumbered TE link (see Section "Link 117 Identifiers" of [RSVP-UNNUM]/[CRLDP-UNNUM]). Furthermore, link local 118 identifiers for all unnumbered links of a given LSR (whether 119 component links, Forwarding Adjacencies or bundled links) MUST be 120 unique in the context of that LSR. 122 The "liveness" of the bundled link is determined by the liveness of 123 each of the component links within the bundled link - a bundled link 124 is alive when at least one its component links is determined to be 125 alive. The liveness of a component link can be determined by any of 126 several means: IS-IS or OSPF hellos over the component link, or RSVP 127 Hello, or LMP hellos (see [LMP]), or from layer 1 or layer 2 128 indications. 130 Once a bundled link is determined to be alive, it can be advertised 131 as a TE link and the TE information can be flooded. If IS-IS/OSPF 132 hellos are run over the component links, IS-IS/OSPF flooding can be 133 restricted to just one of the component links. Procedures for doing 134 this are outside the scope of this document. 136 In the future, as new Traffic Engineering parameters are added to IS- 137 IS and OSPF, they should be accompanied by descriptions as to how 138 they can be bundled, and possible restrictions on bundling. 140 4.3. Signaling Considerations 142 Typically, an LSP's ERO will choose the bundled link to be used for 143 the LSP, but not the component link, since information about the 144 bundled link is flooded, but information about the component links is 145 not. If the ERO chooses the component link by means outside the scope 146 of this document, this section does not apply. Otherwise, the choice 147 of the component link for the LSP is a local matter between the two 148 LSRs at each end of the bundled link. 150 Signaling must identify both the component link to use and the label 151 to use. The choice of the component link to use is always made by the 152 sender of the Path/REQUEST message (if an LSP is bidirectional 153 [GMPLS-SIG], the sender chooses a component link in each direction). 154 For unidirectional LSPs, and the forward direction of bidirectional 155 LSPs, the sender of a Resv/MAPPING message chooses the label. For the 156 reverse direction of a bidirectional LSP, the sender of the 157 Path/REQUEST message selects the upstream label. 159 With RSVP the choice of the component link is indicated by the sender 160 of the Path message by including the IF_ID RSVP_HOP object in the 161 Path message, as described in section 8 of [GMPLS-RSVP]. With CR-LDP 162 the choice of the component link is indicated by the sender of the 163 REQUEST message by including the IF_ID TLV in the REQUEST message, as 164 described in section 8 of [GMPLS-CRLDP]. 166 If the component link is numbered, the IF_ID RSVP_HOP object, or 167 IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6 168 address) TLVs (see [GMPLS-SIG]). The address carried in the TLV 169 identifies the link for which label allocation must be done. 171 If the component link is unnumbered, the IF_ID RSVP_HOP object, or 172 IF_ID TLV carries Type 3 (IF_INDEX) TLV (see [GMPLS-SIG]). The value 173 carried in Type 3 TLV contains the identifier of the selected 174 component link assigned to the link by the sender of the Path/REQUEST 175 message. Processing this object is the same as specified in Section 176 "Processing the IF_ID RSVP_HOP object"/"Processing the IF_ID TLV" of 177 [RSVP-UNNUM]/[CRLDP-UNNUM]. 179 For the purpose of processing the IF_ID RSVP_HOP object or IF_ID TLV, 180 an unnumbered component link formed by a Forwarding Adjacency is 181 treated the same way as an unnumbered TE link formed by a Forwarding 182 Adjacency (see Section "Unnumbered Forwarding Adjacencies" of [RSVP- 183 UNNUM]/[CDLDP-UNNUM]). 185 5. Traffic Engineering Parameters for Bundled Links 187 In this section, we define the Traffic Engineering parameters to be 188 advertised for a bundled link, based on the configuration of the 189 component links and of the bundled link. The definition of these 190 parameters for component links was undertaken in [ISIS-TE] and [OSPF- 191 TE]; we use the terminology from [OSPF-TE]. 193 5.1. OSPF Link Type 195 The Link Type of a bundled link is the (unique) Link Type of the 196 component links. (Note: this parameter is not present in IS-IS.) 198 5.2. OSPF Link ID 200 For point-to-point links, the Link ID of a bundled link is the 201 (unique) Router ID of the neighbor. For multi-access links, this is 202 the interface address of the (unique) Designated Router. (Note: this 203 parameter is not present in IS-IS.) 205 5.3. Local and Remote Interface IP Address 207 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4 208 Neighbor Address, respectively.) 210 If the bundled link is numbered, the Local Interface IP Address is 211 the local address of the bundled link; similarly, the Remote 212 Interface IP Address is the remote address of the bundled link. 214 5.4. Local and Remote Identifiers 216 If the bundled link is unnumbered, the link local identifier is set 217 to the identifier chosen for the bundle by the advertising LSR. The 218 link remote identifier is set to the identifier chosen by the 219 neighboring LSR for the reverse link corresponding to this bundle, if 220 known; otherwise, this is set to 0. 222 5.5. Traffic Engineering Metric 224 The Traffic Engineering Metric for a bundled link is that of the 225 component links. 227 5.6. Maximum Bandwidth 229 This parameter is not used. The maximum LSP Bandwidth (as described 230 below) replaces the Maximum Bandwidth for bundled links. 232 5.7. Maximum Reservable Bandwidth 234 We assume that for a given bundled link either each of its component 235 links is configured with the Maximum Reservable Bandwidth, or the 236 bundled link is configured with the Maximum Reservable Bandwidth. In 237 the former case, the Maximum Reservable Bandwidth of the bundled link 238 is set to the sum of the Maximum Reservable Bandwidths of all 239 component links associated with the bundled link. 241 5.8. Unreserved Bandwidth 243 The unreserved bandwidth of a bundled link at priority p is the sum 244 of the unreserved bandwidths at priority p of all the component links 245 associated with the bundled link. 247 5.9. Resource Classes (Administrative Groups) 249 The Resource Classes for a bundled link are the same as those of the 250 component links. 252 5.10. Maximum LSP Bandwidth 254 The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth. 255 For an unbundled link the Maximum Bandwidth is defined in [GMPLS- 256 ROUTING]. The Maximum LSP Bandwidth of a bundled link at priority p 257 is defined to be the maximum of the Maximum LSP Bandwidth at priority 258 p of all of its component links. 260 The details of how Maximum LSP Bandwidth is carried in IS-IS is given 261 in [GMPLS-ISIS]. The details of how Maximum LSP Bandwidth is carried 262 in OSPF is given in [GMPLS-OSPF]. 264 6. Bandwidth Accounting 266 The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an 267 LSR with bundled links must apply admission control on a per- 268 component link basis. An LSP with a bandwidth requirement b and setup 269 priority p fits in a bundled link if at least one component link has 270 maximum LSP bandwidth >= b at priority p. If there are several such 271 links, the choice of which link is used for the LSP is up to the 272 implementation. 274 In order to know the maximum LSP bandwidth (per priority) of each 275 component link, the Traffic Control module must track the unreserved 276 bandwidth (per priority) for each component link. 278 A change in the unreserved bandwidth of a component link results in a 279 change in the unreserved bandwidth of the bundled link. It also 280 potentially results in a change in the maximum LSP bandwidth of the 281 bundle; thus, the maximum LSP bandwidth should be recomputed. 283 If one of the component links goes down, the associated bundled link 284 remains up and continues to be advertised, provided that at least one 285 component link associated with the bundled link is up. The 286 unreserved bandwidth of the component link that is down is set to 287 zero, and the unreserved bandwidth and maximum LSP bandwidth of the 288 bundle must be recomputed. If all the component links associated with 289 a given bundled link are down, the bundled link MUST not be 290 advertised into OSPF/IS-IS. 292 7. Security Considerations 294 This document defines ways of utilizing procedures defined in other 295 documents referenced herein. Any security issues related to those 296 procedures are addressed in the referenced drafts. This document 297 thus raises no new security issues for RSVP-TE [RSVP-TE] or CR-LDP 298 [CR-LDP]. 300 8. References 302 8.1. Normative References 304 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 305 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 306 extensions-11.txt (work in progress) 308 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 309 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 310 gmpls-extensions-08.txt (work in progress) 312 [GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al, 313 "Routing Extensions in Support of Generalized MPLS", draft-ietf- 314 ccamp-gmpls-routing-04.txt (work in progress) 316 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 317 Functional Description", draft-ietf-generalized-mpls- 318 signalling-08.txt 320 [GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP- 321 TE Extensions", draft-ietf-mpls-generalized-rsvp-te-07.txt 323 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 324 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-06.txt 326 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 327 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 329 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 330 OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) 332 [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling 333 Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work 334 in progress) 336 [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 337 in RSVP-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress) 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RSVP-TE] Awduche, D., Berger, L., Gan, D. H., Li, T., Srinivasan, 343 V., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels", 344 RFC3209, December 2001 346 [CR-LDP] Jamoussi, B., editor, "Constraint-Based LSP Setup using 347 LDP", RFC3212, December 2001 349 8.2. Non-normative References 351 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 352 draft-ietf-ccamp-lmp-03.txt (work in progress) 354 9. Author Information 356 Kireeti Kompella 357 Juniper Networks, Inc. 358 1194 N. Mathilda Ave. 359 Sunnyvale, CA 94089 360 Email: kireeti@juniper.net 362 Yakov Rekhter 363 Juniper Networks, Inc. 364 1194 N. Mathilda Ave. 365 Sunnyvale, CA 94089 366 Email: yakov@juniper.net 368 Lou Berger 369 Movaz Networks, Inc. 370 Voice: +1 301 468 9228 371 Email: lberger@movaz.com