idnits 2.17.00 (12 Aug 2021) /tmp/idnits44129/draft-anand-spring-poi-sr-06.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 18 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2018) is 1391 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) == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-04 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group Madhukar Anand 3 Internet-Draft Sanjoy Bardhan 4 Intended Status: Standard Track Infinera Corporation 6 Ramesh Subrahmaniam 7 Individual 9 Jeff Tantsura 10 Nuage Networks 12 Utpal Mukhopadhyaya 13 Equinix Inc 15 Clarence Filsfils 16 Cisco Systems, Inc. 18 Expires: January 31, 2019 July 30, 2018 20 Packet-Optical Integration in Segment Routing 21 draft-anand-spring-poi-sr-06 23 Abstract 25 This document illustrates a way to integrate a new class of nodes and 26 links in segment routing to represent transport networks in an opaque 27 way into the segment routing domain. An instance of this class would 28 be optical networks that are typically transport centric. In the IP 29 centric network, this will help in defining a common control protocol 30 for packet optical integration that will include optical paths as 31 'transport segments' or sub-paths as an augmentation to packet paths. 32 The transport segment option also defines a general mechanism to 33 allow for future extensibility of segment routing into non-packet 34 domains. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of this Memo 44 This Internet-Draft is submitted to IETF in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF), its areas, and its working groups. Note that 49 other groups may also distribute working documents as 50 Internet-Drafts. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/1id-abstracts.html 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html 63 Copyright and License Notice 65 Copyright (c) 2018 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (http://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4 82 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5 83 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8 84 5. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9 85 6. PCEP extensions for supporting the transport segment . . . . . 10 86 7. BGP-LS extensions for supporting the transport segment . . . . 11 87 7.1 Node Attribuites TLV . . . . . . . . . . . . . . . . . . . . 11 88 7.2 SR-Optical-Node-Capability TLV . . . . . . . . . . . . . . . 11 89 7.3 Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . . 12 90 7.3.1 Transport Segment SID Sub-TLV . . . . . . . . . . . . . 12 91 8. Note about Transport Segments and Scalability . . . . . . . . . 13 92 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 94 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 96 11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 98 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 99 13.1 Normative References . . . . . . . . . . . . . . . . . . . 15 100 13.2 Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 103 1 Introduction 105 Packet and optical transport networks have evolved independently with 106 different control plane mechanisms that have to be provisioned and 107 maintained separately. Consequently, coordinating packet and optical 108 networks for delivering services such as end-to-end traffic 109 engineering or failure response has proved challenging. To address 110 this challenge, a unified control and management paradigm that 111 provides an incremental path to complete packet-optical integration 112 while leveraging existing signaling and routing protocols in either 113 domains is needed. This document introduces such a paradigm based on 114 Segment Routing (SR) [RFC8402]. 116 This document introduces a new type of segment, Transport segment, as 117 a special case of SR traffic engineering (SR-TE) policy (Type 1, Sec 118 5. [I-D.draft-ietf-spring-segment-routing-policy]). Specifically, the 119 structure of SR-TE policy and constraints associated in the transport 120 network are different from those outlined for the packet networks. 121 Transport segment can be used to model abstracted paths through the 122 optical transport domain and integrate it with the packet network for 123 delivering end-to-end services. In addition, this also introduces a 124 notion of a Packet optical gateway (POG). These are nodes in the 125 network that map packet services to the optical domain that originate 126 and terminate these transport segments. Given a transport segment, a 127 POG will expand it to a path in the optical transport network. A POG 128 can be viewed as SR traffic engineering policy headend. 130 The concept of POG introduced here allows for multiple instantiations 131 of the concept. In one case, the packet device is distinct from the 132 optical transport device, and the POG is a logical entity that spans 133 these two devices. In this case, the POG functionality is achieved 134 with the help of external coordination between the packet and optical 135 devices. In another case, the packet and optical components are 136 integrated into one physical device, and the co-ordination required 137 for functioning of the POG is performed by this integrated device. 138 It must be noted that in either case, it is the packet/optical data 139 plane that is either disaggregated or integrated. Control of the 140 devices can be logically centralized or distributed in either 141 scenario. The focus of this document is to define the logical 142 functions of a POG without going into the exact instantiations of the 143 concept. 145 2. Reference Taxonomy 147 POG - Packet optical gateway Device 149 SR Edge Router - The Edge Router which is the ingress device 150 CE - Customer Edge Device that is outside of the SR domain 152 PCE - Path Computation Engine 154 Controller - A network controller 156 3. Use case - Packet Optical Integration 158 Many operators build and operate their networks that are both multi- 159 layer and multi-domain. Services are built around these layers and 160 domains to provide end-to-end services. Due to the nature of the 161 different domains, such as packet and optical, the management and 162 service creation has always been problematic and time consuming. With 163 segment routing, enabling a head-end node to select a path and embed 164 the information in the packet is a powerful construct that would be 165 used in the Packet Optical Gateways (POG). The path is usually 166 constructed for each domain that may be manually derived or through a 167 stateful PCE which is run specifically in that domain. 169 P5 170 P1 _ .-'-._ ,'P4 171 `._ .-' `-. ,' 172 `. _.-' `-._ ,' 173 `-. .-' `-. ,' 174 P2`.-'--------------------------`-.- P3 175 |\ /| 176 | \ / | Packet 177 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 178 | \ / | 179 | \ / | Transport 180 | \ / | 181 | ................./ | 182 | ,'O2 O3`. | 183 | ,' `. | 184 |,' `.| 185 O1\ | O4 186 \ ,' 187 \ ,' 188 .......................- 189 O6 O5 191 Figure 1: Representation of a packet-optical path 193 In Figure 1 above, the nodes represent a packet optical network. 194 P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical 195 network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that 196 communicate with other packet devices and also with the devices in the 197 optical transport domain. In defining a path between nodes P2 and P3, we 198 will need to specify the nodes and the links in both the packet and 199 optical transport domains. 201 To leverage segment routing to define a service between P1 and P4, the 202 ingress node P1 would append all outgoing packets in a SR header 203 consisting of the SIDs that constitute the path. In the packet domain 204 this would mean P1 would send its packets towards P4 using a segment 205 list {P2, P3, P4} or {P2, P5, P3, P4} as the case may be. The operator 206 would need to use a different mechanism in the optical domain to set up 207 the optical paths comprising the nodes O1, O2 and O3. Each POG would 208 announce the active optical path as a transport segment - for example, 209 the optical path {O1, O2, O3} could be represented as a label Om and the 210 optical path {O2, O3} could be represented as a transport label On. Both 211 Om and On will be advertised by Packet node P2. These paths are not 212 known to the packet SR domain and is only relevant to the optical domain 213 D between P2 and P3. A PCE that is run in Domain D would be 214 responsible for calculating paths corresponding to label Om and On. The 215 expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3, 216 P4}. It is to be noted that there are other possible paths between P2 217 and P3 in the optical domain involving optical nodes O5, O6, and O4. 218 There may be multiple optical paths between P2 and P3 corresponding to 219 multiple SR policies. For example, some optical paths can be low-cost, 220 some are low-latency, and some others can be high-bandwidth paths. 221 Transport segments for all these candidate viable alternative paths may 222 be generated statically or dynamically.They may be pre-computed or may 223 be generated on the fly when a customer at node P1 requests a service 224 towards node P4. A discussion on transport segments and scalability can 225 be found in Section 8. 227 Use-case examples of transport segments. 229 1. Consider the scenario where there are multiple fibers between two 230 packet end points. The network operator may choose to route packet 231 traffic on the first fiber, and reserve the second fiber only for 232 maintenance or low priority traffic. 234 2. As a second use-case, consider the case where the packet end points 235 are connected by optical transport provided by two different service 236 providers. The packet operator wants to preferentially route traffic 237 over one of the providers and use the second provider as a backup. 239 3. Finally, let the packet end points be connected by optical paths that 240 may span multiple optical domains i.e. different administrative control. 241 For instance, one optical transport path may lie completely in one 242 country while the other optical transport path transits another country. 243 Weather, tariffs, security considerations and other factors may 244 determine how the packet operator wants to route different types of 245 traffic on this network. 247 All of the above use-cases can be supported by first mapping distinct 248 optical transport paths to different transport segments and then, 249 depending on the need, affixing appropriate transport segment identifier 250 to the specific packet to route it appropriately through the transport 251 domain. 253 +------------------------+ 254 | | 255 +--------------+----' PCE or Controller |----+---------------+ 256 | | | | | | 257 | | +------------------------+ | | 258 | | | | 259 | | .-----. | | 260 | | ( ) | | 261 +-------+ +-------+ .--( )--. +-------+ +-------+ 262 | SR | |Packet | ( ) |Packet | | SR | 263 | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | 264 |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | 265 +---+.--+ +-------+ ( ) +-------+ +---+.--+ 266 | '--( )--' | 267 ,--+. ( ) ,-+-. 268 ( CE ) '-----' ( CE ) 269 `---' `---' 271 Figure 3. Reference Topology for Transport Segment Mechanism 273 4. Mechanism overview 275 The current proposal assumes that the SR domains run standard 276 protocols without any modification to discover the topology and 277 distribute labels. There are also no modifications necessary in the 278 control plane mechanisms in the optical transport domains. The only 279 requirement of a transport segment is that the optical path be setup 280 before they are announced to the packet network. For example, the 281 optical paths may be setup using a domain-specific controller or a 282 PCE based on requirements from the packet domain (such as bandwidth, 283 QoS, latency and cost) taking into consideration the constraints in 284 the optical network. 286 The mechanism for supporting the transport segment is as follows. 288 1. Firstly, the Packet Optical Gateway (POG) devices are announced 289 in the packet domain. This is indicated by advertising a new SR node 290 capability flag. The exact extensions to support this capability are 291 described in the subsequent sections of this document. 293 2. Then, the POG devices announce candidate optical transport 294 paths between that POG (Source POG) and other POGs (Destination POG) 295 via appropriate mechanisms in the packet domain. The paths are 296 announced with an appropriate optical transport domain ID and a 297 Binding SID representing the transport segment from a source POG to a 298 destination POG. The appropriate protocol-specific extensions to 299 carry path characteristics and Binding SID corresponding to a optical 300 path are described in the subsequent sections of this document. 302 3.The transport SR policy can also optionally be announced with a 303 set of attributes that characterizes the path in the optical 304 transport domain between the two POG devices. For instance, those 305 could define the path attributes such as path identifier, latency, 306 bandwidth, quality, directionality, or optical path protection 307 schemes. These attributes can be used to determine the "color" of the 308 SR-TE policy in the tuple used 309 to prioritize different candidate paths between the POGs. 311 4. The POG device is also responsible for programming its 312 forwarding table to map every transport segment Binding SID entry 313 into an appropriate forwarding action relevant in the optical domain, 314 such as mapping it to a optical label-switched path. 316 5. The transport SR policy is communicated to the PCE or 317 Controller using extensions to BGP-LS or PCEP as described in 318 subsequent sections of this document. 320 6. Finally, the PCE or Controller in the packet domain then uses 322 the transport segment binding SID in the overall SR policy to 323 influence the path traversed by the packet in the optical domain, 324 thereby defining the end-to-end path for a given service. 326 In the next few sections, we outline a few representative protocol 327 specific extensions to carry the transport segment. 329 5. Transport Segments as SR Policy 331 The Segment Routing Traffic Engineering (SRTE) [ietf-spring-segment- 332 routing-policy] process installs the transport segment SR policy in 333 the forwarding plane of the POG. The Transport SR policy is 334 identified by using a transport segment Binding SID. Corresponding to 335 each transport segment Binding SID, the SRTE process MAY learn about 336 multiple candidate paths. The SRTE-DB includes information about the 337 candidate paths including optical domain, topology and path 338 characteristics. All of the information can be learned from different 339 sources including but not limited to: Netconf/Restconf, PCEP and BGP- 340 LS. 342 The information model for Transport SR policy is as follows: 344 Transport SR Policy FO1 345 Candidate-paths 346 path preference 200 (selected) 347 BSID1 348 path preference 100 349 BSID2 350 path preference 100 351 BSID3 352 path preference 50 353 BSID4 355 A transport SR policy is identified through the tuple . Each TSR policy is associated with one or more 357 candidate paths, each of them associated with a (locally) unique Binding 358 SID and a path preference. For each transport SR policy, the candidate 359 path with the highest path preference (at most one) is selected and used 360 for forwarding traffic that is being steered onto that policy. When 361 candidate paths change (or a new candidate path is set up), the path 362 selection process can be re-executed. The validity of each path is to be 363 verified by the POG before announcement in the packet domain. If there 364 are no valid paths, then the transport SR policy is deemed invalid. 366 The allocation of BSID to a path can include dynamic, explicit or 367 generic allocation strategies as discussed in [ietf-spring-segment- 368 routing-policy]. We discuss PCEP and BGP-LS specific extensions in the 369 subsequent section. 371 6. PCEP extensions for supporting the transport segment 373 To communicate the Packet-Optical Gateway capability of the device, we 374 introduce a new PCEP capabilities TLV is defined as follows(extensions 375 to [I-D.ietf-pce-segment-routing]): 377 Value Meaning Reference 378 -------- ------------------------------------ ----------------- 379 27 TRANSPORT-SR-PCE-CAPABILITY This document 381 A new type of TLV to accommodate a transport segment is defined 382 by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid] 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type | Length | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Binding Type (BT) | Domain ID | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Binding Value | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 ~ Transport Segment Sub TLVs (variable length) ~ 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 where: 398 Type: TBD, suggested value 32 400 Length: variable. 402 Binding Type: 0 or 1 as defined in 403 [I-D.sivabalan-pce-binding-label-sid] 405 Domain ID: An identifier for the transport domain 407 Binding Value: is the transport segment label 408 Transport Segment Sub TLVs: TBD 410 IANA will be requested to allocate a new TLV type (recommended value 411 is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: 413 1 Transport Segment Label (This document) 415 7. BGP-LS extensions for supporting the transport segment 417 7.1 Node Attribuites TLV 419 To communicate the Packet-Optical Gateway capability of the 420 device, we introduce an new optical informational capability 421 the following new Node Attribute TLV is defined: 423 +-----------+----------------------------+----------+---------------+ 424 | TLV Code | Description | Length | Section | 425 | Point | | | | 426 +-----------+----------------------------+----------+---------------+ 427 | 1172 | SR-Optical-Node-Capability | variable | | 428 | | TLV | | | 429 +-----------+----------------------------+----------+---------------+ 431 Table 1: Node Attribute TLVs 433 These TLVs can ONLY be added to the Node Attribute associated with 434 the node NLRI that originates the corresponding SR TLV. 436 7.2 SR-Optical-Node-Capability TLV 438 The SR Capabilities sub-TLV has following format: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Flags | RESERVED | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 where: 450 Type : TBD, Suggested Value 1157 451 Length: variable. 453 Flags: The Flags field currently has only one bit defined. If the bit 454 is set it has the capability of an Packet Optical Gateway. 456 7.3 Prefix Attribute TLVs 457 The following Prefix Attribute Binding SID Sub-TLVs have been added: 459 +------------+-------------------------+----------+-----------------+ 460 | TLV Code | Description | Length | Section | 461 | Point | | | | 462 +------------+-------------------------+----------+-----------------+ 463 | 1173 | TRANSPORT-SEGMENT-SID | 12 | | 464 | | | | | 465 +------------+-------------------------+----------+-----------------+ 467 Table 4: Prefix Attribute - Binding SID Sub-TLVs 469 The Transport segment TLV allows a node to advertise an transport 470 segment within a single IGP domain. The transport segment SID TLV 471 TRANSPORT-SEGMENT-TLV has the following format: 473 7.3.1 Transport Segment SID Sub-TLV 475 Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of 476 Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 477 transport segment label is defined as follows. 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Type | Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Domain ID | Flags | Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Packet-Optical Label | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 ~ Transport Segment Sub TLVs (variable length) ~ 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 where: 491 Type : TBD 493 Length: variable. 495 Domain ID: An identifier for the transport domain 496 Flags: 1 octet field of following flags: 497 V - Value flag. If set, then the optical label carries a value. 498 By default the flag is SET. 499 L - Local. Local Flag. If set, then the value/index carried by 500 the Adj-SID has local significance. By default the flag is SET. 502 0 1 2 3 4 5 6 7 503 +-+-+-+-+-+-+-+-+ 504 |V|L| 505 +-+-+-+-+-+-+-+-+ 507 Packet-Optical Label : according to the V and L flags, it contains 508 either: 510 * A 3 octet local label where the 20 rightmost bits are 511 used for encoding the label value. In this case the V and 512 L flags MUST be set. 514 * A 4 octet index defining the offset in the label space 515 advertised by this router. In this case V and L flags MUST 516 be unset. 518 Transport Segment Sub TLVs: TBD 520 Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair 521 of POG devices to represent multiple paths within the optical domain 523 8. Note about Transport Segments and Scalability 525 In most operational scenarios, there would be multiple, distinct paths 526 between the POGs. There is no requirement that every distinct path in 527 the optical domain be advertised as a separate transport segment. 528 Transport segments are designed to be consumed in the packet domain, 529 and the correspondence between transport segments and exact paths in 530 the optical domain are determined by their utility to the packet world. 531 Therefore, the number of transport segments is to be determined by the 532 individual packet-optical use-case. The number of actual paths in the 533 optical domain between the POG is expected to be large (counting the 534 number of active and passive devices in the optical network), it is 535 likely that multiple actual paths are to be advertised as one transport 536 segment. Of course, in the degenerate case, it is possible that there 537 is a one-to-one correspondence between an optical path and a transport 538 segment. Given this view of network operation, the POG is not expected 539 to handle a large number of transport segments (and identifiers). This 540 framework does leave open the possibility of handling a large number 541 of transport segments in future. For instance, a hierarchical 542 partitioning of the optical domain along with stacking of multiple 543 transport segment identifiers could be explored towards reducing 544 the overall number of transport segment identifiers. 546 9. Summary 548 The motivation for introducing a new type of segment - transport 549 segment - is to integrate transport networks with the segment 550 routing domain and expose characteristics of the transport domain into 551 the packet domain. An end-to-end path across packet and transport 552 domains can then be specified by attaching appropriate SIDs to the 553 packet. An instance of transport segments has been defined here for 554 optical networks, where paths between packet-optical gateway devices 555 have been abstracted using binding SIDs. Extensions to various 556 protocols to announce the transport segment have been proposed 557 in this document. 559 10. Security Considerations 561 This document does not introduce any new security considerations. 563 11 IANA Considerations 565 This documents request allocation for the following TLVs and subTLVs. 567 11.1 PCEP 568 Packet-Optical Gateway capability of the device 570 Value Meaning Reference 571 -------- ------------------------------------ ----------------- 572 27 TRANSPORT-SR-PCE-CAPABILITY This document 574 A new type of TLV to accommodate a transport segment is defined 575 by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid] 577 Value Description Reference 579 32 TRANSPORT-SR-PCEP-TLV This document 581 This document requests that a registry is created to manage the value 582 of the Binding Type field in the TRANSPORT-SR-PCEP TLV. 584 Value Description Reference 586 1 Transport Segment Label This document 588 11.2 BGP-LS 589 Node Attributes TLV: 591 Value Description Reference 593 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document 595 Prefix Attribute Binding SID SubTLV: 597 Value Description Reference 599 1173 TRANSPORT-SR-BGPLS-TLV This document 601 12 Acknowledgements 602 We would like to thank Peter Psenak, and Radhakrishna 603 Valiveti for their comments and review of this document. 605 13 References 607 13.1 Normative References 609 [RFC8402] 610 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 611 Litkowski, S., and R. Shakir, "Segment Routing Architecture", 612 RFC 8402, July 2018. 614 [I-D.sivabalan-pce-binding-label-sid] 615 Sivabalan, S., Tantsura, J., Filsfils, C., Previdi, S., 616 Hardwick, J., and Dhody, D., "Carrying Binding Label/ 617 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 618 binding-label-sid-04 (work in progress), Mar 2018. 620 [I-D.ietf-pce-segment-routing] 621 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 622 and J. Hardwick, "PCEP Extensions for Segment Routing", 623 draft-ietf-pce-segment-routing-12 (work in progress), 624 June 2018. 626 [I-D.draft-ietf-spring-segment-routing-policy] 627 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., 628 and Mattes, P., "Segment Routing Policy Architecture", 629 draft-ietf-spring-segment-routing-policy-01.txt 630 (work in progress), June 2018. 632 13.2 Informative References 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, 636 DOI 10.17487/RFC2119, March 1997, 637 . 639 Authors' Addresses 641 Madhukar Anand 642 Infinera Corporation 643 169 W Java Dr, Sunnyvale, CA 94089 645 Email: manand@infinera.com 647 Sanjoy Bardhan 648 Infinera Corporation 649 169 W Java Dr, Sunnyvale, CA 94089 651 Email: sbardhan@infinera.com 653 Ramesh Subrahmaniam 654 Email: svr_fremont@yahoo.com 656 Jeff Tantsura 657 Nuage Networks 658 755 Ravendale Drive 659 Mountain View CA 94043 660 Email: jefftant.ietf@gmail.com 661 Utpal Mukhopadhyaya 662 Equinix Inc 663 1188 E. Arques, Sunnyvale, CA 94085 664 Email: umukhopadhyaya@equinix.com 666 Clarence Filsfils 667 Cisco Systems, Inc. 668 Brussels 669 BE 670 Email: cfilsfil@cisco.com