idnits 2.17.1 draft-ietf-teas-rsvp-te-domain-subobjects-03.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 (September 21, 2015) is 3139 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: March 24, 2016 Huawei Technologies 6 R. Casellas 7 CTTC 8 September 21, 2015 10 Domain Subobjects for Resource ReserVation Protocol - Traffic 11 Engineering (RSVP-TE) 12 draft-ietf-teas-rsvp-te-domain-subobjects-03 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 March 24, 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 . . . . . . . . . . . . . . . . . . . . . . 6 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) . . . . . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 8.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 85 A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 13 86 A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 14 87 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14 88 A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 15 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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 This document does not change the procedures for handling subobjects 134 in RSVP-TE. 136 The new subobjects introduced by this document will not be understood 137 by legacy implementations. If one of the subobjects is received in a 138 RSVP-TE object that does not understand it, it will behave as 139 described in [RFC3209] and [RFC4874]. Therefore, it is assumed that 140 this experiment will be conducted only when all nodes processing the 141 new subobject form part of the experiment. 143 When the result of implementation and deployment are available, this 144 document will be updated and refined, and then be moved from 145 Experimental to Standard Track. 147 It should be noted that there are other ways such as use of boundary 148 node to identify the domain (instead of domain identifier), the 149 mechanism defined in this document is just another tool in the 150 toolkit for the operator. 152 1.2. Requirements Language 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 158 2. Terminology 160 The following terminology is used in this document. 162 AS: Autonomous System. 164 Domain: As per [RFC4655], any collection of network elements within 165 a common sphere of address management or path computational 166 responsibility. Examples of domains include Interior Gateway 167 Protocol (IGP) areas and Autonomous Systems (ASs). 169 ERO: Explicit Route Object 171 EXRS: Explicit Exclusion Route Subobject 173 IGP: Interior Gateway Protocol. Either of the two routing 174 protocols, Open Shortest Path First (OSPF) or Intermediate System 175 to Intermediate System (IS-IS). 177 IS-IS: Intermediate System to Intermediate System. 179 OSPF: Open Shortest Path First. 181 PCE: Path Computation Element. An entity (component, application, 182 or network node) that is capable of computing a network path or 183 route based on a network graph and applying computational 184 constraints. 186 PCEP: Path Computation Element Protocol. 188 RSVP: Resource Reservation Protocol 190 TE LSP: Traffic Engineering Label Switched Path. 192 XRO: Exclude Route Object 194 3. Subobjects for Domains 196 3.1. Domains 198 [RFC4726] and [RFC4655] define domain as a separate administrative or 199 geographic environment within the network. A domain could be further 200 defined as a zone of routing or computational ability. Under these 201 definitions a domain might be categorized as an AS or an IGP area. 203 As per [RFC3209], an abstract node is a group of nodes whose internal 204 topology is opaque to the ingress node of the LSP. Using this 205 concept of abstraction, an explicitly routed LSP can be specified as 206 a sequence of IP prefixes or a sequence of Autonomous Systems. In 207 this document we extend the notion to include IGP area and 4-Byte AS 208 number. 210 These sub-objects appear in RSVP-TE, notably in - 212 o Explicit Route Object (ERO): As per [RFC3209], an explicit route 213 is a particular path in the network topology including abstract 214 nodes (including domains). 216 o Exclude Route Object (XRO): As per [RFC4874], an exclude route 217 identifies a list of abstract nodes (including domains), that 218 should not be traversed along the path of the LSP being 219 established. 221 o Explicit Exclusion Route Subobject (EXRS): As per [RFC4874], used 222 to specify exclusion of certain abstract nodes between a specific 223 pair of nodes. EXRS are a subobject carried inside the ERO. 224 These subobjects can be used to specify the domains to be excluded 225 between two abstract nodes. 227 3.2. Explicit Route Object (ERO)'s Subobjects 229 As stated in [RFC3209], an explicit route is a particular path in the 230 network topology. In addition to the ability to identify specific 231 nodes along the path, an explicit route can identify a group of nodes 232 (abstract nodes) to be traversed along the path. 234 Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], 235 [RFC4874] and [RFC5553] but new subobjects related to domains are 236 needed. 238 This document extends the support for 4-Byte AS numbers and IGP 239 Areas. 241 Type Subobject 242 TBD1 Autonomous system number (4 Byte) 243 TBD2 OSPF Area id 244 TBD3 ISIS Area id 246 3.2.1. Autonomous system 248 [RFC3209] already defines 2-Byte AS number. 250 To support 4-Byte AS numbers as per [RFC6793], the following 251 subobject is defined: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |L| Type | Length | Reserved | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | AS-ID (4 bytes) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 L: The L bit is an attribute of the subobject as defined in 262 [RFC3209], i.e., set if the subobject represents a loose hop in 263 the explicit route. If the bit is not set, the subobject 264 represents a strict hop in the explicit route. 266 Type: (TBD1 by IANA) indicating a 4-Byte AS Number. 268 Length: 8 (Total length of the subobject in bytes). 270 Reserved: Zero at transmission, ignored at receipt. 272 AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in 273 use, the low order bits (16 through 31) MUST be used and the high 274 order bits (0 through 15) MUST be set to zero. For the purpose of 275 this experiment, it is advised to use 4-Byte AS number subobject 276 as default. 278 3.2.2. IGP Area 280 Since the length and format of Area-id is different for OSPF and 281 ISIS, the following two subobjects are defined: 283 For OSPF, the area-id is a 32 bit number. The subobject is encoded 284 as follows: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |L| Type | Length | Reserved | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | OSPF Area Id (4 bytes) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 L: The L bit is an attribute of the subobject as defined in 295 [RFC3209]. 297 Type: (TBD2 by IANA) indicating a 4-Byte OSPF Area ID. 299 Length: 8 (Total length of the subobject in bytes). 301 Reserved: Zero at transmission, ignored at receipt. 303 OSPF Area Id: The 4-Byte OSPF Area ID. 305 For IS-IS, the area-id is of variable length and thus the length of 306 the subobject is variable. The Area-id is as described in IS-IS by 307 ISO standard [ISO10589]. The subobject is encoded as follows: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |L| Type | Length | Area-Len | Reserved | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | | 315 // IS-IS Area ID // 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 L: The L bit is an attribute of the subobject as defined in 320 [RFC3209]. 322 Type: (TBD3 by IANA) indicating IS-IS Area ID. 324 Length: Variable. The Length MUST be at least 8, and MUST be a 325 multiple of 4. 327 Area-Len: Variable (Length of the actual (non-padded) IS-IS Area 328 Identifier in octets; Valid values are from 1 to 13 inclusive). 330 Reserved: Zero at transmission, ignored at receipt. 332 IS-IS Area Id: The variable-length IS-IS area identifier. Padded 333 with trailing zeroes to a four-byte boundary. 335 3.2.3. Mode of Operation 337 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 338 could be used in the ERO to specify an abstract node (a group of 339 nodes whose internal topology is opaque to the ingress node of the 340 LSP). 342 All the rules of processing (for example Next Hop Selection, L bit 343 processing, unrecognized subobjects etc) are as per the [RFC3209]. 344 Note that if a node is called upon to process subobject defined in 345 this document, and it does not recognize, it will behave as described 346 in [RFC3209] when an unrecognized ERO subobject is encountered. This 347 means that this node will return a PathErr with error code "Routing 348 Error" and error value "Bad EXPLICIT_ROUTE object" with the 349 EXPLICIT_ROUTE object included, truncated (on the left) to the 350 offending subobject. 352 3.3. Exclude Route Object (XRO)'s Subobjects 354 As stated in [RFC4874], the exclude route identifies a list of 355 abstract nodes that to exclude (not be traversed) along the path of 356 the LSP being established. 358 Some subobjects are defined in [RFC3209], [RFC3477], [RFC4874] and 359 [RFC6001] but new subobjects related to domains are needed. 361 This document extends the support for 4-Byte AS numbers and IGP 362 Areas. 364 Type Subobject 365 TBD1 Autonomous system number (4 Byte) 366 TBD2 OSPF Area id 367 TBD3 ISIS Area id 369 3.3.1. Autonomous system 371 [RFC3209] and [RFC4874] already define a 2-Byte AS number. 373 To support 4-Byte AS numbers as per [RFC6793], a subobject is with 374 the same format as defined in Section 3.2.1 with following 375 difference: 377 The meaning of the L bit is as per [RFC4874], where. 379 0: indicates that the abstract node specified MUST be excluded. 381 1: indicates that the abstract node specified SHOULD be avoided. 383 3.3.2. IGP Area 385 Since the length and format of Area-id is different for OSPF and 386 ISIS, the following two subobjects are defined: 388 For OSPF, the area-id is a 32 bit number. Subobjects for OSPF and 389 IS-IS are of the same format as defined in Section 3.2.2 with 390 following difference: 392 The meaning of the L bit is as per [RFC4874]. 394 3.3.3. Mode of Operation 396 The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area 397 could also be used in the XRO to specify exclusion of an abstract 398 node (a group of nodes whose internal topology is opaque to the 399 ingress node of the LSP). 401 All the rules of processing are as per the [RFC4874]. 403 Note that if a node is called upon to process a subobject defined in 404 this document, and it does not recognize, it will behave as described 405 in [RFC4874] when an unrecognized XRO subobject is encountered, i.e. 406 to ignore it. In this case the desired exclusion will not be carried 407 out. 409 3.4. Explicit Exclusion Route Subobject 411 As per [RFC4874], the Explicit Exclusion Route is used to specify 412 exclusion of certain abstract nodes between a specific pair of nodes 413 or resources in the explicit route. EXRS is an ERO subobject that 414 contains one or more subobjects of its own, called EXRS subobjects. 416 The EXRS subobject could carry any of the subobjects defined for XRO, 417 thus the new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) 418 Area can also be used in the EXRS. The meanings of the fields of the 419 new XRO subobjects are unchanged when the subobjects are included in 420 an EXRS, except that scope of the exclusion is limited to the single 421 hop between the previous and subsequent elements in the ERO. 423 All the rules of processing are as per the [RFC4874]. 425 4. Interaction with Path Computation Element (PCE) 427 The domain subobjects to be used in Path Computation Element Protocol 428 (PCEP) are referred to in [PCE-DOMAIN]. Note that the new domain 429 subobjects follow the principle that subobjects used in PCEP 431 [RFC5440] are identical to the subobjects used in RSVP-TE and thus 432 are interchangeable between PCEP and RSVP-TE. 434 5. IANA Considerations 436 5.1. New Subobjects 438 IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" 439 at http://www.iana.org/assignments/rsvp-parameters/rsvp- 440 parameters.xhtml. Within this registry IANA maintains two sub- 441 registries: 443 o "EXPLICIT_ROUTE subobjects": http://www.iana.org/assignments/rsvp- 444 parameters/rsvp-parameters.xhtml#rsvp-parameters-25 446 o "EXCLUDE_ROUTE subobjects": http://www.iana.org/assignments/rsvp- 447 parameters/rsvp-parameters.xhtml#rsvp-parameters-95 449 Upon approval of this document, IANA is requested to make identical 450 additions to these registries as follows, in sync with [PCE-DOMAIN]: 452 Subobject Type Reference 453 TBD1 4-Byte AS number [This I.D.] 454 TBD2 OSPF Area ID [This I.D.] 455 TBD3 IS-IS Area ID [This I.D.] 457 6. Security Considerations 459 Security considerations for MPLS-TE and GMPLS signaling are covered 460 in [RFC3209] and [RFC3473]. This document does not introduce any new 461 messages or any substantive new processing, and so those security 462 considerations continue to apply. Further, general considerations 463 for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in 464 [RFC5920]. 466 The route exclusion security consideration are covered in [RFC4874] 467 and continue to apply. 469 7. Acknowledgments 471 We would like to thank Adrian Farrel, Lou Berger, George Swallow, 472 Chirag Shah, Reeja Paul, Sandeep Boina and Avantika for their useful 473 comments and suggestions. 475 8. References 477 8.1. Normative References 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 485 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 486 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 487 . 489 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 490 Switching (GMPLS) Signaling Resource ReserVation Protocol- 491 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 492 DOI 10.17487/RFC3473, January 2003, 493 . 495 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 496 in Resource ReSerVation Protocol - Traffic Engineering 497 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 498 . 500 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - 501 Extension to Resource ReserVation Protocol-Traffic 502 Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, 503 April 2007, . 505 [ISO10589] 506 ISO, "Intermediate system to Intermediate system routing 507 information exchange protocol for use in conjunction with 508 the Protocol for providing the Connectionless-mode Network 509 Service (ISO 8473)", ISO/IEC 10589:2002, 1992. 511 [PCE-DOMAIN] 512 Dhody, D., Palle, U., and R. Casellas, "Standard 513 Representation Of Domain Sequence. (draft-ietf-pce-pcep- 514 domain-sequence)", September 2015. 516 8.2. Informative References 518 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 519 Element (PCE)-Based Architecture", RFC 4655, 520 DOI 10.17487/RFC4655, August 2006, 521 . 523 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 524 Inter-Domain Multiprotocol Label Switching Traffic 525 Engineering", RFC 4726, DOI 10.17487/RFC4726, November 526 2006, . 528 [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A 529 Per-Domain Path Computation Method for Establishing Inter- 530 Domain Traffic Engineering (TE) Label Switched Paths 531 (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, 532 . 534 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 535 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 536 DOI 10.17487/RFC5440, March 2009, 537 . 539 [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource 540 Reservation Protocol (RSVP) Extensions for Path Key 541 Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, 542 . 544 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 545 Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, 546 . 548 [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, 549 D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol 550 Extensions for Multi-Layer and Multi-Region Networks (MLN/ 551 MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, 552 . 554 [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet 555 Autonomous System (AS) Number Space", RFC 6793, 556 DOI 10.17487/RFC6793, December 2012, 557 . 559 Appendix A. Examples 561 These examples are for illustration purposes only, to show how the 562 new subobjects could be encoded. They are not meant to be an 563 exhaustive list of all possible usecases and combinations. 565 A.1. Inter-Area LSP Path Setup 567 In an inter-area LSP path setup where the ingress and the egress 568 belong to different IGP areas within the same AS, the domain 569 subobjects could be represented using an ordered list of IGP area 570 subobjects in an ERO. 572 D2 Area D 573 | 574 | 575 D1 576 | 577 | 578 ********BD1****** 579 * | * 580 * | * Area C 581 Area A * | * 582 * | * 583 Ingress------A1-----ABF1------B1------BC1------C1------Egress 584 / * | * 585 / * | * 586 / * Area | B * 587 F1 * | * 588 / ********BE1****** 589 / | 590 / | 591 F2 E1 592 | 593 Area F | 594 E2 Area E 596 * All IGP Area in one AS (AS 100) 598 Figure 1: Domain Corresponding to IGP Area 600 As per Figure 1, the signaling at Ingress could be - 602 ERO:(A1, ABF1, Area B, Area C, Egress) 604 It should be noted that there are other ways to achieve the desired 605 signaling, the area subobject provides another tool in the toolkit 606 and can have operational benefits when - 607 o Use of PCEP like domain-sequence [PCE-DOMAIN] configurations in 608 explicit path such that area subobjects can be used to signal the 609 loose path. 611 o Alignment of subobjects and registries between PCEP and RSVP-TE, 612 thus allowing easier interworking between path computation and 613 signaling i.e. to and fro of subobjects between signalling and 614 path computation (if need be). 616 A.2. Inter-AS LSP Path Setup 618 A.2.1. Example 1 620 In an inter-AS LSP path setup where the ingress and the egress belong 621 to different AS, the domain subobjects (AS) could be used in an ERO. 623 AS A AS E AS C 624 <-------------> <----------> <-------------> 626 A4----------E1---E2---E3---------C4 627 / / \ 628 / / \ 629 / / AS B \ 630 / / <----------> \ 631 Ingress------A1---A2------B1---B2---B3------C1---C2------Egress 632 \ / / 633 \ / / 634 \ / / 635 \ / / 636 A3----------D1---D2---D3---------C3 638 <----------> 639 AS D 641 * All AS have one area (area 0) 643 Figure 2: Domain Corresponding to AS 645 As per Figure 2, the signaling at Ingress could be - 647 ERO:(A1, A2, AS B, AS C, Egress); or 649 ERO:(A1, A2, AS B, Area 0, AS C, Area 0, Egress). 651 Each AS has a single IGP area (area 0), Area subobject is optional. 653 Note that to get a domain disjoint path, the ingress could also 654 signal the backup path with - 656 XRO:(AS B) 658 A.2.2. Example 2 660 As shown in Figure 3, where AS 200 is made up of multiple areas, the 661 signaling can include both AS and Area subobject to uniquely identify 662 a domain. 664 Ingress * 665 | * 666 | * 667 | * 668 X1 * 669 \\ * 670 \ \ * 671 \ \* Inter-AS 672 AS 100 \* \ Link 673 * \ \ 674 * \ \ 675 * \ \ 676 \ \ D2 Area D 677 AS 200 \ \ | 678 \ \ | 679 Inter \ \ D1 680 -AS \ \ | 681 Link \ \| 682 \ ********BD1****** 683 \ * | * 684 \ * | * Area C 685 Area A \ * | * 686 \* | * 687 A2------A1------AB1------B1------BC1------C1------Egress 688 * | * 689 * | * 690 * | * 691 * Area | B * 692 ********BE1****** 693 | 694 | 695 E1 696 | 697 | 698 E2 Area E 700 Figure 3: Domain Corresponding to AS and Area 702 As per Figure 3, the signaling at Ingress could be - 704 ERO:(X1, AS 200, Area B, Area C, Egress). 706 Authors' Addresses 707 Dhruv Dhody 708 Huawei Technologies 709 Divyashree Techno Park, Whitefield 710 Bangalore, Karnataka 560037 711 India 713 EMail: dhruv.ietf@gmail.com 715 Udayasree Palle 716 Huawei Technologies 717 Divyashree Techno Park, Whitefield 718 Bangalore, Karnataka 560037 719 India 721 EMail: udayasree.palle@huawei.com 723 Venugopal Reddy Kondreddy 724 Huawei Technologies 725 Divyashree Techno Park, Whitefield 726 Bangalore, Karnataka 560037 727 India 729 EMail: venugopalreddyk@huawei.com 731 Ramon Casellas 732 CTTC 733 Av. Carl Friedrich Gauss n7 734 Castelldefels, Barcelona 08860 735 Spain 737 EMail: ramon.casellas@cttc.es