idnits 2.17.1 draft-ietf-mpls-bundle-00.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 9 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 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 107: '... Adjacencies or bundled links) MUST be...' RFC 2119 keyword, line 135: '...chanisms is used SHOULD be configurabl...' RFC 2119 keyword, line 327: '...are down, the bundled link MUST not be...' 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) == Missing Reference: 'ISIS-GMPLS' is mentioned on line 178, but not defined == Missing Reference: 'OSPF-GMPLS' is mentioned on line 180, but not defined == Missing Reference: 'RSVP-UNNUM' is mentioned on line 195, but not defined == Missing Reference: 'CRLDP-UNNUM' is mentioned on line 195, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-02 ** 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-00 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-00 -- 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-04 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-04 == 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-ietf-ccamp-lmp-00 == Outdated reference: A later version (-01) exists of draft-ietf-ospf-ppp-flood-00 -- Possible downref: Normative reference to a draft: ref. 'MOY' == 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 (-01) exists of draft-ietf-ospf-isis-flood-opt-00 -- Possible downref: Normative reference to a draft: ref. 'ZININ' Summary: 9 errors (**), 0 flaws (~~), 19 warnings (==), 6 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: March 2002 Yakov Rekhter 5 Juniper Networks 6 Lou Berger 7 Movaz Networks 9 Link Bundling in MPLS Traffic Engineering 11 draft-ietf-mpls-bundle-00.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 In some cases a pair of Label Switching Routers (LSRs) may be 36 connected by several (parallel) links. From the MPLS Traffic 37 Engineering point of view for reasons of scalability it may be 38 desirable to advertise all these links as a single link into OSPF 39 and/or IS-IS. This document describes a mechanism to accomplish this. 41 3. Link Bundling 43 When a pair of LSRs are connected by multiple links, then for the 44 purpose of MPLS Traffic Engineering it is possible to advertise 45 several (or all) of these links as a single link into OSPF and/or IS- 46 IS. We refer to this process as "link bundling", or just "bundling". 47 We refer to the link that is advertised into OSPF/IS-IS as a "bundled 48 link". We refer to the links associated with that bundled link as 49 "component links". 51 Link bundling can be applied recursively. That is, a bundled link 52 that consists of multiple component links may itself be a component 53 link of some other bundled link. 55 The purpose of link bundling is to improve routing scalability by 56 reducing the amount of information that has to be handled by OSPF 57 and/or IS-IS. This reduction is accomplished by performing 58 information aggregation/abstraction. As with any other information 59 aggregation/abstraction, this results in losing some of the 60 information. To limit the amount of losses one need to restrict the 61 type of the information that can be aggregated/abstracted. 63 3.1. Restrictions on Bundling 65 All component links in a bundle must begin and end on the same pair 66 of LSRs, have the same Link Type (i.e., point-to-point or multi- 67 access), the same Traffic Engineering metric, and the same set of 68 resource classes at each end of the links. A Forwarding Adjacency may 69 be a component link; in fact, a bundle can consist of a mix of point- 70 to-point links and FAs. 72 If the component links are all multi-access links, the set of IS-IS 73 or OSPF routers connected to each component link must be the same, 74 and the Designated Router for each component link must be the same. 75 If these conditions cannot be enforced, multi-access links must not 76 be bundled. 78 3.2. Routing Considerations 80 A bundled link is just another kind of Traffic Engineering (TE) link 81 (see [GMPLS-ROUTING]). The "liveness" of the bundled link is 82 determined by the liveness of each of the component links within the 83 bundled link - a bundled link is alive when at least one its 84 component links is determined to be alive. The liveness of a 85 component link can be determined by any of several means: IS-IS or 86 OSPF hellos over the component link, or RSVP Hello, or LMP hellos 87 (see [LMP]), or from layer 1 or layer 2 indications. 89 Once a bundled link is determined to be alive, it can be advertised 90 as a TE link and the TE information can be flooded. If IS-IS/OSPF 91 hellos are run over the component links, IS-IS/OSPF flooding can be 92 restricted to just one of the component links [ZININ] [MOY]. 94 Note that advertising a (bundled) TE link between a pair of LSRs 95 doesn't imply that there is an IGP adjacency between these LSRs that 96 is associated with just that link. In fact, in certain cases a TE 97 link between a pair of LSRs could be advertised even if there is no 98 IGP adjacency at all between the LSRs (e.g., when the TE link is an 99 FA). 101 A component link may be either numbered or unnumbered. A bundled link 102 may itself be numbered or unnumbered independent of whether the 103 component links are numbered or not. This affects how the bundled 104 link is advertised in IS-IS/OSPF, and the format of LSP EROs that 105 traverse the bundled link. Furthermore, unnumbered Interface 106 Identifiers for all unnumbered outgoing links of a given LSR (whether 107 component links, Forwarding Adjacencies or bundled links) MUST be 108 unique in the context of that LSR. 110 In the future, as new Traffic Engineering parameters are added to IS- 111 IS and OSPF, they should be accompanied by descriptions as to how 112 they can be bundled, and possible restrictions on bundling. 114 3.3. Signaling Considerations 116 Typically, an LSP's ERO will choose the bundled link to be used for 117 the LSP, but not the component link(s), since information about the 118 bundled link is flooded, but information about the component links is 119 not. If the ERO chooses the component links by means outside the 120 scope of this document, this section does not apply. Otherwise, the 121 choice of the component link(s) for the LSP is a local matter between 122 the two LSRs at each end of the bundled link. 124 Signaling must identify both the component link to use and the label 125 to use. The choice of the component link to use is always made by the 126 sender of the Path/REQUEST message (if an LSP is bidirectional 127 [GMPLS-SIG], the sender chooses a component link in each direction). 128 For unidirectional LSPs, and the forward direction of bidirectional 129 LSPs, the sender of a Resv/MAPPING message chooses the label. For the 130 reverse direction of a bidirectional LSP, the sender of the 131 Path/REQUEST message selects the upstream label. 133 Two mechanisms for identifying the component link to the receiver of 134 the Path/REQUEST message are described below; which of these 135 mechanisms is used SHOULD be configurable by the user, preferably on 136 a per-bundle basis. Both mechanisms work with either numbered or 137 unnumbered component links. 139 3.3.1. Mechanism 1: Implicit Indication 141 This mechanism requires that each component link has a dedicated 142 signaling channel (for example, the link is packet-switch capable; or 143 the link is a SONET link with an in-band channel for signaling). The 144 sender of the Path/REQUEST message tells the receiver which component 145 link to use by sending the message over the chosen component link's 146 dedicated signaling channel. 148 3.3.2. Mechanism 2: Explicit Indication by Interface ID 150 With RSVP the choice of the component link is indicated by the sender 151 of the Path message by including the IF_ID RSVP_HOP object in the 152 Path message, as described in section 8 of [GMPLS-RSVP]. With CR-LDP 153 the choice of the component link is indicated by the sender of the 154 REQUEST message by including the IF_ID TLV in the REQUEST message, as 155 described in section 8 of [GMPLS-CRLDP]. 157 If the component link is numbered, the IF_ID RSVP_HOP object, or 158 IF_ID TLV carries either Type 1 (IPv4 address) or Type 2 (IPv6 159 address) TLVs (see [GMPLS-SIG]). If the component link is unnumbered, 160 the IF_ID RSVP_HOP object, or IF_ID TLV carries Type 4 161 (COMPONENT_IF_DOWNSTREAM) TLV, and in the case of a bidirectional LSP 162 also Type 5 (COMPONENT_IF_UPSTREAM) TLV (see [GMPLS-SIG]). The value 163 carried in Type 4 and Type 5 TLVs contains the outgoing interface 164 identifier (from the point of view of the sender of the Path/REQUEST 165 message) of the selected component link. 167 When the IF_ID RSVP_HOP or IF_ID TLV carries the IPv4 or IPv6 address 168 (component link is numbered), this address identifies the link for 169 which label allocation must be done. 171 When a component link is unnumbered, this mechanism requires that 172 each component link is assigned a unique Interface Identifier per 173 [UNNUM-RSVP] or [UNNUM-CRLDP], and that the assigned identifiers be 174 exchanged by the two LSRs at each end of the bundled link. 175 Exchanging the identifiers may be accomplished by configuration, by 176 means of a protocol such as LMP ([LMP]), by means of RSVP/CR-LDP 177 (especially in the case where a component link is a Forwarding 178 Adjacency), or by means of IS-IS or OSPF extensions ([ISIS-GMPLS], 180 [OSPF-GMPLS]). 182 When the IF_ID RSVP_HOP or IF_ID TLV carries the 183 COMPONENT_IF_DOWNSTREAM TLV (component link is unnumbered), the LSR 184 that receives the Path/REQUEST message determines the component link 185 for which label allocation must be done as follows. First the LSR 186 checks whether the tuple carried in 187 COMPONENT_IF_DOWNSTREAM matches the tuple (see [RSVP-UNNUM], [CRLDP-UNNUM]) of any LSPs for which 189 the LSR is a tail-end. If the match is found, the match identifies 190 the Forwarding Adjacency for which the LSR has to perform label 191 allocation. 193 Otherwise, the LSR must check whether the tuple carried in COMPONENT_IF_DOWNSTREAM matches the tuple 195 (see [RSVP-UNNUM], [CRLDP-UNNUM]) 196 of any of the bidirectional LSPs for which the LSR is the head-end. 197 If a match is found, the match identifies the Forwarding Adjacency 198 for which the LSR has to perform label allocation, namely, the 199 reverse Forwarding Adjacency for the LSP identified by the match. 201 Otherwise, the LSR must have information about the identifiers 202 assigned by its neighbors to the component links (i.e., incoming 203 interface identifiers from LSR's point of view). The LSR uses this 204 information to find a (component) link with tuple matching the tuple carried in COMPONENT_IF_DOWNSTREAM. If the matching 207 tuple is found, the match identifies the (component) link for which 208 the LSR has to perform label allocation. 210 In both RSVP and CR-LDP, if the Interface ID field of 211 COMPONENT_IF_DOWNSTREAM has the special value of 0xffffffff, this 212 means that the same label is to be valid across all component links 213 in the downstream direction. Likewise, if the Interface ID field of 214 COMPONENT_IF_UPSTREAM has the special value of 0xffffffff, this means 215 that the same label is to be valid across all component links in the 216 upstream direction. 218 4. Traffic Engineering Parameters for Bundled Links 220 In this section, we define the Traffic Engineering parameters to be 221 advertised for a bundled link, based on the configuration of the 222 component links and of the bundled link. The definition of these 223 parameters for component links was undertaken in [ISIS-TE] and [OSPF- 224 TE]; we use the terminology from [OSPF-TE]. 226 4.1. OSPF Link Type 228 The Link Type of a bundled link is the (unique) Link Type of the 229 component links. (Note: this parameter is not present in IS-IS.) 231 4.2. OSPF Link ID 233 For point-to-point links, the Link ID of a bundled link is the 234 (unique) Router ID of the neighbor. For multi-access links, this is 235 the interface address of the (unique) Designated Router. (Note: this 236 parameter is not present in IS-IS.) 238 4.3. Local and Remote Interface IP Address 240 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4 241 Neighbor Address, respectively.) 243 If the bundled link is numbered, the Local Interface IP Address is 244 the local address of the bundled link; similarly, the Remote 245 Interface IP Address is the remote address of the bundled link. 247 4.4. Outgoing and Incoming Interface Identifiers 249 If the bundled link is unnumbered, the Outgoing Interface Identifier 250 is set to the outgoing interface identifier chosen for the bundle by 251 the advertising LSR. The Incoming Interface Identifier is set to the 252 outgoing interface identifier chosen by the neighboring LSR for the 253 reverse link corresponding to this bundle, if known; otherwise, this 254 is set to 0. 256 4.5. Traffic Engineering Metric 258 The Traffic Engineering Metric for a bundled link is that of the 259 component links. 261 4.6. Maximum Link Bandwidth 263 This TLV is not used. The maximum LSP Bandwidth (as described below) 264 replaces the maximum link bandwidth for bundled links. 266 4.7. Total Reservable Bandwidth 268 We assume that for a given bundled link either each of its component 269 links is configured with the Total Reservable Bandwidth, or the 270 bundled link is configured with the Total Reservable Bandwidth. In 271 the former case, the Total Reservable Bandwidth of the bundled link 272 is set to the sum of the Total Reservable Bandwidths of all component 273 links associated with the bundled link. 275 4.8. Unreserved Bandwidth 277 The unreserved bandwidth of a bundled link at priority p is the sum 278 of the unreserved bandwidths at priority p of all the component links 279 associated with the bundled link. 281 4.9. Resource Classes (Administrative Groups) 283 The Resource Classes for a bundled link are the same as those of the 284 component links. 286 4.10. Maximum LSP Bandwidth 288 The Maximum LSP Bandwidth takes the place of the Maximum Link 289 Bandwidth. It is defined in [GMPLS-ROUTING]. The details of how 290 Maximum LPS Bandwidth is carried in IS-IS is given in [GMPLS-ISIS]. 291 The details of how Maximum LSP Bandwidth is carried in OSPF is given 292 in [GMPLS-OSPF]. 294 Maximum LSP Bandwidth of a bundled link is equal to the maximum of 295 Maximum LSP Bandwidth of all of its component links. 297 Since bundling may be applied recursively, a component link may 298 itself be a bundled link. In this case, its Maximum LSP Bandwidth as 299 a component link is the same as its Maximum LSP Bandwidth as a 300 bundled link. 302 5. Bandwidth Accounting 304 The RSVP (or CR-LDP) Traffic Control module, or its equivalent, on an 305 LSR with bundled links must apply admission control on a per- 306 component link basis. An LSP with a bandwidth requirement b and setup 307 priority p fits in a bundled link if at least one component link has 308 maximum LSP bandwidth >= b at priority p. If there are several such 309 links, the choice of which link is used for the LSP is up to the 310 implementation. 312 In order to know the maximum LSP bandwidth (per priority) of each 313 component link, the Traffic Control module must track the unreserved 314 bandwidth (per priority) for each component link. 316 A change in the unreserved bandwidth of a component link results in a 317 change in the unreserved bandwidth of the bundled link. It also 318 potentially results in a change in the maximum LSP bandwidth of the 319 bundle; thus, the maximum LSP bandwidth should be recomputed. 321 If one of the component links goes down, the associated bundled link 322 remains up and continues to be advertised, provided that at least one 323 component link associated with the bundled link is up. The 324 unreserved bandwidth of the component link that is down is set to 325 zero, and the unreserved bandwidth and maximum LSP bandwidth of the 326 bundle must be recomputed. If all the component links associated with 327 a given bundled link are down, the bundled link MUST not be 328 advertised into OSPF/IS-IS. 330 6. Security Considerations 332 This document raises no new security issues for RSVP or CR-LDP. 334 7. References 336 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 337 Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls- 338 extensions-02.txt (work in progress) 340 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 341 Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- 342 gmpls-extensions-00.txt (work in progress) 344 [GMPLS-ROUTING] Kompella, K., Rekhter, Y., Banerjee, A. et al, 345 "Routing Extensions in Support of Generalized MPLS", draft-ietf- 346 ccamp-gmpls-routing-00.txt 348 [GMPLS-SIG] Ashwood, P., et al., "Generalized MPLS - Signalling 349 Functional Description", draft-ietf-generalized-mpls- 350 signalling-05.txt 352 [GMPLS-RSVP] Ashwood, P., et al., "Generalized MPLS Signalling RSVP- 353 TE Extensions", draft-ietf-mpls-generalized-rsvp-te-04.txt 355 [GMPLS-CRLDP] Ashwood, P., et al., "Generalized MPLS Signaling - CR- 356 LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-04.txt 358 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 359 Engineering", draft-ietf-isis-traffic-02.txt (work in progress) 361 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 362 draft-ietf-ccamp-lmp-00.txt (work in progress) 364 [MOY] Moy, J., draft-ietf-ospf-ppp-flood-00.txt (work in progress) 366 [OSPF-TE] Katz, D., Yeung, D., "Traffic Engineering Extensions to 367 OSPF", draft-katz-yeung-ospf-traffic-04.txt (work in progress) 369 [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling 370 Unnumbered Links in CR-LDP", draft-ietf-mpls-crldp-unnum-01.txt (work 371 in progress) 373 [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 374 in RSVP-TE", draft-ietf-mpls-rsvp-unnum-01.txt (work in progress) 376 [ZININ] Zinin, A., Shand, M., "Flooding optimizations in link-state 377 routing protocols", draft-ietf-ospf-isis-flood-opt-00.txt (work in 378 progress) 379 8. Author Information 381 Kireeti Kompella 382 Juniper Networks, Inc. 383 1194 N. Mathilda Ave. 384 Sunnyvale, CA 94089 385 Email: kireeti@juniper.net 387 Yakov Rekhter 388 Juniper Networks, Inc. 389 1194 N. Mathilda Ave. 390 Sunnyvale, CA 94089 391 Email: yakov@juniper.net 393 Lou Berger 394 Movaz Networks, Inc. 395 Voice: +1 301 468 9228 396 Email: lberger@movaz.com