idnits 2.17.1 draft-kompella-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 3 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 a Security Considerations 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: ---------------------------------------------------------------------------- -- 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 section? 'Smit' on line 139 looks like a reference -- Missing reference section? 'Katz' on line 142 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 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: August 2000 Yakov Rekhter 4 Cisco Systems 6 Link Bundling in MPLS Traffic Engineering 8 draft-kompella-mpls-bundle-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 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 2. Abstract 33 In some cases a pair of LSRs may be connected by several (parallel) 34 links. From the MPLS Traffic Engineering point of view for the 35 purpose of scalability it may be desirable to treat all these links 36 as a single IP link. This document describes how to accomplish this. 38 3. Unnumbered links as a bundle 40 When a pair of LSRs are connected by multiple links, then for the 41 purpose of MPLS Traffic Engineering it is possible to advertise 42 several (or all) of these interfaces as a single link into OSPF/ISIS. 43 We refer to this process as "link bundling", or just "bundling". We 44 refer to the link that is advertised into OSPF/ISIS as a "bundled 45 link". We refer to the links associated with that bundled link as 46 "component links". 48 Component links are expected to be unnumbered. A bundled link could 49 be either unnumbered or numbered with IP addresses assigned to some 50 "virtual" interfaces on a router (it is assumed that a router may 51 have multiple virtual interfaces). 53 We assume that for a given bundled link either each of its component 54 links is configured with the maximum reservable bandwidth, or the 55 bundled link is configured with the maximum reservable bandwidth. In 56 the former case the maximum reservable bandwidth of the bundled link 57 is set to the sum over the the maximum reservable bandwidth for all 58 the component links associated with the bundled link. 60 The maximum LSP bandwidth (as described below) replaces the maximum 61 link bandwidth for bundled links. 63 We assume that for a given bundled link either each of its component 64 links is configured with the maximum LSP bandwidth per priority, or 65 the bundled link is configured with the maximum LSP bandwidth per 66 priority. In the former case the maximum LSP bandwidth for a given 67 priority of the bundled link is set to the maximum over maximum LSP 68 bandwidth for that priority for all the component links associated 69 with the bundled link. 71 By default the unreserved bandwidth of a bundled link is set to the 72 sum of all the unreserved bandwidths on all the component links 73 associated with the bundled link. 75 RSVP must track the unreserved bandwidth on each individual component 76 link. 78 If one of the component links goes down, that results in changing the 79 unreserved bandwidth of the associated bundled link, provided that at 80 least one other component link associated with the bundled link is 81 up. When all the component links associated with a given bundled 82 link are down, the bundled link should not be advertised into 83 OSPF/ISIS. 85 This document assumes that the label returned in the Label Object of 86 the Resv message is associated with the interface over which the 87 corresponding Path message is received. Therefore, this document 88 assumes that for a given bundled link connected to an LSR, the LSR 89 should be able to send the Path message over any of the component 90 links associated with the bundled link. 92 Procedures that would allow the label returned in the Label Object of 93 the Resv message to be associated with the interface different from 94 the one over which the corresponding Path message is received are 95 outside the scope of this document. That is, handling the case where 96 an LSR may not be able to send the Path message over some of the 97 component links, while still being able to place LSPs over these 98 links is outside the scope of this document. 100 4. Maximum LSP bandwidth TLV 102 The bandwidth allocated to a single LSP is limited (from above) by 103 the physical capacity of the links traversed by the LSP, as well as 104 other (already existing) LSPs that traverse the links. This value is 105 determined based on the physical link bandwidth, ignoring any 106 oversubscription factor. 108 Maximum LSP bandwidth is carried on a per priority level. This allows 109 to control the maximum amount of bandwidth that an LSP with a given 110 priority could allocate. 112 On a bundled link, the maximum LSP bandwidth for a given priority is 113 set to the maximum of the maximum LSP bandwidth for that priority 114 over all the component links associated with the bundled link. 116 In ISIS, this TLV is a sub-TLV of the Extended IS Reachability TLV 117 with type 21. In OSPF, this TLV is a sub-TLV of the Link TLV, with 118 type 11. 120 The Maximum bandwidth LSP sub-TLV is a list of two-tuples, of which 121 the first field is a 4 octet field, and the second is a one octet 122 field. The first field in a tuple encodes the maximum bandwidth in 123 units of bytes (not bits) per second as an IEEE floating point 124 number. The second field in the tuple encodes the value of the lowest 125 holding priority that an LSP has to have in order to reserve up to 126 the maximum bandwidth specified in the first field. 128 The difference between maximum LSP bandwidth and unreserved bandwidth 129 is that the former is computed based on the actual link bandwidth, 130 while the latter may reflect oversubscription. 132 This sub-TLV is expected to supersede the maximum link bandwidth 133 sub-TLV. 135 5. Acknowledgements 137 6. References 139 [Smit] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering", 140 draft-ietf-isis-traffic-01.txt 142 [Katz] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF", 143 draft-katz-yeung-ospf-traffic-01.txt 145 7. Author Information 147 Kireeti Kompella 148 Juniper Networks, Inc. 149 385 Ravendale Drive 150 Mountain View, CA 94043 151 email: kireeti@juniper.net 153 Yakov Rekhter 154 Cisco Systems, Inc. 155 170 West Tasman Drive 156 San Jose, CA 95134 157 email: yakov@cisco.com