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