idnits 2.17.1 draft-vasseur-isis-te-caps-00.txt: -(311): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(360): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 588. ** 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: ---------------------------------------------------------------------------- ** 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? == There are 2 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 11) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 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 242 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 == Line 231 has weird spacing: '...used to reach...' -- 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 (July 2004) is 7218 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: 'IS-IS-CAP' is mentioned on line 411, but not defined == Missing Reference: 'IS-IS-TE' is mentioned on line 119, but not defined == Missing Reference: 'P2MP-REQ' is mentioned on line 177, but not defined == Missing Reference: 'PATH-COMP' is mentioned on line 309, but not defined == Unused Reference: 'RFC' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 600, but no explicit reference was found in the text == Unused Reference: 'ISIS' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'ISIS-IP' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'ISIS-TE' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'ISIS-CAP' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'ISIS-G' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'INT-AREA-REQ' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'INT-AS-REQ' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'INT-DOMAIN-FRWK' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'P2MP-Req' is defined on line 638, 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. 'ISIS' ** Obsolete normative reference: RFC 3784 (ref. 'ISIS-TE') (Obsoleted by RFC 5305) -- Possible downref: Normative reference to a draft: ref. 'ISIS-CAP' -- Possible downref: Normative reference to a draft: ref. 'TE-INFO' == Outdated reference: A later version (-03) exists of draft-ietf-tewg-interarea-mpls-te-req-02 == Outdated reference: A later version (-09) exists of draft-ietf-tewg-interas-mpls-te-req-07 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-p2mp-requirement-02 -- No information found for draft-dry-mpls-rsvp-te-p2mp - is the name correct? Summary: 13 errors (**), 0 flaws (~~), 24 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IS-IS Working Group JP Vasseur (Ed.) 2 Cisco System Inc. 3 Internet Draft JL Le Roux (Ed.) 4 France Telecom 5 Stefano Previdi 6 Cisco Systems 7 Paul Mabey 8 Qwest 10 Category: Standard Track 11 Expires: January 2005 July 2004 13 IS-IS MPLS Traffic Engineering capabilities 15 draft-vasseur-isis-te-caps-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 and any of which I become aware will be disclosed, in accordance with 22 RFC 3668. 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. Internet-Drafts are working 26 documents of the Internet Engineering Task Force (IETF), its areas, 27 and its working groups. Note that other groups may also distribute 28 working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet- Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document specifies IS-IS traffic engineering capability sub-TLVs 44 related to various router MPLS Traffic Engineering capabilities. 45 These sub-TLVs are carried within the IS-IS CAPABILITY TLV. 47 Conventions used in this document 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in RFC-2119. 53 Table of Contents 55 1. Terminology.....................................................2 56 2. Introduction....................................................3 57 3. TE Node Capability Descriptor sub-TLV format....................3 58 3.1. The DATA-PLANE-CAPABILITY sub-TLV.............................4 59 3.2. The CONTROL-PLANE-CAPABILITY sub-TLV..........................4 60 4. PCED sub-TLV format.............................................5 61 4.1. PCE-ADDRESS sub-TLV...........................................5 62 4.2. PCE-CAPABILITY sub-TLV........................................6 63 4.3. AS-DOMAIN sub-TLV.............................................7 64 5. TE-Mesh-Group sub-TLV format....................................8 65 6. Element of procedure............................................8 66 6.1. TE-NODE-CAP sub-TLV...........................................9 67 6.2. PCED sub-TLV..................................................9 68 6.3. TE-MESH-GROUP sub-TLV........................................11 69 7. Interoperability with routers not supporting the IS-IS MPLS TE 70 capabilities......................................................12 71 8. Security considerations........................................12 72 9. Intellectual Property Statement................................12 73 10. References....................................................12 74 11. Authors' Address:.............................................13 76 1. Terminology 78 Terminology used in this document 80 LSR: Label Switch Router. 82 PCE: Path Computation Element whose function is to compute the 83 path of a TE LSP it is not the head-end for. The PCE may be 84 an LSR or an offline tool not forwarding packet. 86 PCC: Path Computation Client (any head-end LSR) requesting a TE 87 LSP path computation to the Path Computation Element. 89 TE LSP: Traffic Engineering Label Switched Path. 91 TE LSP head-end: head/source of the TE LSP. 93 TE LSP tail-end: tail/destination of the TE LSP. 95 Intra-area TE LSP: TE LSP whose path does not transit across 96 areas. 98 Inter-area TE LSP: A TE LSP whose path transits across at least 99 two different IGP areas. 101 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 102 two different ASes or sub-ASes (BGP confederations). 104 2. Introduction 106 This document defines IS-IS protocol extensions and procedures for 107 the advertisement TE node capabilities. The functional description of 108 these extensions is defined in [TE-INFO], and is not repeated here. 110 This document describes the usage of several IS-IS TE capabilities 111 sub-TLVs: the PCED (PCE Discovery), the TE-MESH-GROUP and the TE- 112 NODE-CAP sub-TLVs. These IS-IS TE capability sub-TLVs are carried 113 within the IS-IS CAPABILITY TLV specified in [IS-IS-CAP]. 115 Each sub-TLV defined in this document is composed of 1 octet for the 116 type, 1 octet specifying the TLV length and a value field. 118 The format of each sub-TLV is identical to the TLV format used by the 119 Traffic Engineering Extensions to IS-IS [IS-IS-TE]. 121 The TE-NODE-CAP sub-TLV is used for the advertisement of both 122 control plane and data plane TE node capabilities. The TE-NODE-CAP 123 sub-TLV is made of a set of non-ordered sub-TLVs each having the 124 format as described above. 126 The PCED sub-TLV is used for the advertisement of Path 127 Computation Element capabilities. The PCED sub-TLV is made of a set 128 of non-ordered sub-TLVs each having the format as described above. 130 The TE-MESH-GROUP sub-TLV is used to advertise the desire to 131 join/leave a given MPLS-TE mesh group. The TE-MESH-GROUP sub-TLV does 132 not have any sub-TLV currently defined. 134 3. TE Node Capability Descriptor sub-TLV format 136 This section specifies the sub-TLVs carried within the TE-NODE-CAP 137 sub-TLV payload which define the TE node capabilities. 139 The TE-NODE-CAP sub-TLV type is 1. 141 The TE-NODE-CAP sub-TLV is made of various non ordered sub-TLVs. 142 Currently two sub-TLVs are defined. 144 TLV type Length Name 145 1 variable DATA-PLANE-CAPABILITY sub-TLV 146 2 variable CONTROL-PLANE-CAPABILITY sub-TLV 148 Any non recognized sub-TLV MUST be silently ignored. 150 More sub-TLV could be added in the future to handle new capabilities. 152 3.1. The DATA-PLANE-CAPABILITY sub-TLV 154 The DATA-PLANE-CAPABILITY is a series of bit flags and has a variable 155 length. 157 CODE: 1 158 LENGTH: Variable (N*8) 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 |B|E| | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 // // 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 TE-NODE-CAP sub-TLV format 169 Two bits are currently defined: 171 -B bit: When set this indicates that the LSR can act as a branch node 172 on a P2MP LSP. 174 -E bit: When set, this indicates that the LSR can act as a bud LSR on 175 a P2MP LSP, i.e. and LSR that is both transit and egress. 177 See [P2MP-REQ]) and [RSVP-P2MP] for more details on the usage of 178 these bits. 180 Note that more flags may be defined in the future. 182 3.2. The CONTROL-PLANE-CAPABILITY sub-TLV 184 The CONTROL-PLANE-CAPABILITY is a series of bit flags and has a 185 variable length. 187 CODE: 2 188 LENGTH: Variable (N*8) 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |M|G|P| | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 // // 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 TE-NODE-CAP sub-TLV format 199 Currently three flags are defined: 201 -M bit: If set this indicates that the LSR supports MPLS-TE 202 signalling ([RSVP-TE]). 204 -G bit: If set this indicates that the LSR supports GMPLS signalling 205 ([RSVP-G]). 207 -P bit: If set this indicates that the LSR supports P2MP MPLS-TE 208 signalling ([RSVP-P2MP]). 210 Note that more flags may be defined in the future. 212 4. PCED sub-TLV format 214 This section specifies the sub-TLVs carried within the PCED sub-TLV 215 payload which describes the PCE capabilities. 217 The PCED sub-TLV type is 2. 219 The PCED sub-TLV is made of various non ordered sub-TLVs defined 220 below: 222 TLV type Length Name 223 1 variable PCE-ADDRESS sub-TLV 224 2 8 PCE-CAPABILITY sub-TLV 225 3 8 AS-DOMAIN sub-TLV 227 Any non recognized sub-TLV MUST be silently ignored and unchanged. 229 4.1. PCE-ADDRESS sub-TLV 231 The PCE-ADDRESS sub-TLV specifies the IP address to be used to reach 232 the PCE described by this PCED sub-TLV. This address will typically 233 be a loop-back address that is always reachable, provided the router 234 is not isolated. The PCE-ADDRESS sub-TLV is mandatory. 236 PCE-ADDRESS sub-TLV type is 1, length is 4 octets for an IPv4 237 address and 20 octets for an IPv6 address, and the value is the PCE 238 IPv4 or IPv6 address. 240 CODE: 1 241 LENGTH: Variable (4 or 20) 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | address-type | Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | | 248 // PCE IP address // 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 PCE-ADDRESS sub-TLV format 254 Address-type: 255 1 IPv4 256 2 IPv6 258 The PCE-ADDRESS sub-TLV MUST appear exactly once in the PCED sub-TLV 259 originated by a router. The only exception is when the PCE has both 260 an IPv4 and IPv6 address; in this case, two Path Computation Element 261 address sub-TLVs might be inserted: one for the IPv4 address, one for 262 the IPv6 address, in this order. 264 4.2. PCE-CAPABILITY sub-TLV 266 The PCE-CAPABILITY sub-TLV is used by the PCE to signal its Path 267 Computation Element capabilities. This could then be used by an LSR 268 to select the appropriate PCE among a list of PCE candidates. This 269 sub-TLV is optional. 271 The PCE-CAPABILITY sub-TLV type is 2 and the length is 8 octets. 273 CODE: 2 274 LENGTH: 4 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Reserved |D|M|P|A|I|L| 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 PCE-CAPABILITY sub-TLV format 283 The first 3 bits L, I and A defines the PCE scope for which the 284 Path Computation Element is capable of performing the TE LSP path 285 computation. 287 L bit: 288 Local scope. When set, this flag indicates that the PCE can compute 289 paths for the IS-IS level the ISIS CAPABILITY TLV is flooded into 290 (the PCE can compute TE LSP paths for intra-area TE LSPs). 292 I bit: 293 Inter-area scope. When set, the PCE can perform TE LSP path 294 computation for inter-area TE LSPs but within the same AS. 296 A bit: 297 Multi-domain scope. When set, the PCE can perform path computation 298 for inter-AS TE LSPs. In this case, the PCED sub-TLV MUST contain one 299 or more AS-DOMAIN sub-TLV(s), each describing the domain for which 300 the PCE can compute TE LSPs paths having their destination address in 301 the respective AS. 303 Note that those flags are not exclusive (a PCE may set one or more 304 flags). 306 P bit: 307 The notion of request priority allows a PCC to specify how urgent the 308 request is, by setting a flag in the REQUEST_ID object of the Path 309 computation request message. See [PATH-COMP] for more details. 311 P=1: the PCE takes into account the ��request priority�� in its 312 scheduling of the various requests. 313 P=0: the PCE does not take the request priority into account. 315 M bit 316 M=1: the PCE is capable of computing more than one path obeying a set 317 of specified constraints (in a single pass), provided that they 318 exist. 319 M=0: the PCE cannot compute more than one path in a single pass 320 obeying a set of specified constraints. 322 D bit 323 The PCC may request the PCE to compute N diversely routed paths 324 obeying a set of specified constraints. Such N paths may not exist of 325 course depending on the current state of the network. S 326 D=1: the PCE is capable of computing diversely (link, node, SRLG) 327 routed paths. 328 D=0: the PCE is not capable of computing diversely routed paths. 329 The D bit is relevant if and only if the M bit has been set to 1. It 330 MUST be set to 0 if the M bit is set to 0. 332 Note that for future capabilities, it may be desirable to introduce 333 new flags or may be new sub-TLV to be carried in the PCED capability 334 sub-TLV if the capability needs more than just a single flag to be 335 described. 337 4.3. AS-DOMAIN sub-TLV 339 When the PCE can perform path computation for an inter-AS TE LSP, the 340 A bit of the PCE-CAPABILITY sub-TLV MUST be set. Moreover, one or 341 more sub-TLVs MUST be included within the PCED sub-TLV, each sub-TLV 342 identifying an AS number. Each AS-DOMAIN sub-TLV has the following 343 form: 345 CODE: 3 346 LENGTH: 4 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | AS Number | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 AS-DOMAIN sub-TLV format 354 The AS-DOMAIN sub-TLV type is 3, length is 4 octets, and the value is 355 the AS number identifying the AS for which the PCE can compute inter- 356 AS TE LSP paths (TE LSP having their destination address in this AS). 357 When coded on four bytes, the AS Number field MUST have its 358 left two bytes set to 0. 360 The set of AS-DOMAIN sub-TLVs specifies a list of ASes (AS1,�, 361 ASn). This means that the PCE can compute TE LSP path such that the 362 destination address of the TE LSP belongs to this set of ASes. 364 5. TE-Mesh-Group sub-TLV format 366 The TE-MESH-GROUP sub-TLV has the following format: 368 CODE: 2 369 LENGTH: Variable (N*8 octets) 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | mesh-group-number | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Tail-end address | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Tail-end name | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 // // 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 TE-MESH-GROUP sub-TLV format 384 N is the number of mesh-groups. 386 For each Mesh-group announced by an LSR, the TLV contains: 387 - A mesh-group-number: identifies the mesh-group number, 388 - A Tail-end address: user configurable IP address to be used as a 389 tail-end address by other LSRs belonging to the same mesh-group. 390 - A Tail-end name: 32-bits string which facilitates the TE LSP 391 identification which can be very useful in inter-area/AS MPLS TE 392 environments. 394 6. Element of procedure 396 The sub-TLVs defined in this document are carried within the IS-IS 397 CAPABILITY TLV defined in [IS-IS-CAP]. 399 An IS-IS router MUST originate a new IS-IS LSP whenever the content 400 of the any of the carried sub-TLV changes or whenever required by the 401 regular IS-IS procedure (LSP refresh). 403 If the flooding scope of an MPLS Traffic Engineering capability is 404 limited to an IS-IS level/area, the S flag of the CAPABILITY TLV MUST 405 be cleared. Conversely,if the flooding scope of an MPLS Traffic 406 Engineering capability is the entire routing domain, the S flag of 407 the CAPABILITY TLV MUST be set. 409 In both cases the flooding rules as specified in [IS-IS-CAP] apply. 411 As specified in [IS-IS-CAP], a router may generate multiple IS-IS 412 CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. 414 6.1. TE-NODE-CAP sub-TLV 416 The flooding scope is defined on a per capability basis. 418 If the capability must be flooded within a single IS-IS area/level, 419 the TE-NODE-CAP sub-TLV MUST be carried within a CAPABILITY TLV 420 having the S flag cleared. Conversely, if the capability must be 421 flooded throughout the entire routing domain, the TE-NODE-CAP sub-TLV 422 MUST be carried within a CAPABILITY TLV having the S flag set. 424 Capabilities with an identical flooding scope MUST be flooded within 425 the same TE-NODE-CAP sub-TLV. 427 6.2. PCED sub-TLV 429 If the PCE can compute an intra-area TE LSP path, the L bit of the 430 PCE-CAPABILITY sub-TLV of the PCED TLV MUST be set. The PCED sub-TLV 431 MUST be carried within a CAPABILITY TLV having the S flag cleared. 433 If the PCE can compute an inter-area TE LSP path, the I bit of the 434 PCE-CAPABILITY sub-TLV of the PCED TLV MUST be set. The PCED sub-TLV 435 MUST be carried: 437 - Within a CAPABILITY TLV having the S flag cleared if the PCE can 438 compute an inter-area TE LSP path for the LSRs in the area(s) it 439 resides in (for instance the PCE is an ABR computing an inter- 440 area TE LSP path for its area). 442 - Within a CAPABILITY TLV having the S flag set if the PCE can 443 compute an inter-area TE LSP path for the whole domain. 445 If the PCE can compute an inter-AS TE LSP path, the A bit of the PCE- 446 CAPABILITY sub-TLV of the PCED TLV MUST be set and the PCED TLV MUST 447 be carried within CAPABILITY TLV having the S flag set. 449 Note: if the PCE can compute both intra and inter-area TE LSP paths, 450 both the L and I bits of the PCE-CAPABILITY sub-TLV MUST be set. The 451 flags are not exclusive. 453 If the PCE can compute inter-as TE-LSPs path, both the A bit of the 454 PCED TLV MUST and the S bit of CAPABILITY TLV MUST be set. 456 Example 458 -----------------AS1----------------- 460 R1(L1)------R3(L1L2)*-----R4(L1L2)*----| ------------ 461 | | | | | | 462 | S1(L1) | S2(L1) | ASBR1*(L1)--eBGP--ASBR2-| AS2 | 463 | | | | | | 464 R2(L1)------R5(L1L2)*-----R6(L1L2)-----| ------------ 466 The areas contents are not detailed. 468 Assumptions: 469 - the * indicates a Path Computation Element capability 470 - R3 is a PCE for level 1 only 471 - R5 is a PCE for intra and inter-area TE LSP path computation for 472 both levels 473 - R4 is a PCE for inter-area TE LSP path computation only for both 474 levels 475 - S1 is a PCE for level 1 only 476 - S2 is a PCE for the whole AS 477 - ASBR1 is a PCE for inter-AS TE LSPs whose destination resides in 478 AS2 (not for intra or inter-area area TE LSPs). 480 In the example above: 481 - S1 originates a level 1 LSP containing a PCED sub-TLV with: 482 o The L bit of the PCE-CAPABILITY sub-TLV set, 483 o The I and A bits of the PCE-CAPABILITY sub-TLV cleared. 484 The S bit of the CAPABILITY TLV MUST be cleared. 486 - S2 originates a level 2 LSP containing 487 -an IS-IS CAPABILITY TLV with the S flag cleared carrying: 488 a PCED TLV with: 489 - The L, and I bits of the PCE-CAPABILITY sub-TLV set, 490 - The A bit of the PCE-CAPABILITY sub-TLV cleared 491 -an IS-IS CAPABILITY TLV with the S flag set carrying: 492 a PCED TLV with 493 -The I bit set 494 -The L and A bit cleared 496 - ASBR1 originates a level1 LSP containing a PCED TLV with: 497 o The L and I bits of the PCE-CAPABILITY sub-TLV cleared, 498 o The A bit of the PCE-CAPABILITY sub-TLV set, 499 o One AS-domain sub-TLV within the PCED sub-TLV with AS number = 500 AS2 501 The S bit of the CAPABILITY TLV MUST be set 503 - R3 originates: 505 * a level 1 LSP containing 506 - an IS-IS CAPABILITY TLV with the S flag cleared carrying: 507 o a PCED TLV describing its own PCE capability with: 508 - The L bit of the PCE-CAPABILITY sub-TLV set, 509 - The I and A bits of the PCE-CAPABILITY sub-TLV 510 cleared, 511 - an IS-IS CAPABILITY TLV with the S flag set carrying: 512 o the S2's PCED TLV (with I and A bit unchanged) 513 o the ASBR1s PCED TLV (unchanged), leaked from level-2 LSP (S 514 bit set). 516 * a level 2 LSP including no PCED TLV 518 - R5 originates: 520 * a level1 LSP containing: 521 - an IS-IS CAPABILITY TLV with the S flag cleared carrying: 522 o a PCED TLV describing its own PCE capability with: 523 - The L and I bits of the PCE-CAPABILITY sub-TLV set, 524 - The A bit of the PCE-CAPABILITY sub-TLV cleared, 525 - an IS-IS CAPABILITY TLV with the S flag set carrying: 526 o the S2's PCED TLV (with the I, A and L bits of the PCE- 527 CAPABILITY sub-TLV unchanged) 528 o the ASBR1's PCED TLV (unchanged) 530 * a level 2 LSP containing an IS-IS CAPABILITY TLV with the S flag 531 cleared carrying: 532 o a PCED sub-TLV describing its own PCED capability with: 533 - Both the L and I bit of the PCE-CAPABILITY sub-TLV set, 534 - The A bit of the PCE-CAPABILITY sub-TLV cleared. 536 The receipt of an IS-IS LSP containing a new PCED TLV never triggers 537 an SPF calculation. 539 When a PCE is newly configured, the corresponding PCED TLV MUST be 540 immediately flooded. 542 When a PCE looses its capability or when one of its PCED capabilities 543 changes, the IS-IS LSP MUST be immediately flooded. 545 6.3. TE-MESH-GROUP sub-TLV 547 If the MPLS TE mesh-group is contained within a single IS-IS 548 level (all the LSRs have their head-end and tail-end LSR within 549 the same IS-IS level), the TE-MESH-GROUP sub-TLV MUST be carried 550 within a CAPABILITY TLV having the S flag cleared. Conversely, if the 551 MPLS TE mesh-group spans multiple IS-IS levels, the TE- 552 MESH-GROUP sub-TLV MUST be carried within a CAPABILITY TLV having the 553 S flag set. 555 7. Interoperability with routers not supporting the IS-IS MPLS TE 556 capabilities 558 There is no interoperability issue as a router not supporting the 559 PCED, TE-MESH-GROUP or TE-NODE-CAP sub-TLVs SHOULD just silently 560 ignore those sub-TLVs. 562 8. Security considerations 564 No new security issues are raised in this document. 566 9. Intellectual Property Statement 568 The IETF takes no position regarding the validity or scope of any 569 Intellectual Property Rights or other rights that might be claimed to 570 pertain to the implementation or use of the technology described in 571 this document or the extent to which any license under such rights 572 might or might not be available; nor does it represent that it has 573 made any independent effort to identify any such rights. Information 574 on the procedures with respect to rights in RFC documents can be 575 found in BCP 78 and BCP 79. 577 Copies of IPR disclosures made to the IETF Secretariat and any 578 assurances of licenses to be made available, or the result of an 579 attempt made to obtain a general license or permission for the use of 580 such proprietary rights by implementers or users of this 581 specification can be obtained from the IETF on-line IPR repository at 582 http://www.ietf.org/ipr. 584 The IETF invites any interested party to bring to its attention any 585 copyrights, patents or patent applications, or other proprietary 586 rights that may cover technology that may be required to implement 587 this standard. Please address the information to the IETF at ietf- 588 ipr@ietf.org. 590 10. References 592 Normative references 594 [RFC] Bradner, S., "Key words for use in RFCs to indicate 595 requirements levels", RFC 2119, March 1997. 597 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 598 RFC 3667, February 2004. 600 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 601 Technology", BCP 79, RFC 3668, February 2004. 603 [ISIS] "Intermediate System to Intermediate System Intra-Domain 604 Routing Exchange Protocol " ISO 10589. 606 [ISIS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 607 dual environments", RFC 1195, December 1990. 609 [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 610 Engineering", RFC 3784, June 2004. 612 [ISIS-CAP] Vasseur, J.P., Aggarwal, R., Shen, N. et al. "IS-IS 613 extensions for advertising router information", draft-vasseur-isis- 614 caps-02.txt, work in progress. 616 [TE-INFO] Vasseur, J.P., Le Roux, J.L., et al., "Routing extensions 617 for discovery of TE router information", draft-vasseur-ccamp-te- 618 router-info-00.txt, work in progress. 620 Informative References 622 [ISIS-G] Kompella, K., Rekhter, Y., "IS-IS extensions in support of 623 Generalized Multi-protocol Label Switching", draft-ietf-isis-gmpls- 624 extensions-19.txt, work in progress. 626 [INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements 627 for inter-area MPLS Traffic Engineering", draft-ietf-tewg-interarea- 628 mpls-te-req-02.txt, work in progress. 630 [INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic 631 Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req- 632 07.txt, work in progress. 634 [INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A 635 Framework for Inter-Domain MPLS Traffic Engineering", draft-farrel- 636 ccamp-inter-domain-framework-01.txt, work in progress. 638 [P2MP-Req] Yasukawa, S., et. al., "Requirements for point-to- 639 multipoint extension to RSVP-TE", draft-ietf-mpls-p2mp-requirement- 640 02.txt, work in progress. 642 [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 643 tunnels", RFC 3209, December 2001. 645 [RSVP-G] Berger, L, et. al., "GMPLS Signaling RSVP-TE extensions", 646 RFC 3473, January 2003. 648 [RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, et. al. "Extensions to 649 RSVP-TE for point-to-multipoint TE LSPs", draft-dry-mpls-rsvp-te- 650 p2mp-00.txt, work in progress. 652 11. Authors' Address: 654 Jean-Philippe Vasseur 655 Cisco Systems, Inc. 656 300 Beaver Brook Road 657 Boxborough , MA - 01719 658 USA 659 Email: jpv@cisco.com 661 Jean-Louis Le Roux 662 France Telecom 663 2, avenue Pierre-Marzin 664 22307 Lannion Cedex 665 FRANCE 666 Email: jeanlouis.leroux@francetelecom.com 668 Stefano Previdi 669 Cisco Systems, Inc. 670 Via Del Serafico 200 671 00142 - Roma 672 ITALY 673 Email: sprevidi@cisco.com 675 Paul Mabey 676 Qwest Communications 677 950 17th Street, 678 Denver, CO 80202 679 USA 680 Email: pmabey@qwest.com 682 Full Copyright Statement 684 Copyright (C) The Internet Society (2004). This document is subject to 685 the rights, licenses and restrictions contained in BCP 78, and except as 686 set forth therein, the authors retain all their rights. 688 This document and the information contained herein are provided on an 689 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 690 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 691 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 692 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 693 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 694 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.