idnits 2.17.1 draft-ietf-pce-disco-proto-isis-08.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 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 759. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 2007) is 6038 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3567 (Obsoleted by RFC 5304) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Intended Status: Standard Track 5 Expires: April 2008 J.P. Vasseur (Editor) 6 Cisco System Inc. 8 Yuichi Ikejiri 9 NTT Communications 11 Raymond Zhang 12 BT Infonet 14 October 2007 16 IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery 18 draft-ietf-pce-disco-proto-isis-08.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). All rights reserved. 47 Abstract 49 There are various circumstances where it is highly desirable for a 50 Path Computation Client (PCC) to be able to dynamically and 51 automatically discover a set of Path Computation Elements (PCEs), 52 along with information that can be used by the PCC for PCE selection. 53 When the PCE is a Label Switching Router (LSR) participating in the 54 Interior Gateway Protocol (IGP), or even a server participating 55 passively in the IGP, a simple and efficient way to announce PCEs 56 consists of using IGP flooding. For that purpose this document 57 defines extensions to the Intermediate System to Intermediate System 58 (IS-IS) routing protocol for the advertisement of PCE Discovery 59 information within an IS-IS area or within the entire IS-IS routing 60 domain. 62 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 Table of Contents 70 1. Terminology.................................................3 71 2. Introduction................................................4 72 3. Overview....................................................5 73 3.1. PCE Discovery Information...................................5 74 3.2. Flooding Scope..............................................5 75 4. The IS-IS PCED Sub-TLV......................................6 76 4.1. PCE-ADDRESS Sub-TLV.........................................7 77 4.2. The PATH-SCOPE Sub-TLV......................................7 78 4.3. PCE-DOMAIN Sub-TLV..........................................9 79 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................10 80 4.5. PCE-CAP-FLAGS Sub-TLV......................................10 81 5. Elements of Procedure......................................11 82 6. Backward Compatibility.....................................12 83 7. IANA Considerations........................................12 84 8. Security Considerations....................................12 85 9. Manageability Considerations...............................12 86 9.1. Control of Policy and Functions............................12 87 9.2. Information and Data Model.................................13 88 9.3. Liveness Detection and Monitoring..........................13 89 9.4. Verify Correct Operations..................................13 90 9.5. Requirements on Other Protocols and Functional 91 Components...............................................13 92 9.6. Impact on Network Operations...............................13 93 10. Acknowledgments............................................14 94 11. References.................................................14 95 11.1. Normative References.......................................14 96 11.2. Informative References.....................................14 97 12. Editors' Addresses:........................................15 98 13. Contributors' Adresses:....................................15 99 14. Intellectual Property Statement............................15 101 1. Terminology 103 ABR: IS-IS Area Border Router. 105 AS: Autonomous System. 107 IGP: Interior Gateway Protocol. Either of the two routing 108 protocols Open Shortest Path First (OSPF) or Intermediate System 109 to Intermediate system (IS-IS). 111 Intra-area TE LSP: A TE LSP whose path does not cross an IGP area 112 boundary. 114 Intra-AS TE LSP: A TE LSP whose path does not cross an AS 115 boundary. 117 Inter-area TE LSP: A TE LSP whose path transits two or 118 more IGP areas. That is a TE LSP that crosses at least one IGP 119 area boundary. 121 Inter-AS TE LSP: A TE LSP whose path transits two or more 122 ASes or sub-ASes (BGP confederations). That is a TE LSP that 123 crosses at least one AS boundary. 125 IS-IS LSP: Link State PDU 127 LSR: Label Switching Router. 129 PCC: Path Computation Client. Any client application requesting a 130 path computation to be performed by a Path Computation Element. 132 PCE: Path Computation Element. An entity (component, application, 133 or network node) that is capable of computing a network path or 134 route based on a network graph, and applying computational 135 constraints. 137 PCE-Domain: In a PCE context this refers to any collection of 138 network elements within a common sphere of address management or 139 path computational responsibility (referred to as a "domain" in 140 [RFC4655]). Examples of PCE-Domains include IGP areas and ASes. 141 This should be distinguished from an IS-IS routing domain as 142 defined by [ISO]. 144 PCEP: Path Computation Element communication Protocol. 146 TE LSP: Traffic Engineered Label Switched Path. 148 2. Introduction 150 [RFC4655] describes the motivations and architecture for a Path 151 Computation Element (PCE)-based path computation model for Multi- 152 Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic 153 Engineered Label Switched Paths (TE LSPs). The model allows for the 154 separation of the PCE from a Path Computation Client (PCC) (also 155 referred to as a non co-located PCE) and allows for cooperation 156 between PCEs (where one PCE acts as a PCC to make requests of the 157 other PCE). This relies on a communication protocol between PCC and 158 PCE, and also between PCEs. The requirements for such a communication 159 protocol can be found in [RFC4657], and the communication protocol is 160 defined in [PCEP]. 162 The PCE architecture requires that a PCC be aware of the location of 163 one or more PCEs in its domain, and also, potentially, of PCEs in 164 other domains, e.g., in the case of inter-domain TE LSP computation. 166 A network may contain a large number of PCEs, each with potentially 167 distinct capabilities. In such a context it is highly desirable to 168 have a mechanism for automatic and dynamic PCE discovery that allows 169 PCCs to automatically discover a set of PCEs along with additional 170 information about each PCE that may be used by a PCC to perform PCE 171 selection. Additionally, it is valuable for a PCC to dynamically 172 detect new PCEs, failed PCEs, or any modification to the PCE 173 information. Detailed requirements for such a PCE discovery mechanism 174 are provided in [RFC4674]. 176 Note that the PCE selection algorithm applied by a PCC is out of the 177 scope of this document. 179 When PCCs are LSRs participating in the IGP (OSPF, IS-IS), and PCEs 180 are either LSRs or servers also participating in the IGP, an 181 effective mechanism for PCE discovery within an IGP routing domain 182 consists of utilizing IGP advertisements. 184 This document defines extensions to IS-IS [ISO] to allow a PCE in an 185 IS-IS routing domain to advertise its location along with some 186 information useful to a PCC for PCE selection, so as to satisfy 187 dynamic PCE discovery requirements set forth in [RFC4674]. 189 Generic capability advertisement mechanisms for IS-IS are defined in 190 [IS-IS-CAP]. These allow a router to advertise its capabilities 191 within an IS-IS area or an entire IS-IS routing domain. This document 192 leverages this generic capability advertisement mechanism to fully 193 satisfy the dynamic PCE discovery requirements. 195 This document defines a new sub-TLV (named the PCE Discovery (PCED)) 196 to be carried within the IS-IS Router Capability TLV ([IS-IS-CAP]). 198 The PCE information advertised is detailed in Section 3. Protocol 199 extensions and procedures are defined in Sections 4 and 5. 201 The IS-IS extensions defined in this document allow for PCE discovery 202 within an IS-IS routing domain. Solutions for PCE discovery across AS 203 boundaries are beyond the scope of this document, and for further 204 study. 206 This document defines a set of sub-TLVs that are nested within each 207 other. When the degree of nesting TLVs is 2 (a TLV is carried within 208 another TLV) the TLV carried within a TLV is called a sub-TLV. 209 Strictly speaking, when the degree of nesting is 3, a subsub-TLV is 210 carried within a sub-TLV that is itself carried within a TLV. For the 211 sake of terminology simplicity, a TLV carried within another TLV is 212 called a sub-TLV regardless of the degree of nesting. 214 3. Overview 216 3.1. PCE Discovery Information 218 The PCE discovery information is composed of: 220 - The PCE location: an IPv4 and/or IPv6 address that is used to reach 221 the PCE. It is RECOMMENDED to use an address that is always 222 reachable if there is any connectivity to the PCE; 224 - The PCE path computation scope (i.e., intra-layer, inter-area, 225 inter-AS, or inter-layer); 227 - The set of one or more PCE-Domain(s) into which the PCE has 228 visibility and for which the PCE can compute paths; 230 - The set of zero, one or more neighbor PCE-Domain(s) toward which 231 the PCE can compute paths; 233 - A set of communication capabilities (e.g., support for request 234 prioritization) and path computation-specific capabilities 235 (e.g., supported constraints). 237 PCE discovery information is by nature fairly static and does not 238 change with PCE activity. Changes in PCE discovery information may 239 occur as a result of PCE configuration updates, PCE 240 deployment/activation, PCE deactivation/suppression, or PCE failure. 241 Hence, this information is not expected to change frequently. 243 3.2. Flooding Scope 245 The flooding scope for PCE information advertised through IS-IS can 246 be a single L1 area, an L1 area and the L2 sub-domain, or the entire 247 IS-IS routing domain. 249 4. The IS-IS PCED Sub-TLV 251 The IS-IS PCED sub-TLV contains a non-ordered set of sub-TLVs. 253 The format of the IS-IS PCED sub-TLV and its sub-TLVs is identical to 254 the TLV format used by the Traffic Engineering Extensions to IS-IS 255 [RFC3784]. That is, the TLV is comprised of 1 octet for the type, 1 256 octet specifying the TLV length, and a value field. The Length field 257 defines the length of the value portion in octets. 259 The IS-IS PCED sub-TLV has the following format: 261 TYPE: To be assigned by IANA (suggested value = 5) 262 LENGTH: Variable 263 VALUE: set of sub-TLVs 265 Five sub-TLVs are defined: 266 Sub-TLV type Length Name 267 1 variable PCE-ADDRESS sub-TLV 268 2 3 PATH-SCOPE sub-TLV 269 3 variable PCE-DOMAIN sub-TLV 270 4 variable NEIG-PCE-DOMAIN sub-TLV 271 5 variable PCE-CAP-FLAGS sub-TLV 273 The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within 274 the PCED sub-TLV. 276 The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They 277 MAY be present in the PCED sub-TLV to facilitate selection of inter- 278 domain PCEs. 280 The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED 281 sub-TLV to facilitate the PCE selection process. 283 Any unrecognized sub-TLV MUST be silently ignored. 285 The PCED sub-TLV is carried within an IS-IS CAPABILITY TLV defined in 286 [IS-IS-CAP]. 288 No additional sub-TLVs will be added to the PCED TLV in the future. 289 If a future application requires the advertisement of additional PCE 290 information in IS-IS, this will not be carried in the CAPABILITY TLV. 292 The following sub-sections describe the sub-TLVs which may be carried 293 within the PCED sub-TLV. 295 4.1. PCE-ADDRESS Sub-TLV 297 The PCE-ADDRESS sub-TLV specifies an IP address that can be 298 used to reach the PCE. It is RECOMMENDED to make use of an address 299 that is always reachable, provided the PCE is alive and reachable. 301 The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the 302 PCED sub-TLV. It MAY appear twice, when the PCE has both an IPv4 and 303 IPv6 address. It MUST NOT appear more than once for the same address 304 type. If it appears more than once only the first occurrence is 305 processed and any others MUST be ignored. 307 The PCE-ADDRESS sub-TLV has the following format: 309 TYPE: 1 310 LENGTH: 5 for an IPv4 address or 17 for an IPv6 address 311 VALUE: This comprises one octet indicating the address-type and 4 312 or 16 octets encoding the IPv4 or IPv6 address to be used 313 to reach the PCE. 315 Address-type: 316 1 IPv4 317 2 IPv6 319 4.2. The PATH-SCOPE Sub-TLV 321 The PATH-SCOPE sub-TLV indicates the PCE path computation scope, 322 which refers to the PCE's ability to compute or take part in the 323 computation of paths for intra-area, inter-area, inter-AS, or inter- 324 layer_TE LSPs. 326 The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the 327 PCED sub-TLV. There MUST be exactly one instance of the PATH-SCOPE 328 sub-TLV within each PCED sub-TLV. If it appears more than once only 329 the first occurrence is processed and any others MUST be ignored. 331 The PATH-SCOPE sub-TLV contains a set of bit flags indicating the 332 supported path scopes, and four fields indicating PCE preferences. 334 The PATH-SCOPE sub-TLV has the following format: 336 TYPE: 2 337 LENGTH: 3 338 VALUE: This comprises a one-octet flags field where each flag 339 represents a supported path scope, followed by a 2-octets 340 preferences field indicating PCE preferences. 342 Here is the structure of the flags field: 344 +-+-+-+-+-+-+-+-+ 345 |0|1|2|3|4|5|Res| 346 +-+-+-+-+-+-+-+-+ 348 Bit Path Scope 350 0 L bit: Can compute intra-area path 351 1 R bit: Can act as PCE for inter-area TE LSP computation 352 2 Rd bit: Can act as a default PCE for inter-area TE LSP 353 computation 354 3 S bit: Can act as PCE for inter-AS TE LSP computation 355 4 Sd bit: Can act as a default PCE for inter-AS TE LSPs 356 computation 357 5 Y bit: Can compute or take part into the computation of 358 paths across layers 359 6-7 Reserved for future use. 361 Here is the structure of the preferences field 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |PrefL|PrefR|PrefS|PrefY| Res | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Res: Reserved for future usage. 369 PrefL field: PCE's preference for intra-area TE LSPs computation. 371 PrefR field: PCE's preference for inter-area TE LSPs computation. 373 PrefS field: PCE's preference for inter-AS TE LSPs computation. 375 Pref-Y field: PCE's preference for inter-layer TE LSPs computation. 377 Res: Reserved for future use. 379 The L, R, S, and Y bits are set when the PCE can act as a PCE for 380 intra-area, inter-area, inter-AS or inter-layer TE LSPs computation 381 respectively. These bits are non-exclusive. 383 When set, the Rd bit indicates that the PCE can act as a default PCE 384 for inter-area TE LSP computation (that is, the PCE can compute a 385 path toward any neighbor area). Similarly, when set, the Sd bit 386 indicates that the PCE can act as a default PCE for inter-AS TE LSP 387 computation (the PCE can compute a path toward any neighbor AS). 389 When the Rd and Sd bit are set, the PCED sub-TLV MUST NOT contain a 390 NEIG-PCE-DOMAIN sub-TLV (see Section 4.4). 392 When the R bit is clear, the Rd bit SHOULD be clear on transmission 393 and MUST be ignored on receipt. When the S bit is clear, the Sd bit 394 SHOULD be clear on transmission and MUST be ignored on receipt. 396 The PrefL, PrefR, PrefS and PrefY fields are each three bits long and 397 allow the PCE to specify a preference for each computation scope, 398 where 7 reflects the highest preference. Such preferences can be used 399 for weighted load balancing of path computation requests. An operator 400 may decide to configure a preference for each computation scope at 401 each PCE so as to balance the path computation load among them. The 402 algorithms used by a PCC to balance its path computation requests 403 according to such PCE preferences are out of the scope of this 404 document and are a matter for local or network-wide policy. The same 405 or different preferences may be used for each scope. For instance, an 406 operator that wants a PCE capable of both inter-area and inter-AS 407 computation to be preferred for use for inter-AS computations may 408 configure PrefS higher than PrefR. 410 When the L, R, S, or Y bits are clear, the PrefL, PrefR, PrefS, PrefY 411 fields SHOULD respectively be set to 0 on transmission and MUST be 412 ignored on receipt. 414 Both reserved fields SHOULD be set to zero on transmission and MUST 415 be ignored on receipt. 417 4.3. PCE-DOMAIN Sub-TLV 419 The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes) 420 where the PCE has topology visibility and through which the PCE can 421 compute paths. 423 The PCE-DOMAIN sub-TLV SHOULD be present when PCE-Domains for which 424 the PCE can operate cannot be inferred by other IGP information, for 425 instance when the PCE is inter-domain capable (i.e., when the R bit 426 or S bit is set) and the flooding scope is the entire routing domain 427 (see Section 5 for a discussion of how the flooding scope is set and 428 interpreted). 430 A PCED sub-TLV may include multiple PCE-DOMAIN sub-TLVs when the PCE 431 has visibility into multiple PCE-Domains. 433 The PCE-DOMAIN sub-TLV has the following format: 435 TYPE: 3 436 LENGTH: Variable 437 VALUE: This is composed of one octet indicating the domain-type (area 438 ID or AS Number) and a variable length IS-IS area ID or a 32 bits AS 439 number, identifying a PCE-domain where the PCE has visibility and can 440 compute paths. 442 Two domain types are defined: 443 1 Area ID 444 2 AS Number 446 The Area ID is the area address as defined in [ISO]. 448 When the AS number is coded in two octets, the AS Number field MUST 449 have its first two octets set to 0. 451 4.4. NEIG-PCE-DOMAIN Sub-TLV 453 The NEIG-PCE-DOMAIN sub-TLV specifies a neighbor PCE-domain (area or 454 AS) toward which a PCE can compute paths. It means that the PCE can 455 take part in the computation of inter-domain TE LSPs with paths that 456 transit this neighbor PCE-domain. 458 A PCED sub-TLV may include several NEIG-PCE-DOMAIN sub-TLVs when the 459 PCE can compute paths towards several neighbour PCE-domains. 461 The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN 462 sub-TLV: 464 TYPE: 4 465 LENGTH: Variable 466 VALUE: This comprises one octet indicating the domain-type (area ID 467 or AS Number) and a variable length IS-IS area ID or a 32 bits AS 468 number, identifying a PCE-domain toward which the PCE can compute 469 paths. 471 Two domain types are defined: 472 1 Area ID 473 2 AS Number 475 The Area ID is the area address as defined in [ISO]. 477 When the AS number is coded in two octets, the AS Number field MUST 478 have its first two octets set to 0. 480 The NEIG-PCE-DOMAIN sub-TLV MUST be present at least once with domain 481 type 1 if the R bit is set and the Rd bit is clear, and MUST be 482 present at least once with domain type 2 if the S bit is set and the 483 Sd bit is clear. 485 4.5. PCE-CAP-FLAGS Sub-TLV 487 The PCE-CAP-FLAGs sub-TLV is an optional sub-TLV used to indicate 488 PCEP related capabilities. It MAY be present within the PCED sub-TLV. 489 It MUST NOT be present more than once. If it appears more than once 490 only the first occurrence is processed and any others MUST be ignored. 492 The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array 493 of units of 32 bit-flags numbered from the most significant as bit 494 zero, where each bit represents one PCE capability. 496 The PCE-CAP-FLAGS sub-TLV has the following format: 498 TYPE: 5 499 LENGTH: Multiple of 4 500 VALUE: This contains an array of units of 32 bit flags numbered 501 from the most significant as bit zero, where each bit 502 represents one PCE capability. 504 The PCE capability registry is managed by IANA, it is common 505 with OSPF and defined in [PCED-OSPF]. 507 Reserved bits SHOULD be set to zero on transmission and MUST be 508 ignored on receipt. 510 5. Elements of Procedure 512 The PCED sub-TLV is advertised within an IS-IS Router Capability TLV 513 defined in [IS-IS-CAP]. As such, elements of procedures are inherited 514 from those defined in [IS-IS-CAP]. 516 The flooding scope is controlled by the S flag in the IS-IS Router 517 Capability TLV (see [IS-IS-CAP]). When the scope of the PCED sub-TLV 518 is area local it MUST be carried within an IS-IS Router Capability 519 TLV having the S bit cleared. When the scope of the PCED sub-TLV is 520 the entire IS-IS routing domain, it MUST be carried within an IS-IS 521 Router Capability TLV having the S bit set. Note that when only the L 522 bit of the PATH-SCOPE sub-TLV is set, the flooding scope MUST be area 523 local. 525 Note that a L1L2 node may include a PCED TLV in a Router Capability 526 TLV with the S bit cleared in both in its L1 and L2 LSPs. This allows 527 the flooding scope to be restricted to the L1 area and the L2 sub- 528 domain. 530 When the PCE function is deactivated, the IS-IS speaker advertising 531 this PCE MUST originate a new IS-IS LSP that no longer includes the 532 corresponding PCED TLV. 534 The PCE address (i.e., the address indicated within the PCE ADDRESS 535 sub-TLV) SHOULD be reachable via some prefixes advertised by IS-IS. 536 This allows the detection of a PCE failure to be sped up. When the 537 PCE address is no longer reachable, the PCE node has failed, has been 538 torn down, or there is no longer IP connectivity to the PCE node. 540 A change in information in the PCED sub-TLV MUST NOT trigger any SPF 541 computation at a receiving router. 543 The way PCEs determine the information they advertise is out of the 544 scope of this document. Some information may be configured (e.g., 545 address, preferences, scope) and other information may be 546 automatically determined by the PCE (e.g. areas of visibility). 548 6. Backward Compatibility 550 The PCED sub-TLV defined in this document does not introduce any 551 interoperability issues. 553 An IS-IS router not supporting the PCED sub-TLV will just silently 554 ignore the sub-TLV as specified in [IS-IS-CAP]. 556 7. IANA Considerations 558 IANA has defined a registry for the sub-TLVs carried in the IS-IS 559 Router Capability sub-TLVs defined in [IS-IS-CAP]. IANA is requested 560 to assign a new sub-TLV code-point for the PCED sub-TLV carried 561 within the Router Capability sub-TLV. 563 Value Sub-TLV References 564 ----- -------- ---------- 565 5 PCED sub-TLV (this document) 567 8. Security Considerations 569 This document defines IS-IS extensions for PCE discovery within an 570 administrative domain. Hence the security of the PCE discovery relies 571 on the security of IS-IS. 573 Mechanisms defined to ensure authenticity and integrity of IS-IS LSPs 574 [RFC3567], and their TLVs, can be used to secure the PCED sub-TLV as 575 well. 577 IS-IS provides no encryption mechanism for protecting the privacy of 578 LSPs, and in particular the privacy of the PCE discovery information. 580 9. Manageability Considerations 582 Manageability considerations for PCE Discovery are addressed in 583 Section 4.10 of [RFC4674]. 585 9.1. Control of Policy and Functions 587 Requirements for the configuration of PCE discovery parameters on 588 PCCs and PCEs are discussed in Section 4.10.1 of [RFC4674]. 590 In particular, a PCE implementation SHOULD allow the following 591 parameters to be configured on the PCE: 592 -The PCE IPv4/IPv6 address(es) (see Section 4.1) 593 -The PCE Scope, including the inter-domain functions (inter- 594 area, inter-AS, inter-layer), the preferences, and whether the 595 PCE can act as default PCE (see Section 4.2) 596 -The PCE domains (see Section 4.3) 597 -The neighbour PCE domains (see Section 4.4) 598 -The PCE capabilities (see Section 4.5) 600 9.2. Information and Data Model 602 A MIB module for PCE Discovery is defined in [PCED-MIB]. 604 9.3. Liveness Detection and Monitoring 606 PCE Discovery Protocol liveness detection relies upon IS-IS liveness 607 detection. IS-IS already includes a liveness detection mechanism 608 (Hello PDUs), and PCE discovery does not require additional 609 capabilities. 611 Procedures defined in Section 5 allow a PCC to detect when a PCE has 612 been deactivated, or is no longer reachable. 614 9.4. Verify Correct Operations 616 The correlation of information advertised against information 617 received can be achieved by comparing the information in the PCED 618 sub-TLV received by the PCC with that stored at the PCE using the 619 PCED MIB [PCED-MIB]. The number of dropped, corrupt, and rejected 620 information elements are available through the PCED MIB. 622 9.5. Requirements on Other Protocols and Functional Components 624 The IS-IS extensions defined in this document do not imply any 625 requirement on other protocols. 627 9.6. Impact on Network Operations 629 Frequent changes in PCE information advertised in the PCED sub-TLV 630 may have a significant impact on IS-IS and might destabilize the 631 operation of the network by causing the PCCs to swap between PCEs. 633 As discussed in Section 4.10.4 of [RFC4674], it MUST be possible to 634 apply at least the following controls: 636 - Configurable limit on the rate of announcement of changed 637 parameters at a PCE. 638 - Control of the impact on PCCs such as through rate-limiting the 639 processing of PCED sub-TLVs. 640 - Configurable control of triggers that cause a PCC to swap to 641 another PCE. 643 10. Acknowledgments 645 We would like to thank Lucy Wong, Adrian Farrel, Les Ginsberg, Mike 646 Shand, Lou Berger, and David Ward, for their useful comments and 647 suggestions. 649 11. References 651 11.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, March 1997. 656 [ISO] "Intermediate System to Intermediate System Intra-Domain 657 Routeing Exchange Protocol for use in Conjunction with the 658 Protocol for Providing the Connectionless-mode Network Service 659 ISO/IEC 10589:2002 Second Edition. 661 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic 662 Engineering", RFC 3784, June 2004. 664 [IS-IS-CAP] Vasseur, J.P. et al., "IS-IS extensions for advertising 665 router information", draft-ietf-isis-caps, work in progress. 667 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 668 Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, 669 July 2003. 671 [PCED-OSPF] Le Roux, Vasseur, et al. "OSPF protocol extensions for 672 Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- 673 proto-ospf, work in progress. 675 11.2. Informative References 677 [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic 678 Requirements", RFC4657, September 2006. 680 [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) 681 communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work 682 in progress. 684 [PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path 685 Computation Element Discovery", draft-ietf-pce-disc-mib, work in 686 progress. 688 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 689 Element (PCE)-based Architecture", RFC4655, august 2006. 691 [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", 692 RFC4674, October 2006. 694 12. Editors' Addresses: 696 Jean-Louis Le Roux (Editor) 697 France Telecom 698 2, avenue Pierre-Marzin 699 22307 Lannion Cedex 700 FRANCE 701 Email: jeanlouis.leroux@orange-ftgroup.com 703 Jean-Philippe Vasseur (Editor) 704 Cisco Systems, Inc. 705 1414 Massachusetts avenue 706 Boxborough , MA - 01719 707 USA 708 Email: jpv@cisco.com 710 13. Contributors' Adresses: 712 Yuichi Ikejiri 713 NTT Communications Corporation 714 1-1-6, Uchisaiwai-cho, Chiyoda-ku 715 Tokyo 100-8019 716 JAPAN 717 Email: y.ikejiri@ntt.com 719 Raymond Zhang 720 BT Infonet 721 2160 E. Grand Ave. 722 El Segundo, CA 90025 723 USA 724 Email: raymond_zhang@bt-infonet.com 726 14. Intellectual Property Statement 728 The IETF takes no position regarding the validity or scope of any 729 Intellectual Property Rights or other rights that might be claimed to 730 pertain to the implementation or use of the technology described in 731 this document or the extent to which any license under such rights 732 might or might not be available; nor does it represent that it has 733 made any independent effort to identify any such rights. Information 734 on the procedures with respect to rights in RFC documents can be 735 found in BCP 78 and BCP 79. 737 Copies of IPR disclosures made to the IETF Secretariat and any 738 assurances of licenses to be made available, or the result of an 739 attempt made to obtain a general license or permission for the use of 740 such proprietary rights by implementers or users of this 741 specification can be obtained from the IETF on-line IPR repository at 742 http://www.ietf.org/ipr. 744 The IETF invites any interested party to bring to its attention any 745 copyrights, patents or patent applications, or other proprietary 746 rights that may cover technology that may be required to implement 747 this standard. Please address the information to the IETF at 748 ietf-ipr@ietf.org. 750 Disclaimer of Validity 752 This document and the information contained herein are provided 753 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 754 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 755 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 756 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 757 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 758 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 759 FOR A PARTICULAR PURPOSE. 761 Copyright Statement 763 Copyright (C) The IETF Trust (2007). This document is subject to the 764 rights, licenses and restrictions contained in BCP 78, and except as 765 set forth therein, the authors retain all their rights.