idnits 2.17.1 draft-lee-ccamp-rsvp-te-exclude-route-01.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 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 14 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 16 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([RSVP-TE], [GMPLS-RSVP-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 bit not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take precedence. If there is still a conflict, the subobjects in the ERO MUST take precedence. == 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 precedence. 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 (November 2002) is 7832 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 410, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 245, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'MPLS-UNNUM' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'GMPLS-SIG' is defined on line 558, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-07 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-07 -- No information found for draft-papadimitriou- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CCAMP-SRLG' == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-08 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-rsvp-unnum-06 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-08 Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force CY Lee 3 INTERNET DRAFT A. Farrel 4 S. De Cnodder 6 November 2002 8 Exclude Routes - Extension to RSVP-TE 9 11 1. Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 2. Abstract 30 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 31 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 32 included in a path setup, but not to be explicitly excluded. 34 In some systems where precise explicit paths are not computed at the 35 head end it may be useful to specify and signal abstract nodes and 36 resources that are to be explicitly excluded from routes. These 37 exclusions may apply to the whole of a path, or to parts of a path 38 between two abstract nodes specified in an explicit route. 40 Shared Risk Link Groups (SRLGs) allow the definition of resources or 41 groups of resources that share the same risk of failure. The 42 knowledge of SRLGs may be used to compute diverse paths that can be 43 used for protection. In systems where it is useful to signal 44 exclusions, it may be useful to signal SRLGs to indicate groups of 45 resources that should be excluded on the whole of a path or between 46 two abstract nodes specified in an explicit path. 48 This draft specifies ways to communicate route exclusions during path 49 setup using RSVP-TE. 51 These approaches are equally applicable to other MPLS TE signaling 52 protocols such as CR-LDP. 54 3. Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC2119]. 59 4. Overview 61 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 62 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 63 included in a path setup, using the Explicit Route Object (ERO). 65 In some systems it may be useful to specify and signal abstract nodes 66 and resources that are to be explicitly excluded from routes. This 67 may be because loose hops or abstract nodes need to be prevented from 68 causing a route through a specific resource. This is a special case 69 of path calculation distribution to nodes within the system. 71 Two types of exclusions are required: 73 i) Do not include any of the abstract nodes in a given set anywhere 74 on the path. This set of abstract nodes to exclude is referred to as 75 the Exclude Route list. 77 ii) Do not include certain abstract nodes or resources between a 78 specific pair of abstract nodes present in an ERO. Such specific 79 exclusions are referred to as Explicit Exclusion Route. 81 A new RSVP-TE object is introduced to convey the Exclude Route list. 82 This object is the Exclude Route Object (XRO). 84 The second type of exclusion is achieved through a modification to 85 the existing ERO. A new subobject type the Explicit Exclude Route 86 Subobject (EXRS) is introduced to indicate an exclusion between a 87 pair of included abstract nodes. 89 At the same time, it is recognized that SRLGs are a useful means of 90 indicating resources that share the same risk of failure. When 91 establishing protection LSPs they are often required to be node and 92 link diverse from the LSPs that they protect. Further, where SRLGs 93 are known, the protection LSPs are required to not utilize resources 94 in the SRLGs traversed by the protected LSPs. 96 This draft introduces an ERO subobject to indicate an SRLG to be 97 signaled in either of the two exclusion methods described above. This 98 subobject might also be appropriate for use within Explicit Routes, 99 but that discussion is outside the scope of this draft. 101 4.1 Scope of Excluded Routes 103 This draft does not preclude a route exclusion from listing many 104 nodes or network elements to avoid. The intent is, however, to 105 indicate only the minimal number of subobjects to be avoided. For 106 instance it may be necessary to signal only the SRLGs (or Shared 107 Risk Groups) to avoid. 109 It is envisaged most of the conventional inclusion subobjects are 110 specified in the ERO of signaling only for the area where they 111 pertain. The number of subobjects to be avoided, specified in the 112 ERO in signaling, may be constant throughout the whole path setup or 113 the subobjects to be avoided may be removed from the ERO as they 114 become irrelevant in the subsequent hops of the path setup. For e.g. 115 let the primary path be (Ingress1 A1,A2,AB1,B1,B2,BC1,C1,C2,Egress1) 116 where Xn denotes a node in Area X and XY1 denotes an ABR (Area Border 117 Router) connected to Area X and Y. Since the ERO for nodes to exclude 118 in Area A are already taken into consideration during CSPF at 119 Ingress1, the ERO for the secondary diverse path signaled at Ingress1 120 would be (A11,A12,AB2,!{B1,B2,BC1,C1,C2}) and at AB2 would be 121 (B11,B12,BC2,!{C1,C2}) and at BC2 would be(C11,C12). 123 In general, consideration should be given (as with explicit route) to 124 the size of signaled data and the impact on the signaling protocol. 126 4.2 Relationship to MPLS TE MIB 128 [MPLS-TE-MIB] defines managed objects for managing and modeling MPLS- 129 based traffic engineering. Included in [MPLS-TE-MIB] is a means to 130 configure explicit routes for use on specific LSPs. This 131 configuration allows the exclusion of certain resources. 133 In systems where the full explicit path is not computed at the 134 ingress (or at a path computation site for use at the ingress) it may 135 be necessary to signal those exclusions. This draft offers a means of 136 doing this signaling. 138 5. Shared Risk Link Groups 139 The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- 140 OSPF]. These 32 bits are divided into an 8 bit type field and a 24 141 bit identifier in [CCAMP-SRLG]. 143 5.1 SRLG ERO Subobject 144 The format of the ERO and its subobjects are defined in [RSVP-TE]. 146 The SRLG subobject is defined as follows. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |L| Type | Length | Tolerance | Reserved | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | SRLG Id | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 L 158 The L bit is an attribute of the subobject. The L bit is set 159 if the subobject represents a loose hop in the explicit route. 160 If the bit is not set, the subobject represents a strict hop in 161 the explicit route. 163 For exclusions, the L bit SHOULD be set to zero and ignored. 165 Type 167 The type of the subobject [TBD]. 169 Length 171 The Length contains the total length of the subobject in bytes, 172 including the Type and Length fields. The Length is always 8. 174 Tolerance 176 The level to which it is permissible for this SRLG to be 177 included in the path when more than one SRLG is specified. 178 A value of zero indicates that this SRLG MUST be avoided. A 179 tolerance value of n < m indicates that the SRLG MUST be 180 avoided in preference to an SRLG with tolerance value m. 182 If only one SRLG is present, then a value other than zero 183 indicates the SRLG SHOULD be avoided. 185 SRLG Id 186 The 32 bit identifier of the SRLG. 188 5.2 Exclusion Tolerance Semantics 190 The Tolerance field in the SRLG subobject indicates the degree to 191 which the SRLG must be avoided. (The degree to which it is 192 permissible to include it.) 194 If the Tolerance field has the value zero (0), the LSP MUST NOT 195 traverse or use any resource that is a member of the SRLG. 197 If the value is non-zero, all path computation elements SHOULD 198 attempt to select routes that avoid all resources that are members of 199 the SRLG. 201 Where more than one SRLG with non-zero Tolerance value is specified 202 for exclusion and no route can be found that avoids both SRLGs, a 203 route SHOULD be chosen that avoids the SRLG with the lower Tolerance 204 value. 206 6. Exclude Route List 208 The exclude route identifies a list of abstract nodes that MUST NOT 209 be traversed along the path. 211 6.1 Exclude Route Object (XRO) 213 Abstract nodes to be excluded from the path are specified via the 214 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 216 Currently one C_Type is defined, Type 1 Exclude Route. The 217 EXCLUDE_ROUTE object has the following format: 219 Class = TBD, C_Type = 1 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | | 225 // (Subobjects) // 226 | | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Subobjects 231 The contents of an EXCLUDE_ROUTE object are a series of variable- 232 length data items called subobjects. The subobjects are identical 233 to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs. 235 The following subobject types are supported. 237 1 IPv4 prefix 238 2 IPv6 prefix 239 32 Autonomous system number 240 TBD SRLG 241 The defined values for Type above are specified in [RSVP-TE] and in 242 this document. 244 The concept of loose or strict hops has no meaning in route 245 exclusion. The L bit defined for ERO subobjects in [RSPV-TE] is re- 246 used to indicate that an abstract node MUST be avoided (value 0) or 247 SHOULD be avoided (value 1). 249 An N bit is introduced in subobjects that define IP addresses to 250 distinguish between addresses that identify a node (value 1) and 251 addresses that identify an interface (value 1). In this way whole 252 nodes or specific interfaces can be excluded from the path. 254 6.1.1 Subobject 1: IPv4 prefix 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |L| Type | Length | IPv4 address (4 bytes) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | IPv4 address (continued) | Prefix Length |N| Resvd | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 L 265 0 indicates that the abstract node specified MUST be excluded 266 1 indicates that the abstract node specified SHOULD be avoided 268 N 269 0 indicates that the abstract node identifies an interface or 270 set of interfaces that should be excluded or avoided according 271 to the setting of the L bit. 272 1 indicates that the abstract node identifies a node or set of 273 nodes that should be excluded or avoided according to the 274 setting of the L bit. 275 Resvd 276 Zero on transmission. Ignored on receipt. 278 The rest of the fields are as defined in [RSVP-TE]. 280 6.1.2 Subobject 2: IPv6 Prefix 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |L| Type | Length | IPv6 address (16 bytes) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | IPv6 address (continued) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | IPv6 address (continued) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | IPv6 address (continued) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | IPv6 address (continued) | Prefix Length |N| Resvd | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 L 297 0 indicates that the abstract node specified MUST be excluded 298 1 indicates that the abstract node specified SHOULD be avoided 300 N 301 0 indicates that the abstract node identifies an interface or 302 set of interfaces that should be excluded or avoided according 303 to the setting of the L bit. 304 1 indicates that the abstract node identifies a node or set of 305 nodes that should be excluded or avoided according to the 306 setting of the L bit. 308 Resvd 309 Zero on transmission. Ignored on receipt. 311 The rest of the fields are as defined in [RSVP-TE]. 313 6.1.3 Subobject 32: Autonomous System Number 315 The L bit of an Autonomous System Number subobject does has meaning 316 in an Exclude Route (contrary to its usage in an Explict Route 317 defined in [RSVP-TE]. The meaning is as for other subobjects 318 described above. That is: 319 0 indicates that the abstract node specified MUST be excluded 320 1 indicates that the abstract node specified SHOULD be avoided 321 The rest of the fields are as defined in [RSVP-TE]. There is no N 322 bit defined. 324 6.1.4 Subobject TBD: SRLG 326 The N bit is not present. The rest of the fields are as defined in 327 the "SRLG ERO Subobject" section of this draft. 329 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 331 The exclude route list is encoded as a series of subobjects contained 332 in an EXCLUDE_ROUTE object. Each subobject identifies an abstract 333 node in the exclude route list. 335 Each abstract node may be a precisely specified IP address a node, or 336 an IP address with prefix identifying interfaces of a group of of 337 nodes or an Autonomous System. 339 The Explicit Route and routing processing is unchanged from the 340 description in [RSVP-TE] with the following additions: 342 a. When a Path message is received at a node, the node must check 343 that it is not a member of any of the abstract nodes in the XRO if it 344 is present in the Path message. If the node is a member of any of 345 the abstract nodes in the XRO it should return a PathErr with the 346 error code "Routing Problem" and error value of "Local node in 347 Exclude Route". If there are SRLGs in the XRO, the node should check 348 that it and the resources it uses are not part of any SRLG that is 349 specified with Tolerance value of zero. If it is, it should return a 350 PathErr with the error code "Routing Problem" and error value of 351 "Local node in Exclude Route". The node may be a member of an SRLG 352 in the XRO that is specified with a non-zero Tolerance value. 354 b. When choosing a next hop or expanding an explicit route to include 355 additional subobjects, a node: i) must not introduce an explicit 356 node or an abstract node that equals or is a member of any abstract 357 node that is specified in the Exclude Route Object. ii) must not (or 358 should not, in the case of a non-zero Tolerance value) introduce 359 links, nodes or resources identified by the SRLG ID specified in the 360 SRLG subobjects(s). If these rules preclude further forwarding of 361 the Path message, the node should return a PathErr with the error 362 code "Routing Problem" and error value of "Route blocked by Exclude 363 Route". 365 c. The subobjects in the ERO and XRO SHOULD not contradict each 366 other. If they do contradict, the subobjects with the L bit not set, 367 strict or MUST be excluded, respectively, in the ERO or XRO MUST take 368 precedence. If there is still a conflict, the subobjects in the ERO 369 MUST take precedence. 371 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 372 support the XRO will forward it uninspected and will not apply the 373 extensions to ERO processing described above. This makes the XRO a 374 'best effort' process. 376 This 'best-effort' approach is chosen to allow route exclusion to 377 traverse parts of the network that are not capable of parsing or 378 handling the new function. Note that Record Route may be used to 379 allow computing nodes to observe violations of route exclusion and 380 attempt to re-route the LSP accordingly. 382 7. Explicit Exclude Route 384 The Explicit Exclude Route defines abstract nodes or resources (such 385 as links, unnumbered interfaces or labels) that must not be used on 386 the path between two inclusive abstract nodes or resources in the 387 explicit route. 389 7.1. Explicit Exclusion Route Subobject (EXRS) 391 A new subobject type is defined. The Explicit Exclude Route 392 Subobject (EXRS) has type [TBD]. 394 The EXRS is an ERO subobject. 396 The format of the EXRS is as follows. 398 0 1 399 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 401 |L| Type | Length | EXRS subobjects | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 404 L 405 ignored and must be zero 406 [Note: The L bit in an ERES subobject is as defined 407 for the XRO subobjects] 409 Type 410 The type of the subobject, i.e. EXRS [TBD] 412 EXRS subobjects 413 An EXRS subobject indicates the abstract node or resource to 414 be excluded. The format of this field is exactly the format of 415 an XRO subobject and may include an SRLG subobject, 416 both subobjects as described earlier in this draft. 418 Thus, an EXRO subobject for an IP hop might look as follows: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |L| Type | Length |L| Type | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | IPv4 address (4 bytes) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Prefix Length |N| Reserved | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 7.2. Semantics and Processing Rules for the EXRS 432 Each EXRS may carry multiple exclusions. The exclusion is encoded 433 exactly as for XRO subobjects and prefixed by an additional Type and 434 Length. 436 The scope of the exclusion is the step between the previous ERO 437 subobject that identifies an abstract node, and the subsequent ERO 438 subobject that identifies an abstract node. Multiple exclusions may 439 be present between any pair of abstract nodes. 441 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 442 Systems that must not be traversed on the path to the next abstract 443 node indicated in the ERO. 445 Exclusions may also indicate resources (such as unnumbered 446 interfaces, link ids, labels) that must not be used on the path to 447 the next abstract node indicated in the ERO. 449 SRLGs may also be indicated for exclusion from the path to the next 450 abstract node in the ERO by the inclusion of an EXRO Subobject 451 containing an SRLG subobject. If the Tolerance value in the SRLG 452 subobject is zero, the resources (nodes, links, etc.) identified by 453 the SRLG must not be used on the path to the next abstract node 454 indicated in the ERO. If the Tolerance value is non- zero, the 455 resources identified by the SRLG should be avoided, but may be used 456 in preference to resources associated with another SRLG indicated for 457 exclusion if that SRLG has a (numerically) lower Tolerance value. 459 The subobjects in the ERO and EXRS SHOULD not contradict each other. 460 If they do contradict, the subobjects with the L bit not set, strict 461 or MUST be excluded, respectively, in the ERO or XRO MUST take 462 precedence. If there is still a conflict, the subobjects in the ERO 463 MUST take precedence. 465 If a node is called upon to process an EXRS and does not support 466 handling of exclusions it will return a PathErr with a "Bad 467 EXPLICIT_ROUTE object" error. 469 If the presence of EXRO Subobjects precludes further forwarding of 470 the Path message, the node should return a PathErr with the error 471 code "Routing Problem" and error value of "Route blocked by Exclude 472 Route". 474 8. Security 476 The new exclude route object poses no security exposures over and 477 above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security concerns 478 that exist with Explicit Routes should be considered with regard to 479 route exclusions. 481 9. IANA Considerations 483 9.1. New Class Numbers 485 One new class number is required. 487 EXCLUDE_ROUTE 488 Class-Num = 011bbbbb 489 CType: 1 491 9.2. New Subobject Types 493 A new subobject type for the Exclude Route Object and Explicit 494 Exclude Route Subobject is required. 496 SRLG subobject 498 A new subobject type for the ERO is required. 500 Explicit Exclude Route subobject 502 9.3. New Error Codes 504 New error values are needed for the error code 'Routing Problem'. 506 Unsupported Exclude Route Subobject Type Local node in Exclude Route 507 Route blocked by Exclude Route 509 10. Acknowledgments 511 This draft reuses text from [RSVP-TE] for the description of 512 EXCLUDE_ROUTE. 514 The authors would like to express their thanks to Igor Bryskin and 515 Lou Berger their considered opinions on this draft. Also thanks to 516 Yakov Rekhter for reminding us about SRLGs. 518 11. Normative References 520 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 521 Requirement Levels", BCP 14, RFC 2119, March 1997 523 [RSVP-TE] D. Awduche, et al., "RSVP-TE: Extensions to RSVP 524 for LSP Tunnels", RFC 3209, December 2001. 526 [GMPLS-RSVP-TE] P. Ashwood-Smith, et al., "Generalized MPLS 527 Signaling - RSVP-TE Extensions", Internet Draft, 528 draft-ietf-mpls-generalized-rsvp-te-07.txt, 529 April 2002 (work in progress). 531 [GMPLS-OSPF] K. Kompela, et al., "OSPF Extensions in Support of 532 Generalized MPLS", Internet Draft, 533 draft-ietf-ccamp-ospf-gmpls-extensions-07.txt, 534 May 2002 (work in progress). 536 [CCAMP-SRLG] D. Papadimitriou, et al., "Shared Risk Link Groups 537 Encoding and Processing", Internet Draft, 538 draft-papadimitriou- ccamp-srlg-processing-01.txt, 539 November 2002 (work in progress). 541 [MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label 542 Switching (MPLS) Traffic Engineering Management 543 Information Base", Internet Draft, draft-ietf-mpls- 544 te-mib-08.txt, January 2002 (work in progress). 546 12. Informational References 548 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., 549 "Link Bundling in MPLS Traffic Engineering", 550 Internet Draft, draft-ietf-mpls-bundle-02.txt, 551 May 2002, (work in progress). 553 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered 554 Links in RSVP-TE", Internet Draft, 555 draft-ietf-mpls-rsvp-unnum-06.txt, May 2002, (work 556 in progress). 558 [GMPLS-SIG] P. Ashwood-Smith, et al, "Generalized MPLS - 559 Signaling Functional Description", 560 draft-ietf-mpls-generalized-signaling-08.txt 561 April 2002, (work in progress). 563 13. Full Copyright Statement 565 Copyright (C) The Internet Society (2002). All Rights Reserved. 567 This document and translations of it may be copied and furnished to 568 others, and derivative works that comment on or otherwise explain it 569 or assist in its implementation may be prepared, copied, published 570 and distributed, in whole or in part, without restriction of any 571 kind, provided that the above copyright notice and this paragraph are 572 included on all such copies and derivative works. However, this 573 document itself may not be modified in any way, such as by removing 574 the copyright notice or references to the Internet Society or other 575 Internet organizations, except as needed for the purpose of 576 developing Internet standards in which case the procedures for 577 copyrights defined in the Internet Standards process must be 578 followed, or as required to translate it into languages other than 579 English. 581 The limited permissions granted above are perpetual and will not be 582 revoked by the Internet Society or its successors or assigns. This 583 document and the information contained herein is provided on an "AS 584 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 585 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 586 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 587 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 588 OR FITNESS FOR A PARTICULAR PURPOSE. 590 14. Authors' Information 592 Cheng-Yin Lee 593 Alcatel 594 600 March Road. 595 Ottawa, Ontario 596 Canada K2K 2E6 597 email: Cheng-Yin.Lee@alcatel.com 599 Adrian Farrel 600 Movaz Networks, Inc. 601 7926 Jones Branch Drive, Suite 615 602 McLean VA, 22102 USA 603 Phone: +1-703-847-1867 604 Email: afarrel@movaz.com 606 Stefaan De Cnodder 607 Alcatel 608 Francis Wellesplein 1 609 B-2018 Antwerp, Belgium 610 email: stefaan.de_cnodder@alcatel.be