idnits 2.17.1 draft-kompella-mpls-bundle-01.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 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.) ** 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 133: '...mpatibility, one MAY advertise the Max...' RFC 2119 keyword, line 215: '...are down, the bundled link MUST not be...' RFC 2119 keyword, line 230: '...the Path message MUST send the Path me...' RFC 2119 keyword, line 259: '...abel binding, it SHOULD send a PathErr...' RFC 2119 keyword, line 263: '... labels) SHOULD send a PathErr with ...' (2 more instances...) 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) == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS') == Outdated reference: A later version (-02) exists of draft-lang-mpls-lmp-00 -- Possible downref: Normative reference to a draft: ref. 'LMP' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-01 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-05 -- Possible downref: Normative reference to a draft: ref. 'RTG' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kireeti Kompella 2 Internet Draft Juniper Networks 3 Expiration Date: December 2000 Yakov Rekhter 4 Cisco Systems 5 Lou Berger 6 LabN Consulting, LLC 8 Link Bundling in MPLS Traffic Engineering 10 draft-kompella-mpls-bundle-01.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 how 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 interfaces as a single link into OSPF 46 and/or IS-IS. We refer to this process as "link bundling", or just 47 "bundling". We refer to the link that is advertised into OSPF/IS-IS 48 as a "bundled link". We refer to the links associated with that 49 bundled link as "component links". 51 3.1. Restrictions on Bundling 53 All component links in a bundle must have the same Link Type (if 54 any), the same Traffic Engineering metric, the same set of resource 55 classes, and the same Link Multiplex Capability (see [RTG]). 57 If the component links are all multi-access links, the set of IS-IS 58 or OSPF routers connected to each component link must be the same, 59 and the Designated Router for each component link must be the same. 60 If these conditions cannot be enforced, multi-access links must not 61 be bundled. 63 Component links may either be unnumbered, or all components links 64 must be numbered identically. In the former case, the bundled link 65 may be either unnumbered or numbered with IP addresses assigned to 66 some "virtual" interfaces on an LSR (it is assumed that an LSR may 67 have multiple virtual interfaces). In the latter case, the bundled 68 link is numbered the same as the component links. 70 3.2. Other Considerations 72 If several component links are bundled, IS-IS/OSPF flooding can be 73 restricted to just one of the component links. Similarly, IS-IS/OSPF 74 hellos can be restricted to just one component link; however, it may 75 be useful to send hellos on all links that do not have a link layer 76 keep-alive mechanism to ensure that a failure of the link is 77 detected. 79 If the component links are bearer channels of a MPL(ambda)S link (see 80 [RTG]), LSP setup signaling needs to identify the component link to 81 use. This protocol is outside the scope of this document; however, 82 see [LMP]. 84 If a bundled link consists of "working" and "protect" component 85 links, then for the purposes of bandwidth computation, only the 86 working links should be taken into account. 88 4. Traffic Engineering Parameters for Bundled Links 90 In this section, we define the Traffic Engineering parameters to be 91 advertised for a bundled link, based on the configuration of the 92 component links and of the bundled link. The definition of these 93 parameters for component links was undertaken in [ISIS] and [OSPF]; 94 we use the terminology from [OSPF]. 96 4.1. Link Type 98 The Link Type of a bundled link is the (unique) Link Type of the 99 component links. (Note: this parameter is not present in IS-IS.) 101 4.2. Link ID 103 For point-to-point links, the Link ID of a bundled link is the 104 (unique) Router ID of the neighbor. For multi-access links, this is 105 the interface address of the (unique) Designated Router. (Note: this 106 parameter is not present in IS-IS.) 108 4.3. Local and Remote Interface IP Address 110 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4 111 Neighbor Address, respectively.) 113 If the component links of a bundled link are numbered, the Local and 114 Remote Interface IP addresses of the bundled link are the same as for 115 the component links. 117 If the component links are unnumbered, the bundled link may also be 118 unnumbered, in which case the Local Address is the Router ID of the 119 advertising LSR, and the Remote Address is the Router ID of the 120 neighboring LSR. Or, the bundled link may be associated with the 121 addresses of a virtual interface, in which case the Local and Remote 122 Addresses are those of the virtual interface. 124 4.4. Traffic Engineering Metric 126 The Traffic Engineering Metric for a bundled link is that of the 127 component links. 129 4.5. Maximum Link Bandwidth 131 This TLV is not used. The maximum LSP Bandwidth (as described below) 132 replaces the maximum link bandwidth for bundled links. For backward 133 compatibility, one MAY advertise the Maximum LSP Bandwidth at 134 priority 7 of the bundle. 136 4.6. Maximum Reservable Bandwidth 138 We assume that for a given bundled link either each of its component 139 links is configured with the maximum reservable bandwidth, or the 140 bundled link is configured with the maximum reservable bandwidth. In 141 the former case, the Maximum Reservable Bandwidth of the bundled link 142 is set to the sum of the maximum reservable bandwidths of all 143 component links associated with the bundled link. 145 4.7. Unreserved Bandwidth 147 The unreserved bandwidth of a bundled link at priority p is the sum 148 of the unreserved bandwidths at priority p of all the component links 149 associated with the bundled link. 151 4.8. Resource Classes (Administrative Groups) 153 The Resource Classes for a bundled link are the same as those of the 154 component links. 156 4.9. Maximum LSP Bandwidth 158 The Maximum LSP Bandwidth takes the place of the Maximum Link 159 Bandwidth. However, while Maximum Link Bandwidth is a single fixed 160 value (usually simply the link capacity), Maximum LSP Bandwidth is 161 carried per priority, and may vary as LSPs are set up and torn down. 163 The Maximum LSP Bandwidth of a bundled link at priority p is defined 164 to be the maximum of the Maximum LSP Bandwidth at priority p of each 165 component link. 167 If a component link is a simple (unbundled) link, define its Maximum 168 LSP Bandwidth at priority p to be the smaller of its unreserved 169 bandwidth at priority p and its maximum link bandwidth. 171 Since bundling may be applied recursively, a component link may 172 itself be a bundled link. In this case, its Maximum LSP Bandwidth as 173 a component link is the same as its Maximum LSP Bandwidth as a 174 bundled link. 176 In IS-IS, the Maximum LSP Bandwidth TLV is a sub-TLV of the Extended 177 IS Reachability TLV with type 21. In OSPF, this TLV is a sub-TLV of 178 the Link TLV within the Traffic Engineering LSA, with type 11. The 179 length of the Maximum LSP Bandwidth TLV is 32 octets. The value is a 180 list of eight 4 octet fields in IEEE floating point format of the 181 Maximum LSP Bandwidth of the bundle, from priority 0 to priority 7. 183 5. Procedures 185 5.1. Bandwidth Accounting 187 The RSVP Traffic Control module on an LSR with bundled links must 188 apply admission control on a per-component link basis. An LSP with a 189 bandwidth requirement b and setup priority p fits in a bundled link 190 if at least one component link has maximum LSP bandwidth >= b at 191 priority p. If there are several such links, the choice of which 192 link is used for the LSP is up to the implementation. 194 In order to know the maximum LSP bandwidth (per priority) of each 195 component link, the RSVP module must track the unreserved bandwidth 196 (per priority) for each component link. This is done as follows. If 197 an LSP with bandwidth b and holding priority p is set up through a 198 component link, that component link's unreserved bandwidth at 199 priority p and lower is reduced by b. If an LSP with bandwidth b and 200 holding priority p that is currently set up through a component link 201 is torn down, the unreserved bandwidth at priority p and lower for 202 that component link is increased by b. 204 A change in the unreserved bandwidth of a component link results in a 205 change in the unreserved bandwidth of the bundled link. It also 206 potentially results in a change in the maximum LSP bandwidth of the 207 bundle; thus, the maximum LSP bandwidth should be recomputed. 209 If one of the component links goes down, the associated bundled link 210 remains up and continues to be advertised, provided that at least one 211 component link associated with the bundled link is up. The 212 unreserved bandwidth of the component link that is down is set to 213 zero, and the unreserved bandwidth and maximum LSP bandwidth of the 214 bundle must be recomputed. If all the component links associated 215 with a given bundled link are down, the bundled link MUST not be 216 advertised into OSPF/IS-IS. 218 5.2. Signaling 220 Signaling must identify both the component link to use and the label 221 to use. The sender of the Path message identifies the component link 222 to be used for the LSP. The sender of the Resv message chooses the 223 label (as before). If the bundled link is composed of packet-switch 224 capable links and there is no designated control channel, then the 225 component link to be used is the link over which the Path message is 226 sent. 228 If, however, there is a protocol such as LMP that uniquely identifies 229 each component link and allocates a designated control channel, then 230 the sender of the Path message MUST send the Path message over the 231 control channel. In this case, the LABEL REQUEST object is modified 232 to identify the component link to use. This method of choosing the 233 link is required if the component links are not packet-switch 234 capable. 236 5.2.1. LABEL_REQUEST with Link ID 238 The Path message from [RSVP-TE] has a LABEL_REQUEST object with Class 239 Num 19 (to be determined by IANA) and C_Types 1, 2 and 3. Here, we 240 define a new format for the LABEL_REQUEST object with the same Class 241 Num, and C_Type 4 as follows: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Reserved | L3PID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Link Identifier | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 The receiver of a LABEL_REQUEST with C_Type 4 treats it as if a 252 LABEL_REQUEST of C_Type 1 was received over the link identified by 253 the Link Identifier. 255 We introduce a new error value for the error code "Routing problem", 256 namely "Unknown Link ID" with error value 11. 258 If the receiver doesn't recognize the LABEL_REQUEST object, or is 259 incapable of providing a label binding, it SHOULD send a PathErr 260 message with an "Unknown Object Class" or an "Unknown Object C-Type" 261 error. A node that recognizes the LABEL_REQUEST object, but that is 262 unable to support it (possibly because of a failure to allocate 263 labels) SHOULD send a PathErr with the error code "Routing problem" 264 and the error value "MPLS label allocation failure." If LMP or some 265 other link identification protocol is not running, or there is no 266 component link with the Link Identifier in the LABEL_REQUEST object, 267 the receiver SHOULD send a PathErr with the error code "Routing 268 problem" and the error value "Unknown Link ID". If the receiver 269 cannot support the protocol L3PID, it SHOULD send a PathErr with the 270 error code "Routing problem" and the error value "Unsupported L3PID." 272 6. Security Considerations 274 This document raises no new security issues for IS-IS, OSPF or RSVP. 276 7. References 278 [ISIS] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering", 279 draft-ietf-isis-traffic-01.txt (work in progress) 281 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 282 draft-lang-mpls-lmp-00.txt (work in progress) 284 [OSPF] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 285 draft-katz-yeung-ospf-traffic-01.txt (work in progress) 287 [RSVP-TE] Awduche, D., Berger, L., Gan, D., et al, "Extensions to 288 RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-05.txt (work 289 in progress) 291 [RTG] Kompella, K., Rekhter, Y., et al, "Extensions to IS-IS/OSPF and 292 RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical.txt 293 (work in progress) (new version forthcoming) 295 8. Author Information 297 Kireeti Kompella 298 Juniper Networks, Inc. 299 1194 N. Mathilda Ave. 300 Sunnyvale, CA 94089 301 Email: kireeti@juniper.net 303 Yakov Rekhter 304 Cisco Systems, Inc. 305 170 West Tasman Drive 306 San Jose, CA 95134 307 Email: yakov@cisco.com 308 Lou Berger 309 LabN Consulting, LLC 310 Voice: +1 301 468 9228 311 Email: lberger@labn.net