idnits 2.17.1 draft-ietf-ccamp-rsvp-te-exclude-route-02.txt: ** The Abstract section seems to be numbered 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 14. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1010), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1010. ** 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. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: c. The subobjects in the ERO and XRO SHOULD not contradict each other. If they do contradict, the subobjects with the L flag not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take precedence. If there is still a conflict, a PathErr with error code "Routing Problem" and error value of "Route blocked by Exclude Route" should be returned. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: SRLGs may also be indicated for exclusion from the path to the next abstract node in the ERO by the inclusion of an EXRO Subobject con-taining an SRLG subobject. If the L-bit value in the SRLG subobject is zero, the resources (nodes, links, etc.) identified by the SRLG MUST not be used on the path to the next abstract node indicated in the ERO. If the L-bit is set, the resources identified by the SRLG SHOULD be avoided. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The subobjects in the ERO and EXRS SHOULD not contradict each other. If they do contradict, the subobjects with the L bit not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take pre-cedence. If there is still a conflict, the subobjects in the ERO MUST take precedence. -- 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 7197 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: 'TBD' is mentioned on line 686, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 279, but not defined == Missing Reference: 'RFC-2026' is mentioned on line 700, but not defined == Unused Reference: 'MPLS-UNNUM' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'MPLS-BUNDLE' is defined on line 754, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-09 == Outdated reference: A later version (-09) exists of draft-ietf-tewg-interas-mpls-te-req-03 == Outdated reference: A later version (-01) exists of draft-decnodder-mpls-interas-protection-00 -- No information found for draft-ccamp-gmpls-overlay - is the name correct? == Outdated reference: A later version (-07) exists of draft-iwata-mpls-crankback-05 Summary: 15 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group CY Lee 2 Internet Draft A. Farrel 3 Expiration Date: January 2005 S. De Cnodder 4 July 2004 6 Exclude Routes - Extension to RSVP-TE 7 9 1. Status of this memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than a "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 2. Abstract 34 The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for 35 LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized 36 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 37 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow 38 abstract nodes and resources to be explicitly included in a path 39 setup, but not to be explicitly excluded. 41 In some networks where precise explicit paths are not computed at the 42 head end it may be useful to specify and signal abstract nodes and 43 resources that are to be explicitly excluded from routes. These 44 exclusions may apply to the whole path, or to parts of a path between 45 two abstract nodes specified in an explicit path. How Shared Risk 46 Link Groups (SLRGs) can be excluded is also specified in this 47 document. 49 This document specifies ways to communicate route exclusions during 50 path setup using RSVP-TE. 52 2.1 Changes compared to version 01 54 References updated. 56 - Editorial updates. 58 - Added Unnumbered Interface exclusions 60 - Acknowledgements updated. 62 - IPR section. 64 - Appendix A with applications is added. 66 3. Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 4. Overview 74 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 75 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 76 included in a path setup, using the Explicit Route Object (ERO). 78 In some systems it may be useful to specify and signal abstract nodes 79 and resources that are to be explicitly excluded from routes. This 80 may be because loose hops or abstract nodes need to be prevented from 81 selecting a route through a specific resource. This is a special case 82 of distributed path calculation in the network. 84 Two types of exclusions are required: 86 i) Exclude any of the abstract nodes in a given set anywhere on the 87 path. This set of abstract nodes is referred to as the Exclude 88 Route list. 90 ii) Exclude certain abstract nodes or resources between a specific 91 pair of abstract nodes present in an ERO. Such specific exclu- 92 sions are referred to as Explicit Exclusion Route. 94 To convey these constructs within the signaling protocol, a new RSVP 95 object and a new ERO subobject are introcuded respectively. 97 i) A new RSVP-TE object is introduced to convey the Exclude Route 98 list. This object is the Exclude Route Object (XRO). 100 ii) The second type of exclusion is achieved through a modification 101 to the existing ERO. A new subobject type the Explicit Exclude 102 Route Subobject (EXRS) is introduced to indicate an exclusion 103 between a pair of included abstract nodes. 105 The knowledge of SRLGs, as defined in [INTERAS-REQ], may be used to 106 compute diverse paths that can be used for protection. In systems 107 where it is useful to signal exclusions, it may be useful to signal 108 SRLGs to indicate groups of resources that should be excluded on the 109 whole of a path or between two abstract nodes specified in an expli- 110 cit path. 112 This document introduces an ERO subobject to indicate an SRLG to be 113 signaled in either of the two exclusion methods described above. This 114 subobject might also be appropriate for use within Explicit Routes or 115 Record Routes, but that discussion is outside the scope of this docu- 116 ment. 118 4.1 Scope of Exclude Routes 120 This document does not preclude a route exclusion from listing many 121 nodes or network elements to avoid. The intent is, however, to indi- 122 cate only the minimal number of subobjects to be avoided. For 123 instance it may be necessary to signal only the SRLGs (or Shared 124 Risk Groups) to avoid. 126 It is envisaged that most of the conventional inclusion subobjects 127 are specified in the signaled ERO only for the area where they are 128 pertinent. The number of subobjects to be avoided, specified in the 129 signaled XRO may be constant throughout the whole path setup, or the 130 subobjects to be avoided may be removed from the XRO as they become 131 irrelevant in the subsequent hops of the path setup. 133 For example, consider an LSP that traverses multiple computation 134 domains. A computation domain may be an area in the administrative 135 or IGP sense, or may be an arbitrary division of the network for 136 active management and path computational purposes. Let the primary 137 path be (Ingress, A1, A2, AB1, B1, B2, BC1, C1, C2, Egress) where: 139 - Xn denotes a node in domain X, and 141 - XYn denotes a node on the border of domain X and domain Y. 143 Note that Ingress is a node in domain A, and Egress is a node in 144 domain C. This is shown in Figure 1 where the domains correspond with 145 areas. 147 area A area B area C 148 <-------------------> <----------------> <------------------> 150 Ingress-----A1----A2----AB1----B1----B2----BC1----C1----C2----Egress 151 ^ \ / | \ / | \ / 152 | \ / | \ / | \ / 153 | A3----------A4--AB2--B3--------B4--BC2--C3----------C4 154 | ^ ^ 155 | | | 156 | | ERO: (C3-strict, C4-strict, 157 | | Egress-strict) 158 | | XRO: Not needed 159 | | 160 | ERO: (B3-strict, B4-strict, BC2-strict, Egress-loose) 161 | XRO: (C1, C2) 162 | 163 ERO: (A3-strict, A4-strict, AB2-strict, Egress-loose) 164 XRO: (B1, B2, BC1, C1, C2, Egress) 166 Consider the establishment of a node-diverse protection path in the 167 example above. The protection path must avoid all nodes on the pri- 168 mary path. The exclusions for area A are handled during Constrained 169 Shortest Path First (CSPF) computation at Ingress, so the ERO and XRO 170 signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, 171 Egress-loose) and (B1, B2, BC1, C1, C2) respectively. At AB2 the ERO 172 and XRO could be (B3-strict, B4-strict, BC2-strict, Egress-loose) and 173 (C1,C2) respectively. At BC2 the ERO could be (C3-strict, C4-strict, 174 Egress-strict) and an XRO is not needed from BC2 onwards. 176 In general, consideration should be given (as with explicit route) to 177 the size of signaled data and the impact on the signaling protocol. 179 4.2 Relationship to MPLS TE MIB 181 [MPLS-TE-MIB] defines managed objects for managing and modeling 182 MPLS-based traffic engineering. Included in [MPLS-TE-MIB] is a means 183 to configure explicit routes for use on specific LSPs. This confi- 184 guration allows the exclusion of certain resources. 186 In systems where the full explicit path is not computed at the 187 ingress (or at a path computation site for use at the ingress) it may 188 be necessary to signal those exclusions. This document offers a means 189 of doing this signaling. 191 5. Shared Risk Link Groups 193 The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- 194 OSPF]. 196 5.1 SRLG ERO Subobject 198 The format of the ERO and its subobjects are defined in [RSVP-TE]. 199 The new SRLG subobject is defined by this document as follows. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 |L| Type | Length | SRLG Id (4 bytes) | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | SRLG Id (continued) | Reserved | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 L 211 The L bit is an attribute of the subobject. The L bit is set 212 if the subobject represents a loose hop in the explicit route. 213 If the bit is not set, the subobject represents a strict hop in 214 the explicit route. 216 For exclusions (as used by XRO and EXRS defined in this docu- 217 ment), the L bit SHOULD be set to zero and ignored. 219 Type 221 The type of the subobject [TBD]. 223 Length 225 The Length contains the total length of the subobject in bytes, 226 including the Type and Length fields. The Length is always 8. 228 SRLG Id 230 The 32 bit identifier of the SRLG. 232 Reserved 233 Zero on transmission. Ignored on receipt 235 6. Exclude Route List 237 The exclude route identifies a list of abstract nodes that MUST NOT 238 be traversed along the path of the LSP being established. It is 239 RECOMMENDED to limit size of the exlude route list to a value local 240 to the node originating the exclude route list. 242 6.1 Exclude Route Object (XRO) 244 Abstract nodes to be excluded from the path are specified via the 245 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 247 Currently one C_Type is defined, Type 1 Exclude Route. The 248 EXCLUDE_ROUTE object has the following format: 250 Class = TBD, C_Type = 1 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | | 256 // (Subobjects) // 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Subobjects 262 The contents of an EXCLUDE_ROUTE object are a series of variable- 263 length data items called subobjects. The subobjects are identical 264 to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs. 266 The following subobject types are supported. 268 Type Subobject 269 1 IPv4 prefix 270 2 IPv6 prefix 271 4 Unnumbered Interface ID 272 32 Autonomous system number 273 TBD SRLG 275 The defined values for Type above are specified in [RSVP-TE] and 276 in this document. 278 The concept of loose or strict hops has no meaning in route exclu- 279 sion. The L bit, defined for ERO subobjects in [RSPV-TE], is re- 280 used here to indicate that an abstract node MUST be avoided (value 281 0) or SHOULD be avoided (value 1). 283 An Attribute octet is introduced in the subobjects that define IP 284 addresses to indicate the attribute (e.g. interface, node, SRLG) 285 associated with the IP addresses that can be excluded from the 286 path. For instance, the attribute node allows a whole node to be 287 excluded from the path, in contrast to the attribute interface, 288 which allows specific interfaces to be excluded from the path. 289 The attribute SRLG allows all SRLGs associated with an IP address 290 to be excluded from the path. 292 6.1.1 Subobject 1: IPv4 prefix 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 |L| Type | Length | IPv4 address (4 bytes) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IPv4 address (continued) | Prefix Length | Attribute | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 L 303 0 indicates that the attribute specified MUST be excluded 304 1 indicates that the attribute specified SHOULD be avoided 306 Attribute 308 interface 310 0 indicates that the interface or set of interfaces associ- 311 ated with the IP prefix should be excluded or avoided 313 node 315 1 indicates that the node or set of nodes associated with the 316 IP prefix should be excluded or avoided 318 SRLG 320 2 indicates that all the SRLGs associated with the IP prefix 321 should be excluded or avoided 323 The rest of the fields are as defined in [RSVP-TE]. 325 6.1.2 Subobject 2: IPv6 Prefix 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |L| Type | Length | IPv6 address (16 bytes) | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | IPv6 address (continued) | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | IPv6 address (continued) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | IPv6 address (continued) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | IPv6 address (continued) | Prefix Length | Attribute | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 L 341 0 indicates that the attribute specified MUST be excluded 342 1 indicates that the attribute specified SHOULD be avoided 344 Attribute 346 interface 348 0 indicates that the interface or set of interfaces associ- 349 ated with the IP prefix should be excluded or avoided 351 node 353 1 indicates that the node or set of nodes associated with the 354 IP prefix should be excluded or avoided 356 SRLG 358 2 indicates that all the SRLG associated with the IP prefix 359 should be excluded or avoided 361 The rest of the fields are as defined in [RSVP-TE]. 363 6.1.3 Subobject 32: Autonomous System Number 365 The L bit of an Autonomous System Number subobject has meaning in 366 an Exclude Route (contrary to its usage in an Explict Route 367 defined in [RSVP-TE]. The meaning is as for other subobjects 368 described above. That is: 370 0 indicates that the abstract node specified MUST be excluded 372 1 indicates that the abstract node specified SHOULD be avoided 374 The rest of the fields are as defined in [RSVP-TE]. There is no 375 Attribute octet defined. 377 6.1.4 Subobject TBD: SRLG 379 The meaning of the L bit is as follows: 381 0 indicates that the SRLG specified MUST be excluded 383 1 indicates that the SRLG specified SHOULD be avoided 385 The Attribute octet is not present. The rest of the fields are as 386 defined in the "SRLG ERO Subobject" section of this document. 388 6.1.5 Subobject 4: Unnumbered Interface ID Subobject 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |L| Type | Length | Reserved | Attribute | 394 | | | |(must be zero) | | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Router ID | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Interface ID (32 bits) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 L 402 0 indicates that the attribute specified MUST be excluded 403 1 indicates that the attribute specified SHOULD be avoided 405 Attribute 407 interface 409 0 indicates that the Interface ID specified should be excluded 410 or avoided 412 node 414 1 indicates that the node with the Router ID should be 415 excluded or avoided (this can be achieved using IPv4/v6 416 subobject as well, but is included here because it may be 417 convenient to use subobjects from RRO, in specifying the 418 exclusions) 420 SRLG 421 2 indicates that all the SRLGs associated with the interface 422 should be excluded or avoided 424 Reserved 425 Zero on transmission. Ignored on receipt. 427 The rest of the fields are as defined in [MPLS_UNNUM]. 429 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 431 The exclude route list is encoded as a series of subobjects con- 432 tained in an EXCLUDE_ROUTE object. Each subobject identifies an 433 abstract node in the exclude route list. 435 Each abstract node may be a precisely specified IP address belong- 436 ing to a node, or an IP address with prefix identifying interfaces 437 of a group of nodes, or an Autonomous System. 439 The Explicit Route and routing processing is unchanged from the 440 description in [RSVP-TE] with the following additions: 442 a. When a Path message is received at a node, the node must check 443 that it is not a member of any of the abstract nodes in the XRO if 444 it is present in the Path message. If the node is a member of any 445 of the abstract nodes in the XRO with the L-flag set to "exclude", 446 it should return a PathErr with the error code "Routing Problem" 447 and error value of "Local node in Exclude Route". If there are 448 SRLGs in the XRO, the node should check that the resources the 449 node uses are not part of any SRLG with the L-flag set to 450 "exclude" that is specified in the XRO. If it is, it should 451 return a PathErr with error code "Routing Problem" and error value 452 of "Local node in Exclude Route". 454 b. Each subobject must be consistent. If a subobject is not con- 455 sistent then the node should return a PathErr with error code 456 "Routing Problem" and error value "Inconsistent Subobject". An 457 example of an inconsistent subobject is an IPv4 Prefix subobject 458 containing the IP address of a node and the attribute field is set 459 to "interface" or "SRLG". 461 c. The subobjects in the ERO and XRO SHOULD not contradict each 462 other. If they do contradict, the subobjects with the L flag not 463 set, strict or MUST be excluded, respectively, in the ERO or XRO 464 MUST take precedence. If there is still a conflict, a PathErr 465 with error code "Routing Problem" and error value of "Route 466 blocked by Exclude Route" should be returned. 468 d. When choosing a next hop or expanding an explicit route to include 469 additional subobjects, a node: 471 i) must not introduce an explicit node or an abstract node that 472 equals or is a member of any abstract node that is specified 473 in the Exclude Route Object with the L-flag set to "exclude". 474 The number of introduced exlicit nodes or abstract nodes with 475 the L flag set to "avoid" should be minimised. 477 ii) must not introduce links, nodes or resources identified by the 478 SRLG Id specified in the SRLG subobjects(s). The number of 479 introduced SLRGs with the L flag set to "avoid" should be 480 minimised. 482 If these rules preclude further forwarding of the Path message, 483 the node should return a PathErr with the error code "Routing 484 Problem" and error value of "Route blocked by Exclude Route". 486 Note that the subobjects in the XRO is an unordered list of subob- 487 jects. 489 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 490 support the XRO will forward it uninspected and will not apply the 491 extensions to ERO processing described above. This makes the XRO a 492 'best effort' process. 494 This 'best-effort' approach is chosen to allow route exclusion to 495 traverse parts of the network that are not capable of parsing or han- 496 dling the new function. Note that Record Route may be used to allow 497 computing nodes to observe violations of route exclusion and attempt 498 to re-route the LSP accordingly. 500 If a node supports the XRO, but not a particular subobject or part of 501 that subobject, then that particular subobject is ignored. Examples 502 of a part of a subobject that can be supported are: (1) only prefix 503 32 of the IPv4 prefix subobject could be supported, or (2) a particu- 504 lar subobject is supported but not the particular attribute field. 506 When a node forwards a Path message, it can do the following three 507 operations related to XRO besides of the processing rules mentioned 508 above: 510 1. If no XRO was present, an XRO may be included. 512 2. If an XRO was present, it may remove the XRO if it is sure that 513 the next nodes do not need this information anymore. An example is 514 where a node can expand the ERO to a full strict path towards the 515 destination. See Figure 1 where BC2 is removing the XRO from the 516 Path message. 518 3. If an XRO was present, the content of the XRO can be modified. 519 Subobjects can be added or removed. See Figure 1 for an example 520 where AB2 is stripping off some subobjects. 522 7. Explicit Exclude Route 524 The Explicit Exclude Route defines abstract nodes or resources (such 525 as links, unnumbered interfaces or labels) that must not be used on 526 the path between two inclusive abstract nodes or resources in the 527 explicit route. 529 7.1. Explicit Exclusion Route Subobject (EXRS) 531 A new ERO subobject type is defined. The Explicit Exclude Route 532 Subobject (EXRS) has type [TBD]. The EXRS may not be present in an 533 RRO or XRO. 535 The format of the EXRS is as follows. 537 0 1 538 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 540 |L| Type | Length | EXRS subobjects | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 543 L 544 ignored and must be zero 545 [Note: The L bit in an EXRS subobject is as defined for the XRO 546 subobjects] 548 Type 549 The type of the subobject, i.e. EXRS [TBD] 551 EXRS subobjects 552 An EXRS subobject indicates the abstract node or resource to be 553 excluded. The format of this field is exactly the format of an 554 XRO subobject and may include an SRLG subobject. Both subob- 555 jects are as described earlier in this document. 557 Thus, an EXRO subobject for an IP hop might look as follows: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |L| Type | Length |L| Type | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | IPv4 address (4 bytes) | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Prefix Length | Attribute | Reserved | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Note: The Most Significant Bit in the Type field could be used to 570 indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating 571 the need to prepend the subobject with an additional TLV header. This 572 would reduce the number bytes require for each subobject by 2 bytes. 573 However, this approach would reduce the ERO Type field space by half. 574 This issue need WG discussion and feedback. 576 7.2. Semantics and Processing Rules for the EXRS 578 Each EXRS may carry multiple exclusions. The exclusion is encoded 579 exactly as for XRO subobjects and prefixed by an additional Type and 580 Length. 582 The scope of the exclusion is the step between the previous ERO 583 subobject that identifies an abstract node, and the subsequent ERO 584 subobject that identifies an abstract node. Multiple exclusions may 585 be present between any pair of abstract nodes. 587 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 588 Systems that must not be traversed on the path to the next abstract 589 node indicated in the ERO. 591 Exclusions may also indicate resources (such as unnumbered inter- 592 faces, link ids, labels) that must not be used on the path to the 593 next abstract node indicated in the ERO. 595 SRLGs may also be indicated for exclusion from the path to the next 596 abstract node in the ERO by the inclusion of an EXRO Subobject con- 597 taining an SRLG subobject. If the L-bit value in the SRLG subobject 598 is zero, the resources (nodes, links, etc.) identified by the SRLG 599 MUST not be used on the path to the next abstract node indicated in 600 the ERO. If the L-bit is set, the resources identified by the SRLG 601 SHOULD be avoided. 603 The subobjects in the ERO and EXRS SHOULD not contradict each other. 604 If they do contradict, the subobjects with the L bit not set, strict 605 or MUST be excluded, respectively, in the ERO or XRO MUST take pre- 606 cedence. If there is still a conflict, the subobjects in the ERO 607 MUST take precedence. 609 If a node is called upon to process an EXRS and does not support han- 610 dling of exclusions it will return a PathErr with a "Bad 611 EXPLICIT_ROUTE object" error. 613 If the presence of EXRO Subobjects precludes further forwarding of 614 the Path message, the node should return a PathErr with the error 615 code "Routing Problem" and error value of "Route blocked by Exclude 616 Route". 618 8. Minimum compliance 620 An implementation must be at least compliant with the following: 622 A. The XRO MUST be supported with the following restrictions: 624 A.1. The IPv4 Prefix subobject MUST be supported with a prefix length 625 of 32, and an attribute value of "interface" and "node". Other 626 prefix values and attribute values MAY be supported. 628 A.2. The IPv6 Prefix subobject MUST be supported with a prefix length 629 of 128, and an attriubute value of "interface" and "node". Other 630 prefix values and attribute values MAY be supported. 632 B. The EXRS SHOULD be supported. If supported, the same restrictions 633 as for the XRO apply. 635 C. If XRO or EXRS are supported, the implementation MUST be compliant 636 with the processing rules of the supported, not supported, or par- 637 tially supported subobjects as specified within this document. 639 9. Security Considerations 641 The new exclude route object poses no security exposures over and 642 above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security con- 643 cerns that exist with Explicit Routes should be considered with 644 regard to route exclusions. 646 10. IANA Considerations 648 It might be considered that a possible approach would be to assign 649 one of the bits of the ERO sub-object type field (perhaps the top 650 bit) to identify that a sub-object is intended for inclusion 651 rather than exclusion. However, [RSVP-TE] states that the type 652 field (seven bits) should be assigned as 0 - 63 through IETF con- 653 sensus action, 64 - 95 as first come first served, and 96 - 127 654 are reserved for private use. It would not be acceptable to dis- 655 rupt existing implementations so the only option would be to split 656 the IETF consensus range leaving only 32 sub-object types. It is 657 felt that that would be an unacceptably small number for future 658 expansion of the protocol. 660 10.1. New Class Numbers 662 One new class number is required. 664 EXCLUDE_ROUTE 665 Class-Num = 011bbbbb 666 CType: 1 668 10.2. New Subobject Types 670 A new subobject type for the Exclude Route Object and Explicit 671 Exclude Route Subobject is required. 673 SRLG subobject 675 A new subobject type for the ERO is required. 677 Explicit Exclude Route subobject 679 10.3. New Error Codes 681 New error values are needed for the error code 'Routing Problem'. 683 Unsupported Exclude Route Subobject Type [TBD] 684 Inconsistent Subobject [TBD] 685 Local Node in Exclude Route [TBD] 686 Route Blocked by Exclude Route [TBD] 688 11. Acknowledgments 690 This document reuses text from [RSVP-TE] for the description of 691 EXCLUDE_ROUTE. 693 The authors would like to express their thanks to Lou Berger, Steffen 694 Brockmann, Igor Bryskin, Dimitri Papadimitriou, Cristel Pelsser, and 695 Richard Rabbat for their considered opinions on this draft. Also 696 thanks to Yakov Rekhter for reminding us about SRLGs! 698 12. Intellectual Property Considerations 700 This following is taken from Section 10.4 of [RFC-2026]. 702 The IETF takes no position regarding the validity or scope of any 703 intellectual property or other rights that might be claimed to per- 704 tain to the implementation or use of the technology described in this 705 document or the extent to which any license under such rights might 706 or might not be available; neither does it represent that it has made 707 any effort to identify any such rights. Information on the IETF's 708 procedures with respect to rights in standards-track and standards- 709 related documentation can be found in BCP-11. Copies of claims of 710 rights made available for publication and any assurances of licenses 711 to be made available, or the result of an attempt made to obtain a 712 general license or permission for the use of such proprietary rights 713 by implementors or users of this specification can be obtained from 714 the IETF Secretariat. 716 The IETF invites any interested party to bring to its attention any 717 copyrights, patents or patent applications, or other proprietary 718 rights which may cover technology that may be required to practice 719 this standard. Please address the information to the IETF Executive 720 Director. 722 The IETF has been notified of intellectual property rights claimed in 723 regard to some or all of the specification contained in this docu- 724 ment. For more information consult the online list of claimed 725 rights. 727 13. References 729 13.1 Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997 734 [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP 735 for LSP Tunnels", RFC 3209, December 2001. 737 [GMPLS-RSVP-TE] Berger, L., (Editor), "Generalized Multi-Protocol Label 738 Switching (GMPLS) Signaling Resource ReserVation 739 Protocol-Traffic Engineering (RSVP-TE) Extensions", 740 RFC 3473, January 2003. 742 [GMPLS-OSPF] K. Kompela, Y. Rekhter, (Editors) "OSPF Extensions 743 in Support of Generalized MPLS", Internet Draft, 744 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, 745 October 2003 (work in progress). 747 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered 748 Links in RSVP-TE", RFC 3477, January 2003. 750 www.ietf.org/ internet-drafts/draft-ietf-mpls-bundle-04.txt 752 13.2 Informational References 754 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., 755 "Link Bundling in MPLS Traffic Engineering", 756 Internet Draft, draft-ietf-mpls-bundle-04.txt, 757 July 2002, (work in progress). 759 [MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label 760 Switching (MPLS) Traffic Engineering Management 761 Information Base", Internet Draft, draft-ietf-mpls- 762 te-mib-09.txt, November 2002 (work in progress). 764 [INTERAS-REQ] R. Zhang, JP Vasseur (Editors), "MPLS Inter-AS Traffic 765 Engineering Requirements", Internet Draft, 766 draft-ietf-tewg-interas-mpls-te-req-03.txt, December 767 2003 (work in progress). 769 [INTERAS] De Cnodder, S., Pelsser, C., "Protection for 770 inter-AS MPLS tunnels", Internet Draft, draft- 771 decnodder-mpls-interas-protection-00.txt, February 772 2003, (work in progress). 774 [OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., Rekhter, Y., 775 GMPLS RSVP Support for the Overlay Model", Internet 776 Draft, draft-ccamp-gmpls-overlay-02.txt, October 777 2003, (work in progress). 779 [OSPF-TE] Katz, D., Yeung, D., and Kompella, K., "Traffic 780 Engineering Extensions to OSPF version 2", RFC 3630, 781 September 2003. 783 [ISIS-TE] Smit, H., Li, T., "IS-IS extensions for Traffic 784 Engineering", Internet Draft, draft-ietf-isis- 785 traffic-05.txt, August 2003, (work in progress). 787 [CRANKBACK] Farrel, A., (Editor), "Crankback Routing Extensions 788 for MPLS Signaling", Internet Draft, draft-iwata-mpls- 789 crankback-05.txt, March 2003, (work in progress). 791 14. Authors' Information 793 Cheng-Yin Lee 794 Alcatel 795 600 March Road. 796 Ottawa, Ontario 797 Canada K2K 2E6 798 EMail: Cheng-Yin.Lee@alcatel.com 800 Adrian Farrel 801 Old Dog Consulting 802 Phone: +44 (0) 1978 860944 803 EMail: adrian@olddog.co.uk 805 Stefaan De Cnodder 806 Alcatel 807 Francis Wellesplein 1 808 B-2018 Antwerp, Belgium 809 EMail: stefaan.de_cnodder@alcatel.be 811 Appendix A: applications 813 This section describes some applications that can make use of the 814 XRO. The intention is to show that the XRO is not an application 815 specific object, but that it can be used for multiple purposes. In a 816 few examples, other solutions might be possible for that particular 817 case but the intention is to show that also a single object can be 818 used for all the examples, hence making the XRO a rather generic 819 object without having to define a solution and new objects for each 820 new application. 822 A.1 Inter-area LSP protection 824 One method to establish an inter-area LSP is where the ingress router 825 selects an ABR, and then the ingress router computes a path towards 826 this selected ABR such that the configured constraints of the LSP are 827 fulfilled. In the example of figure A.1, an LSP has to be established 828 from node A in area 1 to node C in area 2. If no loose hops are con- 829 figured, then the computed ERO at A could looks as follows: (A1- 830 strict, A2-strict, ABR1-strict, C-loose). When the Path message 831 arrives at ABR1, then the ERO is (ABR1-strict, C-loose) and it can be 832 expanded by ABR1 to (B1-strict, ABR3-strict, C-loose). Similar, at 833 ABR3 the received ERO is (ABR3-strict, C-loose) and it can be 834 expanded to (C1-strict, C2-strict, C-strict). If also a backup LSP 835 has to be established, then A takes another ABR (ABR2 in this case) 836 and computes a path towards this ABR that fulfills the constraints of 837 the LSP and such that is disjoint from the path of the primary LSP. 838 The ERO generated by A looks as follows for this example: (A3-strict, 839 A4-strict, ABR2-strict, C-loose). 841 In order to let ABR2 expand the ERO, it also needs to know the path 842 of the primary LSP to expand the ERO such that it is disjoint from 843 the path of the primary LSP. Therefore, A also includes an XRO that 844 at least contains (ABR1, B1, ABR3, C1, C2). Based on these con- 845 straints, ABR2 can expand the ERO such that it is disjoint from the 846 primary LSP. In this example, the ERO computed by ABR2 would be (B2- 847 strict, ABR4-strict, C-loose), and the XRO generated by B contains at 848 least (ABR3, C1, C2). The latter information is needed to let ABR4 to 849 expand the ERO such that the path is disjoint from the primary LSP in 850 area 2. 852 Area 1 Area 0 Area 2 853 <---------------><--------------><---------------> 855 +---A1---A2----ABR1-----B1-----ABR3----C1---C2---+ 856 | | | | | 857 | | | | | 858 A | | | C 859 | | | | | 860 | | | | | 861 +---A3---A4----ABR2-----B2-----ABR4----C3---C4---+ 863 Figure A.1: Inter-area LSPs 865 In this example, a node performing the path computation, first 866 selects an ABR and then it computes a strict path towards this ABR. 867 For the backup LSP, all nodes of the primary LSP in the next areas 868 has to be put in the XRO (with the exception of the destination node 869 if node protection and no link protection is required). When an ABR 870 computes the next path segment, i.e. the path over the next area, it 871 may remove the nodes from the XRO that are located in that area with 872 the exception of the ABR where the primary LSP is exiting the area. 873 The latter information is still required because when the selected 874 ABR (ABR4 in this example) further expands the ERO, it has to exclude 875 the ABR on which the primary is entering that area (ABR3 in this 876 example). This means that when ABR2 generates an XRO, it may remove 877 the nodes in area 0 from the XRO but not ABR3. Note that not doing 878 this would not harm in this example because there is no path from 879 ABR4 to C via ABR3 in area2. If there would be a links between ABR4- 880 ABR3 and ABR3-C, then it is required to have ABR3 in the XRO gen- 881 erated by ABR2. 883 Discussion on the length of the XRO: when link or node protection is 884 requested, the length of the XRO is bounded by the length of the RRO 885 of the primary LSP. It can be made shorter by removing nodes by the 886 ingress node and the ABRs. In the example above, the RRO of the pri- 887 mary LSP contains 8 subobjects, while the maximum XRO length can be 888 bounded by 6 subobjects (nodes A1 adn A2 do not have to be in the 889 XRO. For SRLG protection, the XRO has to list all SRLGs that are 890 crossed by the primary LSP. 892 A.2 Inter-AS LSP protection 894 When an inter-AS LSP is established, which has to be protected by a 895 backup LSP to provide link or node protection, the same method as for 896 the inter-area LSP case can be used. The difference is when the 897 backup LSP is not following the same AS-path as the primary LSP 898 because then the XRO should always contain the full path of the pri- 899 mary LSP. In case the backup LSP is following the same AS-path (but 900 with different ASBRs - at least in case of node protection), it is 901 much similar as the inter-area case: ASBRs expanding the ERO over the 902 next AS may remove the XRO subobjects located in that AS. Note that 903 this can only be done by ingress ASBRs (the ASBR where the LSP is 904 entering the AS). 906 Discussion on the length of the XRO: the XRO is bounded by the length 907 of the RRO of the primary LSP. 909 Suppose that SRLG protection is required, and the ASs crossed by the 910 main LSP use a consistent way of allocating SRLG-ids to the links 911 (i.e. the ASs use a single SRLG space). In this case, the SRLG-ids of 912 each link used by the main LSP can be recorded by means of the RRO, 913 which are then used by the XRO. If the SRLG-ids are only meaningfull 914 local to the AS, putting SRLG-ids in the XRO crossing many ASs makes 915 no sense. More details on the method of providing SRLG protection for 916 inter-AS LSPs can be found in [INTERAS]. Basically, the link IP 917 address of the inter-AS link used by the primary LSP is put into the 918 XRO of the Path message of the detour LSP or bypass tunnel. The ASBR 919 where the detour LSP or bypass tunnel is entering the AS can 920 translate this into the list of SRLG-ids known to the local AS. 922 Discussion on the length of the XRO: the XRO only contains 1 subob- 923 ject, which contains the IP address of the inter-AS link traversed by 924 the primary LSP (in the assumption that the primary LSP and detour 925 LSP or bypass tunnel are leaving the AS in the same area, and they 926 are also entering the next AS in the same area). 928 A.3 Protection in the GMPLS overlay model 930 When an edge-node wants to establish an LSP towards another edge-node 931 over an optical core network as described in [OVERLAY] (see figure 932 A.2), the XRO can be used for multiple purposes. 934 Overlay Overlay 935 Network +----------------------------------+ Network 936 +----------+ | | +----------+ 937 | +----+ | | +-----+ +-----+ +-----+ | | +----+ | 938 | | | | | | | | | | | | | | | | 939 | --+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+-- | 940 | | | | +--+--+ | | | | +---+--+ | | | | 941 | +----+ | | | +--+--+ +--+--+ +--+--+ | | | +----+ | 942 | | | | | | | | | | | 943 +----------+ | | | | | | | +----------+ 944 | | | | | | | 945 +----------+ | | | | | | | +----------+ 946 | | | | +--+--+ | +--+--+ | | | | 947 | +----+ | | | | | +-------+ | | | | +----+ | 948 | | +-+--+ | | CN4 +---------------+ CN5 | | +--+-+ | | 949 | --+ EN2+-+-----+--+ | | +---+-----+-+ EN4+-- | 950 | | | | | +-----+ +-----+ | | | | | 951 | +----+ | | | | +----+ | 952 | | +----------------------------------+ | | 953 +----------+ Core Network +----------+ 954 Overlay Overlay 955 Network Network 957 Legend: EN - Edge Node 958 CN - Core Node 959 Figure A.2 961 A first application is where an edge-node wants to establish multiple 962 LSPs towards the same destinatin edge-node, and these LSPs need to 963 have as few or no SRLGs in common. In this case EN1 could establish 964 an LSP towards EN3 and then it can establish a second LSP listing all 965 links used by the first LSP with the indicition to avoid the SRLGs of 966 these links. This information can be used by CN1 to compute a path 967 for the second LSP. If the core network consists of multiple areas, 968 then the SRLG-ids have to be listed in the XRO. The same example 969 applies to nodes and links. 971 Another application is where the edge-node wants to set up a backup 972 LSP that is also protecting the links between the edge-nodes and 973 core-nodes. For instance, when EN2 establishes an LSP to EN4, it 974 sends a Path message to CN4, which computes a path towards EN4 over 975 for instance CN5. When EN2 gets back the RRO of that LSP, it can sig- 976 nal a new LSP to CN1 with EN4 as destination and the XRO computed 977 based on the RRO of the first LSP. Based on this information, CN1 can 978 compute a path that has the requested diversaty properties (e.g, a 979 path going over CN2, CN3 and then to EN4). 981 It is clear that in these examples, the core-node may not edit the 982 RRO in a Resv message such that it includes only the subobjects from 983 the egress core-node through the egress edge-node. 985 A.4 LSP protection inside a single area 987 The XRO can also be used inside a single area. Take for instance a 988 network where the TE extensions of the IGPs as described in [OSPF-TE] 989 and [ISIS-TE] are not used, and hence each node has to select a 990 next-hop and possibly crankback [CRANKBACK] has to be used when there 991 is no viable next-hop. In this case, when signaling a backup LSP, the 992 XRO can be put in the Path message to exclude the links, nodes or 993 SRLGs of the primary LSP. An alternative to provide this functional- 994 ity would be to indicate in the Path message of the backup LSP, the 995 primary LSP together witn an indication which type of protection is 996 required. This latter solution would work for link and node protec- 997 tion, but not for SRLG protection. 999 Discussion on the length of the XRO: when link or node protection is 1000 requested, the XRO is of the same length as the RRO of the primary 1001 LSP. For SRLG protection, the XRO has to list all SRLGs that are 1002 crossed by the primary LSP. Note that for SRLG protection, the link 1003 IP address to reference the SRLGs of that link cannot be used since 1004 the TE extensions of the IGPs are not used in this example, hence, a 1005 node cannot translate any link IP address located in that area to its 1006 SRLGs. 1008 16. Full Copyright Statement 1010 Copyright (C) The Internet Society (2002). All Rights Reserved. 1012 This document is subject to the rights, licenses and restrictions 1013 contained in BCP 78, and except as set forth therein, the authors 1014 retain all their rights. 1016 This document and translations of it may be copied and furnished to 1017 others, and derivative works that comment on or otherwise explain it 1018 or assist in its implementation may be prepared, copied, published 1019 and distributed, in whole or in part, without restriction of any 1020 kind, provided that the above copyright notice and this paragraph are 1021 included on all such copies and derivative works. However, this 1022 document itself may not be modified in any way, such as by removing 1023 the copyright notice or references to the Internet Society or other 1024 Internet organizations, except as needed for the purpose of develop- 1025 ing Internet standards in which case the procedures for copyrights 1026 defined in the Internet Standards process must be followed, or as 1027 required to translate it into languages other than English. 1029 The limited permissions granted above are perpetual and will not be 1030 revoked by the Internet Society or its successors or assigns. This 1031 document and the information contained herein is provided on an "AS 1032 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1033 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1034 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1035 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1036 OR FITNESS FOR A PARTICULAR PURPOSE.