idnits 2.17.1 draft-ietf-teas-rsvp-te-domain-subobjects-04.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 3073 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-04 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": 456 o "EXCLUDE_ROUTE subobjects": 459 Upon approval of this document, IANA is requested to make identical 460 additions to these registries as follows, in sync with [PCE-DOMAIN]: 462 Subobject Type Reference 463 TBD1 4-Byte AS number [This I.D.][PCE-DOMAIN] 464 TBD2 OSPF Area ID [This I.D.][PCE-DOMAIN] 465 TBD3 IS-IS Area ID [This I.D.][PCE-DOMAIN] 467 Further upon approval of this document, IANA is requested to add a 468 reference to this document to the new PCEP numbers that are 469 registered by [PCE-DOMAIN]. 471 6. Security Considerations 473 Security considerations for RSVP-TE and GMPLS signaling RSVP-TE 474 extensions are covered in [RFC3209] and [RFC3473]. This document 475 does not introduce any new messages or any substantive new 476 processing, and so those security considerations continue to apply. 477 Further, general considerations for securing RSVP-TE in MPLS-TE and 478 GMPLS networks can be found in [RFC5920]. The section 8 of [RFC5920] 479 describes the inter-provider security considerations, which continue 480 to apply. 482 The route exclusion security consideration are covered in [RFC4874] 483 and continue to apply. 485 7. Acknowledgments 487 We would like to thank Adrian Farrel, Lou Berger, George Swallow, 488 Chirag Shah, Reeja Paul, Sandeep Boina and Avantika for their useful 489 comments and suggestions. 491 Thanks to Vishnu Pavan Beeram for shepherding this document. 493 Thanks to Brian Carpenter for Gen-ART Review. 495 Thanks to Liang Xia (Frank) for SecDir Review. 497 Thanks to Spencer Dawkins and Barry Leiba for comments during the 498 IESG Review. 500 8. References 502 8.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 510 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 511 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 512 . 514 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 515 Switching (GMPLS) Signaling Resource ReserVation Protocol- 516 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 517 DOI 10.17487/RFC3473, January 2003, 518 . 520 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 521 in Resource ReSerVation Protocol - Traffic Engineering 522 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 523 . 525 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 526 Extension to Resource ReserVation Protocol-Traffic 527 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 528 April 2007, . 530 [ISO10589] 531 ISO, "Intermediate system to Intermediate system routing 532 information exchange protocol for use in conjunction with 533 the Protocol for providing the Connectionless-mode Network 534 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 536 [PCE-DOMAIN] 537 Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects 538 for Path Computation Element (PCE) Communication Protocol 539 (PCEP). (draft-ietf-pce-pcep-domain-sequence)", November 540 2015. 542 8.2. Informative References 544 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 545 Element (PCE)-Based Architecture", RFC 4655, 546 DOI 10.17487/RFC4655, August 2006, 547 . 549 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 550 Inter-Domain Multiprotocol Label Switching Traffic 551 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 552 2006, . 554 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 555 Per-Domain Path Computation Method for Establishing Inter- 556 Domain Traffic Engineering (TE) Label Switched Paths 557 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 558 . 560 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 561 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 562 DOI 10.17487/RFC5440, March 2009, 563 . 565 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource 566 Reservation Protocol (RSVP) Extensions for Path Key 567 Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, 568 . 570 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 571 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 572 . 574 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 575 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 576 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 577 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 578 . 580 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 581 Autonomous System (AS) Number Space", RFC 6793, 582 DOI 10.17487/RFC6793, December 2012, 583 . 585 Appendix A. Examples 587 These examples are for illustration purposes only, to show how the 588 new subobjects could be encoded. They are not meant to be an 589 exhaustive list of all possible usecases and combinations. 591 A.1. Inter-Area LSP Path Setup 593 In an inter-area LSP path setup where the ingress and the egress 594 belong to different IGP areas within the same AS, the domain 595 subobjects could be represented using an ordered list of IGP area 596 subobjects in an ERO. 598 D2 Area D 599 | 600 | 601 D1 602 | 603 | 604 ********BD1****** 605 * | * 606 * | * Area C 607 Area A * | * 608 * | * 609 Ingress------A1-----ABF1------B1------BC1------C1------Egress 610 / * | * 611 / * | * 612 / * Area | B * 613 F1 * | * 614 / ********BE1****** 615 / | 616 / | 617 F2 E1 618 | 619 Area F | 620 E2 Area E 622 * All IGP Area in one AS (AS 100) 624 Figure 1: Domain Corresponding to IGP Area 626 As per Figure 1, the signaling at Ingress could be - 628 ERO:(A1, ABF1, Area B, Area C, Egress) 630 It should be noted that there are other ways to achieve the desired 631 signaling, the area subobject provides another tool in the toolkit 632 and can have operational benefits when - 633 o Use of PCEP like domain-sequence [PCE-DOMAIN] configurations in 634 explicit path such that area subobjects can be used to signal the 635 loose path. 637 o Alignment of subobjects and registries between PCEP and RSVP-TE, 638 thus allowing easier interworking between path computation and 639 signaling i.e. to and fro of subobjects between signalling and 640 path computation (if need be). 642 A.2. Inter-AS LSP Path Setup 644 A.2.1. Example 1 646 In an inter-AS LSP path setup where the ingress and the egress belong 647 to different AS, the domain subobjects (AS) could be used in an ERO. 649 AS A AS E AS C 650 <-------------> <----------> <-------------> 652 A4----------E1---E2---E3---------C4 653 / / \ 654 / / \ 655 / / AS B \ 656 / / <----------> \ 657 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 658 \ / / 659 \ / / 660 \ / / 661 \ / / 662 A3----------D1---D2---D3---------C3 664 <----------> 665 AS D 667 * All AS have one area (area 0) 669 Figure 2: Domain Corresponding to AS 671 As per Figure 2, the signaling at Ingress could be - 673 ERO:(A1, A2, AS B, AS C, Egress); or 675 ERO:(A1, A2, AS B, Area 0, AS C, Area 0, Egress). 677 Each AS has a single IGP area (area 0), Area subobject is optional. 679 Note that to get a domain disjoint path, the ingress could also 680 signal the backup path with - 682 XRO:(AS B) 684 A.2.2. Example 2 686 As shown in Figure 3, where AS 200 is made up of multiple areas, the 687 signaling can include both AS and Area subobject to uniquely identify 688 a domain. 690 Ingress * 691 | * 692 | * 693 | * 694 X1 * 695 \\ * 696 \ \ * 697 \ \* Inter-AS 698 AS 100 \* \ Link 699 * \ \ 700 * \ \ 701 * \ \ 702 \ \ D2 Area D 703 AS 200 \ \ | 704 \ \ | 705 Inter \ \ D1 706 -AS \ \ | 707 Link \ \| 708 \ ********BD1****** 709 \ * | * 710 \ * | * Area C 711 Area A \ * | * 712 \* | * 713 A2------A1------AB1------B1------BC1------C1------Egress 714 * | * 715 * | * 716 * | * 717 * Area | B * 718 ********BE1****** 719 | 720 | 721 E1 722 | 723 | 724 E2 Area E 726 Figure 3: Domain Corresponding to AS and Area 728 As per Figure 3, the signaling at Ingress could be - 730 ERO:(X1, AS 200, Area B, Area C, Egress). 732 Authors' Addresses 733 Dhruv Dhody 734 Huawei Technologies 735 Divyashree Techno Park, Whitefield 736 Bangalore, Karnataka 560037 737 India 739 EMail: dhruv.ietf@gmail.com 741 Udayasree Palle 742 Huawei Technologies 743 Divyashree Techno Park, Whitefield 744 Bangalore, Karnataka 560037 745 India 747 EMail: udayasree.palle@huawei.com 749 Venugopal Reddy Kondreddy 750 Huawei Technologies 751 Divyashree Techno Park, Whitefield 752 Bangalore, Karnataka 560037 753 India 755 EMail: venugopalreddyk@huawei.com 757 Ramon Casellas 758 CTTC 759 Av. Carl Friedrich Gauss n7 760 Castelldefels, Barcelona 08860 761 Spain 763 EMail: ramon.casellas@cttc.es