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