idnits 2.17.1 draft-ietf-ccamp-rsvp-te-exclude-route-00.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 1) being 61 lines 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 9 instances of too long lines in the document, the longest one being 3 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 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 (June 2003) is 7593 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 574, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 284, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'MPLS-UNNUM' is defined on line 621, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-09 == Outdated reference: A later version (-02) exists of draft-papadimitriou-ccamp-srlg-processing-01 -- Possible downref: Normative reference to a draft: ref. 'CCAMP-SRLG' == Outdated reference: A later version (-14) exists of draft-ietf-mpls-te-mib-09 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 3 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: November 2003 S. De Cnodder 4 June 2003 6 Exclude Routes - Extension to RSVP-TE 7 9 1. Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 2. Abstract 29 The current RSVP-TE specification, "RSVP-TE: Extensions to RSVP for 30 LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized 31 Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation 32 Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow 33 abstract nodes and resources to be explicitly included in a path 34 setup, but not to be explicitly excluded. 36 In some systems where precise explicit paths are not computed at the 37 head end it may be useful to specify and signal abstract nodes and 38 resources that are to be explicitly excluded from routes. These 39 exclusions may apply to the whole of a path, or to parts of a path 40 between two abstract nodes specified in an explicit route. 42 Shared Risk Link Groups (SRLGs) allow the definition of resources or 43 groups of resources that share the same risk of failure. The 44 knowledge of SRLGs may be used to compute diverse paths that can be 45 used for protection. In systems where it is useful to signal 46 exclusions, it may be useful to signal SRLGs to indicate groups of 47 resources that should be excluded on the whole of a path or between 48 two abstract nodes specified in an explicit path. 50 This document specifies ways to communicate route exclusions during 51 path setup using RSVP-TE. 53 2.1 Future Work 55 Future work on this document may include the following. 57 - Addition of further examples and explanation of the applicability 58 of route exclusion. 60 - reduction of the length of the XRO and EXRS subobjects 62 - Identification of the scope of relevance of exclusions so that 63 they may be omited from signaled messages, or at least from path 64 computations, when they are not relevant. 66 - Exclusion of unnumbered links. 68 - Convergence of SRLG identification with formats defined in other 69 drafts. 71 3. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 4. Overview 79 The current RSVP-TE specification [RSVP-TE] and GMPLS extensions 80 [GMPLS-RSVP-TE] allow abstract nodes and resources to be explicitly 81 included in a path setup, using the Explicit Route Object (ERO). 83 In some systems it may be useful to specify and signal abstract nodes 84 and resources that are to be explicitly excluded from routes. This 85 may be because loose hops or abstract nodes need to be prevented from 86 causing a route through a specific resource. This is a special case 87 of path calculation distribution to nodes within the system. 89 Two types of exclusions are required: 91 i) Do not include any of the abstract nodes in a given set anywhere 92 on the path. This set of abstract nodes to exclude is referred 93 to as the Exclude Route list. 95 ii) Do not include certain abstract nodes or resources between a 96 specific pair of abstract nodes present in an ERO. Such specific 97 exclusions are referred to as Explicit Exclusion Route. 99 To convey these constructs within the signaling protocol, a new RSVP 100 object and a new ERO subobject are introcuded respectively. 102 i) A new RSVP-TE object is introduced to convey the Exclude Route 103 list. This object is the Exclude Route Object (XRO). 105 ii) The second type of exclusion is achieved through a modification 106 to the existing ERO. A new subobject type the Explicit Exclude 107 Route Subobject (EXRS) is introduced to indicate an exclusion 108 between a pair of included abstract nodes. 110 SRLGs allow the definition of resources or groups of resources that 111 share the same risk of failure. The knowledge of SRLGs may be used 112 to compute diverse paths that can be used for protection. In systems 113 where it is useful to signal exclusions, it may be useful to signal 114 SRLGs to indicate groups of resources that should be excluded on the 115 whole of a path or between two abstract nodes specified in an 116 explicit path. 118 This document introduces an ERO subobject to indicate an SRLG to be 119 signaled in either of the two exclusion methods described above. This 120 subobject might also be appropriate for use within Explicit Routes or 121 Record Routes, but that discussion is outside the scope of this 122 document. 124 4.1 Scope of Excluded Routes 126 This document does not preclude a route exclusion from listing many 127 nodes or network elements to avoid. The intent is, however, to 128 indicate only the minimal number of subobjects to be avoided. For 129 instance it may be necessary to signal only the SRLGs (or Shared 130 Risk Groups) to avoid. 132 It is envisaged most of the conventional inclusion subobjects are 133 specified in the signaled ERO only for the area where they pertain. 134 The number of subobjects to be avoided, specified in the signaled XRO 135 may be constant throughout the whole path setup, or the subobjects to 136 be avoided may be removed from the XRO as they become irrelevant in 137 the subsequent hops of the path setup. 139 For example, consider an LSP that traverses multiple computation 140 domains. A computation domain may be an area in the administrative 141 or IGP sense, or may be an arbitrary division of the network for 142 active management and path computational pruposes. Let the primary 143 path be (Ingress A1,A2,AB1,B1,B2,BC1,C1,C2,Egress1) where Xn denotes 144 a node in domain X, and XY1 denotes a node on the border of domain X 145 and domain Y. Ingress is a node in cdomain A, and Egress is a node 146 in domain C. 148 Consider the establishment of a node diverse protection path. The 149 protection path must avoid all nodes on the primary path. 150 The exclusions for area A are handled during CSPF at Ingress, so the 151 ERO and XRO signaled at Ingress (A3-strict, A4-strict, AB2-strict, 152 Egress-loose) and (B1, B2, BC1, C1, C2) respectively. At AB2 the ERO 153 and XRO could be (B3-strict, B4-strict, BC2-strict, Egress-loose) and 154 (C1,C2) respectively. At BC2 the ERO could be (C3-strict, C4-strict, 155 Egress-strict) and an XRO is not needed from BC2 onwards. 157 In general, consideration should be given (as with explicit route) to 158 the size of signaled data and the impact on the signaling protocol. 160 4.2 Relationship to MPLS TE MIB 162 [MPLS-TE-MIB] defines managed objects for managing and modeling MPLS- 163 based traffic engineering. Included in [MPLS-TE-MIB] is a means to 164 configure explicit routes for use on specific LSPs. This 165 configuration allows the exclusion of certain resources. 167 In systems where the full explicit path is not computed at the 168 ingress (or at a path computation site for use at the ingress) it may 169 be necessary to signal those exclusions. This document offers a means 170 of doing this signaling. 172 5. Shared Risk Link Groups 174 The identifier of a SRLG is defined as a 32 bit quantity in [GMPLS- 175 OSPF]. These 32 bits are divided into an 8 bit type field and a 24 176 bit identifier in [CCAMP-SRLG]. 178 5.1 SRLG ERO Subobject 180 The format of the ERO and its subobjects are defined in [RSVP-TE]. 182 The new SRLG subobject is defined by this document as follows. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 |L| Type | Length | Tolerance | Reserved | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | SRLG Id | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 L 194 The L bit is an attribute of the subobject. The L bit is set 195 if the subobject represents a loose hop in the explicit route. 196 If the bit is not set, the subobject represents a strict hop in 197 the explicit route. 199 For exclusions, the L bit SHOULD be set to zero and ignored. 201 Type 203 The type of the subobject [TBD]. 205 Length 207 The Length contains the total length of the subobject in bytes, 208 including the Type and Length fields. The Length is always 8. 210 Tolerance 212 The level to which it is permissible for this SRLG to be 213 included in the path when more than one SRLG is specified. 214 A value of zero indicates that this SRLG MUST be avoided. A 215 tolerance value of n < m indicates that the SRLG MUST be 216 avoided in preference to an SRLG with tolerance value m. 218 If only one SRLG is present, then a value other than zero 219 indicates the SRLG SHOULD be avoided. 221 SRLG Id 223 The 32 bit identifier of the SRLG. 225 5.2 Exclusion Tolerance Semantics 227 The Tolerance field in the SRLG subobject indicates the degree to 228 which the SRLG must be avoided. (The degree to which it is 229 permissible to include it.) 231 If the Tolerance field has the value zero (0), the LSP MUST NOT 232 traverse or use any resource that is a member of the SRLG. 234 If the value is non-zero, all path computation elements SHOULD 235 attempt to select routes that avoid all resources that are members of 236 the SRLG. 238 Where more than one SRLG with non-zero Tolerance value is specified 239 for exclusion and no route can be found that avoids both SRLGs, a 240 route SHOULD be chosen that avoids the SRLG with the lower Tolerance 241 value. 243 6. Exclude Route List 245 The exclude route identifies a list of abstract nodes that MUST NOT 246 be traversed along the path of the LSP being established. 248 6.1 Exclude Route Object (XRO) 250 Abstract nodes to be excluded from the path are specified via the 251 EXCLUDE_ROUTE object (XRO). The Exclude Route Class value is [TBD]. 253 Currently one C_Type is defined, Type 1 Exclude Route. The 254 EXCLUDE_ROUTE object has the following format: 256 Class = TBD, C_Type = 1 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | | 262 // (Subobjects) // 263 | | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Subobjects 268 The contents of an EXCLUDE_ROUTE object are a series of variable- 269 length data items called subobjects. The subobjects are identical 270 to those defined in [RSVP-TE] and [GMPLS-RSVP-TE] for use in EROs. 272 The following subobject types are supported. 274 Type Subobject 275 1 IPv4 prefix 276 2 IPv6 prefix 277 32 Autonomous system number 278 TBD SRLG 280 The defined values for Type above are specified in [RSVP-TE] and in 281 this document. 283 The concept of loose or strict hops has no meaning in route 284 exclusion. The L bit, defined for ERO subobjects in [RSPV-TE], is 285 re-used here to indicate that an abstract node MUST be avoided 286 (value 0) or SHOULD be avoided (value 1). 288 An Attribute octet is introduced in the subobjects that define IP 289 addresses to indicate the attribute (e.g. interface, node, SRLG) 290 associated with the IP addresses that can be excluded from the 291 path. For instance, the attribute node allows a whole node to be 292 excluded from the path, in contrast to the attribute interface, 293 which allows specific interfaces to be excluded from the path. 294 The attribute SRLG allows all SRLGs associated with an IP 295 address to be excluded from the path. 297 6.1.1 Subobject 1: IPv4 prefix 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |L| Type | Length | IPv4 address (4 bytes) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | IPv4 address (continued) | Prefix Length | Attribute | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 L 308 0 indicates that the attribute specified MUST be excluded 309 1 indicates that the attribute specified SHOULD be avoided 311 Attribute 312 interface 313 0 indicates that the interface or set of interfaces 314 associated with the IP address that should be excluded 315 or avoided 316 node 317 1 indicates that the node or set of nodes associated with 318 the IP address should be excluded or avoided 319 SRLG 320 2 indicates that all the SRLGs associated with the IP 321 address should be excluded or avoided 323 Resvd 324 Zero on transmission. Ignored on receipt. 326 The rest of the fields are as defined in [RSVP-TE]. 328 6.1.2 Subobject 2: IPv6 Prefix 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |L| Type | Length | IPv6 address (16 bytes) | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | IPv6 address (continued) | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | IPv6 address (continued) | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | IPv6 address (continued) | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | IPv6 address (continued) | Prefix Length | Attribute | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 L 345 0 indicates that the abstract node specified MUST be excluded 346 1 indicates that the abstract node specified SHOULD be avoided 348 Attribute 349 interface 350 0 indicates that the interface or set of interfaces 351 associated with the IP address that should be excluded 352 or avoided 353 node 354 1 indicates that the node or set of nodes associated with 355 the IP address should be excluded or avoided 356 SRLG 357 2 indicates that all the SRLG associated with the IP 358 address should be excluded or avoided 360 Resvd 361 Zero on transmission. Ignored on receipt. 363 The rest of the fields are as defined in [RSVP-TE]. 365 6.1.3 Subobject 32: Autonomous System Number 367 The L bit of an Autonomous System Number subobject does has meaning 368 in an Exclude Route (contrary to its usage in an Explict Route 369 defined in [RSVP-TE]. The meaning is as for other subobjects 370 described above. That is: 372 0 indicates that the abstract node specified MUST be excluded 374 1 indicates that the abstract node specified SHOULD be avoided 376 The rest of the fields are as defined in [RSVP-TE]. There is no 377 Attribute octet defined. 379 6.1.4 Subobject TBD: SRLG 381 The Attribute octet is not present. The rest of the fields are as 382 defined in the "SRLG ERO Subobject" section of this document. 384 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 386 The exclude route list is encoded as a series of subobjects contained 387 in an EXCLUDE_ROUTE object. Each subobject identifies an abstract 388 node in the exclude route list. 390 Each abstract node may be a precisely specified IP address a node, or 391 an IP address with prefix identifying interfaces of a group of nodes, 392 or an Autonomous System. 394 The Explicit Route and routing processing is unchanged from the 395 description in [RSVP-TE] with the following additions: 397 a. When a Path message is received at a node, the node must check 398 that it is not a member of any of the abstract nodes in the XRO if 399 it is present in the Path message. If the node is a member of any 400 of the abstract nodes in the XRO it should return a PathErr with 401 the error code "Routing Problem" and error value of "Local node in 402 Exclude Route". If there are SRLGs in the XRO, the node should 403 check that it and the resources it uses are not part of any SRLG 404 that is specified with Tolerance value of zero. If it is, it 406 should return a PathErr with the error code "Routing Problem" and 407 error value of "Local node in Exclude Route". The node may be a 408 member of an SRLG in the XRO that is specified with a non-zero 409 Tolerance value. 411 b. When choosing a next hop or expanding an explicit route to include 412 additional subobjects, a node: 414 i) must not introduce an explicit node or an abstract node that 415 equals or is a member of any abstract node that is specified 416 in the Exclude Route Object. 418 ii) must not (or should not, in the case of a non-zero Tolerance 419 value) introduce links, nodes or resources identified by the 420 SRLG ID specified in the SRLG subobjects(s). If these rules 421 preclude further forwarding of the Path message, the node 422 should return a PathErr with the error code "Routing Problem" 423 and error value of "Route blocked by Exclude Route". 425 c. The subobjects in the ERO and XRO SHOULD not contradict each 426 other. If they do contradict, the subobjects with the L bit not 427 set, strict or MUST be excluded, respectively, in the ERO or XRO 428 MUST take precedence. If there is still a conflict, the 429 subobjects in the ERO MUST take precedence. 431 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 432 support the XRO will forward it uninspected and will not apply the 433 extensions to ERO processing described above. This makes the XRO a 434 'best effort' process. 436 This 'best-effort' approach is chosen to allow route exclusion to 437 traverse parts of the network that are not capable of parsing or 438 handling the new function. Note that Record Route may be used to 439 allow computing nodes to observe violations of route exclusion and 440 attempt to re-route the LSP accordingly. 442 7. Explicit Exclude Route 444 The Explicit Exclude Route defines abstract nodes or resources (such 445 as links, unnumbered interfaces or labels) that must not be used on 446 the path between two inclusive abstract nodes or resources in the 447 explicit route. 449 7.1. Explicit Exclusion Route Subobject (EXRS) 451 A new ERO subobject type is defined. The Explicit Exclude Route 452 Subobject (EXRS) has type [TBD]. The EXRS may not be present in 453 an RRO or XRO. 455 The format of the EXRS is as follows. 457 0 1 458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 460 |L| Type | Length | EXRS subobjects | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 463 L 464 ignored and must be zero 465 [Note: The L bit in an ERES subobject is as defined 466 for the XRO subobjects] 468 Type 469 The type of the subobject, i.e. EXRS [TBD] 471 EXRS subobjects 472 An EXRS subobject indicates the abstract node or resource to 473 be excluded. The format of this field is exactly the format of 474 an XRO subobject and may include an SRLG subobject. Both 475 subobjects are as described earlier in this document. 477 Thus, an EXRO subobject for an IP hop might look as follows: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |L| Type | Length |L| Type | Length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | IPv4 address (4 bytes) | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Prefix Length | Attribute | Reserved | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 Note: The Most Significant Bit in the Type field could be used to 490 indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating 491 the need to prepend the subobject with an additional TLV header. 492 This would reduce the number bytes require for each subobject by 2 493 bytes. However, this approach would reduce the ERO Type field space by 494 half. This issue need WG discussion and feedback. 496 7.2. Semantics and Processing Rules for the EXRS 498 Each EXRS may carry multiple exclusions. The exclusion is encoded 499 exactly as for XRO subobjects and prefixed by an additional Type and 500 Length. 502 The scope of the exclusion is the step between the previous ERO 503 subobject that identifies an abstract node, and the subsequent ERO 504 subobject that identifies an abstract node. Multiple exclusions may 505 be present between any pair of abstract nodes. 507 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 508 Systems that must not be traversed on the path to the next abstract 509 node indicated in the ERO. 511 Exclusions may also indicate resources (such as unnumbered 512 interfaces, link ids, labels) that must not be used on the path to 513 the next abstract node indicated in the ERO. 515 SRLGs may also be indicated for exclusion from the path to the next 516 abstract node in the ERO by the inclusion of an EXRO Subobject 517 containing an SRLG subobject. If the Tolerance value in the SRLG 518 subobject is zero, the resources (nodes, links, etc.) identified by 519 the SRLG must not be used on the path to the next abstract node 520 indicated in the ERO. If the Tolerance value is non- zero, the 521 resources identified by the SRLG should be avoided, but may be used 522 in preference to resources associated with another SRLG indicated for 523 exclusion if that SRLG has a (numerically) lower Tolerance value. 525 The subobjects in the ERO and EXRS SHOULD not contradict each other. 526 If they do contradict, the subobjects with the L bit not set, strict 527 or MUST be excluded, respectively, in the ERO or XRO MUST take 528 precedence. If there is still a conflict, the subobjects in the ERO 529 MUST take precedence. 531 If a node is called upon to process an EXRS and does not support 532 handling of exclusions it will return a PathErr with a "Bad 533 EXPLICIT_ROUTE object" error. 535 If the presence of EXRO Subobjects precludes further forwarding of 536 the Path message, the node should return a PathErr with the error 537 code "Routing Problem" and error value of "Route blocked by Exclude 538 Route". 540 8. Security 542 The new exclude route object poses no security exposures over and 543 above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security concerns 544 that exist with Explicit Routes should be considered with regard to 545 route exclusions. 547 9. IANA Considerations 549 9.1. New Class Numbers 551 One new class number is required. 553 EXCLUDE_ROUTE 554 Class-Num = 011bbbbb 555 CType: 1 557 9.2. New Subobject Types 559 A new subobject type for the Exclude Route Object and Explicit 560 Exclude Route Subobject is required. 562 SRLG subobject 564 A new subobject type for the ERO is required. 566 Explicit Exclude Route subobject 568 9.3. New Error Codes 570 New error values are needed for the error code 'Routing Problem'. 572 Unsupported Exclude Route Subobject Type [TBD] 573 Local Node in Exclude Route [TBD] 574 Route Blocked by Exclude Route [TBD] 576 10. Acknowledgments 578 This document reuses text from [RSVP-TE] for the description of 579 EXCLUDE_ROUTE. 581 The authors would like to express their thanks to Igor Bryskin, 582 Lou Berger and Dimitri Papadimitriou for their considered opinions on 583 this draft. Also thanks to Yakov Rekhter for reminding us about 584 SRLGs! 586 11. Normative References 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP 14, RFC 2119, March 1997 591 [RSVP-TE] D. Awduche, et al., "RSVP-TE: Extensions to RSVP 592 for LSP Tunnels", RFC 3209, December 2001. 594 [GMPLS-RSVP-TE] L. Berger (Ed.), "Generalized Multi-Protocol Label 595 Switching (GMPLS) Signaling Resource ReserVation 596 Protocol-Traffic Engineering (RSVP-TE) Extensions", 597 RFC 3473, January 2003. 599 [GMPLS-OSPF] K. Kompela, et al., "OSPF Extensions in Support of 600 Generalized MPLS", Internet Draft, 601 draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, 602 December 2002 (work in progress). 604 [CCAMP-SRLG] D. Papadimitriou, et al., "Shared Risk Link Groups 605 Encoding and Processing", Internet Draft, 606 draft-papadimitriou-ccamp-srlg-processing-01.txt, 607 November 2002 (work in progress). 609 [MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label 610 Switching (MPLS) Traffic Engineering Management 611 Information Base", Internet Draft, draft-ietf-mpls- 612 te-mib-09.txt, November 2002 (work in progress). 614 12. Informational References 616 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., 617 "Link Bundling in MPLS Traffic Engineering", 618 Internet Draft, draft-ietf-mpls-bundle-04.txt, 619 January 2003, (work in progress). 621 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered 622 Links in RSVP-TE", RFC 3477, January 2003. 624 13. Authors' Information 626 Cheng-Yin Lee 627 Alcatel 628 600 March Road. 629 Ottawa, Ontario 630 Canada K2K 2E6 631 email: Cheng-Yin.Lee@alcatel.com 633 Adrian Farrel 634 Movaz Networks, Inc. 635 7926 Jones Branch Drive, Suite 615 636 McLean VA, 22102 USA 637 Phone: +1-703-847-1867 638 Email: afarrel@movaz.com 640 Stefaan De Cnodder 641 Alcatel 642 Francis Wellesplein 1 643 B-2018 Antwerp, Belgium 644 email: stefaan.de_cnodder@alcatel.be 646 14. Full Copyright Statement 648 Copyright (C) The Internet Society (2003). All Rights Reserved. 650 This document and translations of it may be copied and furnished to 651 others, and derivative works that comment on or otherwise explain it 652 or assist in its implementation may be prepared, copied, published 653 and distributed, in whole or in part, without restriction of any 654 kind, provided that the above copyright notice and this paragraph are 655 included on all such copies and derivative works. However, this 656 document itself may not be modified in any way, such as by removing 657 the copyright notice or references to the Internet Society or other 658 Internet organizations, except as needed for the purpose of 659 developing Internet standards in which case the procedures for 660 copyrights defined in the Internet Standards process must be 661 followed, or as required to translate it into languages other than 662 English. 664 The limited permissions granted above are perpetual and will not be 665 revoked by the Internet Society or its successors or assigns. This 666 document and the information contained herein is provided on an "AS 667 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 668 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 669 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 670 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 671 OR FITNESS FOR A PARTICULAR PURPOSE.