idnits 2.17.1 draft-anand-spring-poi-sr-00.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 25 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 156 has weird spacing: '...path as an op...' -- The document date (March 20, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ISO10589' is mentioned on line 296, but not defined == Missing Reference: 'I-D.ietf-ospf-ospfv3-lsa-extend' is mentioned on line 397, but not defined == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-ospfv3-segment-routing-extensions' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-ls-distribution' is defined on line 587, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-04 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-23) exists of draft-ietf-ospf-ospfv3-segment-routing-extensions-03 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 2 errors (**), 0 flaws (~~), 11 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 6 Expires: September 21, 2016 March 20, 2016 8 Packet-Optical Integration in Segment Routing 9 draft-anand-spring-poi-sr-00 11 Abstract 13 This document illustrates a way to integrate a new class of nodes and 14 links in segment routing to represent networks in an opaque way for 15 further extensibility of the link-state protocols that help with 16 segment routing. An instance of the opaque definition would be 17 optical networks that are typically transport centric. In the IP 18 centric network, this will help in defining a common control protocol 19 for packet optical integration that will include optical paths as 20 opaque 'segments' or sub-paths as an augmentation to the defined 21 extensions of segment routing. This opaque option defines a general 22 mechanism to allow for future extensibility of segment routing. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3 70 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 5 71 5. IS-IS extensions for supporting the opaque adjacency segment . 6 72 6. OSPF extensions for supporting the opaque adjacency segment . 8 73 7. OSPFv3 extensions for supporting the opaque adjacency 74 segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. BGP-LS extensions for supporting the opaque adjacency 76 segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 8.1 Link Attribute TLVs . . . . . . . . . . . . . . . . . . . . 11 78 8.2 Opaque Adjacency SID TLV . . . . . . . . . . . . . . . . . . 12 79 9. PCEP-LS extensions for supporting the opaque adjacency 80 segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 13.1 Normative References . . . . . . . . . . . . . . . . . . . 14 86 13.2 Informative References . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1 Introduction 91 Packet and optical transport networks have evolved independently with 92 different control plane mechanisms that have to be provisioned and 93 maintained separately. Consequently, coordinating packet and optical 94 networks for delivering services such as end-to-end traffic 95 engineering or failure response has proved challenging. To address 96 this challenge, a unified control and management paradigm that 97 provides an incremental path to complete packet-optical integration 98 while leveraging existing signaling and routing protocols in either 99 domains is needed. This document introduces such a paradigm based on 100 Segment Routing (SR) [I-D.ietf-spring-segment-routing]. 102 This document introduces a new type of segment, Opaque Adjacency 103 Segment. Opaque Adjacency Segment can be used to model abstracted 104 paths through the optical transport domain and integrate it with the 105 packet network for delivering end-to-end services. In addition, this 106 also introduces a notion of a Packet optical gateway (POG). These are 107 nodes in the network that map packet services to the optical domain 108 that originate and terminate these opaque adjacency segments. Given 109 an opaque adjacency, a POG will expand it to a path in the optical 110 transport network. 112 2. Reference Taxonomy 114 POG - Packet optical gateway Device 116 SR Edge Router - The Edge Router which is the first SR capable device 118 CE - Customer Edge Device that is outside of the SR domain 120 PCE - Path Computation Engine 122 Controller - A network controller 124 3. Use case - Packet Optical Integration 126 Many operators build and operate their networks that are both multi- 127 layer and multi-domain. Services are built around these layers and 128 domains to provide end-to-end services. Due to the nature of the 129 different domains, such as packet and optical, the management and 130 service creation has always been problematic and time consuming. With 131 segment routing, enabling a head-end node to select a path and embed 132 the information in the packet is a powerful construct that would be 133 used in the Packet Optical Gateways (POG). The path is usually 134 constructed for each domain that may be manually derived or through a 135 stateful PCE which is run specifically in that domain. 137 P1---------O1---------P2---------O2---------P3---------O3---------P4 139 Figure 1: Representation of a packet-optical path 141 In Figure 1 above, the nodes represent a packet optical network. P1, 142 P2, P3 and P4 are packet optical devices that are connected via 143 optical paths O1, O2 and O3. Nodes P1 and P4 are edge devices that 144 have customer facing devices (denoted as Border POGs) and P2 and P3 145 are core nodes (denoted as Transit POGs) in the network. A packet 146 service is established by specifying a path between P1 and P4. Note 147 that in defining this path, we will need to specify both the nodes 148 and the links that make up this service. POGs advertise themselves 149 along with their adjacencies and the domains they belong to. To 150 leverage segment routing to define the above service, the ingress 151 node P1 would append all outgoing packets in a SR header consisting 152 of the SIDs that constitute the path. In the packet domain this would 153 mean P1 would send its packets towards P4 using the segment list {P2, 154 P4}. The operator would need to use a different mechanism in the 155 optical domain to set up the optical paths denoted by O1, O2 and O3. 156 Each POG would announce the active optical path as an opaque 157 adjacency - for example, in the case of P1, the optical path O1 would 158 represent an optical path that includes the optical nodes Om and On 159 as shown on Figure 2. This path is not known to the packet SR domain 160 and is only relevant to the optical domain D between P1 and P2. A 161 PCE that is run in Domain D would be responsible for calculating path 162 O1. 164 |-----Om--------On-----| 166 P1----| (D) |------P2 168 |-----Ox---------Oy----| 170 Figure 2: POG with multiple optical paths through an optical domain 172 Similarly, the transit POGs P2 and P3 in Figure 1 would announce 173 opaque adjacencies O2 and O3. The border POG would include the 174 optical paths O1, O2 and O3 to the segment list for P1 to P4. The 175 expanded segment list would read as {O1, P2, O2, P3, O3, P4}. 177 There are potentially two locations for Borders POGs - one that has 178 last-mile access nodes and the other being Data Center Interconnect 179 nodes. The POGs that are in the core of the network which connect 180 with long haul optical networks are usually Transit POGs. 182 +------------------------+ 183 | | 184 +--------------+----' PCE or Controller |----+---------------+ 185 | | | | | | 186 | | +------------------------+ | | 187 | | | | 188 | | .-----. | | 189 | | ( ) | | 190 +-------+ +-------+ .--( )--. +-------+ +-------+ 191 | SR | |Packet | ( ) |Packet | | SR | 192 | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | 193 |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | 194 +---+.--+ +-------+ ( ) +-------+ +---+.--+ 195 | '--( )--' | 196 ,--+. ( ) ,-+-. 197 ( CE ) '-----' ( CE ) 198 `---' `---' 200 Figure 3. Reference Topology for Opaque Adjacency Segment 202 4. Mechanism overview 204 The current proposal assumes that the SR domains run standard IGP 205 protocols to discover the topology and distribute labels without any 206 modification. There are also no modifications to the control plane 207 mechanisms in the Optical transport domains. The mechanism for 208 supporting the opaque adjacency segment is as follows. 210 1. Firstly, the Packet Optical Gateway (POG) devices announce 211 themselves in the SR domain. This is indicated by advertising a new 212 SR node capability flag. The exact extensions to support this 213 capability are described in the subsequent sections of this 214 document. 216 2. Then, the POG devices announce paths to other POGs through the 217 optical transport domain as an opaque adjacency segment (opaque 218 adjacency SID) in the SR domain. The paths are announced with an 219 appropriate transit domain type, optical transport domain ID, and a 220 label to be used to bind to the opaque adjacency segment. The 221 appropriate IGP segment routing extensions to carry this information 222 is described in the subsequent sections of this document. 224 3. The opaque adjacency segment can also optionally be announced 225 with a set of attributes that characterizes the path in the optical 226 transport domain between the two POG devices. For instance, those 227 attributes could define the OTN mapping used (e.g., ODU4, 228 ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical 229 path protection schemes. 231 4. The POG device is also responsible for programming its 232 forwarding table to map every opaque adjacency label entry into an 233 appropriate forwarding action relevant in the optical domain, such as 234 mapping it to a label-switched path. 236 5. The opaque adjacency segment is communicated to the PCE or 237 Controller using extensions to BGP-LS or PCEP-LS as described in 238 subsequent sections of this document. 240 6. Finally, the PCE or Controller then uses the opaque adjacency 241 segment label to influence the path leaving the SR domain into the 242 optical domain, thereby defining the end-to-end path for a given 243 service. 245 5. IS-IS extensions for supporting the opaque adjacency segment 247 A new IS-IS sub-TLV is defined: the Opaque Adjacency Segment 248 Identifier sub-TLV (Opaque-Adj-SID sub-TLV). The Opaque-Adj-SID sub- 249 TLV is an optional sub-TLV carrying the opaque adjacency SID with 250 flags and fields that may be used, in future extensions of Segment 251 Routing, for carrying other types of Opaque Adjacency SIDs. 253 Multiple Opaque-Adj-SID sub-TLVs MAY be associated with a pair of 254 POG devices to represent multiple paths within the optical domain 255 with perhaps different characteristics. 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type | Length | Flags | Weight | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Domain ID |Opaque Sub Type| Reserved | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Remote POG System ID | 264 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Packet-Optical Label | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Where: 271 Type: TBD, suggested value 33 273 Length: variable. 275 Flags: 1 octet field of following flags: 276 V - Value flag. If set, then the packet-optical label carries 277 a value. By default the flag is SET. 278 L - Local. Local Flag. If set, then the value/index carried by 279 the Adj-SID has local significance. By default the flag is SET. 281 0 1 2 3 4 5 6 7 282 +-+-+-+-+-+-+-+-+ 283 |V|L| 284 +-+-+-+-+-+-+-+-+ 286 Other bits: Reserved. These MUST be zero when sent and are ignored 287 when received. 289 Weight: TBD 291 Domain ID: An identifier for the transport domain 293 Opaque Sub Type: TBD 295 Remote POG System-ID: 6 octets of IS-IS System-ID of length 296 "ID Length" as defined in [ISO10589]. 298 Packet-Optical Label : according to the V and L flags, it contains 299 either: 301 * A 3 octet local label where the 20 rightmost bits are 302 used for encoding the label value. In this case the V and 303 L flags MUST be set. 305 * A 4 octet index defining the offset in the label space 306 advertised by this router. In this case V and L flags MUST 307 be unset. 309 Further, to communicate the Packet-Optical Gateway capability of the 310 device, we introduce a new flag O in the SR Node Capabilities sub-TLV: 312 0 1 2 3 4 5 6 7 313 +-+-+-+-+-+-+-+-+ 314 |I|V|H|O| | 315 +-+-+-+-+-+-+-+-+ 317 I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions]. 318 O-Flag: If set, then the router is capable of performing Packet Optical 319 Gateway function. 321 6. OSPF extensions for supporting the opaque adjacency segment 323 A new OSPF sub-TLV is defined: the Opaque Adjacency Segment Identifier 324 sub-TLV (Opaque-Adj-SID sub-TLV). The Opaque-Adj-SID sub-TLV is an 325 optional sub-TLV of the Extended Link TLV carrying the opaque adjacency 326 SID with flags and fields that may be used, in future extensions of 327 Segment Routing, for carrying other types of Opaque Adjacency SIDs. 329 Multiple Opaque-Adj-SID sub-TLVs MAY be associated with a pair of 330 POG devices to represent multiple paths within the optical domain 331 with perhaps different characteristics. 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Flags | Reserved | MT-ID | Weight | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Domain ID |Opaque Sub Type| Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Remote POG Router-ID | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Packet-Optical Label | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 where: 348 Type: TBD, suggested value 3 350 Length: variable. 352 Flags: 1 octet field of following flags: 353 V - Value flag. If set, then the optical label carries a value. 354 By default the flag is SET. 355 L - Local. Local Flag. If set, then the value/index carried by 356 the Adj-SID has local significance. By default the flag is SET. 358 0 1 2 3 4 5 6 7 359 +-+-+-+-+-+-+-+-+ 360 |V|L| 361 +-+-+-+-+-+-+-+-+ 363 Other bits: Reserved. These MUST be zero when sent and are ignored 364 when received. 366 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 368 Weight: TBD 370 Domain ID: An identifier for the transport domain 372 Opaque Sub Type: TBD 374 Remote POG Router-ID: 4 octets of OSPF Router-ID 376 Packet-Optical Label : according to the V and L flags, it contains 377 either: 379 * A 3 octet local label where the 20 rightmost bits are 380 used for encoding the label value. In this case the V and 381 L flags MUST be set. 383 * A 4 octet index defining the offset in the label space 384 advertised by this router. In this case V and L flags MUST 385 be unset. 387 Further, to communicate the Packet-Optical Gateway capability of the 388 device, we introduce an new optical informational capability bit in the 389 Router Information capabilities TLV (as defined in [RFC4970]). 391 Bit-24 - Optical - If set, then the router is capable of performing 392 Packet Optical Gateway function. 394 7. OSPFv3 extensions for supporting the opaque adjacency segment 396 The Opaque-Adj-SID Sub-TLV is an optional Sub-TLV of the 397 Router-Link TLV as defined in [I-D.ietf-ospf-ospfv3-lsa-extend]. 398 It MAY appear multiple times in Router-Link TLV. 400 Multiple Opaque-Adj-SID sub-TLVs MAY be associated with a pair of 401 POG devices to represent multiple paths within the optical domain 402 with perhaps different characteristics. 404 The Opaque-Adj-SID Sub-TLV has the following format: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Flags | Weight | Reserved | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Domain ID |Opaque Sub Type| Reserved | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Remote POG Router-ID | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Packet-Optical Label | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 where: 422 Type: TBD, suggested value 6 424 Length: variable. 426 Flags: 1 octet field of following flags: 427 V - Value flag. If set, then the optical label carries a value. 428 By default the flag is SET. 429 L - Local. Local Flag. If set, then the value/index carried by 430 the Adj-SID has local significance. By default the flag is SET. 432 0 1 2 3 4 5 6 7 433 +-+-+-+-+-+-+-+-+ 434 |V|L| 435 +-+-+-+-+-+-+-+-+ 437 Other bits: Reserved. These MUST be zero when sent and are ignored 438 when received. 440 Weight: TBD 441 Domain ID: An identifier for the transport domain 443 Opaque Sub Type: TBD 445 Remote POG Router-ID: 4 octets of OSPFv3 Router-ID 447 Packet-Optical Label : according to the V and L flags, it contains 448 either: 450 * A 3 octet local label where the 20 rightmost bits are 451 used for encoding the label value. In this case the V and 452 L flags MUST be set. 454 * A 4 octet index defining the offset in the label space 455 advertised by this router. In this case V and L flags MUST 456 be unset. 458 Further, to communicate the Packet-Optical Gateway capability of the 459 device, we introduce an new optical informational capability bit in the 460 Router Information capabilities TLV (as defined in [RFC4970]). 462 Bit-24 - Optical - If set, then the router is capable of performing 463 Packet Optical Gateway function. 465 8. BGP-LS extensions for supporting the opaque adjacency segment 467 8.1 Link Attribute TLVs 468 The following new Link Attribute TLVs are defined: 470 +-----------+----------------------------+----------+---------------+ 471 | TLV Code | Description | Length | Section | 472 | Point | | | | 473 +-----------+----------------------------+----------+---------------+ 474 | 1101 | Opaque Adjacency Segment | variable | | 475 | | Identifier (Opq-Adj-SID)TLV| | | 476 +-----------+----------------------------+----------+---------------+ 478 Table 1: BGP-LS Link Attribute TLVs 480 These TLVs can ONLY be added to the Link Attribute associated with 481 the link whose local node originates the corresponding SR TLV. 483 The Opaque adjacency segment TLV allows a node to advertise an opaque 484 adjacency within a single IGP domain. 486 8.2 Opaque Adjacency SID TLV 487 The Opaque Adjacency SID (Opq-Adj-SID) TLV has the following format: 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Type | Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Flags | Weight | Reserved | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Domain ID |Opaque Sub Type| Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Remote POG System ID/Router-ID | 499 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Packet-Optical Label | 503 +---------------------------------------------------------------+ 505 Where: 507 Type: TBD, suggested value 1101. 509 Length: Variable. 511 Flags: 1 octet field of following flags as defined in the previous 512 sections for IS-IS and OSPF. 514 Weight: TBD. 516 Domain ID: An identifier for the optical transport domain 518 Opaque Sub Type : TBD 520 Remote POG Router-ID/System-ID: 4 octets of OSPF Router-ID or 6 Octets 521 of IS-IS System ID. 523 Packet-Optical Label: 4 octet field carrying the label as defined 524 in the previous sections for IS-IS and OSPF. 526 9. PCEP-LS extensions for supporting the opaque adjacency segment 528 Changes similar to BGP-LS are needed for supporting the opaque 529 adjacency segment in PCEP-LS. Details TBD. 531 10. Summary 533 The motivation for introducing an opaque adjacency segment that is 534 separate from an IGP adjacency segment is to distinguish between a 535 real IGP adjacency (which is typically a symmetric relationship 536 between the devices that share a route flooding domain), and a 537 relationship between devices in potentially two different domains such 538 as packet and optical domains with no real IGP adjacency. Further, 539 the opaque adjacency segment can carry optional information that is 540 of significance only in the optical domain, and hence, opaque, to 541 the IGPs. This is specifically useful if the optical domain is 542 bridging the same IGP domain, then, the POG can attach both the 543 adjacency SID and the opaque adjacency SID to influence the 544 end-to-end path in the packet and optical domains respectively. 546 11. Security Considerations 548 This document does not introduce any new security considerations. 550 12 IANA Considerations 552 TBD. 554 13 References 556 13.1 Normative References 558 [I-D.ietf-spring-segment-routing] 559 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 560 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 561 ietf-spring-segment-routing-04 (work in progress), July 562 2015. 564 [I-D.ietf-isis-segment-routing-extensions] 565 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 566 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 567 Extensions for Segment Routing", draft-ietf-isis-segment- 568 routing-extensions-05 (work in progress), June 2015. 570 [I-D.ietf-ospf-segment-routing-extensions] 571 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 572 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 573 Extensions for Segment Routing", draft-ietf-ospf-segment- 574 routing-extensions-05 (work in progress), June 2015. 576 [RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and 577 A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915, 578 . 580 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] 581 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 582 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 583 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- 584 segment-routing-extensions-03 (work in progress), June 585 2015. 587 [I-D.ietf-idr-ls-distribution] 588 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 590 Ray, "North-Bound Distribution of Link-State and TE 591 Information using BGP", draft-ietf-idr-ls-distribution-13 592 (work in progress), October 2015. 594 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 595 S. Shaffer, "Extensions to OSPF for Advertising Optional 596 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 597 2007, . 599 13.2 Informative References 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, 603 DOI 10.17487/RFC2119, March 1997, 604 . 606 Authors' Addresses 608 Madhukar Anand 609 Infinera Corporation 610 169 W Java Dr, Sunnyvale, CA 94089 612 Email: manand@infinera.com 614 Sanjoy Bardhan 615 Infinera Corporation 616 169 W Java Dr, Sunnyvale, CA 94089 618 Email: sbardhan@infinera.com 620 Ramesh Subrahmaniam 621 Infinera Corporation 622 169 W Java Dr, Sunnyvale, CA 94089 624 Email: RSubrahmaniam@@infinera.com