idnits 2.17.1 draft-ietf-ccamp-automesh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 493), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == 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 9) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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.) ** There are 177 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 408 has weird spacing: '...afts as refer...' == Line 495 has weird spacing: '...ses and restr...' == Line 499 has weird spacing: '... This docum...' == 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 the flooding scope of an MPLS Traffic Engineering capability is limited to an IS-IS level/area, the TLV MUST not be leaked across level/area and the S flag of the Router CAPABILITY TLV MUST be cleared. Conversely, if the flooding scope of an MPLS Traffic Engineering capability is the entire routing domain, the TLV MUST be leaked across levels for IS-IS the S flag of the CAPABILITY TLV MUST be set. -- 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.) -- The document date (November 2005) is 6729 days in the past. Is this intentional? 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: 'FRR' is mentioned on line 145, but not defined == Missing Reference: 'OSPF' is mentioned on line 159, but not defined == Missing Reference: 'OSPF-CAPS' is mentioned on line 305, but not defined == Missing Reference: 'IS-IS-CAPS' is mentioned on line 305, but not defined == Unused Reference: 'RFC' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 471, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (ref. 'IS-IS-TE') (Obsoleted by RFC 5305) Summary: 11 errors (**), 0 flaws (~~), 21 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP Vasseur (Ed.) 2 Cisco System Inc. 3 IETF Internet Draft JL Le Roux (Ed.) 4 France Telecom 6 Proposed Status: Standard 7 Expires: May 2006 November 2005 9 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 10 Router (LSR) Traffic Engineering (TE) mesh membership 12 draft-ietf-ccamp-automesh-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 The set up of a full mesh of MPLS TE LSPs among a set of Label Switch 44 Router (LSR) is common deployment scenario of MPLS Traffic 45 Engineering either for bandwidth optimization, bandwidth guarantees 46 or fast rerouting with MPLS Fast Reroute. Such deployment requires 47 the configuration of potentially a large number of TE LSPs (on the 48 order of the square of the number LSRs). This document specifies IGP 49 (OSPF and IS-IS) traffic engineering extensions so as to provide an 50 automatic discovery of the set of LSRs members of a mesh, leading to 51 an automatic mechanism to set up TE LSP mesh(es) (also referred to as 52 a mesh-group in this document). 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119. 60 Table of Contents 62 1. Contributors------------------------- 2 63 2. Terminology-------------------------- 3 64 3. Introduction------------------------- 3 65 4. TE mesh-roup------------------------- 4 66 4.1. Description------------------------ 4 67 4.2. Required Information--------------- 4 68 5. TE-MESH-GROUP TLV formats------------ 4 69 5.1. OSPF TE-MESH-GROUP TLV format------ 5 70 5.2. IS-IS TE-MESH-GROUP TLV format----- 6 71 6. Elements of procedure---------------- 7 72 6.1. OSPF------------------------------- 7 73 6.2. IS-IS------------------------------ 7 74 7. Backward compatibility--------------- 8 75 8. Security Considerations-------------- 8 76 9. Intellectual Property Statement------ 8 77 10. Acknowledgment---------------------- 9 78 11. References-------------------------- 9 79 11.1. Normative references-------------- 9 80 11.2. Informative References------------ 9 81 12. Editors' Address-------------------- 10 83 1. Contributors 85 This document was the collective work of several. The text and 86 content of this document was contributed by the editors and the 87 co-authors listed below (the contact information for the editors 88 appears in section 12, and is not repeated below): 90 Paul Mabey Seisho Yasukawa 91 Qwest Communications NTT 92 950 17th street 9-11, Midori-Cho 3-Chome 93 Denver, CO 80202 Musashino-Shi, Tokyo 180-8585 94 USA JAPAN 95 Email: pmabey@qwest.com Email: yasukawa.seisho@lab.ntt.co.jp 96 Stefano Previdi Peter Psenak 97 Cisco System, Inc. Cisco System, Inc. 98 Via del Serafico 200 Pegasus Park 99 00142 Roma DE Kleetlaan 6A 100 ITALY 1831, Diegmen 101 Email: sprevidi@cisco.com BELGIUM 102 Email: ppsenak@cisco.com 104 2. Terminology 106 Terminology used in this document 108 LSR: Label Switch Router. 110 TE LSP: Traffic Engineering Label Switched Path. 112 TE LSP head-end: head/source of the TE LSP. 114 TE LSP tail-end: tail/destination of the TE LSP. 116 IGP Area: OSPF Area or IS-IS level 118 Link State Advertisement: An OSPF LSA or IS-IS LSP 120 Intra-area TE LSP: TE LSP whose path does not transit across 121 areas. 123 Inter-area TE LSP: A TE LSP whose path transits across at least 124 two different IGP areas. 126 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 127 two different ASes or sub-ASes (BGP confederations). 129 3. Introduction 131 As of today, there are different approaches in deploying MPLS Traffic 132 Engineering: 134 (1) The 'systematic' approach consisting of setting up a full 135 mesh of TE LSPs between a set of LSRs, 137 (2) The 'by exception' approach whereby a set of TE LSPs are 138 provisioned on hot spots to alleviate a congestion resulting 139 for instance from an unexpected traffic growth in some part 140 of the network. 142 The set up of a full mesh of MPLS TE LSPs among a set of LSRs is a 143 common deployment scenario of MPLS Traffic Engineering either for 144 bandwidth optimization, bandwidth guarantees or fast rerouting with 145 MPLS Fast Reroute ([FRR]). Setting up a full mesh of TE LSPs between 146 a set of LSRs requires the configuration of a potentially large 147 number of TE LSPs on every head-end LSR. The resulting total number 148 of TE LSP in a full TE mesh of n LSRs is O(n^2). Furthermore, the 149 addition of any new LSR in the mesh requires the configuration of n 150 additional TE LSPs on the new LSR and one new TE LSP on every LSR of 151 the existing mesh terminating to this new LSR, which gives a total of 152 2*n TE LSPs. Such operation is not only time consuming but also a 153 risky operation for Service Providers. Hence, a more automatic 154 mechanism to setting up one or more full meshes of TE LSPs is 155 desirable and requires the ability to automatically discover the LSRs 156 that belong to the mesh. 158 MPLS Traffic Engineering (MPLS-TE) routing ([IS-IS-TE], [OSPF-TE]) 159 relies on extensions to link state IGP routing protocols ([OSPF], 160 [IS-IS]) in order to carry Traffic Engineering link information used 161 for constraint based routing. Generalized MPLS (GMPLS) related 162 routing extensions are defined in [IS-IS-G] and [OSPF-G]. 164 Further routing extensions have been defined in [OSPF-CAPS] and [IS- 165 IS-CAPS] so as to advertise router capabilities. This document 166 specifies IGP (OSPF and IS-IS) traffic engineering capability TLVs in 167 order to provide a mechanism to automatically discover the LSR 168 members of a mesh, leading to an automatic mechanism to set up TE LSP 169 mesh (also referred to as a mesh-group in this document) in a 170 network. The routing extensions specified in this document provide 171 the ability to signal multiple TE meshes whereby an LSR can belong to 172 one or more TE meshes. 174 4. TE mesh-group 176 4.1. Description 178 A TE mesh-group is defined as a group of LSRs that are connected by a 179 full mesh of TE LSPs. It is useful to dynamically advertise the 180 desire of a node to join/leave a particular TE mesh-group. This 181 allows for an automatic provisioning of a full mesh of TE LSPs, and 182 thus drastically reduces the configuration overhead and risk of mis- 183 configuration. 185 4.2. Required Information 187 This document specifies a TE-MESH-GROUP TLV that indicates the set of 188 TE mesh-group(s) an LSR belongs to. For each TE mesh group announced 189 by the LSR, the TE-MESH-GROUP TLV carries the following information: 190 -A mesh-group number identifying the TE mesh-group, 191 -A Tail-end address (address used as a tail end address by other 192 LSRs belonging to the same mesh-group), 193 -A Tail-end name: string used to ease the TE-LSP naming (e.g. 194 'head-name->tail-name'). 196 5. TE-MESH-GROUP TLV formats 197 5.1. OSPF TE-MESH-GROUP TLV format 199 The OSPF TE-MESH-GROUP TLV (carried in an OSPF router information LSA 200 as defined in [OSPF-CAP]) has the following format: 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 // Value // 209 | | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 OSPF TE-MESH-GROUP TLV format 213 Where 214 Type: identifies the TLV type 215 Length: length of the value field in octets 217 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 218 format used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. 219 The TLV is padded to four-octet alignment; padding is not included in 220 the length field (so a three octet value would have a length of 221 three, but the total size of the TLV would be eight octets). Nested 222 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 223 types between 32768 and 65535 are reserved for vendor-specific 224 extensions. All other undefined type codes are reserved for future 225 assignment by IANA. 227 The TE-MESH-GROUP TLV is used to advertise the desire to 228 join/leave a given MPLS TE mesh group. No sub-TLV is currently 229 defined for the TE-mesh-group TLV. 231 The TE-MESH-GROUP TLV has the following format: 233 CODE: 3 234 LENGTH: Variable (N*12 octets) 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | mesh-group-number | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Tail-end address | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Tail-end name | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 // // 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 TE-MESH-GROUP TLV format 249 N is the number of mesh-groups. 251 For each TE mesh group announced by the LSR, the TE-MESH-GROUP TLV 252 contains: 253 - A mesh-group-number: identifies the mesh-group number, 254 - A Tail-end address: user configurable IP address to be used as a 255 tail-end address by other LSRs belonging to the same mesh-group. 256 - A Tail-end name: 32-bits string which facilitates the TE LSP 257 identification which can be very useful in some environments such 258 as inter-area/AS MPLS TE environments. 260 5.2. IS-IS TE-MESH-GROUP TLV format 262 The IS-IS TE-MESH-GROUP TLV is composed of 1 octet for the type, 1 263 octet specifying the TLV length and a value field. 265 The format of the TE-MESH-GROUP TLV is identical to the TLV format 266 used by the Traffic Engineering Extensions to IS-IS [IS-IS-TE]. 268 The TE-MESH-GROUP TLV is used to advertise the desire to join/leave a 269 given TE mesh group. No sub-TLV is currently defined for the TE-MESH- 270 GROUP TLV. 272 The TE-MESH-GROUP TLV has the following format: 274 CODE: 2 275 LENGTH: Variable (N*12 octets) 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | mesh-group-number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Tail-end address | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Tail-end name | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 // // 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 TE-MESH-GROUP TLV format 290 N is the number of mesh-groups. 292 For each Mesh-group announced by an LSR, the TLV contains: 293 - A mesh-group-number: identifies the mesh-group number, 294 - A Tail-end address: user configurable IP address to be used as a 295 tail-end address by other LSRs belonging to the same mesh-group. 296 - A Tail-end name: 32-bits string which facilitates the TE LSP 297 identification which can be very useful in inter-area/AS MPLS TE 298 environments. 300 6. Elements of procedure 302 The TE-MESH-GROUP TLV is carried in Link State Advertisements (LSA) 303 and Router capability TLV (carried itself within a Link State Packet 304 (LSP)) for OSPF and ISIS respectively. As such, elements of 305 procedures are inherited from those defined in [OSPF-CAPS] and [IS- 306 IS-CAPS]. Specifically, a router MUST originate a new LSA/LSP 307 whenever the content of this information changes, or whenever 308 required by regular routing procedure (e.g. refresh). 310 The TE-MESH-GROUP TLV is OPTIONAL. 312 6.1. OSPF 314 The TE-MESH-GROUP TLV is carried within an OSPF router information 315 opaque LSA (opaque type of 4, opaque ID of 0) as defined in [OSPF- 316 CAP]. 318 A router MUST originate a new OSPF router information LSA whenever 319 the content of the any of the carried TLV changes or whenever 320 required by the regular OSPF procedure (LSA refresh (every 321 LSRefreshTime)). 323 As defined in RFC2370, an opaque LSA has a flooding scope determined 324 by its LSA type: 325 - link-local (type 9), 326 - area-local (type 10) 327 - entire OSPF routing domain (type 11). In this case, the 328 flooding scope is equivalent to the Type 5 LSA flooding scope. 330 A router may generate multiple OSPF router information LSAs with 331 different flooding scopes. 333 The TE-MESH-GROUP TLV may be carried within a type 10 or 11 router 334 information LSA depending on the MPLS TE mesh group profile: 336 - If the MPLS TE mesh-group is contained within a single area 337 (all the LSRs have their head-end and tail-end LSR within the 338 same OSPF area), the TE-MESH-GROUP TLV MUST be generated 339 within a Type 10 router information LSA, 340 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE 341 mesh-group TLV MUST be generated within a Type 11 router 342 information LSA, 344 6.2. IS-IS 346 The TE-MESH-GROUP TLV is carried within the IS-IS Router CAPABILITY 347 TLV defined in [IS-IS-CAP]. 349 An IS-IS router MUST originate a new IS-IS LSP whenever the content 350 of the any of the carried sub-TLV changes or whenever required by the 351 regular IS-IS procedure (LSP refresh). 353 If the flooding scope of an MPLS Traffic Engineering capability is 354 limited to an IS-IS level/area, the TLV MUST not be leaked across 355 level/area and the S flag of the Router CAPABILITY TLV MUST be 356 cleared. Conversely, if the flooding scope of an MPLS Traffic 357 Engineering capability is the entire routing domain, the TLV MUST be 358 leaked across levels for IS-IS the S flag of the CAPABILITY TLV MUST 359 be set. 361 In both cases the flooding rules as specified in [IS-IS-CAP] apply. 363 As specified in [IS-IS-CAP], a router may generate multiple IS-IS 364 CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. 366 7. Backward compatibility 368 The TE-MESH-GROUP TLVs defined in this document do not introduce any 369 interoperability issue. For OSPF, a router not supporting the TE- 370 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 371 RFC2370. For IS-IS a router not supporting the TE-MESH-GROUP TLV 372 SHOULD just silently ignore the TLV. 374 8. Security Considerations 376 No new security issues are raised in this document. 378 9. Intellectual Property Statement 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at ietf- 400 ipr@ietf.org. 402 Internet-Drafts are working documents of the Internet Engineering 403 Task Force (IETF), its areas, and its working groups. Note that other 404 groups may also distribute working documents as Internet-Drafts. 406 Internet-Drafts are draft documents valid for a maximum of six 407 months and may be updated, replaced, or obsoleted by other documents 408 at any time. It is inappropriate to use Internet-Drafts as reference 409 material or to cite them other than as "work in progress". 411 10. Acknowledgment 413 We would like to thank Yannick Le Louedec for his useful comments. 415 11. References 417 11.1. Normative references 419 [RFC] Bradner, S., "Key words for use in RFCs to indicate 420 requirements levels", RFC 2119, March 1997. 422 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 423 RFC 3667, February 2004. 425 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 426 Technology", BCP 79, RFC 3668, February 2004. 428 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 430 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 431 Routing Exchange Protocol " ISO 10589. 433 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 434 dual environments", RFC 1195, December 1990. 436 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 437 Extensions to OSPF Version 2", RFC 3630, September 2003. 439 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 440 Engineering", RFC 3784, June 2004. 442 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 443 J.P., "Extensions to OSPF for advertising Optional Router 444 Capabilities", draft-ietf-ospf-cap, work in progress. 446 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 447 router information", draft-ietf-isis-caps, work in progress. 449 11.2. Informative References 451 [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support 452 of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- 453 gmpls-routing-09.txt (work in progress) 455 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 456 Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- 457 gmpls-extensions-12.txt, work in progress. 459 [IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 460 Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- 461 extensions-19.txt, work in progress. 463 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al, 464 "Requirements for inter-area MPLS Traffic Engineering", RFC4105, June 465 2005. 467 [INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic 468 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req, work 469 in progress. 471 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A 472 Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf- 473 ccamp-inter-domain-framework, work in progress. 475 12. Editors' Address 477 Jean-Philippe Vasseur 478 Cisco Systems, Inc. 479 300 Beaver Brook Road 480 Boxborough , MA - 01719 481 USA 482 Email: jpv@cisco.com 484 Jean-Louis Le Roux 485 France Telecom 486 2, avenue Pierre-Marzin 487 22307 Lannion Cedex 488 FRANCE 489 Email: jeanlouis.leroux@francetelecom.com 491 Full Copyright Statement 493 Copyright (C) The Internet Society (2005). 495 This document is subject to the rights, licenses and restrictions 496 contained in BCP 78, and except as set forth therein, the authors 497 retain all their rights." 499 This document and the information contained herein are provided on 500 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 501 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 502 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 503 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 504 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 505 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.