idnits 2.17.1 draft-ietf-teas-rsvp-te-domain-subobjects-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 19, 2015) is 3081 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group D. Dhody 3 Internet-Draft U. Palle 4 Intended status: Experimental V. Kondreddy 5 Expires: May 22, 2016 Huawei Technologies 6 R. Casellas 7 CTTC 8 November 19, 2015 10 Domain Subobjects for Resource ReserVation Protocol - Traffic 11 Engineering (RSVP-TE) 12 draft-ietf-teas-rsvp-te-domain-subobjects-05 14 Abstract 16 The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) 17 specification and the Generalized Multiprotocol Label Switching 18 (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to 19 be explicitly included in a path setup. Further Exclude Routes 20 extensions to RSVP-TE allow abstract nodes and resources to be 21 explicitly excluded in a path setup. 23 This document specifies new subobjects to include or exclude 4-Byte 24 Autonomous System (AS) and Interior Gateway Protocol (IGP) area 25 during path setup. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 22, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . 5 66 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Explicit Route Object (ERO)'s Subobjects . . . . . . . . 5 68 3.2.1. Autonomous system . . . . . . . . . . . . . . . . . . 6 69 3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 7 70 3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 8 71 3.3. Exclude Route Object (XRO)'s Subobjects . . . . . . . . . 8 72 3.3.1. Autonomous system . . . . . . . . . . . . . . . . . . 8 73 3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 9 74 3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 9 75 3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . 9 76 4. Interaction with Path Computation Element (PCE) . . . . . . . 10 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 8.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14 85 A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 14 86 A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 15 87 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 15 88 A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 16 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP- 94 TE [RFC3473] allow abstract nodes and resources to be explicitly 95 included in a path setup using the Explicit Route Object (ERO). 97 Further Exclude Routes extensions [RFC4874] allow abstract nodes or 98 resources to be excluded from the whole path using the Exclude Route 99 object (XRO). To exclude certain abstract nodes or resources between 100 a specific pair of abstract nodes present in an ERO, a Explicit 101 Exclusion Route Subobject (EXRS) is used. 103 [RFC3209] already describes the notion of abstract nodes, where an 104 abstract node is a group of nodes whose internal topology is opaque 105 to the ingress node of the Label Switched Path (LSP). It further 106 defines a subobject for AS, but with a 2-Byte AS number only. 108 This document extends the notion of abstract nodes by adding new 109 subobjects for IGP Areas and 4-byte AS numbers (as per [RFC6793]). 110 These subobjects can be included in Explicit Route Object (ERO), 111 Exclude Route Object (XRO) or Explicit Exclusion Route Subobject 112 (EXRS). 114 In case of per-domain path computation [RFC5152], where the full path 115 of an inter-domain TE LSP cannot be or is not determined at the 116 ingress node, and signaling message could use domain identifiers. 117 The use of these new subobjects is illustrated in Appendix A. 119 Further, the domain identifier could simply act as delimiter to 120 specify where the domain boundary starts and ends. 122 This is a companion document to Path Computation Element Protocol 123 (PCEP) extensions for the domain sequence [PCE-DOMAIN]. 125 1.1. Scope 127 The procedures described in this document are experimental. The 128 experiment is intended to enable research for the usage of Domain 129 subobjects for inter-domain path setup. For this purpose this 130 document specify new domain subobjects as well as how they 131 incorporate with existing subobjects. 133 The experiment will end two years after the RFC is published. At 134 that point, the RFC authors will attempt to determine how widely this 135 has been implemented and deployed. 137 This document does not change the procedures for handling subobjects 138 in RSVP-TE. 140 The new subobjects introduced by this document will not be understood 141 by legacy implementations. If a legacy implementation receives one 142 of the subobjects that it does not understand in an RSVP-TE object, 143 the legacy implementation will behave as described in [RFC3209] and 144 [RFC4874]. Therefore, it is assumed that this experiment will be 145 conducted only when all nodes processing the new subobject form part 146 of the experiment. 148 When the result of implementation and deployment are available, this 149 document will be updated and refined, and then be moved from 150 Experimental to Standard Track. 152 It should be noted that there are other ways such as use of boundary 153 node to identify the domain (instead of domain identifier), the 154 mechanism defined in this document is just another tool in the 155 toolkit for the operator. 157 1.2. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 2. Terminology 165 The following terminology is used in this document. 167 AS: Autonomous System. 169 Domain: As per [RFC4655], any collection of network elements within 170 a common sphere of address management or path computational 171 responsibility. Examples of domains include Interior Gateway 172 Protocol (IGP) areas and Autonomous Systems (ASs). 174 ERO: Explicit Route Object 176 EXRS: Explicit Exclusion Route Subobject 178 IGP: Interior Gateway Protocol. Either of the two routing 179 protocols, Open Shortest Path First (OSPF) or Intermediate System 180 to Intermediate System (IS-IS). 182 IS-IS: Intermediate System to Intermediate System. 184 OSPF: Open Shortest Path First. 186 PCE: Path Computation Element. An entity (component, application, 187 or network node) that is capable of computing a network path or 188 route based on a network graph and applying computational 189 constraints. 191 PCEP: Path Computation Element Protocol. 193 RSVP: Resource Reservation Protocol 195 TE LSP: Traffic Engineering Label Switched Path. 197 XRO: Exclude Route Object 199 3. Subobjects for Domains 201 3.1. Domains 203 [RFC4726] and [RFC4655] define domain as a separate administrative or 204 geographic environment within the network. A domain could be further 205 defined as a zone of routing or computational ability. Under these 206 definitions a domain might be categorized as an AS or an IGP area. 208 As per [RFC3209], an abstract node is a group of nodes whose internal 209 topology is opaque to the ingress node of the LSP. Using this 210 concept of abstraction, an explicitly routed LSP can be specified as 211 a sequence of IP prefixes or a sequence of Autonomous Systems. In 212 this document we extend the notion to include IGP area and 4-Byte AS 213 number. 215 These sub-objects appear in RSVP-TE, notably in - 217 o Explicit Route Object (ERO): As per [RFC3209], an explicit route 218 is a particular path in the network topology including abstract 219 nodes (including domains). 221 o Exclude Route Object (XRO): As per [RFC4874], an exclude route 222 identifies a list of abstract nodes (including domains), that 223 should not be traversed along the path of the LSP being 224 established. 226 o Explicit Exclusion Route Subobject (EXRS): As per [RFC4874], used 227 to specify exclusion of certain abstract nodes between a specific 228 pair of nodes. EXRS are a subobject carried inside the ERO. 229 These subobjects can be used to specify the domains to be excluded 230 between two abstract nodes. 232 3.2. Explicit Route Object (ERO)'s Subobjects 234 As stated in [RFC3209], an explicit route is a particular path in the 235 network topology. In addition to the ability to identify specific 236 nodes along the path, an explicit route can identify a group of nodes 237 (abstract nodes) to be traversed along the path. 239 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], 240 [RFC4874] and [RFC5553] but new subobjects related to domains are 241 needed. 243 This document extends the support for 4-Byte AS numbers and IGP 244 Areas. 246 Type Subobject 247 TBD1 Autonomous system number (4 Byte) 248 TBD2 OSPF Area id 249 TBD3 ISIS Area id 251 3.2.1. Autonomous system 253 [RFC3209] already defines 2-Byte AS number. 255 To support 4-Byte AS numbers as per [RFC6793], the following 256 subobject is defined: 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 |L| Type | Length | Reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | AS-ID (4 bytes) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 L: The L bit is an attribute of the subobject as defined in 267 [RFC3209], i.e., set if the subobject represents a loose hop in 268 the explicit route. If the bit is not set, the subobject 269 represents a strict hop in the explicit route. 271 Type: (TBD1 by IANA) indicating a 4-Byte AS Number. 273 Length: 8 (Total length of the subobject in bytes). 275 Reserved: Zero at transmission, ignored at receipt. 277 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 278 use, the low order bits (16 through 31) MUST be used and the high 279 order bits (0 through 15) MUST be set to zero. For the purpose of 280 this experiment, it is advised to use 4-Byte AS number subobject 281 as default. 283 3.2.2. IGP Area 285 Since the length and format of Area-id is different for OSPF and 286 ISIS, the following two subobjects are defined: 288 For OSPF, the area-id is a 32 bit number. The subobject is encoded 289 as follows: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |L| Type | Length | Reserved | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | OSPF Area Id (4 bytes) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 L: The L bit is an attribute of the subobject as defined in 300 [RFC3209]. 302 Type: (TBD2 by IANA) indicating a 4-Byte OSPF Area ID. 304 Length: 8 (Total length of the subobject in bytes). 306 Reserved: Zero at transmission, ignored at receipt. 308 OSPF Area Id: The 4-Byte OSPF Area ID. 310 For IS-IS, the area-id is of variable length and thus the length of 311 the subobject is variable. The Area-id is as described in IS-IS by 312 ISO standard [ISO10589]. The subobject is encoded as follows: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 |L| Type | Length | Area-Len | Reserved | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | | 320 // IS-IS Area ID // 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 L: The L bit is an attribute of the subobject as defined in 325 [RFC3209]. 327 Type: (TBD3 by IANA) indicating IS-IS Area ID. 329 Length: Variable. The Length MUST be at least 8, and MUST be a 330 multiple of 4. 332 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 333 Identifier in octets; Valid values are from 1 to 13 inclusive). 335 Reserved: Zero at transmission, ignored at receipt. 337 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 338 with trailing zeroes to a four-byte boundary. 340 3.2.3. Mode of Operation 342 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 343 could be used in the ERO to specify an abstract node (a group of 344 nodes whose internal topology is opaque to the ingress node of the 345 LSP). 347 All the rules of processing (for example Next Hop Selection, L bit 348 processing, unrecognized subobjects etc) are as per the [RFC3209]. 349 Note that if a node is called upon to process subobject defined in 350 this document, and it does not recognize, it will behave as described 351 in [RFC3209] when an unrecognized ERO subobject is encountered. This 352 means that this node will return a PathErr with error code "Routing 353 Error" and error value "Bad EXPLICIT_ROUTE object" with the 354 EXPLICIT_ROUTE object included, truncated (on the left) to the 355 offending subobject. 357 3.3. Exclude Route Object (XRO)'s Subobjects 359 As stated in [RFC4874], the exclude route identifies a list of 360 abstract nodes that to exclude (not be traversed) along the path of 361 the LSP being established. 363 Some subobjects are defined in [RFC3209], [RFC3477], [RFC4874] and 364 [RFC6001] but new subobjects related to domains are needed. 366 This document extends the support for 4-Byte AS numbers and IGP 367 Areas. 369 Type Subobject 370 TBD1 Autonomous system number (4 Byte) 371 TBD2 OSPF Area id 372 TBD3 ISIS Area id 374 3.3.1. Autonomous system 376 [RFC3209] and [RFC4874] already define a 2-Byte AS number. 378 To support 4-Byte AS numbers as per [RFC6793], a subobject is with 379 the same format as defined in Section 3.2.1 with following 380 difference: 382 The meaning of the L bit is as per [RFC4874], where. 384 0: indicates that the abstract node specified MUST be excluded. 386 1: indicates that the abstract node specified SHOULD be avoided. 388 3.3.2. IGP Area 390 Since the length and format of Area-id is different for OSPF and 391 ISIS, the following two subobjects are defined: 393 For OSPF, the area-id is a 32 bit number. Subobjects for OSPF and 394 IS-IS are of the same format as defined in Section 3.2.2 with 395 following difference: 397 The meaning of the L bit is as per [RFC4874]. 399 3.3.3. Mode of Operation 401 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 402 could also be used in the XRO to specify exclusion of an abstract 403 node (a group of nodes whose internal topology is opaque to the 404 ingress node of the LSP). 406 All the rules of processing are as per the [RFC4874]. 408 Note that if a node is called upon to process a subobject defined in 409 this document, and it does not recognize, it will behave as described 410 in [RFC4874] when an unrecognized XRO subobject is encountered, i.e. 411 to ignore it. In this case the desired exclusion will not be carried 412 out. 414 IGP Area subobjects in the XRO are local to the current AS. In case 415 of multi-AS path computation to exclude an IGP area in a different 416 AS, IGP Area subobject should be part of Explicit Exclusion Route 417 Subobject (EXRS) in the ERO to specify the AS in which the IGP area 418 is to be excluded. Further policy may be applied to prune/ignore 419 Area subobjects in XRO at AS boundary. 421 3.4. Explicit Exclusion Route Subobject 423 As per [RFC4874], the Explicit Exclusion Route is used to specify 424 exclusion of certain abstract nodes between a specific pair of nodes 425 or resources in the explicit route. EXRS is an ERO subobject that 426 contains one or more subobjects of its own, called EXRS subobjects. 428 The EXRS subobject could carry any of the subobjects defined for XRO, 429 thus the new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) 430 Area can also be used in the EXRS. The meanings of the fields of the 431 new XRO subobjects are unchanged when the subobjects are included in 432 an EXRS, except that scope of the exclusion is limited to the single 433 hop between the previous and subsequent elements in the ERO. 435 All the rules of processing are as per the [RFC4874]. 437 4. Interaction with Path Computation Element (PCE) 439 The domain subobjects to be used in Path Computation Element Protocol 440 (PCEP) are referred to in [PCE-DOMAIN]. Note that the new domain 441 subobjects follow the principle that subobjects used in PCEP 442 [RFC5440] are identical to the subobjects used in RSVP-TE and thus 443 are interchangeable between PCEP and RSVP-TE. 445 5. IANA Considerations 447 5.1. New Subobjects 449 IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 450 at . Within this 451 registry IANA maintains two sub-registries: 453 o EXPLICIT_ROUTE subobjects (see Sub-object type 20 EXPLICIT_ROUTE 454 Type 1 Explicit Route at http://www.iana.org/assignments/rsvp- 455 parameters) 457 o EXCLUDE_ROUTE subobjects (see Sub-object types of Class Types or 458 C-Types 232 EXCLUDE_ROUTE at http://www.iana.org/assignments/rsvp- 459 parameters) 461 Upon approval of this document, IANA is requested to make identical 462 additions to these registries as follows, in sync with [PCE-DOMAIN]: 464 Subobject Type Reference 465 TBD1 4-Byte AS number [This I.D.][PCE-DOMAIN] 466 TBD2 OSPF Area ID [This I.D.][PCE-DOMAIN] 467 TBD3 IS-IS Area ID [This I.D.][PCE-DOMAIN] 469 Further upon approval of this document, IANA is requested to add a 470 reference to this document to the new PCEP numbers that are 471 registered by [PCE-DOMAIN]. 473 6. Security Considerations 475 Security considerations for RSVP-TE and GMPLS signaling RSVP-TE 476 extensions are covered in [RFC3209] and [RFC3473]. This document 477 does not introduce any new messages or any substantive new 478 processing, and so those security considerations continue to apply. 479 Further, general considerations for securing RSVP-TE in MPLS-TE and 480 GMPLS networks can be found in [RFC5920]. The section 8 of [RFC5920] 481 describes the inter-provider security considerations, which continue 482 to apply. 484 The route exclusion security consideration are covered in [RFC4874] 485 and continue to apply. 487 7. Acknowledgments 489 We would like to thank Adrian Farrel, Lou Berger, George Swallow, 490 Chirag Shah, Reeja Paul, Sandeep Boina and Avantika for their useful 491 comments and suggestions. 493 Thanks to Vishnu Pavan Beeram for shepherding this document. 495 Thanks to Deborah Brungard for being the Responsible AD. 497 Thanks to Amanda Baber for IANA Review. 499 Thanks to Brian Carpenter for Gen-ART Review. 501 Thanks to Liang Xia (Frank) for SecDir Review. 503 Thanks to Spencer Dawkins and Barry Leiba for comments during the 504 IESG Review. 506 8. References 508 8.1. Normative References 510 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 511 Requirement Levels", BCP 14, RFC 2119, 512 DOI 10.17487/RFC2119, March 1997, 513 . 515 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 516 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 517 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 518 . 520 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 521 Switching (GMPLS) Signaling Resource ReserVation Protocol- 522 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 523 DOI 10.17487/RFC3473, January 2003, 524 . 526 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 527 in Resource ReSerVation Protocol - Traffic Engineering 528 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 529 . 531 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 532 Extension to Resource ReserVation Protocol-Traffic 533 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 534 April 2007, . 536 [ISO10589] 537 ISO, "Intermediate system to Intermediate system routing 538 information exchange protocol for use in conjunction with 539 the Protocol for providing the Connectionless-mode Network 540 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 542 [PCE-DOMAIN] 543 Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects 544 for Path Computation Element (PCE) Communication Protocol 545 (PCEP). (draft-ietf-pce-pcep-domain-sequence)", November 546 2015. 548 8.2. Informative References 550 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 551 Element (PCE)-Based Architecture", RFC 4655, 552 DOI 10.17487/RFC4655, August 2006, 553 . 555 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 556 Inter-Domain Multiprotocol Label Switching Traffic 557 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 558 2006, . 560 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 561 Per-Domain Path Computation Method for Establishing Inter- 562 Domain Traffic Engineering (TE) Label Switched Paths 563 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 564 . 566 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 567 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 568 DOI 10.17487/RFC5440, March 2009, 569 . 571 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource 572 Reservation Protocol (RSVP) Extensions for Path Key 573 Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, 574 . 576 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 577 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 578 . 580 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 581 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 582 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 583 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 584 . 586 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 587 Autonomous System (AS) Number Space", RFC 6793, 588 DOI 10.17487/RFC6793, December 2012, 589 . 591 Appendix A. Examples 593 These examples are for illustration purposes only, to show how the 594 new subobjects could be encoded. They are not meant to be an 595 exhaustive list of all possible usecases and combinations. 597 A.1. Inter-Area LSP Path Setup 599 In an inter-area LSP path setup where the ingress and the egress 600 belong to different IGP areas within the same AS, the domain 601 subobjects could be represented using an ordered list of IGP area 602 subobjects in an ERO. 604 D2 Area D 605 | 606 | 607 D1 608 | 609 | 610 ********BD1****** 611 * | * 612 * | * Area C 613 Area A * | * 614 * | * 615 Ingress------A1-----ABF1------B1------BC1------C1------Egress 616 / * | * 617 / * | * 618 / * Area | B * 619 F1 * | * 620 / ********BE1****** 621 / | 622 / | 623 F2 E1 624 | 625 Area F | 626 E2 Area E 628 * All IGP Area in one AS (AS 100) 630 Figure 1: Domain Corresponding to IGP Area 632 As per Figure 1, the signaling at Ingress could be - 634 ERO:(A1, ABF1, Area B, Area C, Egress) 636 It should be noted that there are other ways to achieve the desired 637 signaling, the area subobject provides another tool in the toolkit 638 and can have operational benefits when - 639 o Use of PCEP like domain-sequence [PCE-DOMAIN] configurations in 640 explicit path such that area subobjects can be used to signal the 641 loose path. 643 o Alignment of subobjects and registries between PCEP and RSVP-TE, 644 thus allowing easier interworking between path computation and 645 signaling i.e. to and fro of subobjects between signalling and 646 path computation (if need be). 648 A.2. Inter-AS LSP Path Setup 650 A.2.1. Example 1 652 In an inter-AS LSP path setup where the ingress and the egress belong 653 to different AS, the domain subobjects (AS) could be used in an ERO. 655 AS A AS E AS C 656 <-------------> <----------> <-------------> 658 A4----------E1---E2---E3---------C4 659 / / \ 660 / / \ 661 / / AS B \ 662 / / <----------> \ 663 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 664 \ / / 665 \ / / 666 \ / / 667 \ / / 668 A3----------D1---D2---D3---------C3 670 <----------> 671 AS D 673 * All AS have one area (area 0) 675 Figure 2: Domain Corresponding to AS 677 As per Figure 2, the signaling at Ingress could be - 679 ERO:(A1, A2, AS B, AS C, Egress); or 681 ERO:(A1, A2, AS B, Area 0, AS C, Area 0, Egress). 683 Each AS has a single IGP area (area 0), Area subobject is optional. 685 Note that to get a domain disjoint path, the ingress could also 686 signal the backup path with - 688 XRO:(AS B) 690 A.2.2. Example 2 692 As shown in Figure 3, where AS 200 is made up of multiple areas, the 693 signaling can include both AS and Area subobject to uniquely identify 694 a domain. 696 Ingress * 697 | * 698 | * 699 | * 700 X1 * 701 \\ * 702 \ \ * 703 \ \* Inter-AS 704 AS 100 \* \ Link 705 * \ \ 706 * \ \ 707 * \ \ 708 \ \ D2 Area D 709 AS 200 \ \ | 710 \ \ | 711 Inter \ \ D1 712 -AS \ \ | 713 Link \ \| 714 \ ********BD1****** 715 \ * | * 716 \ * | * Area C 717 Area A \ * | * 718 \* | * 719 A2------A1------AB1------B1------BC1------C1------Egress 720 * | * 721 * | * 722 * | * 723 * Area | B * 724 ********BE1****** 725 | 726 | 727 E1 728 | 729 | 730 E2 Area E 732 Figure 3: Domain Corresponding to AS and Area 734 As per Figure 3, the signaling at Ingress could be - 736 ERO:(X1, AS 200, Area B, Area C, Egress). 738 Authors' Addresses 739 Dhruv Dhody 740 Huawei Technologies 741 Divyashree Techno Park, Whitefield 742 Bangalore, Karnataka 560037 743 India 745 EMail: dhruv.ietf@gmail.com 747 Udayasree Palle 748 Huawei Technologies 749 Divyashree Techno Park, Whitefield 750 Bangalore, Karnataka 560037 751 India 753 EMail: udayasree.palle@huawei.com 755 Venugopal Reddy Kondreddy 756 Huawei Technologies 757 Divyashree Techno Park, Whitefield 758 Bangalore, Karnataka 560037 759 India 761 EMail: venugopalreddyk@huawei.com 763 Ramon Casellas 764 CTTC 765 Av. Carl Friedrich Gauss n7 766 Castelldefels, Barcelona 08860 767 Spain 769 EMail: ramon.casellas@cttc.es