idnits 2.17.1 draft-vasseur-ccamp-te-node-cap-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 501. -- Found old boilerplate from RFC 3978, Section 5.5 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 488. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 494. ** 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 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 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.) 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: Note that a change in any of these capabilities MAY trigger CSPF computation, but MUST not trigger normal SPF computation. == 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: Note that a change in any of these capabilities MAY trigger CSPF computation, but MUST not trigger normal SPF computation. -- 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 7009 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: 'OSPF' is mentioned on line 122, but not defined == Missing Reference: 'ISIS-CAP' is mentioned on line 376, but not defined == Missing Reference: 'ISIS-TE' is mentioned on line 357, but not defined == Unused Reference: 'RFC' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'OSPF-v2' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'IS-IS-IP' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RTG' is defined on line 550, 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 (-04) exists of draft-ietf-mpls-p2mp-sig-requirement-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-rsvp-te-p2mp-01 Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP 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: August 2005 February 2005 9 Routing extensions for discovery of Traffic Engineering Node 10 Capabilities 12 draft-vasseur-ccamp-te-node-cap-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or IPR claims of which I am aware have been disclosed, and any 18 of which I become aware will be disclosed, in accordance with RFC 19 3668. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 It is highly desired in several cases, to take into account Traffic 41 Engineering (TE) node capabilities during TE LSP path selection, such 42 as for instance the capability to act as a branch LSR of a P2MP LSP. 43 This requires advertising these capabilities within the IGP. 44 For that purpose, this document specifies OSPF and IS-IS traffic 45 engineering extensions for the advertisement of control plane and 46 data plane traffic engineering node capabilities. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119. 54 Table of Contents 56 1. Contributors................................................3 57 2. Terminology.................................................3 58 3. Introduction................................................4 59 4. TE Node Capability Descriptor...............................4 60 4.1. Description.................................................4 61 4.2. Required Information........................................5 62 5. OSPF TE extensions..........................................6 63 5.1. OSPF TE Node Capability Descriptor TLV format...............6 64 5.1.1. The DATA-PLANE-CAP sub-TLV..................................7 65 5.1.2. The CONTROL-PLANE-CAP sub-TLV...............................8 66 5.2. Elements of Procedure.......................................9 67 6. IS-IS TE Extensions........................................10 68 6.1. IS-IS TE Node Capability Descriptor TLV format.............10 69 6.1.1. DATA-PLANE-CAP sub-TLV.....................................10 70 6.1.2. CONTROL-PLANE-CAP sub-TLV..................................11 71 6.2. Elements of procedure......................................12 72 7. Backward compatibility.....................................12 73 8. Security Considerations....................................12 74 9. Intellectual Property Statement............................12 75 9.1. IPR Disclosure Acknowledgement.............................13 76 10. Acknowledgments............................................13 77 11. References.................................................13 78 11.1. Normative references.......................................13 79 11.2. Informative References.....................................14 80 12. Editors' Address...........................................14 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. 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 LSR: Label Switch Router. 108 TE LSP: Traffic Engineering Label Switched Path. 110 P2MP TE LSP: A TE LSP that has one unique 111 ingress LSR and one or more egress LSRs. 113 Branch LSR: An LSR on a P2MP LSP that has more than one directly 114 connected downstream LSRs. 116 Bud-LSR: An LSR on a P2MP LSP, that is an egress, but also has one or 117 more directly connected downstream LSRs. 119 3. Introduction 121 MPLS Traffic Engineering (MPLS-TE) routing ([IS-IS-TE], [OSPF-TE]) 122 relies on extensions to link state IGP routing protocols ([OSPF], 123 [IS-IS]) in order to carry Traffic Engineering (TE) link information 124 used for constraint based routing. Further Generalized MPLS (GMPLS) 125 related routing extensions are defined in [IS-IS-G] and [OSPF-G]. 127 It is desired to complement these routing extensions in order to 128 carry TE node capabilities, in addition to TE link information. These 129 TE node capabilities will be taken into account as constraints during 130 path selection. 131 Indeed, it is useful to advertise data plane TE node capabilities, 132 such as, for instance the capability to be a branch LSR or a bud-LSR 133 of a P2MP LSP. These capabilities are then taken into account as 134 constraints when computing TE LSP paths. 135 It is also useful to advertise control plane TE node capabilities 136 such as for instance the capability to support GMPLS 137 signaling for a packet LSR, or the capability to support P2MP (Point 138 to Multipoint) TE LSP signaling. This allows selecting a path that 139 avoids nodes that do not support a given signaling feature, or 140 triggering a mechanism to support such nodes. Hence this facilitates 141 backward compatibility. 143 For that purpose, this document specifies IGP (OSPF and IS-IS) 144 traffic engineering node capability TLVs in order to advertise data 145 plane and control plane capabilities of a node. 147 A new TLV is defined for ISIS and OSPF: the TE Node Capability 148 Descriptor TLV, to be carried within: 149 - the ISIS Capability TLV ([ISIS-CAP]) for ISIS 150 - the Router Information LSA ([OSPF-CAP]), for OSPF. 152 4. TE Node Capability Descriptor 154 4.1. Description 156 LSRs in a network may have distinct control plane and data plane 157 Traffic Engineering capabilities. The TE Node Capability Descriptor 158 information defined in this document describes data and control plane 159 capabilities of an LSR. Such information can be used for instance 160 during path computation so as to avoid nodes that do not support a 161 given TE feature either in the control or data plane or to trigger 162 procedure to handle these nodes. In some cases, this may also be 163 useful to ensure backward compatibility. 165 4.2. Required Information 167 The TE Node Capability Descriptor contains two variable length sets 168 of bit flags: 169 -The Data Plane Capabilities: This a variable length 170 set of bit flags where each bit corresponds to a given TE data plane 171 capability. 172 -The Control Plane Capabilities: This a variable length 173 set of bit flags where each bit corresponds to a given TE control 174 plane capability. 176 Two Data Plane Capabilities are currently defined: 177 -B bit: when set, this flag indicates that the LSR can act 178 as a branch node on a P2MP LSP (see [P2MP-REQ]) and [RSVP- 179 P2MP]). 180 -E bit: when set, this flag indicates that the LSR can act 181 as a bud LSR on a P2MP LSP, i.e. an LSR that is both 182 transit and egress. 184 Three Control Plane Capabilities are currently defined: 185 -M bit: when set, this flag indicates that the LSR supports 186 MPLS-TE signaling ([RSVP-TE]). 187 -G bit: when set this flag indicates that the LSR supports 188 GMPLS signaling ([RSVP-G]). 189 -P bit: when set, this flag indicates that the LSR supports 190 P2MP MPLS-TE signaling ([RSVP-P2MP]). 192 Note that new capabilities may be added in the future if required. 194 5. OSPF TE extensions 196 5.1. OSPF TE Node Capability Descriptor TLV format 198 The OSPF TE Node Capability Descriptor TLV is made of various non 199 ordered sub-TLVs. 200 The format of the OSPF TE Node Capability Descriptor TLV and its sub- 201 TLVs is the same as the TLV format used by the Traffic Engineering 202 Extensions to OSPF [OSPF-TE]. That is, the TLV is composed of 2 203 octets for the type, 2 octets specifying the TLV length and a value 204 field. 205 The TLV is padded to four-octet alignment; padding is not included in 206 the length field (so a three octet value would have a length of 207 three, but the total size of the TLV would be eight octets). Nested 208 TLVs are also 32-bit aligned. Unrecognized types are ignored. All 209 types between 32768 and 65535 are reserved for vendor-specific 210 extensions. All other undefined type codes are reserved for future 211 assignment by IANA. 213 The OSPF TE Node Capability Descriptor TLV has the following format: 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Type | Length | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 // sub-TLVs // 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Type To be defined by IANA 225 Length Variable 226 Value This comprises one or more sub-TLVs 228 Currently two sub-TLVs are defined: 229 Sub-TLV type Length Name 230 1 variable DATA-PLANE-CAP sub-TLV 231 2 variable CONTROL-PLANE-CAP sub-TLV 233 Any non recognized sub-TLV MUST be silently ignored. 234 More sub-TLVs could be added in the future to handle new 235 capabilities. 237 The OSPF TE Node Capability Descriptor TLV is carried within an OSPF 238 router information LSA which is defined in [OSPF-CAP]. 240 5.1.1. The DATA-PLANE-CAP sub-TLV 242 The DATA-PLANE-CAP sub-TLV is a series of bit flags, where each bit 243 correspond to a data plane TE node capability, and has a variable 244 length. 246 The format of the DATA-PLANE-CAP sub-TLV is as follows: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Data Plane TE Node Capabilities | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Type Set to 1. 257 Length It is set to N x 4 octets. N starts 258 from 1 and can be increased when there is a need. 259 Each 4 260 octets are referred to as a capability flag. 261 Value This comprises one or more capability flags. 262 For each 4 octets, the bits are indexed from the most 263 Significant to the least significant, where each bit 264 represents one data plane TE node capability. When 265 the first 32 capabilities are defined, a new 266 capability flag will be used to accommodate the next 267 capability. 269 The following bits in the first capability flag have been assigned: 271 Bit Capabilities 273 0 B bit: P2MP Branch Node capability: When set this indicates 274 that the LSR can act as a branch node on a P2MP LSP 275 [P2MP-REQ]; 276 1 E bit: P2MP Bud-LSR capability: When set, this indicates 277 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 278 LSR that is both transit and egress [P2MP-REQ]; 280 2-31 Future assignments. 282 5.1.2. The CONTROL-PLANE-CAP sub-TLV 284 The CONTROL-PLANE-CAP sub-TLV is a series of bit flags, where each 285 bit correspond to a control plane TE node capability, and has a 286 variable length. 288 The format of the CONTROL-PLANE-CAP sub-TLV is as follows: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Control Plane TE Node Capabilities | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Type Set to 1. 299 Length It is set to N x 4 octets. N starts 300 from 1 and can be increased when there is a need. 301 Each 4 octets are referred to as a capability flag. 302 Value This comprises one or more capability flags. 303 For each 4 octets, the bits are indexed from the most 304 Significant to the least significant, where each bit 305 represents one control plane TE node capability. When 306 the first 32 capabilities are defined, a new 307 capability flag will be used to accommodate the next 308 capability. 310 The following bits in the first capability flag have been assigned: 312 Bit Capabilities 314 0 M bit: If set this indicates that the LSR supports 315 MPLS-TE signaling ([RSVP-TE]). 317 1 G bit: If set this indicates that the LSR supports 318 GMPLS signaling ([RSVP-G]). 320 2 P bit: If set this indicates that the LSR supports 321 P2MP MPLS-TE signaling ([RSVP-P2MP]). 323 3-31 Future assignments 325 5.2. Elements of Procedure 327 The TE Node Capability Descriptor TLV is carried within an OSPF 328 Router information opaque LSA (opaque type of 4, opaque ID of 0) 329 which is defined in [OSPF-CAP]. 331 A router MUST originate a new OSPF router information LSA whenever 332 the content of any of the carried TLVs changes or whenever 333 required by the regular OSPF procedure (LSA refresh (every 334 LSRefreshTime)). 336 The TE Node Capability Descriptor TLV advertises capabilities that 337 are taken into account as constraints during path selection. Hence 338 its flooding scope is area-local, and MUST be carried within a type 339 10 router information LSA. 341 TE Node Capability Descriptor TLVs are OPTIONAL. When an OSPF LSA 342 does not contain any TE Node capability Descriptor TLV, this means 343 that the TE Capabilities of that LSR are unknown. 345 Note that a change in any of these capabilities MAY trigger CSPF 346 computation, but MUST not trigger normal SPF computation. 348 6. IS-IS TE Extensions 350 6.1. IS-IS TE Node Capability Descriptor TLV format 352 The IS-IS TE Node Capability Descriptor TLV is made of various non 353 ordered sub-TLVs. 355 The format of the IS-IS TE Node Capability TLV and its sub-TLVs is 356 the same as the TLV format used by the Traffic Engineering Extensions 357 to IS-IS [ISIS-TE]. That is, the TLV is composed of 1 octet for the 358 type, 1 octet specifying the TLV length and a value field. 360 The IS-IS TE Node Capability Descriptor TLV has the following format: 362 TYPE: To be assigned by IANA 363 LENGTH: Variable, from 3 to 255 364 VALUE: set of one or more sub-TLVs 366 Currently two sub-TLVs are defined: 367 Sub-TLV type Length Name 368 1 variable DATA-PLANE-CAP sub-TLV 369 2 variable CONTROL-PLANE-CAP sub-TLV 371 Any non recognized sub-TLV MUST be silently ignored. 372 More sub-TLVs could be added in the future to handle new 373 capabilities. 375 The IS-IS TE Node Capability Descriptor TLV is carried within an IS- 376 IS CAPABILITY TLV which is defined in [ISIS-CAP]. 378 6.1.1. DATA-PLANE-CAP sub-TLV 380 The DATA-PLANE-CAP sub-TLV is a series of bit flags, where each bit 381 correspond to a data plane TE node capability, and has a variable 382 length. 384 The DATA-PLANE-CAP sub-TLV has the following format: 386 TYPE: It is set to 1 387 LENGTH: It is set to N. N starts from 1 and can be increased when 388 there is a need. Each octet is referred to as a 389 capability flag. 390 VALUE: This comprises one or more data plane TE node capability 391 flags. 393 The following bits in the first capability flag have been assigned: 395 0 1 2 3 4 5 6 7 396 +-+-+-+-+-+-+-+-+ 397 |B|E| Reserved | 398 +-+-+-+-+-+-+-+-+ 400 B bit: P2MP Branch node capability: When set this indicates 401 that the LSR can act as a branch node on a P2MP LSP 402 [P2MP-REQ] 403 E bit: P2MP bud-LSR capability: When set, this indicates 404 that the LSR can act as a bud LSR on a P2MP LSP, i.e. an 405 LSR that is both transit and egress [P2MP-REQ]. 407 6.1.2. CONTROL-PLANE-CAP sub-TLV 409 The CONTROL-PLANE-CAP sub-TLV is a series of bit flags, where each 410 bit correspond to a control plane TE node capability, and has a 411 variable length. 413 The CONTROL-PLANE-CAP sub-TLV has the following format: 415 TYPE: It is set to 2 416 LENGTH: It is set to N. N starts from 1 and can be increased 417 when there is a need. Each octet is referred to as a 418 capability flag. 419 VALUE: This comprises one or more control plane TE node capability 420 flags. 422 The following bits in the first capability flag have been assigned: 424 0 1 2 3 4 5 6 7 425 +-+-+-+-+-+-+-+-+ 426 |M|G|P|Reserved | 427 +-+-+-+-+-+-+-+-+ 429 -M bit: If set this indicates that the LSR supports MPLS-TE 430 signaling ([RSVP-TE]). 432 -G bit: If set this indicates that the LSR supports GMPLS signaling 433 ([RSVP-G]). 435 -P bit: If set this indicates that the LSR supports P2MP MPLS-TE 436 signaling ([RSVP-P2MP]). 438 6.2. Elements of procedure 440 The TE Node Capability TLV is carried within an IS-IS Router 441 CAPABILITY TLV defined in [IS-IS-CAP]. 443 An IS-IS router MUST originate a new IS-IS LSP whenever the content 444 of any of the TE Node Capability TLV changes or whenever required by 445 the regular IS-IS procedure (LSP refresh). 447 The TE Node Capability Descriptor TLV advertises capabilities that 448 are taken into account as constraints during path selection. Hence 449 its flooding is area-local, and MUST be carried within an IS-IS 450 CAPABILITY TLV having the S flag cleared. 452 TE Node Capability Descriptor TLVs are OPTIONAL. When a IS-IS LSP 453 does not contain any TE Node capability Descriptor TLV, this means 454 that the TE Capabilities of that LSR are unknown. 456 Note that a change in any of these capabilities MAY trigger CSPF 457 computation, but MUST not trigger normal SPF computation. 459 7. Backward compatibility 461 The TE Node Capability Descriptor TLVs defined in this document do 462 not introduce any interoperability issue. For OSPF, a router not 463 supporting the TE Node Capability Descriptor TLV SHOULD just silently 464 ignore the TLV as specified in RFC2370. For IS-IS a router not 465 supporting the TE Node Capability Descriptor TLV SHOULD just silently 466 ignore the TLV. 468 8. Security Considerations 470 No new security issues are raised in this document. 472 9. Intellectual Property Statement 474 The IETF takes no position regarding the validity or scope of any 475 Intellectual Property Rights or other rights that might be claimed to 476 pertain to the implementation or use of the technology described in 477 this document or the extent to which any license under such rights 478 might or might not be available; nor does it represent that it has 479 made any independent effort to identify any such rights. Information 480 on the procedures with respect to rights in RFC documents can be 481 found in BCP 78 and BCP 79. 483 Copies of IPR disclosures made to the IETF Secretariat and any 484 assurances of licenses to be made available, or the result of an 485 attempt made to obtain a general license or permission for the use of 486 such proprietary rights by implementers or users of this 487 specification can be obtained from the IETF on-line IPR repository at 488 http://www.ietf.org/ipr. 490 The IETF invites any interested party to bring to its attention any 491 copyrights, patents or patent applications, or other proprietary 492 rights that may cover technology that may be required to implement 493 this standard. Please address the information to the IETF at ietf- 494 ipr@ietf.org. 496 9.1. IPR Disclosure Acknowledgement 498 By submitting this Internet-Draft, I certify that any applicable 499 patent or other IPR claims of which I am aware have been disclosed, 500 and any of which I become aware will be disclosed, in accordance with 501 RFC 3668. 503 10. Acknowledgments 505 We would like to thank Benoit Fondeviole for its useful comments and 506 suggestions. 508 11. References 510 11.1. Normative references 512 [RFC] Bradner, S., "Key words for use in RFCs to indicate 513 requirements levels", RFC 2119, March 1997. 515 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 516 RFC 3667, February 2004. 518 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 519 Technology", BCP 79, RFC 3668, February 2004. 521 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 523 [IS-IS] "Intermediate System to Intermediate System Intra-Domain 524 Routing Exchange Protocol " ISO 10589. 526 [IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 527 dual environments", RFC 1195, December 1990. 529 [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 530 Extensions to OSPF Version 2", RFC 3630, September 2003. 532 [IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 533 Engineering", RFC 3784, June 2004. 535 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, 536 J.P., "Extensions to OSPF for advertising Optional Router 537 Capabilities", draft-ietf-ospf-cap-05.txt, work in progress. 539 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 540 router information", draft-ietf-isis-caps-00.txt, work in progress. 542 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 543 tunnels", RFC 3209, December 2001. 545 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 546 RFC 3473, January 2003. 548 11.2. Informative References 550 [GMPLS-RTG] Kompella, K., Rekhter, Y., "Routing Extensions in Support 551 of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp- 552 gmpls-routing-09.txt (work in progress) 554 [OSPF-G] Kompella, K., Rekhter, Y., "OSPF extensions in support of 555 Generalized Multi-protocol Label Switching", draft-ietf-ccamp-ospf- 556 gmpls-extensions-12.txt, work in progress. 558 [IS-IS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 559 Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- 560 extensions-19.txt, work in progress. 562 [P2MP-REQ] Yasukawa, S., et. al., "Signaling Requirements for Point 563 to Multipoint Traffic Engineered MPLS LSPs", draft-ietf-mpls-p2mp- 564 sig-requirement-00.txt, work in progress. 566 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 567 RSVP-TE for point-to-multipoint TE LSPs", draft-ietf-mpls-rsvp-te- 568 p2mp-01.txt, work in progress. 570 12. Editors' Address 572 Jean-Philippe Vasseur 573 Cisco Systems, Inc. 574 300 Beaver Brook Road 575 Boxborough , MA - 01719 576 USA 577 Email: jpv@cisco.com 579 Jean-Louis Le Roux 580 France Telecom 581 2, avenue Pierre-Marzin 582 22307 Lannion Cedex 583 FRANCE 584 Email: jeanlouis.leroux@francetelecom.com 586 Full Copyright Statement 588 Copyright (C) The Internet Society (2005). This document is subject to 589 the rights, licenses and restrictions contained in BCP 78, and except as 590 set forth therein, the authors retain all their rights. 592 This document and the information contained herein are provided on an 593 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 594 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 595 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 596 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 597 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 598 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.