idnits 2.17.1 draft-vasseur-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 3667, Section 5.1 on line 410. -- Found old boilerplate from RFC 3978, Section 5.5 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 390. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 397. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 9 longer pages, the longest (page 2) being 59 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 174 instances of too long lines in the document, the longest one being 6 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 == 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 (February 2005) is 6981 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 146, but not defined == Missing Reference: 'OSPF' is mentioned on line 160, but not defined == Missing Reference: 'OSPF-CAPS' is mentioned on line 308, but not defined == Missing Reference: 'IS-IS-CAPS' is mentioned on line 308, but not defined == Unused Reference: 'RFC' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 434, but no explicit reference was found in the text == Unused Reference: 'RSVP-TE' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'RSVP-G' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 458, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 470, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 478, 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) == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-05 == Outdated reference: A later version (-07) exists of draft-ietf-isis-caps-00 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-framework-00 Summary: 15 errors (**), 0 flaws (~~), 23 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group JP Vasseur (Ed.) 3 Cisco System Inc. 4 IETF Internet Draft JL Le Roux (Ed.) 5 France Telecom 7 Proposed Status: Standard 8 Expires: August 2005 February 2005 10 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 11 Router (LSR) Traffic Engineering (TE) mesh membership 13 draft-vasseur-ccamp-automesh-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or IPR claims of which I am aware have been disclosed, and any 19 of which I become aware will be disclosed, in accordance with RFC 20 3668. 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The set up of a full mesh of MPLS TE LSPs among a set of Label Switch 42 Router (LSR) is common deployment scenario of MPLS Traffic 43 Engineering either for bandwidth optimization, bandwidth guarantees 44 or fast rerouting with MPLS Fast Reroute. Such deployment requires 45 the configuration of potentially a large number of TE LSPs (on the 46 order of the square of the number LSRs). This document specifies IGP 47 (OSPF and IS-IS) traffic engineering extensions so as to provide an 48 automatic discovery of the set of LSRs members of a mesh, leading to 49 an automatic mechanism to set up TE LSP mesh(es) (also referred to as 50 a mesh-group in this document). 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC-2119. 58 Table of Contents 60 1. Contributors------------------------- 2 61 2. Terminology-------------------------- 3 62 3. Introduction------------------------- 3 63 4. TE mesh-roup------------------------- 4 64 4.1. Description------------------------ 4 65 4.2. Required Information--------------- 4 66 5. TE-MESH-GROUP TLV formats------------ 4 67 5.1. OSPF TE-MESH-GROUP TLV format------ 4 68 5.2. IS-IS TE-MESH-GROUP TLV format----- 6 69 6. Elements of procedure---------------- 6 70 6.1. OSPF------------------------------- 7 71 6.2. IS-IS------------------------------ 7 72 7. Backward compatibility--------------- 8 73 8. Security Considerations-------------- 8 74 9. Intellectual Property Statement------ 8 75 9.1. IPR Disclosure Acknowledgement----- 8 76 10. Acknowledgment---------------------- 9 77 11. References-------------------------- 9 78 11.1. Normative references-------------- 9 79 11.2. Informative References------------ 9 80 12. Editors' Address-------------------- 10 82 1. Contributors 84 This document was the collective work of several. The text and 85 content of this document was contributed by the editors and the 86 co-authors listed below (the contact information for the editors 87 appears in section 12, and is not repeated below): 89 Paul Mabey Seisho Yasukawa 90 Qwest Communications NTT 91 950 17th street 9-11, Midori-Cho 3-Chome 92 Denver, CO 80202 Musashino-Shi, Tokyo 180-8585 93 USA JAPAN 94 Email: pmabey@qwest.com Email: yasukawa.seisho@lab.ntt.co.jp 96 Stefano Previdi Peter Psenak 97 Cisco System, Inc. Cisco System, Inc. 99 Via del Serafico 200 Pegasus Park 100 00142 Roma DE Kleetlaan 6A 101 ITALY 1831, Diegmen 102 Email: sprevidi@cisco.com BELGIUM 103 Email: ppsenak@cisco.com 105 2. Terminology 107 Terminology used in this document 109 LSR: Label Switch Router. 111 TE LSP: Traffic Engineering Label Switched Path. 113 TE LSP head-end: head/source of the TE LSP. 115 TE LSP tail-end: tail/destination of the TE LSP. 117 IGP Area: OSPF Area or IS-IS level 119 Link State Advertisement: An OSPF LSA or IS-IS LSP 121 Intra-area TE LSP: TE LSP whose path does not transit across 122 areas. 124 Inter-area TE LSP: A TE LSP whose path transits across at least 125 two different IGP areas. 127 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 128 two different ASes or sub-ASes (BGP confederations). 130 3. Introduction 132 As of today, there are different approaches in deploying MPLS Traffic 133 Engineering: 135 (1) The 'systematic' approach consisting of setting up a full 136 mesh of TE LSPs between a set of LSRs, 138 (2) The 'by exception' approach whereby a set of TE LSPs are 139 provisioned on hot spots to alleviate a congestion resulting 140 for instance from an unexpected traffic growth in some part 141 of the network. 143 The set up of a full mesh of MPLS TE LSPs among a set of LSRs is a 144 common deployment scenario of MPLS Traffic Engineering either for 145 bandwidth optimization, bandwidth guarantees or fast rerouting with 146 MPLS Fast Reroute ([FRR]). Setting up a full mesh of TE LSPs between 147 a set of LSRs requires the configuration of a potentially large 148 number of TE LSPs on every head-end LSR. The resulting total number 149 of TE LSP in a full TE mesh of n LSRs is O(n^2). Furthermore, the 150 addition of any new LSR in the mesh requires the configuration of n 151 additional TE LSPs on the new LSR and one new TE LSP on every LSR of 152 the existing mesh terminating to this new LSR, which gives a total of 153 2*n TE LSPs. Such operation is not only time consuming but also a 154 risky operation for Service Providers. Hence, a more automatic 155 mechanism to setting up one or more full meshes of TE LSPs is 156 desirable and requires the ability to automatically discover the LSRs 157 that belong to the mesh. 159 MPLS Traffic Engineering (MPLS-TE) routing ([IS-IS-TE], [OSPF-TE]) 160 relies on extensions to link state IGP routing protocols ([OSPF], 161 [IS-IS]) in order to carry Traffic Engineering link information used 162 for constraint based routing. Generalized MPLS (GMPLS) related 163 routing extensions are defined in [IS-IS-G] and [OSPF-G]. 165 Further routing extensions have been defined in [OSPF-CAPS] and [IS- 166 IS-CAPS] so as to advertise router capabilities. This document 167 specifies IGP (OSPF and IS-IS) traffic engineering capability TLVs in 168 order to provide a mechanism to automatically discover the LSR 169 members of a mesh, leading to an automatic mechanism to set up TE LSP 170 mesh (also referred to as a mesh-group in this document) in a 171 network. The routing extensions specified in this document provide 172 the ability to signal multiple TE meshes whereby an LSR can belong to 173 one or more TE meshes. 175 4. TE mesh-group 177 4.1. Description 179 A TE mesh-group is defined as a group of LSRs that are connected by a 180 full mesh of TE LSPs. It is useful to dynamically advertise the 181 desire of a node to join/leave a particular TE mesh-group. This 182 allows for an automatic provisioning of a full mesh of TE LSPs, and 183 thus drastically reduces the configuration overhead and risk of mis- 184 configuration. 186 4.2. Required Information 188 This document specifies a TE-MESH-GROUP TLV that indicates the set of 189 TE mesh-group(s) an LSR belongs to. For each TE mesh group announced 190 by the LSR, the TE-MESH-GROUP TLV carries the following information: 191 -A mesh-group number identifying the TE mesh-group, 192 -A Tail-end address (address used as a tail end address by other 193 LSRs belonging to the same mesh-group), 194 -A Tail-end name: string used to ease the TE-LSP naming (e.g. 195 'head-name->tail-name'). 197 5. TE-MESH-GROUP TLV formats 199 5.1. OSPF TE-MESH-GROUP TLV format 201 The OSPF TE-MESH-GROUP TLV (carried in an OSPF router information LSA 202 as defined in [OSPF-CAP]) has the following format: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | | 210 // Value // 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 OSPF TE-MESH-GROUP TLV format 215 Where 216 Type: identifies the TLV type 217 Length: length of the value field in octets 219 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 220 format used by the Traffic Engineering Extensions to OSPF [OSPF-TE]. 221 The TLV is padded to four-octet alignment; padding is not included in 222 the length field (so a three octet value would have a length of 223 three, but the total size of the TLV would be eight octets). Nested 224 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 225 types between 32768 and 65535 are reserved for vendor-specific 226 extensions. All other undefined type codes are reserved for future 227 assignment by IANA. 229 The TE-MESH-GROUP TLV is used to advertise the desire to 230 join/leave a given MPLS TE mesh group. No sub-TLV is currently 231 defined for the TE-mesh-group TLV. 233 The TE-MESH-GROUP TLV has the following format: 235 CODE: 3 236 LENGTH: Variable (N*12 octets) 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | mesh-group-number | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Tail-end address | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Tail-end name | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 // // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 TE-MESH-GROUP TLV format 251 N is the number of mesh-groups. 253 For each TE mesh group announced by the LSR, the TE-MESH-GROUP TLV 254 contains: 256 - A mesh-group-number: identifies the mesh-group number, 257 - A Tail-end address: user configurable IP address to be used as a 258 tail-end address by other LSRs belonging to the same mesh-group. 259 - A Tail-end name: 32-bits string which facilitates the TE LSP 260 identification which can be very useful in some environments such 261 as inter-area/AS MPLS TE environments. 263 5.2. IS-IS TE-MESH-GROUP TLV format 265 The IS-IS TE-MESH-GROUP TLV is composed of 1 octet for the type, 1 266 octet specifying the TLV length and a value field. 268 The format of the TE-MESH-GROUP TLV is identical to the TLV format 269 used by the Traffic Engineering Extensions to IS-IS [IS-IS-TE]. 271 The TE-MESH-GROUP TLV is used to advertise the desire to join/leave a 272 given TE mesh group. No sub-TLV is currently defined for the TE-MESH- 273 GROUP TLV. 275 The TE-MESH-GROUP TLV has the following format: 277 CODE: 2 278 LENGTH: Variable (N*12 octets) 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | mesh-group-number | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Tail-end address | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Tail-end name | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 // // 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 TE-MESH-GROUP TLV format 293 N is the number of mesh-groups. 295 For each Mesh-group announced by an LSR, the TLV contains: 296 - A mesh-group-number: identifies the mesh-group number, 297 - A Tail-end address: user configurable IP address to be used as a 298 tail-end address by other LSRs belonging to the same mesh-group. 299 - A Tail-end name: 32-bits string which facilitates the TE LSP 300 identification which can be very useful in inter-area/AS MPLS TE 301 environments. 303 6. Elements of procedure 305 The TE-MESH-GROUP TLV is carried in Link State Advertisements (LSA) 306 and Router capability TLV (carried itself within a Link State Packet 307 (LSP)) for OSPF and ISIS respectively. As such, elements of 308 procedures are inherited from those defined in [OSPF-CAPS] and [IS- 309 IS-CAPS]. Specifically, a router MUST originate a new LSA/LSP 310 whenever the content of this information changes, or whenever 311 required by regular routing procedure (e.g. refresh). 313 The TE-MESH-GROUP TLV is OPTIONAL. 315 6.1. OSPF 317 The TE-MESH-GROUP TLV is carried within an OSPF router information 318 opaque LSA (opaque type of 4, opaque ID of 0) as defined in [OSPF- 319 CAP]. 321 A router MUST originate a new OSPF router information LSA whenever 322 the content of the any of the carried TLV changes or whenever 323 required by the regular OSPF procedure (LSA refresh (every 324 LSRefreshTime)). 326 As defined in RFC2370, an opaque LSA has a flooding scope determined 327 by its LSA type: 328 - link-local (type 9), 329 - area-local (type 10) 330 - entire OSPF routing domain (type 11). In this case, the 331 flooding scope is equivalent to the Type 5 LSA flooding scope. 333 A router may generate multiple OSPF router information LSAs with 334 different flooding scopes. 336 The TE-MESH-GROUP TLV may be carried within a type 10 or 11 router 337 information LSA depending on the MPLS TE mesh group profile: 339 - If the MPLS TE mesh-group is contained within a single area 340 (all the LSRs have their head-end and tail-end LSR within the 341 same OSPF area), the TE-MESH-GROUP TLV MUST be generated 342 within a Type 10 router information LSA, 343 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE 344 mesh-group TLV MUST be generated within a Type 11 router 345 information LSA, 347 6.2. IS-IS 349 The TE-MESH-GROUP TLV is carried within the IS-IS Router CAPABILITY 350 TLV defined in [IS-IS-CAP]. 352 An IS-IS router MUST originate a new IS-IS LSP whenever the content 353 of the any of the carried sub-TLV changes or whenever required by the 354 regular IS-IS procedure (LSP refresh). 356 If the flooding scope of an MPLS Traffic Engineering capability is 357 limited to an IS-IS level/area, the TLV MUST not be leaked across 358 level/area and the S flag of the Router CAPABILITY TLV MUST be 359 cleared. Conversely, if the flooding scope of an MPLS Traffic 360 Engineering capability is the entire routing domain, the TLV MUST be 361 leaked across levels for IS-IS the S flag of the CAPABILITY TLV MUST 362 be set. 364 In both cases the flooding rules as specified in [IS-IS-CAP] apply. 366 As specified in [IS-IS-CAP], a router may generate multiple IS-IS 367 CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. 369 7. Backward compatibility 371 The TE-MESH-GROUP TLVs defined in this document do not introduce any 372 interoperability issue. For OSPF, a router not supporting the TE- 373 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 374 RFC2370. For IS-IS a router not supporting the TE-MESH-GROUP TLV 375 SHOULD just silently ignore the TLV. 377 8. Security Considerations 379 No new security issues are raised in this document. 381 9. Intellectual Property Statement 383 The IETF takes no position regarding the validity or scope of any 384 Intellectual Property Rights or other rights that might be claimed to 385 pertain to the implementation or use of the technology described in 386 this document or the extent to which any license under such rights 387 might or might not be available; nor does it represent that it has 388 made any independent effort to identify any such rights. Information 389 on the procedures with respect to rights in RFC documents can be 390 found in BCP 78 and BCP 79. 392 Copies of IPR disclosures made to the IETF Secretariat and any 393 assurances of licenses to be made available, or the result of an 394 attempt made to obtain a general license or permission for the use of 395 such proprietary rights by implementers or users of this 396 specification can be obtained from the IETF on-line IPR repository at 397 http://www.ietf.org/ipr. 399 The IETF invites any interested party to bring to its attention any 400 copyrights, patents or patent applications, or other proprietary 401 rights that may cover technology that may be required to implement 402 this standard. Please address the information to the IETF at ietf- 403 ipr@ietf.org.. 405 9.1. IPR Disclosure Acknowledgement 407 By submitting this Internet-Draft, I certify that any applicable 408 patent or other IPR claims of which I am aware have been disclosed, 409 and any of which I become aware will be disclosed, in accordance with 410 RFC 3668. 412 10. Acknowledgment 414 We would like to thank Yannick Le Louedec for his useful comments. 416 11. References 418 11.1. Normative references 420 [RFC] Bradner, S., "Key words for use in RFCs to indicate 421 requirements levels", RFC 2119, March 1997. 423 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 424 RFC 3667, February 2004. 426 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 427 Technology", BCP 79, RFC 3668, February 2004. 429 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 431 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 432 Routing Exchange Protocol " ISO 10589. 434 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 435 dual environments", RFC 1195, December 1990. 437 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 438 Extensions to OSPF Version 2", RFC 3630, September 2003. 440 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 441 Engineering", RFC 3784, June 2004. 443 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 444 J.P., "Extensions to OSPF for advertising Optional Router 445 Capabilities", draft-ietf-ospf-cap-05.txt, work in progress. 447 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 448 router information", draft-ietf-isis-caps-00.txt, work in progress. 450 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 451 tunnels", RFC 3209, December 2001. 453 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 454 RFC 3473, January 2003. 456 11.2. Informative References 458 [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support 459 of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- 460 gmpls-routing-09.txt (work in progress) 462 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 463 Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- 464 gmpls-extensions-12.txt, work in progress. 466 [IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 467 Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- 468 extensions-19.txt, work in progress. 470 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J. et al, 471 "Requirements for inter-area MPLS Traffic Engineering", draft-ietf- 472 tewg-interarea-mpls-te-req-03.txt, work in progress. 474 [INT-AS-REQ] Zhang, R., Vasseur, J.P. et al, "MPLS Inter-AS Traffic 475 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req- 476 09.txt, work in progress. 478 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A 479 Framework for Inter-Domain MPLS Traffic Engineering", draft-ietf- 480 ccamp-inter-domain-framework-00.txt, work in progress. 482 12. Editors' Address 484 Jean-Philippe Vasseur 485 Cisco Systems, Inc. 486 300 Beaver Brook Road 487 Boxborough , MA - 01719 488 USA 489 Email: jpv@cisco.com 491 Jean-Louis Le Roux 492 France Telecom 493 2, avenue Pierre-Marzin 494 22307 Lannion Cedex 495 FRANCE 496 Email: jeanlouis.leroux@francetelecom.com 498 Full Copyright Statement 500 Copyright (C) The Internet Society (2005). This document is subject to 501 the rights, licenses and restrictions contained in BCP 78, and except as 502 set forth therein, the authors retain all their rights. 504 This document and the information contained herein are provided on an 505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 506 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.