idnits 2.17.1 draft-lee-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): ---------------------------------------------------------------------------- ** 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 12 longer pages, the longest (page 6) being 69 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 (March 2003) is 7713 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 571, but not defined == Missing Reference: 'RSPV-TE' is mentioned on line 284, but not defined == Unused Reference: 'MPLS-BUNDLE' is defined on line 613, but no explicit reference was found in the text == Unused Reference: 'MPLS-UNNUM' is defined on line 618, 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: September 2003 S. De Cnodder 4 March 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 L 344 0 indicates that the abstract node specified MUST be excluded 345 1 indicates that the abstract node specified SHOULD be avoided 347 Attribute 348 interface 349 0 indicates that the interface or set of interfaces 350 associated with the IP address that should be excluded 351 or avoided 352 node 353 1 indicates that the node or set of nodes associated with 354 the IP address should be excluded or avoided 355 SRLG 356 2 indicates that all the SRLG associated with the IP 357 address should be excluded or avoided 359 Resvd 360 Zero on transmission. Ignored on receipt. 362 The rest of the fields are as defined in [RSVP-TE]. 364 6.1.3 Subobject 32: Autonomous System Number 366 The L bit of an Autonomous System Number subobject does has meaning 367 in an Exclude Route (contrary to its usage in an Explict Route 368 defined in [RSVP-TE]. The meaning is as for other subobjects 369 described above. That is: 371 0 indicates that the abstract node specified MUST be excluded 373 1 indicates that the abstract node specified SHOULD be avoided 375 The rest of the fields are as defined in [RSVP-TE]. There is no 376 Attribute octet defined. 378 6.1.4 Subobject TBD: SRLG 380 The Attribute octet is not present. The rest of the fields are as 381 defined in the "SRLG ERO Subobject" section of this document. 383 6.2. Semantics and Processing Rules for the Exclude Route Object (XRO) 385 The exclude route list is encoded as a series of subobjects contained 386 in an EXCLUDE_ROUTE object. Each subobject identifies an abstract 387 node in the exclude route list. 389 Each abstract node may be a precisely specified IP address a node, or 390 an IP address with prefix identifying interfaces of a group of nodes, 391 or an Autonomous System. 393 The Explicit Route and routing processing is unchanged from the 394 description in [RSVP-TE] with the following additions: 396 a. When a Path message is received at a node, the node must check 397 that it is not a member of any of the abstract nodes in the XRO if 398 it is present in the Path message. If the node is a member of any 399 of the abstract nodes in the XRO it should return a PathErr with 400 the error code "Routing Problem" and error value of "Local node in 401 Exclude Route". If there are SRLGs in the XRO, the node should 402 check that it and the resources it uses are not part of any SRLG 403 that is specified with Tolerance value of zero. If it is, it 404 should return a PathErr with the error code "Routing Problem" and 405 error value of "Local node in Exclude Route". The node may be a 406 member of an SRLG in the XRO that is specified with a non-zero 407 Tolerance value. 409 b. When choosing a next hop or expanding an explicit route to include 410 additional subobjects, a node: 412 i) must not introduce an explicit node or an abstract node that 413 equals or is a member of any abstract node that is specified 414 in the Exclude Route Object. 416 ii) must not (or should not, in the case of a non-zero Tolerance 417 value) introduce links, nodes or resources identified by the 418 SRLG ID specified in the SRLG subobjects(s). If these rules 419 preclude further forwarding of the Path message, the node 420 should return a PathErr with the error code "Routing Problem" 421 and error value of "Route blocked by Exclude Route". 423 c. The subobjects in the ERO and XRO SHOULD not contradict each 424 other. If they do contradict, the subobjects with the L bit not 425 set, strict or MUST be excluded, respectively, in the ERO or XRO 426 MUST take precedence. If there is still a conflict, the 427 subobjects in the ERO MUST take precedence. 429 The XRO Class-Num is of the form 11bbbbbb so that nodes which do not 430 support the XRO will forward it uninspected and will not apply the 431 extensions to ERO processing described above. This makes the XRO a 432 'best effort' process. 434 This 'best-effort' approach is chosen to allow route exclusion to 435 traverse parts of the network that are not capable of parsing or 436 handling the new function. Note that Record Route may be used to 437 allow computing nodes to observe violations of route exclusion and 438 attempt to re-route the LSP accordingly. 440 7. Explicit Exclude Route 442 The Explicit Exclude Route defines abstract nodes or resources (such 443 as links, unnumbered interfaces or labels) that must not be used on 444 the path between two inclusive abstract nodes or resources in the 445 explicit route. 447 7.1. Explicit Exclusion Route Subobject (EXRS) 449 A new ERO subobject type is defined. The Explicit Exclude Route 450 Subobject (EXRS) has type [TBD]. The EXRS may not be present in 451 an RRO or XRO. 453 The format of the EXRS is as follows. 455 0 1 456 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 458 |L| Type | Length | EXRS subobjects | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+ 460 L 461 ignored and must be zero 462 [Note: The L bit in an ERES subobject is as defined 463 for the XRO subobjects] 465 Type 466 The type of the subobject, i.e. EXRS [TBD] 468 EXRS subobjects 469 An EXRS subobject indicates the abstract node or resource to 470 be excluded. The format of this field is exactly the format of 471 an XRO subobject and may include an SRLG subobject. Both 472 subobjects are as described earlier in this document. 474 Thus, an EXRO subobject for an IP hop might look as follows: 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 |L| Type | Length |L| Type | Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | IPv4 address (4 bytes) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Prefix Length | Attribute | Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Note: The Most Significant Bit in the Type field could be used to 487 indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating 488 the need to prepend the subobject with an additional TLV header. 489 This would reduce the number bytes require for each subobject by 2 490 bytes. However, this approach would reduce the ERO Type field space by 491 half. This issue need WG discussion and feedback. 493 7.2. Semantics and Processing Rules for the EXRS 495 Each EXRS may carry multiple exclusions. The exclusion is encoded 496 exactly as for XRO subobjects and prefixed by an additional Type and 497 Length. 499 The scope of the exclusion is the step between the previous ERO 500 subobject that identifies an abstract node, and the subsequent ERO 501 subobject that identifies an abstract node. Multiple exclusions may 502 be present between any pair of abstract nodes. 504 Exclusions may indicate explicit nodes, abstract nodes or Autonomous 505 Systems that must not be traversed on the path to the next abstract 506 node indicated in the ERO. 508 Exclusions may also indicate resources (such as unnumbered 509 interfaces, link ids, labels) that must not be used on the path to 510 the next abstract node indicated in the ERO. 512 SRLGs may also be indicated for exclusion from the path to the next 513 abstract node in the ERO by the inclusion of an EXRO Subobject 514 containing an SRLG subobject. If the Tolerance value in the SRLG 515 subobject is zero, the resources (nodes, links, etc.) identified by 516 the SRLG must not be used on the path to the next abstract node 517 indicated in the ERO. If the Tolerance value is non- zero, the 518 resources identified by the SRLG should be avoided, but may be used 519 in preference to resources associated with another SRLG indicated for 520 exclusion if that SRLG has a (numerically) lower Tolerance value. 522 The subobjects in the ERO and EXRS SHOULD not contradict each other. 523 If they do contradict, the subobjects with the L bit not set, strict 524 or MUST be excluded, respectively, in the ERO or XRO MUST take 525 precedence. If there is still a conflict, the subobjects in the ERO 526 MUST take precedence. 528 If a node is called upon to process an EXRS and does not support 529 handling of exclusions it will return a PathErr with a "Bad 530 EXPLICIT_ROUTE object" error. 532 If the presence of EXRO Subobjects precludes further forwarding of 533 the Path message, the node should return a PathErr with the error 534 code "Routing Problem" and error value of "Route blocked by Exclude 535 Route". 537 8. Security 539 The new exclude route object poses no security exposures over and 540 above [RSVP-TE] and [GMPLS-RSVP-TE]. Note that any security concerns 541 that exist with Explicit Routes should be considered with regard to 542 route exclusions. 544 9. IANA Considerations 546 9.1. New Class Numbers 548 One new class number is required. 550 EXCLUDE_ROUTE 551 Class-Num = 011bbbbb 552 CType: 1 554 9.2. New Subobject Types 556 A new subobject type for the Exclude Route Object and Explicit 557 Exclude Route Subobject is required. 559 SRLG subobject 561 A new subobject type for the ERO is required. 563 Explicit Exclude Route subobject 565 9.3. New Error Codes 567 New error values are needed for the error code 'Routing Problem'. 569 Unsupported Exclude Route Subobject Type [TBD] 570 Local Node in Exclude Route [TBD] 571 Route Blocked by Exclude Route [TBD] 573 10. Acknowledgments 575 This document reuses text from [RSVP-TE] for the description of 576 EXCLUDE_ROUTE. 578 The authors would like to express their thanks to Igor Bryskin, 579 Lou Berger and Dimitri Papadimitriou for their considered opinions on 580 this draft. Also thanks to Yakov Rekhter for reminding us about 581 SRLGs! 583 11. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, March 1997 588 [RSVP-TE] D. Awduche, et al., "RSVP-TE: Extensions to RSVP 589 for LSP Tunnels", RFC 3209, December 2001. 591 [GMPLS-RSVP-TE] L. Berger (Ed.), "Generalized Multi-Protocol Label 592 Switching (GMPLS) Signaling Resource ReserVation 593 Protocol-Traffic Engineering (RSVP-TE) Extensions", 594 RFC 3473, January 2003. 596 [GMPLS-OSPF] K. Kompela, et al., "OSPF Extensions in Support of 597 Generalized MPLS", Internet Draft, 598 draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, 599 December 2002 (work in progress). 601 [CCAMP-SRLG] D. Papadimitriou, et al., "Shared Risk Link Groups 602 Encoding and Processing", Internet Draft, 603 draft-papadimitriou-ccamp-srlg-processing-01.txt, 604 November 2002 (work in progress). 606 [MPLS-TE-MIB] C. Srinivasan, et al., "Multiprotocol Label 607 Switching (MPLS) Traffic Engineering Management 608 Information Base", Internet Draft, draft-ietf-mpls- 609 te-mib-09.txt, November 2002 (work in progress). 611 12. Informational References 613 [MPLS-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., 614 "Link Bundling in MPLS Traffic Engineering", 615 Internet Draft, draft-ietf-mpls-bundle-04.txt, 616 July 2002, (work in progress). 618 [MPLS-UNNUM] Kompella, K., Rekhter, Y., "Signalling Unnumbered 619 Links in RSVP-TE", RFC 3477, January 2003. 621 13. Authors' Information 623 Cheng-Yin Lee 624 Alcatel 625 600 March Road. 626 Ottawa, Ontario 627 Canada K2K 2E6 628 email: Cheng-Yin.Lee@alcatel.com 630 Adrian Farrel 631 Movaz Networks, Inc. 632 7926 Jones Branch Drive, Suite 615 633 McLean VA, 22102 USA 634 Phone: +1-703-847-1867 635 Email: afarrel@movaz.com 637 Stefaan De Cnodder 638 Alcatel 639 Francis Wellesplein 1 640 B-2018 Antwerp, Belgium 641 email: stefaan.de_cnodder@alcatel.be 643 14. Full Copyright Statement 645 Copyright (C) The Internet Society (2003). All Rights Reserved. 647 This document and translations of it may be copied and furnished to 648 others, and derivative works that comment on or otherwise explain it 649 or assist in its implementation may be prepared, copied, published 650 and distributed, in whole or in part, without restriction of any 651 kind, provided that the above copyright notice and this paragraph are 652 included on all such copies and derivative works. However, this 653 document itself may not be modified in any way, such as by removing 654 the copyright notice or references to the Internet Society or other 655 Internet organizations, except as needed for the purpose of 656 developing Internet standards in which case the procedures for 657 copyrights defined in the Internet Standards process must be 658 followed, or as required to translate it into languages other than 659 English. 661 The limited permissions granted above are perpetual and will not be 662 revoked by the Internet Society or its successors or assigns. This 663 document and the information contained herein is provided on an "AS 664 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 665 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 666 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 667 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 668 OR FITNESS FOR A PARTICULAR PURPOSE.