idnits 2.17.1 draft-ietf-mpls-lsp-hierarchy-06.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 11 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 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 219: '...s a SRLG TLV, it MUST be the case that...' RFC 2119 keyword, line 313: '...the Path message MUST contain an IF_ID...' RFC 2119 keyword, line 315: '... identification MUST identify the FA-...' RFC 2119 keyword, line 323: '...for the Path message MUST NOT have the...' RFC 2119 keyword, line 328: '.... RSVP TTL check MUST NOT be made. In...' (4 more instances...) 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: 'RSVP-TE' is mentioned on line 82, but not defined == Missing Reference: 'CR-LDP' is mentioned on line 82, but not defined == Missing Reference: '1-4' is mentioned on line 346, but not defined == Unused Reference: 'GRSVP-TE' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'GSIG' is defined on line 456, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GCR-LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-ISIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-OSPF' -- Possible downref: Non-RFC (?) normative reference: ref. 'GRSVP-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNNUM-CRLDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'UNNUM-RSVP' == Outdated reference: A later version (-10) exists of draft-ietf-ccamp-lmp-02 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 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: November 2002 Yakov Rekhter 5 Juniper Networks 7 LSP Hierarchy with Generalized MPLS TE 9 draft-ietf-mpls-lsp-hierarchy-06.txt 11 1. Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 2. Abstract 34 To improve scalability of Generalized MPLS (GMPLS) it may be useful 35 to aggregate Label Switched Paths (LSPs) by creating a hierarchy of 36 such LSPs. A way to create such a hierarchy is by (a) an LSR 37 creating a TE LSP, (b) the LSR forming a forwarding adjacency (FA) 38 out of that LSP (by advertising this LSP as a TE link into the same 39 instance of ISIS/OSPF as the one that was used to create the LSP), 40 (c) allowing other LSRs to use FAs for their path computation, and 41 (d) nesting of LSPs originated by other LSRs into that LSP (by using 42 the label stack construct). 44 This document describes the mechanisms to accomplish this. 46 3. Overview 48 An LSR uses Generalized MPLS (GMPLS) TE procedures to create and 49 maintain an LSP. The LSR then may (under local configuration control) 50 announce this LSP as a Traffic Engineering (TE) link into the same 51 instance of the GMPLS control plane (or more precisely its ISIS/OSPF 52 component) as the one that was used to create the LSP. We call such 53 a link a "forwarding adjacency" (FA). We refer to the LSP as the 54 "forwarding adjacency LSP", or just FA-LSP. Note that an FA-LSP is 55 both created and used as a TE link by exactly the same instance of 56 the GMPLS control plane. Thus the concept of an FA is applicable only 57 when an LSP is both created and used as a TE link by exactly the same 58 instance of the GMPLS control plane. Note also that an FA is a TE 59 link between two GMPLS nodes whose path transits zero or more (G)MPLS 60 nodes in the same instance of the GMPLS control plane. 62 The nodes connected by a 'basic' TE link may have a routing 63 adjacency; however, the nodes connected by an FA would not usually 64 have a routing adjacency. A TE link of any kind (either 'basic' or 65 FA) would have to have a signaling adjacency in order for it to be 66 used to establish an LSP across it. 68 In general, the creation/termination of an FA and its FA-LSP could be 69 driven either by mechanisms outside of GMPLS (e.g., via configuration 70 control on the LSR at the head-end of the adjacency), or by 71 mechanisms within GMPLS (e.g., as a result of the LSR at the head-end 72 of the adjacency receiving LSP setup requests originated by some 73 other LSRs). 75 ISIS/OSPF floods the information about FAs just as it floods the 76 information about any other links. As a result of this flooding, an 77 LSR has in its TE link state database the information about not just 78 basic TE links, but FAs as well. 80 An LSR, when performing path computation, uses not just basic TE 81 links, but FAs as well. Once a path is computed, the LSR uses 82 RSVP/CR-LDP [RSVP-TE, CR-LDP] for establishing label binding along 83 the path. 85 In this document we define mechanisms/procedures to accomplish the 86 above. These mechanisms/procedures cover both the routing 87 (ISIS/OSPF) and the signalling (RSVP/CR-LDP) aspects. 89 Note that an LSP may be advertised as a point-to-point link into ISIS 90 or OSPF, to be used in normal SPF by nodes other than the head end. 91 While this is similar in spirit to an FA, this is beyond the scope of 92 this document. 94 Scenarios where an LSP is created (and maintained) by one instance of 95 the GMPLS control plane, and is used as a (TE) link by another 96 instance of the GMPLS control plane are outside the scope of this 97 document. 99 4. Routing aspects 101 In this section we describe procedures for constructing FAs out of 102 LSPs, and handling of FAs by ISIS/OSPF. Specifically, this section 103 describes how to construct the information needed to advertise LSPs 104 as links into ISIS/OSPF. Procedures for creation/termination of such 105 LSPs are defined in Section 6. 107 FAs may be represented as either unnumbered or numbered links. If FAs 108 are numbered with IPv4 addresses, the local and remote IPv4 addresses 109 come out of a /31 that is allocated by the LSR that originates the 110 FA-LSP; the head-end address of the FA-LSP is the one specified as 111 the IPv4 tunnel sender address; the remote (tail-end) address can 112 then be inferred. If the LSP is bidirectional, the tail-end can thus 113 know the addresses to assign to the reverse FA. 115 If there are multiple LSPs that all originate on one LSR and all 116 terminate on another LSR, then at one end of the spectrum all these 117 LSPs could be merged (under control of the head-end LSR) into a 118 single FA using the concept of Link Bundling (see [BUNDLE]), while at 119 the other end of the spectrum each such LSP could be advertised as 120 its own adjacency. 122 When an FA is created under administrative control (static 123 provisioning), the attributes of the FA-LSP have to be provided via 124 configuration. Specifically, the following attributes may be 125 configured for the FA-LSP: the head-end address (if left 126 unconfigured, this defaults to the head-end LSR's Router ID); the 127 tail-end address; bandwidth and resource colors constraints. The 128 path taken by the FA-LSP may be either computed by the LSR at the 129 head-end of the FA-LSP, or specified by explicit configuration; this 130 choice is determined by configuration. 132 When an FA is created dynamically, the attributes of its FA-LSP are 133 inherited from the LSP which induced its creation. Note that the 134 bandwidth of the FA-LSP must be at least as big as the LSP that 135 induced it, but may be bigger if only discrete bandwidths are 136 available for the FA-LSP. In general, for dynamically provisioned 137 FAs, a policy-based mechanism may be needed to associate attributes 138 to the FA-LSPs. 140 4.1. Traffic Engineering parameters 142 In this section, the Traffic Engineering parameters (see [OSPF-TE] 143 and [ISIS-TE]) for FAs are described. 145 4.1.1. Link type (OSPF only) 147 The Link Type of an FA is set to "point-to-point". 149 4.1.2. Link ID (OSPF only) 151 The Link ID is set to the Router ID of the tail end of FA-LSP. 153 4.1.3. Local and remote interface IP address 155 If the FA is to be numbered, the local interface IP address (OSPF) or 156 IPv4 interface address (ISIS) is set to the head-end address of the 157 FA-LSP. The remote interface IP address (OSPF) or IPv4 neighbor 158 address (ISIS) is set to the tail-end address of the FA-LSP. 160 4.1.4. Local and Remote Link Identifiers 162 For an unnumbered FA the assignment and handling of the local and 163 remote link identifiers is specified in [UNNUM-RSVP], [UNNUM-CRLDP]. 165 4.1.5. Traffic Engineering metric 167 By default the TE metric on the FA is set to max(1, (the TE metric of 168 the FA-LSP path) - 1) so that it attracts traffic in preference to 169 setting up a new LSP. This may be overridden via configuration at 170 the head-end of the FA. 172 4.1.6. Maximum bandwidth 174 By default the Maximum Reservable Bandwidth and the initial Maximum 175 LSP Bandwidth for all priorities of the FA is set to the bandwidth of 176 the FA-LSP. These may be overridden via configuration at the head- 177 end of the FA (note that the Maximum LSP Bandwidth at any one 178 priority should be no more than the bandwidth of the FA-LSP). 180 4.1.7. Unreserved bandwidth 182 The initial unreserved bandwidth for all priority levels of the FA is 183 set to the bandwidth of the FA-LSP. 185 4.1.8. Resource class/color 187 By default, a FA does not have resource colors (administrative 188 groups). This may be overridden by configuration at the head-end of 189 the FA. 191 4.1.9. Interface Switching Capability 193 The (near end) Interface Switching Capability associated with the FA 194 is the (near end) Interface Switching Capability of the first link in 195 the FA-LSP. 197 When the (near end) Interface Switching Capability field is PSC-1, 198 PSC-2, PSC-3, or PSC-4, the specific information includes Interface 199 MTU and Minimum LSP Bandwidth. The Interface MTU is the minimum MTU 200 along the path of the FA-LSP; the Minimum LSP Bandwidth is the 201 bandwidth of the LSP. 203 4.1.10. SRLG information 205 An FA advertisement could contain the information about the Shared 206 Risk Link Groups (SRLG) for the path taken by the FA-LSP associated 207 with that FA. This information may be used for path calculation by 208 other LSRs. The information carried is the union of the SRLGs of the 209 underlying TE links that make up the FA-LSP path; it is carried in 210 the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF. 211 See [GMPLS-ISIS, GMPLS-OSPF] for details on the format of this 212 information. 214 It is possible that the underlying path information might change over 215 time, via configuration updates, or dynamic route modifications, 216 resulting in the change of the SRLG TLV. 218 If FAs are bundled (via link bundling), and if the resulting bundled 219 link carries a SRLG TLV, it MUST be the case that the list of SRLGs 220 in the underlying path followed by each of the FA-LSPs that form the 221 component links is the same (note that the exact paths need not be 222 the same). 224 5. Other considerations 226 It is expected that FAs will not be used for establishing ISIS/OSPF 227 peering relation between the routers at the ends of the adjacency. 229 It may be desired in some cases that FAs only be used in Traffic 230 Engineering path computations. In IS-IS, this can be accomplished by 231 setting the default metric of the extended IS reachability TLV for 232 the FA to the maximum link metric (2^24 - 1). In OSPF, this can be 233 accomplished by not advertising the link as a regular LSA, but only 234 as a TE opaque LSA. 236 6. Controlling FA-LSPs boundaries 238 To facilitate controlling the boundaries of FA-LSPs this document 239 introduces two new mechanisms: Interface Switching Capability (see 240 [GMPLS-ISIS, GMPLS-OSPF], and "LSP region" (or just "region"). 242 6.1. LSP regions 244 The information carried in the Interface Switching Capabilities is 245 used to construct LSP regions, and determine regions' boundaries as 246 follows. 248 Define an ordering among interface switching capabilities as follows: 249 PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. Given two 250 interfaces if-1 and if-2 with interface switching capabilities isc-1 251 and isc-2 respectively, say that if-1 < if-2 iff isc-1 < isc-2 or 252 isc-1 == isc-2 == TDM, and if-1's max LSP bandwidth is less than 253 if-2's max LSP bandwidth. 255 Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2, 256 node-2, ..., link-n, node-n. Moreover, for link-i denote by [link-i, 257 node-(i-1)] the interface that connects link-i to node-(i-1), and by 258 [link-i, node-i] the interface that connects link-i to node-i. 260 If [link-(i+1), node-i)] < [link-(i+1), node-(i+1)], we say that the 261 LSP has crossed a region boundary at node-i; with respect to that LSP 262 path, the LSR at node-i is an edge LSR. The 'other edge' of the 263 region with respect to the LSP path is node-k, where k is the 264 smallest number greater than i such that [link-(i+1), node-(i+1)] 265 equal [link-k, node-(k-1)], and [link-k, node-(k-1)] > [link-k, node- 266 k]. 268 Path computation may take into account region boundaries when 269 computing a path for an LSP. For example, path computation may 270 restrict the path taken by an LSP to only the links whose Interface 271 Switching Capability is PSC-1. 273 Note that an interface may have multiple Interface Switching 274 Capabilities. In such a case, the test whether if-i < if-j depends 275 on the Interface Switching Capabilities chosen for if-i and if-j, 276 which in turn determines whether or not there is a region boundary at 277 node-i. 279 7. Signalling aspects 281 In this section we describe procedures that an LSR at the head-end of 282 an FA uses for handling LSP setup originated by other LSR. 284 As we mentioned before, establishment/termination of FA-LSPs may 285 triggered either by mechanisms outside of GMPLS (e.g., via 286 administrative control), or by mechanisms within GMPLS (e.g., as a 287 result of the LSR at the edge of an aggregate LSP receiving LSP setup 288 requests originated by some other LSRs beyond LSP aggregate and its 289 edges). Procedures described in Section 7.1 applied to both cases. 290 Procedures described in Section 7.2 apply only to the latter case. 292 7.1. Common procedures 294 For the purpose of processing the ERO in a Path/Request message of an 295 LSP that is to be tunneled over an FA , an LSR at the head-end of the 296 FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP 297 hop away). 299 How this is to be achieved for RSVP-TE and CR-LDP is described in the 300 following subsections. 302 In either case (RSVP-TE or CR-LDP), when an LSP is tunneled through 303 an FA-LSP, the LSR at the head-end of the FA-LSP subtracts the LSP's 304 bandwidth from the unreserved bandwidth of the FA. 306 In the presence of link bundling (when link bundling is applied to 307 FAs), when an LSP is tunneled through an FA-LSP, the LSR at the head- 308 end of the FA-LSP also need to adjust Max LSP bandwidth of the FA. 310 7.1.1. RSVP-TE 312 If one uses RSVP-TE to signal an LSP to be tunneled over an FA-LSP, 313 then the Path message MUST contain an IF_ID RSVP_HOP object [GRSVP- 314 TE, GSIG] instead of an RSVP_HOP object; and the data interface 315 identification MUST identify the FA-LSP. 317 The preferred method of sending the Path message is to set the 318 destination IP address of the Path message to the computed NHOP for 319 that Path message. This NHOP address must be a routable address; in 320 the case of separate control and data planes, this must be a control 321 plane address. 323 Furthermore, the IP header for the Path message MUST NOT have the 324 Router Alert option. The Path message is intended to be IP-routed to 325 the tail end of the FA-LSP without being intercepted and processed as 326 an RSVP message by any of the intermediate nodes. 328 Finally, the IP TTL vs. RSVP TTL check MUST NOT be made. In general, 329 if the IF_ID RSVP_HOP object is used, this check must be disabled, as 330 the number of hops over the control plane may be greater than one. 331 Instead, the following check is done by the receiver Y of the IF_ID 332 RSVP_HOP object: 334 1. Make sure that the data interface identified in the IF_ID 335 RSVP_HOP object actually terminates on Y. 336 2. Find the "other end" of the above data interface, say X. 337 Make sure that the PHOP in the IF_ID RSVP_HOP object is a 338 control channel address that belongs to X. 340 How check #2 is carried out is beyond the scope of this document; 341 suffice it to say that it may require a Traffic Engineering Database, 342 or the use of LMP [LMP] or yet other means. 344 An alternative method is to encapsulate the Path message in an IP 345 tunnel (or, in the case that the Interface Switching Capability of 346 the FA-LSP is PSC[1-4], in the FA-LSP itself), and unicast the 347 message to the tail end of the FA-LSP, without the Router Alert 348 option. This option may be needed if intermediate nodes process RSVP 349 messages regardless of whether the Router Alert option is present. 351 A PathErr sent in response to a Path message with an IF_ID RSVP_HOP 352 object SHOULD contain an IF_ID HOP object. (Note: a PathErr does not 353 normally carry an RSVP_HOP object, but in the case of separated 354 control and data, it is necessary to identify the data channel in the 355 PathErr message.) 357 The Resv message back to the head-end of the FA-LSP (PHOP) is IP- 358 routed to the PHOP in the Path message. If necessary, Resv Messages 359 MAY be encapsulated in another IP header whose destination IP address 360 is the PHOP of the received Path message. 362 7.1.2. CR-LDP 364 If one uses CR-LDP to signal an LSP to be tunneled over an FA-LSP, 365 then the Request message MUST contain an IF_ID TLV [GCR-LDP] object; 366 and the data interface identification MUST identify the FA-LSP. 368 Furthermore, the head end LSR must create a targetted LDP session 369 with the tail end LSR. The Request (Mapping) message is unicast from 370 the head end (tail end) to the tail end (head end). 372 7.2. Specific procedures 374 When an LSR receives a Path/Request message, the LSR determines 375 whether it is at the edge of a region with respect to the ERO carried 376 in the message. The LSR does this by looking up the interface 377 switching capabilities of the previous hop and the next hop in its 378 IGP database, and comparing them using the relation defined in 379 Section 7.2. If the LSR is not at the edge of a region, the 380 procedures in this section do not apply. 382 If the LSR is at the edge of a region, it must then determine the 383 other edge of the region with respect to the ERO, again using the IGP 384 database. The LSR then extracts from the ERO the subsequence of hops 385 from itself to the other end of the region. 387 The LSR then compares the subsequence of hops with all existing FA- 388 LSPs originated by the LSR; if a match is found, that FA-LSP has 389 enough unreserved bandwidth for the LSP being signaled, and the L3PID 390 of the FA-LSP is compatible with the L3PID of the LSP being signaled, 391 the LSR uses that FA-LSP as follows. The Path/Request message for the 392 original LSP is sent to the egress of the FA-LSP, not to the next hop 393 along the FA-LSP's path. The PHOP in the message is the address of 394 the LSR at the head-end of the FA-LSP. Before sending the 395 Path/Request message, the ERO in that message is adjusted by removing 396 the subsequence of the ERO that lies in the FA-LSP, and replacing it 397 with just the end point of the FA-LSP. 399 Otherwise (if no existing FA-LSP is found), the LSR sets up a new FA- 400 LSP. That is, it initiates a new LSP setup just for the FA-LSP. Note 401 that the new LSP may traverse either 'basic' TE links or FAs. 403 After the LSR establishes the new FA-LSP, the LSR announces this LSP 404 into IS-IS/OSPF as an FA. 406 The unreserved bandwidth of the FA is computed by subtracting the 407 bandwidth of sessions pending the establishment of the FA-LSP 408 associated from the bandwidth of the FA-LSP. 410 An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP 411 as a matter of policy local to the LSR. It is expected that the FA- 412 LSP would be torn down once there are no more LSPs carried by the FA- 413 LSP. When the FA-LSP is torn down, the FA associated with the FA-LSP 414 is no longer advertised into IS-IS/OSPF. 416 7.3. FA-LSP Holding Priority 418 The value of the holding priority of an FA-LSP must be the minimum of 419 the configured holding priority of the FA-LSP and the holding 420 priorities of the LSPs tunneling through the FA-LSP (note that 421 smaller priority values denote higher priority). Thus, if an LSP of 422 higher priority than the FA-LSP tunnels through the FA-LSP, the FA- 423 LSP is itself promoted to the higher priority. However, if the 424 tunneled LSP is torn down, the FA-LSP need not drop its priority to 425 its old value right away; it may be advisable to apply hysteresis in 426 this case. 428 If the holding priority of an FA-LSP is configured, this document 429 restricts it to 0. 431 8. Security Considerations 433 Security issues are not discussed in this document. 435 9. Acknowledgements 437 Many thanks to Alan Hannan, whose early discussions with Yakov 438 Rekhter contributed greatly to the notion of Forwarding Adjacencies. 439 We would also like to thank George Swallow, Quaizar Vohra and Ayan 440 Banerjee. 442 10. Normative References 444 [GCR-LDP] Ashwood-Smith, Berger et al, "Generalized MPLS - CR-LDP 445 Extensions" (work in progress). 447 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 448 Extensions in Support of Generalized MPLS", (work in progress). 450 [GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF 451 Extensions in Support of Generalized MPLS", (work in progress). 453 [GRSVP-TE] Ashwood-Smith, Berger et al, "Generalized MPLS - RSVP-TE 454 Extensions" (work in progress). 456 [GSIG] Ashwood-Smith, Berger et al, "Generalized MPLS - Signaling 457 Functional Description" (work in progress). 459 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 460 Engineering", (work in progress). 462 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 463 Extensions to OSPF", (work in progress). 465 [UNNUM-CRLDP] Kompella, K., Rekhter, Y., Kullberg, A., "Signalling 466 Unnumbered Links in CR-LDP", (work in progress). 468 [UNNUM-RSVP] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links 469 in RSVP", (work in progress). 471 11. Non-normative References 473 [BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 474 MPLS Traffic Engineering", (work in progress). 476 [LMP] "Link Management Protocol (LMP)", draft-ietf-ccamp-lmp-02.txt, 477 (work in progress) 478 12. Author Information 480 Kireeti Kompella 481 Juniper Networks, Inc. 482 1194 N. Mathilda Ave 483 Sunnyvale, CA 94089 484 e-mail: kireeti@juniper.net 486 Yakov Rekhter 487 Juniper Networks, Inc. 488 1194 N. Mathilda Ave 489 Sunnyvale, CA 94089 490 e-mail: yakov@juniper.net