idnits 2.17.00 (12 Aug 2021) /tmp/idnits3547/draft-anand-spring-poi-sr-01.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 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 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 6, 2016) is 2145 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 250, but not defined == Missing Reference: 'I-D.draft-sivabalan-pce-binding-label-sid-01' is mentioned on line 626, but not defined == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'RFC4915' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-segment-routing-extensions' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'I-D.sivabalan-pce-binding-label-sid' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-segment-routing' is defined on line 722, but no explicit reference was found in the text == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 == Outdated reference: draft-ietf-isis-segment-routing-extensions has been published as RFC 8667 == Outdated reference: draft-ietf-ospf-segment-routing-extensions has been published as RFC 8665 == Outdated reference: draft-ietf-ospf-ospfv3-segment-routing-extensions has been published as RFC 8666 == Outdated reference: draft-ietf-idr-ls-distribution has been published as RFC 7752 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-07) exists of draft-sivabalan-pce-binding-label-sid-01 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 Summary: 2 errors (**), 0 flaws (~~), 17 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 Ramesh Subrahmaniam 5 Infinera Corporation 7 Jeff Tantsura 8 Individual 9 Expires: January 7, 2017 July 6, 2016 11 Packet-Optical Integration in Segment Routing 12 draft-anand-spring-poi-sr-01 14 Abstract 16 This document illustrates a way to integrate a new class of nodes and 17 links in segment routing to represent transport networks in an opaque 18 way into the segment routing domain. An instance of this class would 19 be optical networks that are typically transport centric. In the IP 20 centric network, this will help in defining a common control protocol 21 for packet optical integration that will include optical paths as 22 'transport segments' or sub-paths as an augmentation to the defined 23 extensions of segment routing. The transport segment option also 24 defines a general mechanism to allow for future extensibility of 25 segment routing into non-packet domains. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2016 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3 73 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 5 74 5. PCEP-LS extensions for supporting the transport segment . . . 6 75 6. OSPF extensions for supporting the transport segment . . . . . 7 76 7. OSPFv3 extensions for supporting the transport segment . . . . 9 77 8. IS-IS extensions for supporting the transport segment . . . . 10 78 9. BGP-LS extensions for supporting the transport segment . . . . 12 79 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 12.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 12.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 12.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 12.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 12.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 13.1 Normative References . . . . . . . . . . . . . . . . . . . 16 89 13.2 Informative References . . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1 Introduction 94 Packet and optical transport networks have evolved independently with 95 different control plane mechanisms that have to be provisioned and 96 maintained separately. Consequently, coordinating packet and optical 97 networks for delivering services such as end-to-end traffic 98 engineering or failure response has proved challenging. To address 99 this challenge, a unified control and management paradigm that 100 provides an incremental path to complete packet-optical integration 101 while leveraging existing signaling and routing protocols in either 102 domains is needed. This document introduces such a paradigm based on 103 Segment Routing (SR) [I-D.ietf-spring-segment-routing]. 105 This document introduces a new type of segment, Transport segment. 106 Transport segment can be used to model abstracted paths through the 107 optical transport domain and integrate it with the packet network for 108 delivering end-to-end services. In addition, this also introduces a 109 notion of a Packet optical gateway (POG). These are nodes in the 110 network that map packet services to the optical domain that originate 111 and terminate these transport segments. Given a transport segment, a 112 POG will expand it to a path in the optical transport network. 114 2. Reference Taxonomy 116 POG - Packet optical gateway Device 118 SR Edge Router - The Edge Router which is the ingress device 120 CE - Customer Edge Device that is outside of the SR domain 122 PCE - Path Computation Engine 124 Controller - A network controller 126 3. Use case - Packet Optical Integration 128 Many operators build and operate their networks that are both multi- 129 layer and multi-domain. Services are built around these layers and 130 domains to provide end-to-end services. Due to the nature of the 131 different domains, such as packet and optical, the management and 132 service creation has always been problematic and time consuming. With 133 segment routing, enabling a head-end node to select a path and embed 134 the information in the packet is a powerful construct that would be 135 used in the Packet Optical Gateways (POG). The path is usually 136 constructed for each domain that may be manually derived or through a 137 stateful PCE which is run specifically in that domain. 139 P1---------O1---------P2---------O2---------P3---------O3---------P4 141 Figure 1: Representation of a packet-optical path 143 In Figure 1 above, the nodes represent a packet optical network. P1, 144 P2, P3 and P4 are packet optical devices that are connected via 145 optical paths O1, O2 and O3. Nodes P1 and P4 are edge devices that 146 have customer facing devices (denoted as Border POGs) and P2 and P3 147 are core nodes (denoted as Transit POGs) in the network. A packet 148 service is established by specifying a path between P1 and P4. Note 149 that in defining this path, we will need to specify both the nodes 150 and the links that make up this service. POGs advertise themselves 151 along with their adjacencies and the domains they belong to. To 152 leverage segment routing to define the above service, the ingress 153 node P1 would append all outgoing packets in a SR header consisting 154 of the SIDs that constitute the path. In the packet domain this would 155 mean P1 would send its packets towards P4 using the segment list {P2, 156 P4}. The operator would need to use a different mechanism in the 157 optical domain to set up the optical paths denoted by O1, O2 and O3. 158 Each POG would announce the active optical path as a transport 159 segment - for example, in the case of P1, the optical path O1 would 160 represent an optical path that includes the optical nodes Om and On 161 as shown on Figure 2. This path is not known to the packet SR domain 162 and is only relevant to the optical domain D between P1 and P2. A 163 PCE that is run in Domain D would be responsible for calculating path 164 O1. 166 |-----Om--------On-----| 168 P1----| (D) |------P2 170 |-----Ox---------Oy----| 172 Figure 2: POG with multiple optical paths through an optical domain 174 Similarly, the transit POGs P2 and P3 in Figure 1 would announce 175 transport segments O2 and O3. The border POG would include the 176 optical paths O1, O2 and O3 to the segment list for P1 to P4. The 177 expanded segment list would read as {O1, P2, O2, P3, O3, P4}. 179 There are potentially two locations for Borders POGs - one that has 180 last-mile access nodes and the other being Data Center Interconnect 181 nodes. The POGs that are in the core of the network which connect 182 with long haul optical networks are usually Transit POGs. 184 +------------------------+ 185 | | 186 +--------------+----' PCE or Controller |----+---------------+ 187 | | | | | | 188 | | +------------------------+ | | 189 | | | | 190 | | .-----. | | 191 | | ( ) | | 192 +-------+ +-------+ .--( )--. +-------+ +-------+ 193 | SR | |Packet | ( ) |Packet | | SR | 194 | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | 195 |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | 196 +---+.--+ +-------+ ( ) +-------+ +---+.--+ 197 | '--( )--' | 198 ,--+. ( ) ,-+-. 199 ( CE ) '-----' ( CE ) 200 `---' `---' 202 Figure 3. Reference Topology for Transport Segment 204 4. Mechanism overview 206 The current proposal assumes that the SR domains run standard IGP 207 protocols to discover the topology and distribute labels without any 208 modification. There are also no modifications to the control plane 209 mechanisms in the Optical transport domains. The mechanism for 210 supporting the transport segment is as follows. 212 1. Firstly, the Packet Optical Gateway (POG) devices announce 213 themselves in the SR domain. This is indicated by advertising a new 214 SR node capability flag. The exact extensions to support this 215 capability are described in the subsequent sections of this 216 document. 218 2. Then, the POG devices announce paths to other POGs through the 219 optical transport domain as a transport segment (transport segment 220 binding SID) in the SR domain. The paths are announced with an 221 appropriate optical transport domain ID, and a label (Packet-Optical 222 Label) to be used to bind to the transport segment. The appropriate 223 IGP segment routing extensions to carry this information is described 224 in the subsequent sections of this document. 226 3. The transport segment can also optionally be announced with a 227 set of attributes that characterizes the path in the optical 228 transport domain between the two POG devices. For instance, those 229 attributes could define the OTN mapping used (e.g., ODU4, 230 ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical 231 path protection schemes. 233 4. The POG device is also responsible for programming its 234 forwarding table to map every transport segment label entry into an 235 appropriate forwarding action relevant in the optical domain, such as 236 mapping it to a label-switched path. 238 5. The transport segment is communicated to the PCE or Controller 239 using extensions to BGP-LS or PCEP-LS as described in subsequent 240 sections of this document. 242 6. Finally, the PCE or Controller then uses the transport segment 243 label to influence the path leaving the SR domain into the optical 244 domain, thereby defining the end-to-end path for a given service. 246 5. PCEP-LS extensions for supporting the transport segment 248 To communicate the Packet-Optical Gateway capability of the device, 249 we introduce a new PCEP capabilities TLV is defined as 250 follows(extensions to [I-D.draft-sivabalan-pce-segment-routing]): 252 Value Meaning Reference 253 -------- ------------------------------------ ----------------- 254 27 TRANSPORT-SR-PCE-CAPABILITY This document 256 A new type of TLV to accommodate a transport segment is defined 257 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 258 0 1 2 3 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Type | Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Binding Type (BT) | Domain ID | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Binding Value | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 ~ Transport Segment Sub TLVs (variable length) ~ 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 where: 272 Type: TBD, suggested value 32 274 Length: variable. 276 Binding Type: 0 or 1 as defined in 277 [I-D.draft-sivabalan-pce-binding-label-sid-01] 279 Domain ID: An identifier for the transport domain 281 Binding Value: is the transport segment label 283 Transport Segment Sub TLVs: TBD 285 IANA will be requested to allocate a new TLV type (recommended value 286 is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: 288 1 Transport Segment Label (This document) 290 6. OSPF extensions for supporting the transport segment 292 To communicate the Packet-Optical Gateway capability of the 293 device, we introduce an new optical informational capability bit in the 294 Router Information capabilities TLV (as defined in [RFC4970]). 296 Bit-24 - Optical - If set, then the router is capable of performing 297 Packet Optical Gateway function. 299 Further, a new OSPF sub-TLV (similar to the ERO SubTLV) of SID/Label 300 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 301 transport segment label is defined as follows. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Length | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Domain ID | Flags | Reserved | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Packet-Optical Label | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 ~ Transport Segment Sub TLVs (variable length) ~ 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 where: 316 Type : TBD, Suggested Value 9 318 Length: variable. 320 Domain ID: An identifier for the transport domain 322 Flags: 1 octet field of following flags: 323 V - Value flag. If set, then the optical label carries a value. 324 By default the flag is SET. 325 L - Local. Local Flag. If set, then the value/index carried by 326 the Adj-SID has local significance. By default the flag is SET. 328 0 1 2 3 4 5 6 7 329 +-+-+-+-+-+-+-+-+ 330 |V|L| 331 +-+-+-+-+-+-+-+-+ 333 Packet-Optical Label : according to the V and L flags, it contains 334 either: 336 * A 3 octet local label where the 20 rightmost bits are 337 used for encoding the label value. In this case the V and 338 L flags MUST be set. 340 * A 4 octet index defining the offset in the label space 341 advertised by this router. In this case V and L flags MUST 342 be unset. 344 Transport Segment Sub TLVs: TBD 346 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 347 of POG devices to represent multiple paths within the optical domain 349 7. OSPFv3 extensions for supporting the transport segment 351 To communicate the Packet-Optical Gateway capability of the 352 device, we introduce an new optical informational capability bit in the 353 Router Information capabilities TLV (as defined in [RFC4970]). 355 Bit-24 - Optical - If set, then the router is capable of performing 356 Packet Optical Gateway function. 358 Further, a new OSPFv3 sub-TLV similar to the ERO SubTLV) of SID/Label 359 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 360 transport segment label is defined as follows. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Length | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Domain ID | Flags | Reserved | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Packet-Optical Label | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 ~ Transport Segment Sub TLVs (variable length) ~ 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 where: 376 Type : TBD,Suggested Value 12 378 Length: variable. 380 Domain ID: An identifier for the transport domain 382 Flags: 1 octet field of following flags: 383 V - Value flag. If set, then the optical label carries a value. 384 By default the flag is SET. 385 L - Local. Local Flag. If set, then the value/index carried by 386 the Adj-SID has local significance. By default the flag is SET. 388 0 1 2 3 4 5 6 7 389 +-+-+-+-+-+-+-+-+ 390 |V|L| 391 +-+-+-+-+-+-+-+-+ 393 Packet-Optical Label : according to the V and L flags, it contains 394 either: 396 * A 3 octet local label where the 20 rightmost bits are 397 used for encoding the label value. In this case the V and 398 L flags MUST be set. 400 * A 4 octet index defining the offset in the label space 401 advertised by this router. In this case V and L flags MUST 402 be unset. 404 Transport Segment Sub TLVs: TBD 406 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 407 of POG devices to represent multiple paths within the optical domain 409 8. IS-IS extensions for supporting the transport segment 411 To communicate the Packet-Optical Gateway capability of the device, we 412 introduce a new flag O in the SR Node Capabilities sub-TLV: 414 0 1 2 3 4 5 6 7 415 +-+-+-+-+-+-+-+-+ 416 |I|V|H|O| | 417 +-+-+-+-+-+-+-+-+ 419 I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions] 421 O-Flag: If set, then the router is capable of performing Packet 422 Optical Gateway function. 424 Further, a new IS-IS sub-TLV (similar to the ERO SubTLV) of SID/Label 425 Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 426 transport segment label is defined as follows. 428 First, we define the O flag in the SID/Label Binding TLV 430 0 1 2 3 4 5 6 7 431 +-+-+-+-+-+-+-+-+ 432 |F|M|S|D|A|O| | 433 +-+-+-+-+-+-+-+-+ 434 F, M, S, D, and A flags: are defined in [I-D.ietf-isis-segment-routing 435 -extensions] 436 O-Flag: If set, then the F flag, Range, Prefix Length FEC Prefix, must 438 be ignored in the SID/Label Binding TLV 440 Secondly, we define the SubTLV of the SID/Label Binding Sub-TLV: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type | Length | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Domain ID | Flags | Reserved | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Packet-Optical Label | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 ~ Transport Segment Sub TLVs (variable length) ~ 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 where: 456 Type : TBD, Suggested Value 151 458 Length: variable. 460 Domain ID: An identifier for the transport domain 462 Flags: 1 octet field of following flags: 463 V - Value flag. If set, then the optical label carries a value. 464 By default the flag is SET. 465 L - Local. Local Flag. If set, then the value/index carried by 466 the Adj-SID has local significance. By default the flag is SET. 468 0 1 2 3 4 5 6 7 469 +-+-+-+-+-+-+-+-+ 470 |V|L| 471 +-+-+-+-+-+-+-+-+ 473 Packet-Optical Label : according to the V and L flags, it contains 474 either: 476 * A 3 octet local label where the 20 rightmost bits are 477 used for encoding the label value. In this case the V and 478 L flags MUST be set. 480 * A 4 octet index defining the offset in the label space 481 advertised by this router. In this case V and L flags MUST 482 be unset. 484 Transport Segment Sub TLVs: TBD 486 Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair 487 of POG devices to represent multiple paths within the optical domain 488 with perhaps different characteristics. 490 9. BGP-LS extensions for supporting the transport segment 492 9.1 Node Attribuites TLV 494 To communicate the Packet-Optical Gateway capability of the 495 device, we introduce an new optical informational capability 496 the following new Node Attribute TLV is defined: 498 +-----------+----------------------------+----------+---------------+ 499 | TLV Code | Description | Length | Section | 500 | Point | | | | 501 +-----------+----------------------------+----------+---------------+ 502 | 1172 | SR-Optical-Node-Capability | variable | | 503 | | TLV | | | 504 +-----------+----------------------------+----------+---------------+ 506 Table 1: Node Attribute TLVs 508 These TLVs can ONLY be added to the Node Attribute associated with 509 the node NLRI that originates the corresponding SR TLV. 511 9.2 SR-Optical-Node-Capability TLV 513 The SR Capabilities sub-TLV has following format: 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Type | Length | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Flags | RESERVED | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 where: 525 Type : TBD, Suggested Value 1157 526 Length: variable. 528 Flags: The Flags field currently has only one bit defined. If the bit 529 is set it has the capability of an Packet Optical Gateway. 531 9.3 Prefix Attribute TLVs 532 The following Prefix Attribute Binding SID Sub-TLVs have been added: 534 +------------+-------------------------+----------+-----------------+ 535 | TLV Code | Description | Length | Section | 536 | Point | | | | 537 +------------+-------------------------+----------+-----------------+ 538 | 1173 | TRANSPORT-SEGMENT-SID | 12 | | 539 | | | | | 540 +------------+-------------------------+----------+-----------------+ 542 Table 4: Prefix Attribute - Binding SID Sub-TLVs 544 The Transport segment TLV allows a node to advertise an transport 545 segment within a single IGP domain. The transport segment SID TLV 546 TRANSPORT-SEGMENT-TLV has the following format: 548 9.3.1 Transport Segment SID Sub-TLV 550 Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of 551 Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the 552 transport segment label is defined as follows. 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type | Length | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Domain ID | Flags | Reserved | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Packet-Optical Label | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 ~ Transport Segment Sub TLVs (variable length) ~ 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 where: 566 Type : TBD 568 Length: variable. 570 Domain ID: An identifier for the transport domain 571 Flags: 1 octet field of following flags: 572 V - Value flag. If set, then the optical label carries a value. 573 By default the flag is SET. 574 L - Local. Local Flag. If set, then the value/index carried by 575 the Adj-SID has local significance. By default the flag is SET. 577 0 1 2 3 4 5 6 7 578 +-+-+-+-+-+-+-+-+ 579 |V|L| 580 +-+-+-+-+-+-+-+-+ 582 Packet-Optical Label : according to the V and L flags, it contains 583 either: 585 * A 3 octet local label where the 20 rightmost bits are 586 used for encoding the label value. In this case the V and 587 L flags MUST be set. 589 * A 4 octet index defining the offset in the label space 590 advertised by this router. In this case V and L flags MUST 591 be unset. 593 Transport Segment Sub TLVs: TBD 595 Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair 596 of POG devices to represent multiple paths within the optical domain 598 10. Summary 600 The motivation for introducing a new type of segment - transport 601 segment - is to integrate transport networks with the segment routing 602 domain and expose characteristics of the transport domain into the 603 packet domain. An end-to-end path across packet and transport domains 604 can then be specified by attaching appropriate SIDs to the packet. 605 An instance of transport segments has been defined here for optical 606 networks, where paths between packet-optical gateway devices has been 607 abstracted using binding SIDs. Extensions to various protocols to 608 announce the transport segment have been proposed in this document. 610 11. Security Considerations 612 This document does not introduce any new security considerations. 614 12 IANA Considerations 616 This documents request allocation for the following TLVs and subTLVs. 618 12.1 PCEP 619 Packet-Optical Gateway capability of the device 621 Value Meaning Reference 622 -------- ------------------------------------ ----------------- 623 27 TRANSPORT-SR-PCE-CAPABILITY This document 625 A new type of TLV to accommodate a transport segment is defined 626 by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 628 Value Description Reference 630 32 TRANSPORT-SR-PCEP-TLV This document 632 This document requests that a registry is created to manage the value 633 of the Binding Type field in the TRANSPORT-SR-PCEP TLV. 635 Value Description Reference 637 1 Transport Segment Label This document 639 12.2 OSPF 640 Transport-Segment SubTLV of OSPF Extended Prefix LSA 642 Value Description Reference 644 9 TRANSPORT-SR-OSPF-SUBTLV This document 646 12.3 OSPFv3 647 Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry 649 Value Description Reference 651 12 TRANSPORT-SR-OSPFv3-SUBTLV This document 653 12.4 IS-IS 654 Transport-Segment SubTLV of Segment Identifier / Label Binding TLV 655 Value Description Reference 657 151 TRANSPORT-SR-ISIS-SUBTLV This document 659 12.5 BGP-LS 660 Node Attributes TLV: 662 Value Description Reference 664 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document 666 Prefix Attribute Binding SID SubTLV: 668 Value Description Reference 670 1173 TRANSPORT-SR-BGPLS-TLV This document 672 13 References 674 13.1 Normative References 676 [I-D.ietf-spring-segment-routing] 677 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 678 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 679 ietf-spring-segment-routing-04 (work in progress), July 680 2015. 682 [I-D.ietf-isis-segment-routing-extensions] 683 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 684 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 685 Extensions for Segment Routing", draft-ietf-isis-segment- 686 routing-extensions-05 (work in progress), June 2015. 688 [I-D.ietf-ospf-segment-routing-extensions] 689 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 690 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 691 Extensions for Segment Routing", draft-ietf-ospf-segment- 692 routing-extensions-05 (work in progress), June 2015. 694 [RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and 695 A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915, 696 . 698 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 699 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 700 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 701 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 702 segment-routing-extensions-03 (work in progress), June 703 2015. 705 [I-D.ietf-idr-ls-distribution] 706 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 707 Ray, "North-Bound Distribution of Link-State and TE 708 Information using BGP", draft-ietf-idr-ls-distribution-13 709 (work in progress), October 2015. 711 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 712 S. Shaffer, "Extensions to OSPF for Advertising Optional 713 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 714 2007, . 716 [I-D.sivabalan-pce-binding-label-sid] 717 Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., 718 Hardwick, J., and M. Nanduri, "Carrying Binding Label/ 719 Segment-ID in PCE-based Networks.", draft-sivabalan-pce- 720 binding-label-sid-01 (work in progress), March 2016. 722 [I-D.ietf-pce-segment-routing] 723 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 724 Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, 725 "PCEP Extensions for Segment Routing", draft-ietf-pce- 726 segment-routing-07 (work in progress), March 2016. 728 13.2 Informative References 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, 732 DOI 10.17487/RFC2119, March 1997, 733 . 735 Authors' Addresses 737 Madhukar Anand 738 Infinera Corporation 739 169 W Java Dr, Sunnyvale, CA 94089 740 Email: manand@infinera.com 742 Sanjoy Bardhan 743 Infinera Corporation 744 169 W Java Dr, Sunnyvale, CA 94089 746 Email: sbardhan@infinera.com 748 Ramesh Subrahmaniam 749 Infinera Corporation 750 169 W Java Dr, Sunnyvale, CA 94089 752 Email: RSubrahmaniam@@infinera.com 754 Jeff Tantsura 756 Email: jefftant.ietf@gmail.com