idnits 2.17.1 draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1176. 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 : ---------------------------------------------------------------------------- No issues found here. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Takeda, Ed. 2 Internet Draft NTT 3 Intended Status: Informational A. Farrel, Ed. 4 Created April 16, 2008 Old Dog Consulting 5 Expires: October 16, 2008 Y. Ikejiri 6 NTT Communications 7 JP. Vasseur 8 Cisco Systems, Inc. 10 Analysis of Inter-domain Label Switched Path (LSP) Recovery 12 draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 Protection and recovery are important features of service offerings 40 in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 41 networks. Increasingly, MPLS and GMPLS networks are being extended 42 from single domain scope to multi-domain environments. 44 Various schemes and processes have been developed to establish Label 45 Switched Paths (LSPs) in multi-domain environments. These are 46 discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol 47 Label Switching Traffic Engineering. 49 This document analyzes the application of these techniques to 50 protection and recovery in multi-domain networks. The main focus for 51 this document is on establishing end-to-end diverse Traffic 52 Engineering (TE) LSPs in multi-domain networks. 54 Table of Contents 56 1. Introduction...................................................3 57 1.1 Terminology...................................................3 58 1.2 Domain........................................................4 59 1.3 Document Scope................................................5 60 1.4 Note on Other Recovery Techniques.............................6 61 1.5 Signaling Options.............................................6 62 2. Diversity in Multi-Domain Networks.............................6 63 2.1 Multi-Domain Network Topology.................................6 64 2.2 Note on Domain Diversity......................................8 65 3. Factors to Consider............................................9 66 3.1 Scalability Versus Optimality.................................9 67 3.2 Key Concepts..................................................9 68 4. Diverse LSP Setup Schemes Without Confidentiality.............11 69 4.1 Management Configuration.....................................11 70 4.2 Head-End Path Computation (With Multi-Domain Visibility).....12 71 4.3 Per-Domain Path Computation..................................12 72 4.3.1 Sequential Path Computation................................12 73 4.3.2 Simultaneous Path Computation..............................13 74 4.4 Inter-Domain Collaborative Path Computation..................14 75 4.4.1 Sequential Path Computation................................15 76 4.4.2 Simultaneous Path Computation..............................15 77 5. Diverse LSP Setup Schemes With Confidentiality................15 78 5.1 Management Configuration.....................................17 79 5.2 Head-End Path Computation (With Multi-Domain Visibility).....17 80 5.3 Per-Domain Path Computation..................................17 81 5.3.1 Sequential Path Computation................................17 82 5.3.2 Simultaneous Path Computation..............................18 83 5.4 Inter-Domain Collaborative Path Computation..................19 84 5.4.1 Sequential Path Computation................................19 85 5.4.2 Simultaneous Path Computation..............................20 86 6. Network Topology Specific Considerations......................20 87 7. Addressing Considerations.....................................20 88 8. Note on SRLG Diversity........................................20 89 9. IANA Considerations ..........................................21 90 10. Security Considerations......................................21 91 11. References...................................................21 92 11.1 Normative References........................................21 93 11.2 Informative References......................................22 94 12. Acknowledgments..............................................24 95 13. Authors' Addresses...........................................24 97 1. Introduction 99 Protection and recovery in Multiprotocol Label Switching (MPLS) and 100 Generalized MPLS (GMPLS) networks are described in [RFC4428]. These 101 are important features for service delivery in MPLS and GMPLS 102 networks. 104 MPLS and GMPLS networks were originally limited to single domain 105 environments. Increasingly, multi-domain MPLS and GMPLS networks are 106 being considered, where a domain is considered to be any collection 107 of network elements within a common sphere of address management or 108 path computational responsibility. Examples of such domains include 109 Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). 111 [RFC4726] provides a framework for inter-domain MPLS and GMPLS 112 traffic engineering. It introduces and discusses the various schemes 113 and processes to establish Label Switched Paths (LSPs) in multi- 114 domain environments. 116 However, protection and recovery introduce additional complexities to 117 LSP establishment. Protection LSPs are generally required to be path 118 diverse from the working LSPs that they protect. Achieving this is 119 particularly challenging in multi-domain environments because no 120 single path computation or planning point is capable of determining 121 path diversity for both paths from one end to the other. 123 This document analyzes various schemes to realize MPLS and GMPLS 124 LSP recovery in multi-domain networks. The main focus for this 125 document is on establishing end-to-end diverse Traffic Engineering 126 (TE) LSPs in multi-domain networks. 128 1.1 Terminology 130 The reader is assumed to be familiar with the terminology for LSP 131 recovery set out in [RFC4427], and with the terms introduced in 132 [RFC4726] that provides a framework for inter-domain Label Switched 133 Path (LSP) setup. Key terminology may also be found in [RFC4216] 134 that sets out requirements for inter-AS MPLS traffic engineering. 136 The following key terms from those sources are used within this 137 document. 139 - Domain: See [RFC4726]. A domain is considered to be any 140 collection of network elements within a common sphere of address 141 management or path computational responsibility. Note that nested 142 domains continue to be out of scope. Section 1.2 provides 143 additional details. 145 - Working LSP: See [RFC4427]. The working LSP transports normal user 146 traffic. Note that the term LSP and TE LSP will be used 147 interchangeably. 149 - Recovery LSP: See [RFC4427]. The recovery LSP transports normal 150 user traffic when the working LSP fails. The recovery LSP may 151 also carry user traffic even when the working LSP is operating 152 normally and transporting the user traffic (e.g., 1+1 protection). 153 The recovery LSP is sometimes referred to as a protecting LSP. 155 - Diversity: See [RFC4726]. Diversity means the relationship 156 of multiple LSPs, where those LSPs do not share some specific type 157 of resource (e.g., link, node, or shared risk link group (SRLG)). 158 Diversity is also referred to as disjointness. 160 Diverse LSPs may be used for various purposes, such as load- 161 balancing and recovery. In this document, the recovery aspect of 162 diversity, specifically the end-to-end diversity of two traffic 163 engineering (TE) LSPs, is the focus. The two diverse LSPs are 164 referred to as the working LSP and recovery LSP. 166 - Confidentiality: See [RFC4216]. Confidentiality refers to the 167 protection of information about the topology and resources 168 of one domain from visibility by people or applications outside 169 that domain. 171 1.2 Domain 173 In order to fully understand the issues addressed in this document, 174 it is necessary to carefully define and scope the term "domain". 176 As defined in [RFC4726], a domain is considered to be any collection 177 of network elements within a common sphere of address management or 178 path computational responsibility. Examples of such domains include 179 IGP areas and Autonomous Systems. Networks accessed over the GMPLS 180 User-to-Network Interface (UNI) [RFC4208], and Layer One Virtual 181 Private Networks (L1VPNs) [RFC4847] are special cases of multi-domain 182 networks. 184 Example motivations for using more than one domain include 185 administrative separation, scalability, and the construction of 186 domains for the purpose of providing protection. These latter 187 "protection domains" offer edge-to-edge protection facilities for 188 spans or segments of end-to-end LSPs. 190 As described in [RFC4726], there could be TE parameters (such as 191 color and priority) whose meanings are specific to each domain. In 192 such scenarios, in order to set up inter-domain LSPs, mapping 193 functions may be needed to transform the TE parameters based on 194 policy agreements between domain administrators. 196 1.3 Document Scope 198 This document analyzes various schemes to realize MPLS and GMPLS LSP 199 recovery in multi-domain networks. It is based on the existing 200 framework for multi-domain LSP setup [RFC4726]. Note that this 201 document does not prevent the development of additional techniques 202 where appropriate (i.e., additional to the ones described in this 203 document). In other words, this document shows how the existing 204 techniques can be applied. 206 There are various recovery techniques for LSPs. For TE LSPs, the 207 major techniques are end-to-end recovery [RFC4872], local protection 208 such as Fast Reroute (FRR) [RFC4090] (in packet switching 209 environments), and segment recovery [RFC4873] (in GMPLS). 211 The main focus of this document is the analysis of diverse TE LSP 212 setup schemes that can be used in the context of end-to-end recovery. 213 The methodology is to show different combinations of functional 214 elements such as path computation and signaling techniques. 216 [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There 217 are various types of diversity, and this document focuses on node, 218 link, and shared risk link group (SRLG) diversity. 220 Recovery LSPs may be used for 1+1 protection, 1:1 protection, or 221 shared mesh restoration. However, the requirements for path 222 diversity, the ways to compute diverse paths, and the signaling of 223 these TE LSPs are common across all uses. These topics are the main 224 scope of this document. 226 Note that diverse LSPs may be used for various purposes in addition 227 to recovery. An example is for load-balancing, so as to limit the 228 traffic disruption to a portion of the traffic flow in case of a 229 single node failure. This document does not preclude use of diverse 230 LSP setup schemes for other purposes. 232 The following are beyond the scope of this document. 234 - Analysis of recovery techniques other than the use of link, node, 235 or SRLG diverse LSPs (see Section 1.4). 237 - Details of maintenance of diverse LSPs, such as re-optimization and 238 OAM. 240 - Comparative evaluation of LSP setup schemes. 242 1.4 Note on Other Recovery Techniques 244 Fast Reroute and segment recovery in multi-domain networks are 245 described in Section 5.4 of [RFC4726], and a more detailed analysis 246 is provided in Section 5 of [RFC5151]. This document does not cover 247 any additional analysis for Fast ReRoute and segment recovery in 248 multi-domain networks. 250 The recovery type of an LSP or service may change at a domain 251 boundary. That is, the recovery type could remain the same within one 252 domain, but might be different in the next domain or on the 253 connections between domains. This may be due to the capabilities of 254 each domain, administrative policies, or to topology limitations. An 255 example is where protection at the domain boundary is provided by 256 link protection on the inter-domain links, but where protection 257 within each domain is achieved through segment recovery. This mixture 258 of protection techniques is beyond the scope of this document. 260 Domain diversity (that is, the selection of paths that have only the 261 ingress and egress domains in common) may be considered as one form 262 of diversity in multi-domain networks, but this is beyond the scope 263 of this document (see Section 2.2). 265 1.5 Signaling Options 267 There are three signaling options for establishing inter-domain TE 268 LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The 269 description in this document of diverse LSP setup is agnostic in 270 relation to the signaling option used, unless otherwise specified. 272 Note that signaling option considerations for Fast Reroute and 273 segment recovery are described in [RFC5151]. 275 2. Diversity in Multi-Domain Networks 277 This section describes some assumptions about achieving path 278 diversity in multi-domain networks. 280 2.1 Multi-Domain Network Topology 282 Figures 1 and 2 show examples of multi-domain network topologies. In 283 Figure 1, domains are connected in a linear topology. There are 284 multiple paths between nodes A and L, but all of them cross domain#1- 285 domain#2-domain#3 in that order. 287 +--Domain#1--+ +--Domain#2--+ +--Domain#3--+ 288 | | | | | | 289 | B------+---+---D-----E--+---+------J | 290 | / | | \ / | | \ | 291 | / | | \ / | | \ | 292 | A | | H | | L | 293 | \ | | / \ | | / | 294 | \ | | / \ | | / | 295 | C------+---+---F-----G--+---+------K | 296 | | | | | | 297 +------------+ +------------+ +------------+ 299 Figure 1: Linear Domain Connectivity 301 +-----Domain#2-----+ 302 | | 303 | E--------------F | 304 | | | | 305 | | | | 306 +-+--------------+-+ 307 | | 308 | | 309 +--Domain#1-+--+ +-------+------+ 310 | | | | | | 311 | | | | | | 312 | A----B--+---+--C----D | 313 | | | | | | 314 | | | | | | 315 +------+-------+ +--+-Domain#4--+ 316 | | 317 +-+--------------+-+ 318 | | | | 319 | | | | 320 | G--------------H | 321 | | 322 +-----Domain#3-----+ 324 Figure 2: Meshed Domain Connectivity 326 In Figure 2, domains are connected in a mesh topology. There are 327 multiple paths between nodes A and D, and these paths do not cross 328 the same domains. If inter-domain connectivity forms a mesh, domain 329 level routing is required (even for the unprotected case). This is 330 tightly coupled with the next hop domain resolution/discovery 331 mechanisms used in IP networks. 333 In this document, we assume that domain level routing is given via 334 configuration, policy, or some external mechanism, and that this is 335 not part of the path computation process described later in this 336 document. 338 Domain level routing may also allow "domain re-entry" where a path 339 re-enters a domain that it has previously exited (e.g., domain#X- 340 domain#Y-domain#X). This requires specific considerations when 341 confidentiality (described in Section 3.2) is required, and is beyond 342 the scope of this document. 344 Furthermore, the working LSP and the recovery LSP may or may not be 345 routed along the same set of domains in the same order. In this 346 document, we assume that the working LSP and recovery LSP follow the 347 same set of domains in the same order (via configuration, policy or 348 some external mechanism). That is, we assume that the domain mesh 349 topology is reduced to a linear domain topology for each pair of 350 working and recovery LSPs. 352 In summary, 354 - There is no assumption about the multi-domain network topology. For 355 example, there could be more than two domain boundary nodes or 356 inter-domain links (links connecting a pair of domain boundary 357 nodes belonging to different domains). 359 - It is assumed that in a multi-domain topology, the sequence of 360 domains that the working LSP and the recovery LSP follow must be 361 the same and is pre-configured. 363 - Domain re-entry is out of scope and is not considered further. 365 2.2 Note on Domain Diversity 367 As described in Section 1.4, domain diversity means the selection of 368 paths that have only the ingress and egress domains in common. This 369 may provide enhanced resilience against failures, and is a way to 370 ensure path diversity for most of the path of the LSP. 372 In Section 2.1 we assumed that the working LSP and the recovery LSP 373 follow the same set of domains in the same order. Under this 374 assumption, domain diversity cannot be achieved. However, by relaxing 375 this assumption, domain diversity could be achieved, e.g., by either 376 of the following schemes. 378 - Consider domain diversity as a special case of SRLG diversity 379 (i.e., assign an SRLG ID to each domain). 381 - Configure domain level routing to provide domain diverse paths 382 (e.g., by means of AS_PATH in BGP). 384 Further details of the operation of domain diversity are beyond the 385 scope of this document. 387 3. Factors to Consider 389 3.1 Scalability Versus Optimality 391 As described in [RFC4726], scalability and optimality are two 392 conflicting objectives. Note that the meaning of optimality differs 393 depending on each network operation. Some examples of optimality in 394 the context of diverse LSPs are: 396 - Minimizing the sum of their cost while maintaining diversity. 398 - Restricting the difference of their costs (for example, so as to 399 minimize the delay difference after switch-over) while maintaining 400 diversity. 402 By restricting TE information distribution to only within each domain 403 (and not across domain boundaries) as required by [RFC4105] and 404 [RFC4216], it may not be possible to compute an optimal path. As 405 such, it might not be possible to compute diverse paths, even if they 406 exist. However, if we assume domain level routing is given (as 407 discussed in Section 2), it would be possible to compute diverse 408 paths using specific computation schemes, if such paths exist. This 409 is discussed further in Section 4. 411 3.2 Key Concepts 413 Three key concepts to classify various diverse LSP computation and 414 setup schemes are presented below. 416 o With or without confidentiality 418 - Without confidentiality 420 It is possible to specify a path across multiple domains in 421 signaling (by means of the RSVP-TE Explicit Route Object (ERO)), 422 and to obtain record of the inter-domain path used (by means of 423 the RSVP-TE Record Route Object (RRO)). In this case, it is clear 424 that one domain has control over the path followed in another 425 domain, and that the path actually used in one domain is visible 426 from within another domain. 428 Examples of this configuration are multi-area networks, and some 429 forms of multi-AS networks (especially within the same provider). 430 In these cases, there is no requirement for confidentiality. 432 - With confidentiality 434 Where confidentiality of domain topology and operational policy 435 is required, it is not possible to specify or obtain a full path 436 across other domains. Partial paths may be specified and reported 437 using domain identifiers or the addresses of domain border 438 routers in the EROs and RROs. 440 Examples of this configuration are some forms of multi-AS 441 networks (especially inter-provider networks), GMPLS-UNI 442 networks, and L1VPNs. 444 o Multi-domain path computation, per-domain path computation, and 445 inter-domain collaborative path computation 447 - Multi-domain path computation 449 If a single network element can see the topology of all domains 450 along the path, it is able to compute a full end-to-end path. 451 Clearly this is only possible where confidentiality is not 452 required. 454 Such a network element might be the head-end Label Switching 455 Router (LSR), a Path Computation Element (PCE) [RFC4655], or a 456 Network Management System (NMS). This mode of path computation is 457 discussed in Sections 4 and 5. 459 - Per-domain path computation 461 The path of an LSP may be computed domain-by-domain as LSP 462 signaling progresses through the network. This scheme requires 463 ERO expansion in each domain to construct the next segment of 464 the path toward the destination. The establishment of unprotected 465 LSPs in this way is covered in [RFC5152]. 467 - Inter-domain collaborative path computation 469 In this scheme, path computation is typically done before 470 signaling and uses communication between cooperating PCEs. An 471 example of such a scheme is Backward Recursive Path Computation 472 (BRPC) [BRPC]. 474 It is possible to combine multiple path computation techniques 475 (including using a different technique for the working and recovery 476 LSPs), but details are beyond the scope of this document. 478 o Sequential path computation or simultaneous path computation 480 - Sequential path computation 482 The path of the working LSP is computed without considering the 483 recovery LSP, and then the path of the recovery LSP is computed. 484 This scheme is applicable when the recovery LSP is added later as 485 a change to the service grade, but may also be used when both the 486 working and recovery LSPs are established from the start. 488 Using this approach it may not be possible to find diverse paths 489 for the LSPs in "trap" topologies. Furthermore, such sequential 490 path computation approaches reduce the likelihood of selecting an 491 "optimal" solution with regards to a specific objective function. 493 - Simultaneous path computation 495 The path of the working LSP and the path of the recovery LSP are 496 computed simultaneously. In this scheme it is possible to avoid 497 trap conditions and it may be more possible to achieve an optimal 498 result. 500 Note that LSP setup with or without confidentiality depends on per- 501 domain configuration. The choice of per-domain path computation or 502 inter-domain collaborative path computation, and the choice between 503 sequential path computation or simultaneous path computation can be 504 determined for each individual pair of working/recovery LSPs. 506 The analysis of various diverse LSP setup schemes is described in 507 Sections 4 and 5, based on the concepts set out above. 509 Some other considerations, such as network topology-specific 510 considerations, addressing considerations, and SRLG diversity are 511 described in Sections 6, 7, and 8. 513 4. Diverse LSP Setup Schemes Without Confidentiality 515 This section examines schemes for diverse LSP setup based on 516 different path computation techniques assuming that there is no 517 requirement for domain confidentiality. Section 5 makes a similar 518 examination of schemes where domain confidentiality is required. 520 4.1 Management Configuration 522 [RFC4726] describes this path computation technique where the full 523 explicit paths for the working and recovery LSPs are specified by a 524 management application at the head-end, and no further computation or 525 signaling considerations are needed. 527 4.2 Head-End Path Computation (With Multi-Domain Visibility) 529 Section 3.2.1 [RFC4726] describes this path computation technique. 530 The full explicit paths for the working and recovery LSPs are 531 computed at the head-end either by the head-end itself or by a PCE. 532 In either case the computing entity has full TE visibility across 533 multiple domains and no further computation or signaling 534 considerations are needed. 536 4.3 Per-Domain Path Computation 538 Sections 3.2.2, 3.2.3 and 3.3 of [RFC4726] describe this path 539 computation technique. More detailed procedures are described in 540 [RFC5152]. 542 In this scheme, the explicit paths of the working and recovery LSPs 543 are specified as the complete strict paths through the source domain 544 followed by either of the following: 546 - The complete list of boundary LSRs or domain identifiers (e.g., AS 547 numbers) along the paths. 549 - The LSP destination. 551 Thus, in order to navigate each domain, the path must be expanded at 552 each domain boundary, i.e. per-domain. This path computation is 553 performed by the boundary LSR or by a PCE on its behalf. 555 There are two schemes for establishing diverse LSPs using per-domain 556 computation. These are described Sections 4.3.1 and 4.3.2. 558 4.3.1 Sequential Path Computation 560 As previously noted, the main issue with sequential path computation 561 is that diverse paths cannot be guaranteed. Where a per-domain path 562 computation scheme is applied, the computation of second path needs 563 to be aware of the path used by the first path in order that path 564 diversity can be attempted. 566 The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used when the 567 second path is signaled to report the details of the first path. It 568 should be noted that the PRIMARY_PATH_ROUTE Object defined in 569 [RFC4872] for end-to-end protection is not intended as a path 570 exclusion mechanism and should not be used for this purpose. 572 The process for sequential path computation is as follows: 574 - The working LSP is established using per-domain path computation as 575 described in [RFC5152]. The path of the working LSP is available at 576 the head-end through the RSVP-TE RRO since domain confidentiality 577 is not required. 579 - The path of the recovery LSP across the first domain is computed 580 excluding the resources used by the working LSP within that domain. 581 If a PCE is used, the resources to be avoided can be passed to the 582 PCE using the Exclude Route Object (XRO) extensions to the PCE 583 Protocol [PCEP-XRO], [PCEP]. 585 - The recovery LSP is now signaled across the first domain as usual, 586 but the path of the working LSP is also conveyed in an RSVP-TE XRO. 587 The XRO lists nodes, links and SRLGs that must be avoided by the 588 LSP being signaled, and its contents are copied from the RRO of the 589 working LSP. 591 - At each subsequent domain boundary, a segment of the path of the 592 recovery LSP can be computed across the new domain excluding the 593 resources indicated in the RSVP-TE XRO. 595 This scheme cannot guarantee to establish diverse LSPs (even if they 596 could exist) because the first (working) LSP is established without 597 consideration of the need for a diverse recovery LSP. It is possible 598 modify the path of the working LSP using the crankback techniques 599 [RFC4920] if the setup of the recovery LSP is blocked or if some 600 resources are shared. 602 Note that even if a solution is found, the degree of optimality of 603 the solution (i.e., of the set of diverse TE LSPs) might not be 604 maximal. 606 4.3.2 Simultaneous Path Computation 608 Simultaneous path computation gives a better likelihood of finding a 609 pair of diverse paths as the diversity requirement forms part of the 610 computation process. In per-domain path computation mechanisms there 611 are several aspects to consider. 613 Simultaneous path computation means that the paths of the working and 614 recovery LSPs are computed at the same time. Since we are considering 615 per-domain path computation, these two paths must be computed at the 616 boundary of each domain. 618 The process for simultaneous path computation is as follows: 620 - The ingress LSR (or a PCE) computes a pair of diverse paths across 621 the first domain. If a PCE is used, PCEP offers the ability to 622 request disjoint paths. 624 - The working LSP is signaled across the first domain as usual, but 625 must carry with it the requirement for a disjoint recovery LSP and 626 the information about the path already computed for the recovery 627 LSP across the first domain. In particular, the domain boundary 628 node used by the recovery LSP must be reported. 630 - Each domain boundary router in turn computes a pair of disjoint 631 paths across the next domain. The working LSP is signaled as usual 632 and the computed path of the recovery LSP is collected in the 633 signaling messages. 635 - When the working LSP has been set up, the full path of the recovery 636 LSP is returned to the head-end LSR in the signaling messages for 637 the working LSP. This allows the head-end LSR to signal the 638 recovery LSP using a full path without the need for further path 639 computation. 641 Note that the signaling protocol mechanisms do not currently exist to 642 collect the path of the recovery LSP during the signaling of the 643 working LSP. Definition of protocol mechanisms are beyond the scope 644 of this document, but it is believed that such mechanisms would be 645 simple to define and implement. 647 Note also that the mechanism described is still not able to guarantee 648 the selection of diverse paths even where they exist since, when 649 domains are multiply interconnected, the determination of diverse 650 end-to-end paths may depend on the correct selection of inter-domain 651 links. Crankback [RFC4920] may also be used in combination with this 652 scheme to improve the chances of success. 654 Note that even if a solution is found, the degree of optimality of 655 the solution (i.e., set of diverse TE LSPs) might not be maximal. 657 4.4 Inter-Domain Collaborative Path Computation 659 Collaborative path computation requires the cooperation between PCEs 660 that are responsible for different domains. This approach is 661 described in Section 3.4 of [RFC4726]. Backward recursive path 662 computation (BRPC) [BRPC] provides a collaborative path computation 663 technique where the paths of LSPs are fully determined by 664 communication between PCEs before the LSPs are established. Two ways 665 to use BRPC for diverse LSPs are described in the following sections. 667 4.4.1 Sequential Path Computation 669 In sequential path computation, the path of the working LSP is 670 computed using BRPC as described in [BRPC]. The path of the recovery 671 LSP is then computed also using BRPC with the addition that the path 672 of the working LSP is explicitly excluded using the XRO route 673 exclusion techniques described in [PCEP-XRO]. 675 In this case, the working LSP could be set up before or after the 676 path of the recovery LSP is computed. In the latter case the actual 677 path of the working LSP as reported in the RSVP-TE RRO should be used 678 when computing the path of the recovery LSP. 680 This scheme cannot guarantee to establish diverse LSPs (even if they 681 exist) because the working LSP may block the recovery LSP. In such a 682 scenario, re-optimization of the working and recovery LSPs may be 683 used to achieve fully diverse paths. 685 4.4.2 Simultaneous Path Computation 687 In simultaneous path computation, the PCEs collaborate to compute the 688 paths of both the working and the recovery LSPs at the same time. 689 Since both LSPs are computed in a single pass, the LSPs can be 690 signaled simultaneously of sequentially according to the preference 691 of the head-end LSR. 693 Collaborative simultaneous path computation is achieved using the 694 Synchronization Vector (SVEC) object in the PCE Protocol [PCEP]. This 695 object allows two computation requests to be associated and made 696 dependent. The coordination of multiple computation requests within 697 the BRPC mechanism is not described in [BRPC]. It is believed that it 698 is possible to specify procedures for such coordination, but the 699 development of new procedures is outside the scope of this document. 701 This scheme can guarantee to establish diverse LSPs where they are 702 possible, assuming that domain level routing is pre-determined as 703 described in Section 2. Furthermore, the computed set of TE LSPs can 704 be guaranteed to be optimal with respect to some objective functions. 706 5. Diverse LSP Setup Schemes with Confidentiality 708 In the context of this section, the term confidentiality applies to 709 the protection of information about the topology and resources 710 present within one domain from visibility by people or applications 711 outside that domain. This includes, but is not limited to, recording 712 of LSP routes, and the advertisements of TE information. The 713 confidentiality does not apply to the protection of user traffic. 715 Diverse LSP setup schemes with confidentiality are similar to ones 716 without confidentiality. However, several additional mechanisms are 717 needed to preserve confidentiality. Examples of such mechanisms are: 719 - Path key: A path key is used in place of a segment of the path of 720 an LSP when the LSP is signaled, when the path of the LSP is 721 reported by signaling, or when the LSP's path is generated by a 722 PCE. This allows the exact path of the LSP to remain confidential 723 through the substitution of "confidential path segments" (CPSs) by 724 these path keys. 726 [PCE-PATH-KEY] describes how path keys can be used by PCEs to 727 preserve path confidentiality, and [RSVP-PATH-KEY] explains how 728 path keys are used in signaling. Note that if path keys are 729 signaled in RSVP-TE EROs they must be expanded so that the 730 signaling can proceed. This expansion normally takes place when the 731 first node in the CPS is reached. The expansion of the path key 732 would normally be carried out by the PCE that generated the key, 733 and for that reason, the path key contains an identifier of the PCE 734 (the PCE-ID). 736 - LSP segment: LSP segments can be pre-established across domains 737 according to some management policy. The LSP segments can be used 738 to support end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP 739 stitching segments [RFC5150]. 741 The end-to-end LSPs are signaled indicating just the series of 742 domains or domain border routers. Upon entry to each domain an 743 existing trans-domain LSP is selected and used to carry the end-to- 744 end LSP across the domain. 746 Note that although the LSP segments are described as being pre- 747 established, they could be set up on demand on receipt of the 748 request for the end-to-end LSP at the domain border. 750 It is also worth noting that in schemes that result in a single 751 contiguous end-to-end LSP (without LSP tunneling or stitching) the 752 same concept of LSP segments may apply provided that ERO expansion 753 is applied at domain boundaries and that the path of the LSP is not 754 reported in the RSVP-TE RRO. 756 These techniques may be applied directly or may require protocol 757 extensions depending on the specific diverse LSP setup schemes 758 described below. Note that in the schemes below, the paths of the 759 working and recovery LSPs are not impacted by the confidentiality 760 requirements. 762 5.1 Management Configuration 764 Although management systems may exist that can determine end-to-end 765 paths even in the presence of domain confidentiality, the full paths 766 cannot be provided to the head-end LSR for LSP signaling as this 767 would break the confidentiality requirements. 769 Thus, for LSPs that are configured through management applications, 770 the end-to-end path must either be constructed using LSP segments 771 that cross the domains, or communicated to the head-end LSR with the 772 use of path keys. 774 5.2 Head-End Path Computation (With Multi-Domain Visibility) 776 It is not possible for the head-end LSR to compute the full end-to- 777 end path of an inter-domain LSP when domain confidentiality is in use 778 because the LSR will not have any TE information about the other 779 domains. 781 5.3 Per-Domain Path Computation 783 Per-domain path computation for working and recovery LSPs is 784 practical with domain confidentiality. As when there are no 785 confidentiality restrictions, we can separate the cases of sequential 786 and simultaneous path computation. 788 5.3.1 Sequential Path Computation 790 In sequential path computation, we can assume that the working LSP 791 has its path computed and is set up using the normal per-domain 792 technique as described in [RFC5152]. However, because of 793 confidentiality issues, the full path of the working LSP is not 794 returned in the signaling messages and is not available to the head- 795 end LSR. 797 To compute a disjoint path for the recovery LSP, each domain border 798 node needs to know the path of the working LSP within the domain to 799 which it provides entry. This is easy for the ingress LSR as it has 800 access to the RSVP-TE RRO within first domain. In subsequent domains, 801 the process requires that the path of the working LSP is somehow made 802 available to the domain border router as the recovery LSP is 803 signaled. Note that the working and recovery LSPs do not use the same 804 border routers if the LSPs are node or SRLG diverse. 806 There are several possible mechanisms to achieve this. 808 - Path keys could be used in the RRO for the working LSP. As the 809 signaling messages are propagated back towards the head-end LSR, 810 each domain border router substitutes a path key for the segment of 811 the working LSP's path within its domain. Thus, the RRO received at 812 the head-end LSR consists of the path within the initial domain 813 followed by a series of path keys. 815 When the recovery LSP is signaled, the path keys can be included in 816 the ERO as exclusions. Each domain border router in turn can 817 expand the path key for its domain and know which resources must be 818 avoided. PCEP provides a protocol that can be used to request the 819 expansion of the path key from the domain border router used by the 820 working LSP, or from some third party such as a PCE. 822 - Instead of using path keys, each confidential path segment in the 823 RRO of the working LSP could be encrypted by the domain border 824 routers. These encrypted segments would appear as exclusions in the 825 ERO for the recovery LSP and could be decrypted by the domain 826 border routers. 828 No mechanism currently exists in RSVP-TE for this function which 829 would probably assume a domain-wide encryption key. 831 - The identity of the working LSP could be included in the XRO of the 832 recovery LSP to indicate that a disjoint path must be found. 834 This option could require a simple extension to the current XRO 835 specification [RFC4874] to allow LSP identifiers to be included. It 836 could also use the Association Object [RFC4872] to identify the 837 working LSP. 839 This scheme would also need a way for a domain border router to 840 find the path of an LSP within its domain. An efficient way to 841 achieve this would be to also include the domain border router used 842 by the working LSP in the signaling for the recovery LSP, but other 843 schemes based on management applications or stateful PCEs might 844 also be developed. 846 Clearly, the details of this alternative have not been specified. 848 5.3.2 Simultaneous Path Computation 850 In per-domain simultaneous path computation the path of the recovery 851 LSP is computed at the same time as the working LSP (i.e., as the 852 working LSP is signaled). The computed path of the recovery LSP is 853 propagated to the head-end LSR as part of the signaling process for 854 the working LSP, but confidentiality must be maintained, so the full 855 path cannot be returned. There are two options as follows. 857 - LSP segment: As the signaling of the working LSP progresses and the 858 path of the recovery LSP is computed domain-by-domain, trans-domain 859 LSPs can be set up for use by the recovery LSP. When the recovery 860 LSP is signaled, it will pick up these LSP segments and use them 861 for tunneling or stitching. 863 This mechanism needs coordination through the management plane 864 between domain border routers so that a router on the working path 865 can request the establishment of an LSP segment for use by the 866 protection path. This could be achieved through the TE MIB modules 867 [RFC3812], [RFC4802]. 869 Furthermore, when the recovery LSP is signaled it needs to be sure 870 to pick up the correct LSP segment. Therefore some form of LSP 871 segment identifier needs to be reported in the signaling of the 872 working LSP and propagated in the signaling of the recovery LSP. 873 Mechanisms for this do not currently exist, but would be relatively 874 simple to construct. 876 Alternatively, the LSP segments could be marked as providing 877 protection for the working LSP. In this case the recovery LSP can 878 be signaled with the identifier of the working LSP using the 879 Association Object [RFC4872] enabling the correct LSP segments to 880 be selected. 882 - Path key: The path of the recovery LSP can be determined and 883 returned to the head-end LSR just described in Section 4.4.2, but 884 each CPS is replaced by a path key. As the recovery path is 885 signaled each path key is expanded, domain-by-domain to achieve the 886 correct path. This requires that the entity that computes the path 887 of the recovery LSP (domain border LSR or PCE) is stateful. 889 5.4 Inter-Domain Collaborative Path Computation 891 Cooperative collaboration between PCEs is also applicable when domain 892 confidentiality is required. 894 5.4.1 Sequential Path Computation 896 In sequential cooperative path computation the path of the working 897 LSP is determined first using a mechanism such as BRPC. Since domain 898 confidentiality is in use, the path returned may contain path keys. 900 When the path of the recovery LSP is computed (which may be before or 901 after the working LSP is signaled) the path exclusions supplied to 902 the PCE and exchanged between PCEs must use path keys as described in 903 [PCEP-XRO]. 905 5.4.2 Simultaneous Path Computation 907 As described in Section 4.4.2, diverse path computation can be 908 requested using the PCEP SVEC Object [PCEP], and BRPC could be 909 extended for inter-domain diverse path computation. However, to 910 conform to domain confidentiality requirements, path keys must be 911 used in the paths returned by the PCEs and signaled by RSVP-TE. 913 Note that the LSP segment approach may not be applicable here because 914 a path cannot be determined until BRPC procedures are completed. 916 6. Network Topology Specific Considerations 918 In some specific network topologies the schemes for setting up 919 diverse LSPs could be significantly simplified. 921 For example, consider the L1VPN or GMPLS UNI case. This may be viewed 922 as a linear sequence of three domains where the first and last 923 domains contain only a single node each. In such a scenario, no BRPC 924 procedures are needed, because there is no need for path computation 925 in the first and last domains even if the source and destination 926 nodes are multi-homed. 928 7. Addressing Considerations 930 All of the schemes described in this document are applicable when a 931 single address space is used across all domains. 933 There may also be cases where private address spaces are used within 934 some of the domains. This problem is similar to the use of domain 935 confidentiality since the ERO and RRO are meaningless outside a 936 domain even if they are available, and the problem can be solved 937 using the same techniques. 939 8. Note on SRLG Diversity 941 The schemes described in this document are applicable when the nodes 942 and links in different domains belong to different SRLGs which is 943 normally the case. 945 However, it is possible that nodes or links in different domains 946 belong to the same SRLG. That is, an SRLG may span domain boundaries. 947 In such cases, in order to establish SRLG diverse LSPs, several 948 considerations are needed: 950 - Record of the SRLGs used by the working LSP. 951 - Indication of a set of SRLGs to exclude in the computation of the 952 recovery LSP's path. 954 In this case, there is a conflict between any requirement for domain 955 confidentiality, and the requirement for SRLG diversity. One of the 956 requirements must be compromised. 958 Furthermore, SRLG IDs may be assigned independently in each domain, 959 and might not have global meaning. In such a scenario, some mapping 960 functions are necessary, similar to the mapping of other TE 961 parameters mentioned in Section 1.2. 963 9. IANA Considerations 965 This informational document makes no requests for IANA action. 967 10. Security Considerations 969 The core protocols used to achieve the procedures described in this 970 document are RSVP-TE and PCEP. These protocols include policy and 971 authentication capabilities as described in [RFC3209] and [PCEP]. 972 Furthermore, these protocols may be operated using more advanced 973 security features such as IPsec [RFC4301] and TLS [RFC4346]. 975 Security may be regarded as particularly important in inter-domain 976 deployments and serious consideration should be given to applying 977 the available security techniques as described in the documents 978 referenced above and as set out in [RFC4726]. 980 Additional discussion of security considerations for MPLG/GMPLS 981 networks can be found in [SECURITY-FW]. 983 This document does not of itself require additional security measures 984 and does not modify the trust model implicit in the protocols used. 985 Note, however, that domain confidentiality (that is the 986 confidentiality of the topology and path information from within any 987 one domain) is an important consideration in this document, and a 988 significant number of the mechanisms described in this document are 989 designed to preserve domain confidentiality. 991 11. References 993 11.1 Normative References 995 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 996 Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions 997 to RSVP for LSP Tunnels", RFC 3209, December 2001. 999 [RFC4216] Zhang, R., and Vasseur, JP., "MPLS Inter-Autonomous 1000 System (AS) Traffic Engineering (TE) Requirements", 1001 RFC 4216, November 2005. 1003 [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery 1004 (Protection and Restoration) Terminology for 1005 Generalized Multi-Protocol Label Switching (GMPLS)", 1006 RFC 4427, March 2006. 1008 [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A 1009 Framework for Inter-Domain MPLS Traffic 1010 Engineering", RFC 4726, November 2006. 1012 11.2 Informative References 1014 [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T., 1015 "Multiprotocol Label Switching (MPLS) Traffic 1016 Engineering (TE) Management Information Base (MIB)", 1017 June 2004. 1019 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 1020 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 1021 May 2005. 1023 [RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle, 1024 "Requirements for Inter-Area MPLS Traffic 1025 Engineering", RFC 4105, June 2005. 1027 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths 1028 (LSP) Hierarchy with Generalized Multi-Protocol 1029 Label Switching (GMPLS) Traffic Engineering (TE)", 1030 RFC 4206, October 2005. 1032 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. 1033 Rekhter, "Generalized Multiprotocol Label Switching 1034 (GMPLS) User-Network Interface (UNI): Resource 1035 ReserVation Protocol-Traffic Engineering (RSVP-TE) 1036 Support for the Overlay Model", RFC 4208, October 1037 2005. 1039 [RFC4301] Kent, S., Seo, K., "Security Architecture for the 1040 Internet Protocol," December 2005. 1042 [RFC4346] Dierks, T., and Rescorla, E., "The Transport Layer 1043 Security (TLS) Protocol Version 1.1", RFC 4346, 1044 April 2006. 1046 [RFC4428] D. Papadimitriou, Ed., "Analysis of Generalized 1047 Multi-Protocol Label Switching (GMPLS)-based 1048 Recovery Mechanisms (including Protection and 1049 Restoration)", RFC 4428, March 2006. 1051 [RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path 1052 Computation Element (PCE) Architecture", RFC 4655, 1053 August 2006. 1055 [RFC4802] Nadeau, T., and Farrel, A., "Generalized 1056 Multiprotocol Label Switching (GMPLS) Traffic 1057 Engineering Management Information Base", February 1058 2007. 1060 [RFC4847] Takeda, T., Ed., "Framework and Requirements for 1061 Layer 1 Virtual Private Networks", RFC 4847, April 1062 2007. 1064 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.), 1065 "RSVP-TE Extensions in support of End-to-End 1066 Generalized Multi-Protocol Label Switching (GMPLS)- 1067 based Recovery", RFC 4872, May 2007. 1069 [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. 1070 Farrel, "GMPLS Based Segment Recovery", RFC 4873, 1071 May 2007. 1073 [RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S., "Exclude 1074 Routes - Extension to Resource ReserVation Protocol- 1075 Traffic Engineering (RSVP-TE)", RFC 4874, April 1076 2007. 1078 [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for 1079 MPLS and GMPLS RSVP-TE ", RFC 4920, July 2007. 1081 [RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, "Label 1082 Switched Path Stitching with Generalized 1083 Multiprotocol Label Switching Traffic Engineering 1084 (GMPLS TE)", RFC 5150, February 2008. 1086 [RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS 1087 Traffic Engineering -- Resource Reservation 1088 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1089 RFC 5151, February 2008. 1091 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and Zhang, R., 1092 "A Per-Domain Path Computation Method for 1093 Establishing Inter-Domain Traffic Engineering (TE) 1094 Label Switched Paths (LSPs)", RFC 5152, February 1095 2008. 1097 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 1098 Computation (BRPC) procedure to compute shortest 1099 inter-domain Traffic Engineering Label Switched 1100 Paths", draft-ietf-pce-brpc, work in progress. 1102 [PCE-PATH-KEY] Bradford, R., Vasseur, JP., and Farrel, A, 1103 "Preserving Topology Confidentiality in Inter-Domain 1104 Path Computation Using a Key Based Mechanism", 1105 draft-ietf-pce-path-key, work in progress. 1107 [PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path 1108 Computation Element (PCE) communication Protocol 1109 (PCEP)", draft-ietf-pce-pcep, work in progress. 1111 [PCEP-XRO] Oki, E. and A. Farrel, "Extensions to the Path 1112 Computation Element Communication Protocol (PCEP) 1113 for Route Exclusions", draft-ietf-pce-pcep-xro, work 1114 in progress. 1116 [RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and Farrel, A., "RSVP 1117 Extensions for Path Key Support", draft-ietf-ccamp- 1118 path-key-ero, work in progress. 1120 [SECURITY-FW] Fang, L., " Security Framework for MPLS and GMPLS 1121 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 1122 framework, work in progress. 1124 12. Acknowledgments 1126 The authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro 1127 Fujihara, Dimitri Papadimitriou, and Meral Shirazipour for valuable 1128 comments. Deborah Brungard provided useful advice about the text. 1130 13. Authors' Addresses 1132 Tomonori Takeda 1133 NTT Network Service Systems Laboratories, NTT Corporation 1134 3-9-11, Midori-Cho 1135 Musashino-Shi, Tokyo 180-8585 Japan 1136 Email : takeda.tomonori@lab.ntt.co.jp 1138 Yuichi Ikejiri 1139 NTT Communications Corporation 1140 Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku 1141 Tokyo 163-1421, Japan 1142 Email: y.ikejiri@ntt.com 1143 Adrian Farrel 1144 Old Dog Consulting 1145 Email: adrian@olddog.co.uk 1147 Jean-Philippe Vasseur 1148 Cisco Systems, Inc. 1149 300 Beaver Brook Road 1150 Boxborough , MA - 01719 1151 USA 1152 Email: jpv@cisco.com 1154 Intellectual Property Consideration 1156 The IETF takes no position regarding the validity or scope of any 1157 Intellectual Property Rights or other rights that might be claimed 1158 to pertain to the implementation or use of the technology 1159 described in this document or the extent to which any license 1160 under such rights might or might not be available; nor does it 1161 represent that it has made any independent effort to identify any 1162 such rights. Information on the procedures with respect to 1163 rights in RFC documents can be found in BCP 78 and BCP 79. 1165 Copies of IPR disclosures made to the IETF Secretariat and any 1166 assurances of licenses to be made available, or the result of an 1167 attempt made to obtain a general license or permission for the use 1168 of such proprietary rights by implementers or users of this 1169 specification can be obtained from the IETF on-line IPR repository 1170 at http://www.ietf.org/ipr. 1172 The IETF invites any interested party to bring to its attention 1173 any copyrights, patents or patent applications, or other 1174 proprietary rights that may cover technology that may be required 1175 to implement this standard. Please address the information to the 1176 IETF at ietf-ipr@ietf.org. 1178 Full Copyright Statement 1180 Copyright (C) The IETF Trust (2008). 1182 This document is subject to the rights, licenses and 1183 restrictions contained in BCP 78, and except as set 1184 forth therein, the authors retain all their rights. 1186 This document and the information contained herein are provided 1187 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1188 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1189 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 1190 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1191 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1192 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 1193 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.