idnits 2.17.1 draft-kompella-mpls-bundle-02.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 136: '...mpatibility, one MAY advertise the Max...' RFC 2119 keyword, line 218: '...are down, the bundled link MUST not be...' RFC 2119 keyword, line 233: '...the Path message MUST send the Path me...' RFC 2119 keyword, line 259: '...ize the LINK_ID object, it SHOULD send...' RFC 2119 keyword, line 263: '... labels) SHOULD send an error messag...' (1 more instance...) 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: 'RSVP-TE' is defined on line 285, but no explicit reference was found in the text == 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 (~~), 7 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: January 2001 Yakov Rekhter 4 Cisco Systems 5 Lou Berger 6 LabN Consulting, LLC 8 Link Bundling in MPLS Traffic Engineering 10 draft-kompella-mpls-bundle-02.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 be unnumbered, or the various component links may 64 be numbered differently, or all components links may be numbered 65 identically. In the first two cases, the bundled link is unnumbered 66 by default; in the last case, the bundled link is numbered the same 67 as the component links by default. In all cases, the bundled link's 68 addresses may be overridden by configuration with IP addresses 69 assigned to some "virtual" interfaces on an LSR (it is assumed that 70 an LSR may have multiple virtual interfaces). 72 3.2. Other Considerations 74 If several component links are bundled, IS-IS/OSPF flooding can be 75 restricted to just one of the component links. Similarly, IS-IS/OSPF 76 hellos can be restricted to just one component link; however, it may 77 be useful to send hellos on all links that do not have a link layer 78 keep-alive mechanism to ensure that a failure of the link is 79 detected. 81 If the component links are not Packet Switch Capable, LSP setup 82 signalling needs to identify the component link to use. This 83 protocol is outside the scope of this document; however, see [LMP]. 85 If a bundled link consists of "working" and "protect" component 86 links, then for the purposes of bandwidth computation, only the 87 working links should be taken into account. 89 In the future, as new Traffic Engineering parameters are added to IS- 90 IS and OSPF, they should be accompanied by descriptions as to how 91 they can be bundled, and possible restrictions on bundling. 93 4. Traffic Engineering Parameters for Bundled Links 95 In this section, we define the Traffic Engineering parameters to be 96 advertised for a bundled link, based on the configuration of the 97 component links and of the bundled link. The definition of these 98 parameters for component links was undertaken in [ISIS] and [OSPF]; 99 we use the terminology from [OSPF]. 101 4.1. Link Type 103 The Link Type of a bundled link is the (unique) Link Type of the 104 component links. (Note: this parameter is not present in IS-IS.) 106 4.2. Link ID 108 For point-to-point links, the Link ID of a bundled link is the 109 (unique) Router ID of the neighbor. For multi-access links, this is 110 the interface address of the (unique) Designated Router. (Note: this 111 parameter is not present in IS-IS.) 113 4.3. Local and Remote Interface IP Address 115 (Note: in IS-IS, these are known as IPv4 Interface Address and IPv4 116 Neighbor Address, respectively.) 118 If the bundled link is numbered (see section 3.1), the Local 119 Interface IP Address is the local address of the bundled link; 120 similarly, the Remote Interface IP Address is the remote address of 121 the bundled link. 123 If the bundled link is unnumbered, the Local Address is the Router ID 124 of the advertising LSR, and the Remote Address is the Router ID of 125 the neighboring LSR. 127 4.4. Traffic Engineering Metric 129 The Traffic Engineering Metric for a bundled link is that of the 130 component links. 132 4.5. Maximum Link Bandwidth 134 This TLV is not used. The maximum LSP Bandwidth (as described below) 135 replaces the maximum link bandwidth for bundled links. For backward 136 compatibility, one MAY advertise the Maximum LSP Bandwidth at 137 priority 7 of the bundle. 139 4.6. Maximum Reservable Bandwidth 141 We assume that for a given bundled link either each of its component 142 links is configured with the maximum reservable bandwidth, or the 143 bundled link is configured with the maximum reservable bandwidth. In 144 the former case, the Maximum Reservable Bandwidth of the bundled link 145 is set to the sum of the maximum reservable bandwidths of all 146 component links associated with the bundled link. 148 4.7. Unreserved Bandwidth 150 The unreserved bandwidth of a bundled link at priority p is the sum 151 of the unreserved bandwidths at priority p of all the component links 152 associated with the bundled link. 154 4.8. Resource Classes (Administrative Groups) 156 The Resource Classes for a bundled link are the same as those of the 157 component links. 159 4.9. Maximum LSP Bandwidth 161 The Maximum LSP Bandwidth takes the place of the Maximum Link 162 Bandwidth. However, while Maximum Link Bandwidth is a single fixed 163 value (usually simply the link capacity), Maximum LSP Bandwidth is 164 carried per priority, and may vary as LSPs are set up and torn down. 166 The Maximum LSP Bandwidth of a bundled link at priority p is defined 167 to be the maximum of the Maximum LSP Bandwidth at priority p of each 168 component link. 170 If a component link is a simple (unbundled) link, define its Maximum 171 LSP Bandwidth at priority p to be the smaller of its unreserved 172 bandwidth at priority p and its maximum link bandwidth. 174 Since bundling may be applied recursively, a component link may 175 itself be a bundled link. In this case, its Maximum LSP Bandwidth as 176 a component link is the same as its Maximum LSP Bandwidth as a 177 bundled link. 179 In IS-IS, the Maximum LSP Bandwidth TLV is a sub-TLV of the Extended 180 IS Reachability TLV with type 21. In OSPF, this TLV is a sub-TLV of 181 the Link TLV within the Traffic Engineering LSA, with type 11. The 182 length of the Maximum LSP Bandwidth TLV is 32 octets. The value is a 183 list of eight 4 octet fields in IEEE floating point format of the 184 Maximum LSP Bandwidth of the bundle, from priority 0 to priority 7. 186 5. Procedures 188 5.1. Bandwidth Accounting 190 The RSVP Traffic Control module on an LSR with bundled links must 191 apply admission control on a per-component link basis. An LSP with a 192 bandwidth requirement b and setup priority p fits in a bundled link 193 if at least one component link has maximum LSP bandwidth >= b at 194 priority p. If there are several such links, the choice of which 195 link is used for the LSP is up to the implementation. 197 In order to know the maximum LSP bandwidth (per priority) of each 198 component link, the RSVP module must track the unreserved bandwidth 199 (per priority) for each component link. This is done as follows. If 200 an LSP with bandwidth b and holding priority p is set up through a 201 component link, that component link's unreserved bandwidth at 202 priority p and lower is reduced by b. If an LSP with bandwidth b and 203 holding priority p that is currently set up through a component link 204 is torn down, the unreserved bandwidth at priority p and lower for 205 that component link is increased by b. 207 A change in the unreserved bandwidth of a component link results in a 208 change in the unreserved bandwidth of the bundled link. It also 209 potentially results in a change in the maximum LSP bandwidth of the 210 bundle; thus, the maximum LSP bandwidth should be recomputed. 212 If one of the component links goes down, the associated bundled link 213 remains up and continues to be advertised, provided that at least one 214 component link associated with the bundled link is up. The 215 unreserved bandwidth of the component link that is down is set to 216 zero, and the unreserved bandwidth and maximum LSP bandwidth of the 217 bundle must be recomputed. If all the component links associated 218 with a given bundled link are down, the bundled link MUST not be 219 advertised into OSPF/IS-IS. 221 5.2. Signaling 223 Signaling must identify both the component link to use and the label 224 to use. The sender of the Path message identifies the component link 225 to be used for the LSP. The sender of the Resv message chooses the 226 label (as before). If the bundled link is composed of packet-switch 227 capable links and there is no designated control channel, then the 228 component link to be used is the link over which the Path message is 229 sent. 231 If, however, there is a protocol such as LMP that uniquely identifies 232 each component link and allocates a designated control channel, then 233 the sender of the Path message MUST send the Path message over the 234 control channel. In this case, the LINK_ID object is used to 235 identify the component link to use. This method of choosing the link 236 is required if the component links are not packet-switch capable. 238 5.2.1. LINK_ID object 240 A new object, the LINK_ID object, is defined. The Length field is 241 set to 8. The Class Num and C_Type of the LINK_ID object are to be 242 obtained from IANA. The format is given below; it consists simply of 243 a 32-bit Link Identifier that identifies the link to be used for the 244 LSP being set up. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Length |Class Num (TBD)| C_Type (TBD) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Link Identifier | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 This object is an optional subobject of the Path and Resv messages. 256 We introduce a new error value for the error code "Routing problem", 257 namely "Unknown Link ID" with error value 11. 259 If the receiver doesn't recognize the LINK_ID object, it SHOULD send 260 an error message with an "Unknown Object Class" or an "Unknown Object 261 C-Type" error. A node that recognizes the LINK_ID object, but that 262 is unable to support it (possibly because of a failure to allocate 263 labels) SHOULD send an error message with the error code "Routing 264 problem" and the error value "MPLS label allocation failure." If LMP 265 or some other link identification protocol is not running, or there 266 is no component link with the Link Identifier in the LINK_ID object, 267 the receiver SHOULD send an error message with the error code 268 "Routing problem" and the error value "Unknown Link ID". 270 6. Security Considerations 272 This document raises no new security issues for IS-IS, OSPF or RSVP. 274 7. References 276 [ISIS] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering", 277 draft-ietf-isis-traffic-01.txt (work in progress) 279 [LMP] Lang, J., Mitra, K., et al., "Link Management Protocol (LMP)", 280 draft-lang-mpls-lmp-00.txt (work in progress) 282 [OSPF] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 283 draft-katz-yeung-ospf-traffic-01.txt (work in progress) 285 [RSVP-TE] Awduche, D., Berger, L., Gan, D., et al, "Extensions to 286 RSVP for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-tunnel-05.txt (work 287 in progress) 289 [RTG] Kompella, K., Rekhter, Y., et al, "Extensions to IS-IS/OSPF and 290 RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical.txt 291 (work in progress) (new version forthcoming) 293 8. Author Information 295 Kireeti Kompella 296 Juniper Networks, Inc. 297 1194 N. Mathilda Ave. 298 Sunnyvale, CA 94089 299 Email: kireeti@juniper.net 301 Yakov Rekhter 302 Cisco Systems, Inc. 303 170 West Tasman Drive 304 San Jose, CA 95134 305 Email: yakov@cisco.com 306 Lou Berger 307 LabN Consulting, LLC 308 Voice: +1 301 468 9228 309 Email: lberger@labn.net