idnits 2.17.1 draft-anand-spring-poi-sr-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: ---------------------------------------------------------------------------- == 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 13 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 == Line 301 has weird spacing: '...he path attri...' -- The document date (November 14, 2017) is 2347 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.draft-sivabalan-pce-segment-routing' is mentioned on line 371, but not defined == Missing Reference: 'I-D.draft-sivabalan-pce-binding-label-sid-01' is mentioned on line 572, but not defined == Unused Reference: 'RFC7752' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-segment-routing' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'I-D.filsfils-spring-segment-routing-policy' is defined on line 629, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-12 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-03 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-10 == Outdated reference: A later version (-06) exists of draft-filsfils-spring-segment-routing-policy-01 Summary: 2 errors (**), 0 flaws (~~), 13 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: Informational Infinera Corporation 6 Ramesh Subrahmaniam 7 Individual 9 Jeff Tantsura 10 Individual 12 Utpal Mukhopadhyaya 13 Equinix Inc 15 Clarence Filsfils 16 Cisco Systems, Inc. 18 Expires: May 18, 2018 November 14, 2017 20 Packet-Optical Integration in Segment Routing 21 draft-anand-spring-poi-sr-04 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) 2017 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 8. Note about Transport Segments and Scalability . . . . . . . . . 13 88 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 91 11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 92 11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15 93 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 94 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 13.1 Normative References . . . . . . . . . . . . . . . . . . . 15 96 13.2 Informative References . . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 99 1 Introduction 101 Packet and optical transport networks have evolved independently with 102 different control plane mechanisms that have to be provisioned and 103 maintained separately. Consequently, coordinating packet and optical 104 networks for delivering services such as end-to-end traffic 105 engineering or failure response has proved challenging. To address 106 this challenge, a unified control and management paradigm that 107 provides an incremental path to complete packet-optical integration 108 while leveraging existing signaling and routing protocols in either 109 domains is needed. This document introduces such a paradigm based on 110 Segment Routing (SR) [I-D.ietf-spring-segment-routing]. 112 This document introduces a new type of segment, Transport segment, as 113 a special case of SR traffic engineering (SR-TE) policy [Type 1, Sec 114 5. I-D.filsfils-spring-segment-routing-policy]. Specifically, the 115 structure of SR-TE policy and constraints associated in the transport 116 network are different from those outlined for the packet networks. 117 Transport segment can be used to model abstracted paths through the 118 optical transport domain and integrate it with the packet network for 119 delivering end-to-end services. In addition, this also introduces a 120 notion of a Packet optical gateway (POG). These are nodes in the 121 network that map packet services to the optical domain that originate 122 and terminate these transport segments. Given a transport segment, a 123 POG will expand it to a path in the optical transport network. A POG 124 can be viewed as SR traffic engineering policy headend. 126 The concept of POG introduced here allows for multiple instantiations 127 of the concept. In one case, the packet device is distinct from the 128 optical transport device, and the POG is a logical entity that spans 129 these two devices. In this case, the POG functionality is achieved 130 with the help of external coordination between the packet and optical 131 devices. In another case, the packet and optical components are 132 integrated into one physical device, and the co-ordination required 133 for functioning of the POG is performed by this integrated device. 134 It must be noted that in either case, it is the packet/optical data 135 plane that is either disaggregated or integrated. Control of the 136 devices can be logically centralized or distributed in either 137 scenario. The focus of this document is to define the logical 138 functions of a POG without going into the exact instantiations of the 139 concept. 141 2. Reference Taxonomy 143 POG - Packet optical gateway Device 145 SR Edge Router - The Edge Router which is the ingress device 146 CE - Customer Edge Device that is outside of the SR domain 148 PCE - Path Computation Engine 150 Controller - A network controller 152 3. Use case - Packet Optical Integration 154 Many operators build and operate their networks that are both multi- 155 layer and multi-domain. Services are built around these layers and 156 domains to provide end-to-end services. Due to the nature of the 157 different domains, such as packet and optical, the management and 158 service creation has always been problematic and time consuming. With 159 segment routing, enabling a head-end node to select a path and embed 160 the information in the packet is a powerful construct that would be 161 used in the Packet Optical Gateways (POG). The path is usually 162 constructed for each domain that may be manually derived or through a 163 stateful PCE which is run specifically in that domain. 165 P5 166 P1 _ .-'-._ ,'P4 167 `._ .-' `-. ,' 168 `. _.-' `-._ ,' 169 `-. .-' `-. ,' 170 P2`.-'--------------------------`-.- P3 171 |\ /| 172 | \ / | Packet 173 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 174 | \ / | 175 | \ / | Transport 176 | \ / | 177 | ................./ | 178 | ,'O2 O3`. | 179 | ,' `. | 180 |,' `.| 181 O1\ | O4 182 \ ,' 183 \ ,' 184 .......................- 185 O6 O5 187 Figure 1: Representation of a packet-optical path 189 In Figure 1 above, the nodes represent a packet optical network. 190 P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical 191 network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that 192 communicate with other packet devices and also with the devices in the 193 optical transport domain. In defining a path between nodes P2 and P3, we 194 will need to specify the nodes and the links in both the packet and 195 optical transport domains. 197 To leverage segment routing to define a service between P1 and P4, the 198 ingress node P1 would append all outgoing packets in a SR header 199 consisting of the SIDs that constitute the path. In the packet domain 200 this would mean P1 would send its packets towards P4 using a segment 201 list {P2, P3, P4} or {P2, P5, P3, P4} as the case may be. The operator 202 would need to use a different mechanism in the optical domain to set up 203 the optical paths comprising the nodes O1, O2 and O3. Each POG would 204 announce the active optical path as a transport segment - for example, 205 the optical path {O1, O2, O3} could be represented as a label Om and the 206 optical path {O2, O3} could be represented as a transport label On. Both 207 Om and On will be advertised by Packet node P2. These paths are not 208 known to the packet SR domain and is only relevant to the optical domain 209 D between P2 and P3. A PCE that is run in Domain D would be 210 responsible for calculating paths corresponding to label Om and On. The 211 expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3, 212 P4}. It is to be noted that there are other possible paths between P2 213 and P3 in the optical domain involving optical nodes O5, O6, and O4. 214 There may be multiple optical paths between P2 and P3 corresponding to 215 multiple SR policies. For example, some optical paths can be low-cost, 216 some are low-latency, and some others can be high-bandwidth paths. 217 Transport segments for all these candidate viable alternative paths may 218 be generated statically or dynamically.They may be pre-computed or may 219 be generated on the fly when a customer at node P1 requests a service 220 towards node P4. A discussion on transport segments and scalability can 221 be found in Section 8. 223 Use-case examples of transport segments. 225 1. Consider the scenario where there are multiple fibers between two 226 packet end points. The network operator may choose to route packet 227 traffic on the first fiber, and reserve the second fiber only for 228 maintenance or low priority traffic. 230 2. As a second use-case, consider the case where the packet end points 231 are connected by optical transport provided by two different service 232 providers. The packet operator wants to preferentially route traffic 233 over one of the providers and use the second provider as a backup. 235 3. Finally, let the packet end points be connected by optical paths that 236 may span multiple optical domains i.e. different administrative control. 237 For instance, one optical transport path may lie completely in one 238 country while the other optical transport path transits another country. 239 Weather, tariffs, security considerations and other factors may 240 determine how the packet operator wants to route different types of 241 traffic on this network. 243 All of the above use-cases can be supported by first mapping distinct 244 optical transport paths to different transport segments and then, 245 depending on the need, affixing appropriate transport segment identifier 246 to the specific packet to route it appropriately through the transport 247 domain. 249 +------------------------+ 250 | | 251 +--------------+----' PCE or Controller |----+---------------+ 252 | | | | | | 253 | | +------------------------+ | | 254 | | | | 255 | | .-----. | | 256 | | ( ) | | 257 +-------+ +-------+ .--( )--. +-------+ +-------+ 258 | SR | |Packet | ( ) |Packet | | SR | 259 | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | 260 |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | 261 +---+.--+ +-------+ ( ) +-------+ +---+.--+ 262 | '--( )--' | 263 ,--+. ( ) ,-+-. 264 ( CE ) '-----' ( CE ) 265 `---' `---' 267 Figure 3. Reference Topology for Transport Segment Mechanism 269 4. Mechanism overview 271 The current proposal assumes that the SR domains run standard 272 protocols without any modification to discover the topology and 273 distribute labels. There are also no modifications necessary in the 274 control plane mechanisms in the optical transport domains. The only 275 requirement of a transport segment is that the optical path be setup 276 before they are announced to the packet network. For example, the 277 optical paths may be setup using a domain-specific controller or a 278 PCE based on requirements from the packet domain (such as bandwidth, 279 QoS, latency and cost) taking into consideration the constraints in 280 the optical network. 282 The mechanism for supporting the transport segment is as follows. 284 1. Firstly, the Packet Optical Gateway (POG) devices are announced 285 in the packet domain. This is indicated by advertising a new SR node 286 capability flag. The exact extensions to support this capability are 287 described in the subsequent sections of this document. 289 2. Then, the POG devices announce candidate optical transport 290 paths between that POG (Source POG) and other POGs (Destination POG) 291 via appropriate mechanisms in the packet domain. The paths are 292 announced with an appropriate optical transport domain ID and a 293 Binding SID representing the transport segment from a source POG to a 294 destination POG. The appropriate protocol-specific extensions to 295 carry path characteristics and Binding SID corresponding to a optical 296 path are described in the subsequent sections of this document. 298 3.The transport SR policy can also optionally be announced with a 299 set of attributes that characterizes the path in the optical 300 transport domain between the two POG devices. For instance, those 301 could define the path attributes such as path identifier, latency, 302 bandwidth, quality, directionality, or optical path protection 303 schemes. These attributes can be used to determine the "color" of the 304 SR-TE policy in the tuple used 305 to prioritize different candidate paths between the POGs. 307 4. The POG device is also responsible for programming its 308 forwarding table to map every transport segment Binding SID entry 309 into an appropriate forwarding action relevant in the optical domain, 310 such as mapping it to a optical label-switched path. 312 5. The transport SR policy is communicated to the PCE or 313 Controller using extensions to BGP-LS or PCEP as described in 314 subsequent sections of this document. 316 6. Finally, the PCE or Controller in the packet domain then uses 318 the transport segment binding SID in the overall SR policy to 319 influence the path traversed by the packet in the optical domain, 320 thereby defining the end-to-end path for a given service. 322 In the next few sections, we outline a few representative protocol 323 specific extensions to carry the transport segment. 325 5. Transport Segments as SR Policy 327 The Segment Routing Traffic Engineering (SRTE) [I-D.filsfils-spring- 328 segment-routing-policy] process installs the transport segment SR 329 policy in the forwarding plane of the POG. The Transport SR policy is 330 identified by using a transport segment Binding SID. Corresponding to 331 each transport segment Binding SID, the SRTE process MAY learn about 332 multiple candidate paths. The SRTE-DB includes information about the 333 candidate paths including optical domain, topology and path 334 characteristics. All of the information can be learned from different 335 sources including but not limited to: Netconf/Restconf, PCEP and BGP- 336 LS. 338 The information model for Transport SR policy is as follows: 340 Transport SR Policy FO1 341 Candidate-paths 342 path preference 200 (selected) 343 BSID1 344 path preference 100 345 BSID2 346 path preference 100 347 BSID3 348 path preference 50 349 BSID4 351 A transport SR policy is identified through the tuple . Each TSR policy is associated with one or more 353 candidate paths, each of them associated with a (locally) unique Binding 354 SID and a path preference. For each transport SR policy, the candidate 355 path with the highest path preference (at most one) is selected and used 356 for forwarding traffic that is being steered onto that policy. When 357 candidate paths change (or a new candidate path is set up), the path 358 selection process can be re-executed. The validity of each path is to be 359 verified by the POG before announcement in the packet domain. If there 360 are no valid paths, then the transport SR policy is deemed invalid. 362 The allocation of BSID to a path can include dynamic, explicit or 363 generic allocation strategies as discussed in [I-D.filsfils-spring- 364 segment-routing-policy]. We discuss PCEP and BGP-LS specific extensions 365 in the subsequent section. 367 6. PCEP extensions for supporting the transport segment 369 To communicate the Packet-Optical Gateway capability of the device, we 370 introduce a new PCEP capabilities TLV is defined as follows(extensions 371 to [I-D.draft-sivabalan-pce-segment-routing]): 373 Value Meaning Reference 374 -------- ------------------------------------ ----------------- 375 27 TRANSPORT-SR-PCE-CAPABILITY This document 377 A new type of TLV to accommodate a transport segment is defined 378 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Binding Type (BT) | Domain ID | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Binding Value | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 ~ Transport Segment Sub TLVs (variable length) ~ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 where: 394 Type: TBD, suggested value 32 396 Length: variable. 398 Binding Type: 0 or 1 as defined in 399 [I-D.draft-sivabalan-pce-binding-label-sid-01] 401 Domain ID: An identifier for the transport domain 403 Binding Value: is the transport segment label 404 Transport Segment Sub TLVs: TBD 406 IANA will be requested to allocate a new TLV type (recommended value 407 is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: 409 1 Transport Segment Label (This document) 411 7. BGP-LS extensions for supporting the transport segment 413 7.1 Node Attribuites TLV 415 To communicate the Packet-Optical Gateway capability of the 416 device, we introduce an new optical informational capability 417 the following new Node Attribute TLV is defined: 419 +-----------+----------------------------+----------+---------------+ 420 | TLV Code | Description | Length | Section | 421 | Point | | | | 422 +-----------+----------------------------+----------+---------------+ 423 | 1172 | SR-Optical-Node-Capability | variable | | 424 | | TLV | | | 425 +-----------+----------------------------+----------+---------------+ 427 Table 1: Node Attribute TLVs 429 These TLVs can ONLY be added to the Node Attribute associated with 430 the node NLRI that originates the corresponding SR TLV. 432 7.2 SR-Optical-Node-Capability TLV 434 The SR Capabilities sub-TLV has following format: 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Length | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Flags | RESERVED | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 where: 446 Type : TBD, Suggested Value 1157 448 Length: variable. 450 Flags: The Flags field currently has only one bit defined. If the bit 451 is set it has the capability of an Packet Optical Gateway. 453 9.3 Prefix Attribute TLVs 454 The following Prefix Attribute Binding SID Sub-TLVs have been added: 456 +------------+-------------------------+----------+-----------------+ 457 | TLV Code | Description | Length | Section | 458 | Point | | | | 459 +------------+-------------------------+----------+-----------------+ 460 | 1173 | TRANSPORT-SEGMENT-SID | 12 | | 461 | | | | | 462 +------------+-------------------------+----------+-----------------+ 464 Table 4: Prefix Attribute - Binding SID Sub-TLVs 466 The Transport segment TLV allows a node to advertise an transport 467 segment within a single IGP domain. The transport segment SID TLV 468 TRANSPORT-SEGMENT-TLV has the following format: 470 7.3.1 Transport Segment SID Sub-TLV 472 Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of 473 Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 474 transport segment label is defined as follows. 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Domain ID | Flags | Reserved | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Packet-Optical Label | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 ~ Transport Segment Sub TLVs (variable length) ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 where: 488 Type : TBD 490 Length: variable. 492 Domain ID: An identifier for the transport domain 494 Flags: 1 octet field of following flags: 495 V - Value flag. If set, then the optical label carries a value. 496 By default the flag is SET. 497 L - Local. Local Flag. If set, then the value/index carried by 498 the Adj-SID has local significance. By default the flag is SET. 500 0 1 2 3 4 5 6 7 501 +-+-+-+-+-+-+-+-+ 502 |V|L| 503 +-+-+-+-+-+-+-+-+ 505 Packet-Optical Label : according to the V and L flags, it contains 506 either: 508 * A 3 octet local label where the 20 rightmost bits are 509 used for encoding the label value. In this case the V and 510 L flags MUST be set. 512 * A 4 octet index defining the offset in the label space 513 advertised by this router. In this case V and L flags MUST 514 be unset. 516 Transport Segment Sub TLVs: TBD 518 Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair 519 of POG devices to represent multiple paths within the optical domain 521 8. Note about Transport Segments and Scalability 523 In most operational scenarios, there would be multiple, distinct paths 524 between the POGs. There is no requirement that every distinct path in 525 the optical domain be advertised as a separate transport segment. 526 Transport segments are designed to be consumed in the packet domain, 527 and the correspondence between transport segments and exact paths in 528 the optical domain are determined by their utility to the packet world. 529 Therefore, the number of transport segments is to be determined by the 530 individual packet-optical use-case. The number of actual paths in the 531 optical domain between the POG is expected to be large (counting the 532 number of active and passive devices in the optical network), it is 533 likely that multiple actual paths are to be advertised as one transport 534 segment. Of course, in the degenerate case, it is possible that there 535 is a one-to-one correspondence between an optical path and a transport 536 segment. Given this view of network operation, the POG is not expected 537 to handle a large number of transport segments (and identifiers). This 538 framework does leave open the possibility of handling a large number 539 of transport segments in future. For instance, a hierarchical 540 partitioning of the optical domain along with stacking of multiple 541 transport segment identifiers could be explored towards reducing 542 the overall number of transport segment identifiers. 544 9. Summary 546 The motivation for introducing a new type of segment - transport 547 segment - is to integrate transport networks with the segment routing 548 domain and expose characteristics of the transport domain into the 549 packet domain. An end-to-end path across packet and transport domains 550 can then be specified by attaching appropriate SIDs to the packet. 551 An instance of transport segments has been defined here for optical 552 networks, where paths between packet-optical gateway devices have been 553 abstracted using binding SIDs. Extensions to various protocols to 554 announce the transport segment have been proposed in this document. 556 10. Security Considerations 558 This document does not introduce any new security considerations. 560 11 IANA Considerations 562 This documents request allocation for the following TLVs and subTLVs. 564 11.1 PCEP 565 Packet-Optical Gateway capability of the device 567 Value Meaning Reference 568 -------- ------------------------------------ ----------------- 569 27 TRANSPORT-SR-PCE-CAPABILITY This document 571 A new type of TLV to accommodate a transport segment is defined 572 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 574 Value Description Reference 576 32 TRANSPORT-SR-PCEP-TLV This document 578 This document requests that a registry is created to manage the value 579 of the Binding Type field in the TRANSPORT-SR-PCEP TLV. 581 Value Description Reference 583 1 Transport Segment Label This document 585 11.2 BGP-LS 586 Node Attributes TLV: 588 Value Description Reference 590 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document 592 Prefix Attribute Binding SID SubTLV: 594 Value Description Reference 596 1173 TRANSPORT-SR-BGPLS-TLV This document 598 12 Acknowledgements 599 We would like to thank Peter Psenak, and Radhakrishna 600 Valiveti for their comments and review of this document. 602 13 References 604 13.1 Normative References 606 [I-D.ietf-spring-segment-routing] 607 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 608 and R. Shakir, "Segment Routing Architecture", draft-ietf- 609 spring-segment-routing-12 (work in progress), June 2017. 611 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 612 S. Ray, "North-Bound Distribution of Link-State and 613 Traffic Engineering (TE) Information Using BGP", RFC 7752, 614 DOI 10.17487/RFC7752, March 2016, 615 . 617 [I-D.sivabalan-pce-binding-label-sid] 618 Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., 619 Hardwick, J., and Dhody, D., "Carrying Binding Label/ 620 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 621 binding-label-sid-03 (work in progress), July 2017. 623 [I-D.ietf-pce-segment-routing] 624 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 625 and J. Hardwick, "PCEP Extensions for Segment Routing", 626 draft-ietf-pce-segment-routing-10 (work in progress), 627 October 2017. 629 [I-D.filsfils-spring-segment-routing-policy] 630 Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, 631 F., Lin, S., bogdanov@google.com, b., Horneffer, M., 632 Steinberg, D., Decraene, B., and S. Litkowski, "Segment 633 Routing Policy for Traffic Engineering", draft-filsfils- 634 spring-segment-routing-policy-01 (work in progress), July 635 2017. 637 13.2 Informative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 Authors' Addresses 646 Madhukar Anand 647 Infinera Corporation 648 169 W Java Dr, Sunnyvale, CA 94089 650 Email: manand@infinera.com 652 Sanjoy Bardhan 653 Infinera Corporation 654 169 W Java Dr, Sunnyvale, CA 94089 656 Email: sbardhan@infinera.com 658 Ramesh Subrahmaniam 659 Email: svr_fremont@yahoo.com 660 Jeff Tantsura 661 Email: jefftant.ietf@gmail.com 663 Utpal Mukhopadhyaya 664 Equinix Inc 665 1188 E. Arques, Sunnyvale, CA 94085 666 Email: umukhopadhyaya@equinix.com 668 Clarence Filsfils 669 Cisco Systems, Inc. 670 Brussels 671 BE 672 Email: cfilsfil@cisco.com