SPRING Working Group Madhukar Anand Internet-Draft Sanjoy Bardhan Intended Status: InformationalRamesh SubrahmaniamInfinera Corporation Ramesh Subrahmaniam Individual Jeff Tantsura Individual Utpal Mukhopadhyaya Equinix Inc Clarence Filsfils Cisco Systems, Inc. Expires:December 28, 2017 June 26,May 18, 2018 November 14, 2017 Packet-Optical Integration in Segment Routingdraft-anand-spring-poi-sr-03draft-anand-spring-poi-sr-04 Abstract This document illustrates a way to integrate a new class of nodes and links in segment routing to represent transport networks in an opaque way into the segment routing domain. An instance of this class would be optical networks that are typically transport centric. In the IP centric network, this will help in defining a common control protocol for packet optical integration that will include optical paths as 'transport segments' or sub-paths as an augmentation tothe defined extensions of segment routing.packet paths. The transport segment option also defines a general mechanism to allow for future extensibility of segment routing into non-packet domains. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4 3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5 4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8 5.PCEP-LS extensions for supporting the transport segmentTransport Segments as SR Policy . . .8 6. OSPF extensions for supporting the transport segment. . . . .10 7. OSPFv3 extensions for supporting the transport segment. . . .11 8. IS-IS. . . 9 6. PCEP extensions for supporting the transport segment . . . .12 9.. 10 7. BGP-LS extensions for supporting the transport segment . . . .14 10.11 8. Note about Transport Segments and Scalability . . . . . . . .17 11.. 13 9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .17 12.. 14 10. Security Considerations . . . . . . . . . . . . . . . . . . .17 1314 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . .17 13.114 11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . .18 13.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.4 IS-IS . . . .14 11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . .18 13.5 BGP-LS. . . 15 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .18 1415 13 References . . . . . . . . . . . . . . . . . . . . . . . . . .19 14.115 13.1 Normative References . . . . . . . . . . . . . . . . . . .19 14.215 13.2 Informative References . . . . . . . . . . . . . . . . . .2016 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .2016 1 Introduction Packet and optical transport networks have evolved independently with different control plane mechanisms that have to be provisioned and maintained separately. Consequently, coordinating packet and optical networks for delivering services such as end-to-end traffic engineering or failure response has proved challenging. To address this challenge, a unified control and management paradigm that provides an incremental path to complete packet-optical integration while leveraging existing signaling and routing protocols in either domains is needed. This document introduces such a paradigm based on Segment Routing (SR) [I-D.ietf-spring-segment-routing]. This document introduces a new type of segment, Transportsegment.segment, as a special case of SR traffic engineering (SR-TE) policy [Type 1, Sec 5. I-D.filsfils-spring-segment-routing-policy]. Specifically, the structure of SR-TE policy and constraints associated in the transport network are different from those outlined for the packet networks. Transport segment can be used to model abstracted paths through the optical transport domain and integrate it with the packet network for delivering end-to-end services. In addition, this also introduces a notion of a Packet optical gateway (POG). These are nodes in the network that map packet services to the optical domain that originate and terminate these transport segments. Given a transport segment, a POG will expand it to a path in the optical transport network. A POG can be viewed as SR traffic engineering policy headend. The concept of POG introduced here allows for multiple instantiations of the concept. In one case, the packet device is distinct from the optical transport device, and the POG is a logical entity that spans these two devices. In this case, the POG functionality is achieved with the help of external coordination between the packet and optical devices. In another case, the packet and optical components are integrated into one physical device, and the co-ordination required for functioning of the POG is performed by this integrated device. It must be noted that in either case, it is the packet/optical data plane that is either disaggregated or integrated. Control of the devices can be logically centralized or distributed in either scenario. The focus of this document is to define the logical functions of a POG without going into the exact instantiations of the concept. 2. Reference Taxonomy POG - Packet optical gateway Device SR Edge Router - The Edge Router which is the ingress device CE - Customer Edge Device that is outside of the SR domain PCE - Path Computation Engine Controller - A network controller 3. Use case - Packet Optical Integration Many operators build and operate their networks that are both multi- layer and multi-domain. Services are built around these layers and domains to provide end-to-end services. Due to the nature of the different domains, such as packet and optical, the management and service creation has always been problematic and time consuming. With segment routing, enabling a head-end node to select a path and embed the information in the packet is a powerful construct that would be used in the Packet Optical Gateways (POG). The path is usually constructed for each domain that may be manually derived or through a stateful PCE which is run specifically in that domain. P5 P1 _ .-'-._ ,'P4 `._ .-' `-. ,' `. _.-' `-._ ,' `-. .-' `-. ,' P2`.-'--------------------------`-.- P3 |\ /| | \ / | Packet ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, | \ / | | \ / | Transport | \ / | |................../................./ | | ,'O2 O3`. | | ,' `. | |,'`. |`.| O1\ | O4 \ ,' \ ,' .......................- O6 O5 Figure 1: Representation of a packet-optical path In Figure 1 above, the nodes represent a packet optical network. P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that communicate with other packet devices and also with the devices in the optical transport domain. In defining alink in the packet domainpath between nodes P2 and P3, we will need to specifyboththe nodes and the links in both the packet and optical transportdomain that establish this link.domains. To leverage segment routing to define a service between P1 and P4, the ingress node P1 would append all outgoing packets in a SR header consisting of the SIDs that constitute the path. In the packet domain this would mean P1 would send its packets towards P4 using a segment list {P2, P3, P4} or {P2, P5, P3, P4} as the case may be. The operator would need to use a different mechanism in the optical domain to set up the optical paths comprising the nodes O1, O2 and O3. Each POG would announce the active optical path as a transport segment - for example, the optical path {O1, O2, O3} could be represented as a label Om and the optical path {O2, O3} could be represented as a transport label On. Both Om and On will be advertised by Packet nodeP1.P2. These paths are not known to the packet SR domain and is only relevant to the optical domain D between P2 and P3. A PCE that is run in Domain D would be responsible for calculating paths corresponding to label Om and On. The expanded segment list would read as {P2, Om, P3, P4} or {P2, On, P3, P4}. It is to be noted that there are other possible paths between P2 and P3 in the optical domain involving optical nodes O5, O6, and O4. Thereis no requirement that every pathmay be multiple optical paths between P2 and P3 corresponding to multiple SR policies. For example, some optical paths can berepresented as transport segments.low-cost, some are low-latency, and some others can be high-bandwidth paths. Transport segments for all these candidate viable alternative paths may be generated statically or dynamically.They may be pre-computed or may be generated on the fly when a customer at node P1 requests a service towards node P4. A discussion on transport segments and scalability can be found in Section10.8. Use-case examples of transport segments. 1. Consider the scenario where there are multiple fibers between two packet end points. The network operator may choose to route packet traffic on the first fiber, and reserve the second fiber onlytofor maintenance or low priority traffic. 2. As a second use-case, consider the case where the packet end points are connected by optical transport provided by two different service providers. The packet operator wants to preferentially route traffic over one of the providers and use the second provider as a backup. 3. Finally, let the packet end points be connected by optical paths thatlie inmay span multiple optical domains i.e. differentgeographies.administrative control. For instance, one optical transport path may lie completely in one country while the other optical transport path transits another country. Weather, tariffs, security considerations and other factors may determine how the packet operator wants to route different types of traffic on this network. All of the above use-cases can be supported by first mapping distinct optical transport paths to different transport segments and then, depending on the need, affixing appropriate transport segment identifier to the specific packet to route it appropriately through the transport domain. +------------------------+ | | +--------------+----' PCE or Controller |----+---------------+ | | | | | | | | +------------------------+ | | | | | | | | .-----. | | | | ( ) | | +-------+ +-------+ .--( )--. +-------+ +-------+ | SR | |Packet | ( ) |Packet | | SR | | Edge | |Optical|-( Optical Transport )_ |Optical| | Edge | |Router | ... |Gateway| ( Domain ) |Gateway| ... |Router | +---+.--+ +-------+ ( ) +-------+ +---+.--+ | '--( )--' | ,--+. ( ) ,-+-. ( CE ) '-----' ( CE ) `---' `---' Figure 3. Reference Topology for Transport Segment Mechanism 4. Mechanism overview The current proposal assumes that the SR domains run standardIGPprotocols without any modification to discover the topology and distributelabels without any modification.labels. There are also no modificationstonecessary in the control plane mechanisms in theOpticaloptical transport domains. The only requirement of a transport segment is that the optical path be setup before they are announced to the packet network. For example, the optical paths may be setup using a domain-specific controller or a PCE based on requirements from the packet domain (such as bandwidth, QoS, latency andcost).cost) taking into consideration the constraints in the optical network. The mechanism for supporting the transport segmentin the packet domainis as follows. 1. Firstly, the Packet Optical Gateway (POG) devicesannounce themselvesare announced in theSRpacket domain. This is indicated by advertising a new SR node capability flag. The exact extensions to support this capability are described in the subsequent sections of this document. 2. Then, the POG devices announce candidate optical transport pathstobetween that POG (Source POG) and other POGsthrough the optical transport domain as a transport segment (transport segment binding SID)(Destination POG) via appropriate mechanisms in theSRpacket domain. The paths are announced with an appropriate optical transport domainID,ID and alabel (Packet-Optical Label) to be used to bind toBinding SID representing the transportsegment.segment from a source POG to a destination POG. The appropriateIGP segment routingprotocol-specific extensions to carrythis information ispath characteristics and Binding SID corresponding to a optical path are described in the subsequent sections of this document.3. The3.The transportsegmentSR policy can also optionally be announced with a set of attributes that characterizes the path in the optical transport domain between the two POG devices. For instance, thoseattributescould define theOTN mapping used (e.g., ODU4, ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5),path attributes such as path identifier, latency, bandwidth, quality, directionality, or optical path protection schemes. These attributes can be used to determine the "color" of the SR-TE policy in the tuple <Source POG, Destination POG, color> used to prioritize different candidate paths between the POGs. 4. The POG device is also responsible for programming its forwarding table to map every transport segmentlabelBinding SID entry into an appropriate forwarding action relevant in the optical domain, such as mapping it to a optical label-switched path. 5. The transportsegmentSR policy is communicated to the PCE or Controller using extensions to BGP-LS orPCEP-LSPCEP as described in subsequent sections of this document. 6. Finally, the PCE or Controller in the packet domain then uses the transport segmentlabelbinding SID in the overall SR policy to influence the pathleavingtraversed by theSR domain intopacket in the optical domain, thereby defining the end-to-end path for a given service. In the next few sections, we outline a few representative protocol specific extensions to carry the transport segment. 5.PCEP-LSTransport Segments as SR Policy The Segment Routing Traffic Engineering (SRTE) [I-D.filsfils-spring- segment-routing-policy] process installs the transport segment SR policy in the forwarding plane of the POG. The Transport SR policy is identified by using a transport segment Binding SID. Corresponding to each transport segment Binding SID, the SRTE process MAY learn about multiple candidate paths. The SRTE-DB includes information about the candidate paths including optical domain, topology and path characteristics. All of the information can be learned from different sources including but not limited to: Netconf/Restconf, PCEP and BGP- LS. The information model for Transport SR policy is as follows: Transport SR Policy FO1 Candidate-paths path preference 200 (selected) BSID1 path preference 100 BSID2 path preference 100 BSID3 path preference 50 BSID4 A transport SR policy is identified through the tuple <Source POG, Destination POG, color>. Each TSR policy is associated with one or more candidate paths, each of them associated with a (locally) unique Binding SID and a path preference. For each transport SR policy, the candidate path with the highest path preference (at most one) is selected and used for forwarding traffic that is being steered onto that policy. When candidate paths change (or a new candidate path is set up), the path selection process can be re-executed. The validity of each path is to be verified by the POG before announcement in the packet domain. If there are no valid paths, then the transport SR policy is deemed invalid. The allocation of BSID to a path can include dynamic, explicit or generic allocation strategies as discussed in [I-D.filsfils-spring- segment-routing-policy]. We discuss PCEP and BGP-LS specific extensions in the subsequent section. 6. PCEP extensions for supporting the transport segment To communicate the Packet-Optical Gateway capability of the device, we introduce a new PCEP capabilities TLV is defined as follows(extensions to [I-D.draft-sivabalan-pce-segment-routing]): Value Meaning Reference -------- ------------------------------------ ----------------- 27 TRANSPORT-SR-PCE-CAPABILITY This document A new type of TLV to accommodate a transport segment is defined by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Type (BT) | Domain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport Segment Sub TLVs (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD, suggested value 32 Length: variable. Binding Type: 0 or 1 as defined in [I-D.draft-sivabalan-pce-binding-label-sid-01] Domain ID: An identifier for the transport domain Binding Value: is the transport segment label Transport Segment Sub TLVs: TBD IANA will be requested to allocate a new TLV type (recommended value is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document: 1 Transport Segment Label (This document)6. OSPF extensions for supporting the transport segment To communicate the Packet-Optical Gateway capability of the device, we introduce an new optical informational capability bit in the Router Information capabilities TLV (as defined in [RFC4970]). Bit-24 - Optical - If set, then the router is capable of performing Packet Optical Gateway function. Further, a new OSPF sub-TLV (similar to the ERO SubTLV) of SID/Label Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the transport segment label is defined as follows. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain ID | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet-Optical Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport Segment Sub TLVs (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type : TBD, Suggested Value 9 Length: variable. Domain ID: An identifier for the transport domain Flags: 1 octet field of following flags: V - Value flag. If set, then the optical label carries a value. By default the flag is SET. L - Local. Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L| +-+-+-+-+-+-+-+-+ Packet-Optical Label : according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the label space advertised by this router. In this case V and L flags MUST be unset. Transport Segment Sub TLVs: TBD Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair of POG devices to represent multiple paths within the optical domain7.OSPFv3 extensions for supporting the transport segment To communicate the Packet-Optical Gateway capability of the device, we introduce an new optical informational capability bit in the Router Information capabilities TLV (as defined in [RFC4970]). Bit-24 - Optical - If set, then the router is capable of performing Packet Optical Gateway function. Further, a new OSPFv3 sub-TLV similar to the ERO SubTLV) of SID/Label Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the transport segment label is defined as follows. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain ID | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet-Optical Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport Segment Sub TLVs (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type : TBD,Suggested Value 12 Length: variable. Domain ID: An identifier for the transport domain Flags: 1 octet field of following flags: V - Value flag. If set, then the optical label carries a value. By default the flag is SET. L - Local. Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L| +-+-+-+-+-+-+-+-+ Packet-Optical Label : according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the label space advertised by this router. In this case V and L flags MUST be unset. Transport Segment Sub TLVs: TBD Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair of POG devices to represent multiple paths within the optical domain 8. IS-IS extensions for supporting the transport segment To communicate the Packet-Optical Gateway capability of the device, we introduce a new flag O in the SR Node Capabilities sub-TLV: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |I|V|H|O| | +-+-+-+-+-+-+-+-+ I, V, H flags are defined in [I-D.ietf-isis-segment-routing-extensions] O-Flag: If set, then the router is capable of performing Packet Optical Gateway function. Further, a new IS-IS sub-TLV (similar to the ERO SubTLV) of SID/Label Binding Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the transport segment label is defined as follows. First, we define the O flag in the SID/Label Binding TLV 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|M|S|D|A|O| | +-+-+-+-+-+-+-+-+ F, M, S, D, and A flags: are defined in [I-D.ietf-isis-segment-routing -extensions] O-Flag: If set, then the F flag, Range, Prefix Length FEC Prefix, must be ignored in the SID/Label Binding TLV Secondly, we define the SubTLV of the SID/Label Binding Sub-TLV: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain ID | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet-Optical Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport Segment Sub TLVs (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type : TBD, Suggested Value 151 Length: variable. Domain ID: An identifier for the transport domain Flags: 1 octet field of following flags: V - Value flag. If set, then the optical label carries a value. By default the flag is SET. L - Local. Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L| +-+-+-+-+-+-+-+-+ Packet-Optical Label : according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the label space advertised by this router. In this case V and L flags MUST be unset. Transport Segment Sub TLVs: TBD Multiple TRANSPORT-SEGMENT-BINDING-SUBTLV MAY be associated with a pair of POG devices to represent multiple paths within the optical domain with perhaps different characteristics. 9.BGP-LS extensions for supporting the transport segment9.17.1 Node Attribuites TLV To communicate the Packet-Optical Gateway capability of the device, we introduce an new optical informational capability the following new Node Attribute TLV is defined: +-----------+----------------------------+----------+---------------+ | TLV Code | Description | Length | Section | | Point | | | | +-----------+----------------------------+----------+---------------+ | 1172 | SR-Optical-Node-Capability | variable | | | | TLV | | | +-----------+----------------------------+----------+---------------+ Table 1: Node Attribute TLVs These TLVs can ONLY be added to the Node Attribute associated with the node NLRI that originates the corresponding SR TLV.9.27.2 SR-Optical-Node-Capability TLV The SR Capabilities sub-TLV has following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type : TBD, Suggested Value 1157 Length: variable. Flags: The Flags field currently has only one bit defined. If the bit is set it has the capability of an Packet Optical Gateway. 9.3 Prefix Attribute TLVs The following Prefix Attribute Binding SID Sub-TLVs have been added: +------------+-------------------------+----------+-----------------+ | TLV Code | Description | Length | Section | | Point | | | | +------------+-------------------------+----------+-----------------+ | 1173 | TRANSPORT-SEGMENT-SID | 12 | | | | | | | +------------+-------------------------+----------+-----------------+ Table 4: Prefix Attribute - Binding SID Sub-TLVs The Transport segment TLV allows a node to advertise an transport segment within a single IGP domain. The transport segment SID TLV TRANSPORT-SEGMENT-TLV has the following format:9.3.17.3.1 Transport Segment SID Sub-TLV Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the transport segment label is defined as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain ID | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet-Optical Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Transport Segment Sub TLVs (variable length) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type : TBD Length: variable. Domain ID: An identifier for the transport domain Flags: 1 octet field of following flags: V - Value flag. If set, then the optical label carries a value. By default the flag is SET. L - Local. Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L| +-+-+-+-+-+-+-+-+ Packet-Optical Label : according to the V and L flags, it contains either: * A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags MUST be set. * A 4 octet index defining the offset in the label space advertised by this router. In this case V and L flags MUST be unset. Transport Segment Sub TLVs: TBD Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair of POG devices to represent multiple paths within the optical domain10.8. Note about Transport Segments and Scalability In most operational scenarios, there would be multiple, distinct paths between the POGs. There is no requirement that every distinct path in the optical domain be advertised as a separate transport segment. Transport segments are designed to be consumed in the packet domain, and the correspondence between transport segments and exact paths in the optical domain are determined by their utility to the packet world. Therefore, the number of transport segments is to be determined by the individual packet-optical use-case. The number of actual paths in the optical domain between the POG is expected to be large (counting the number of active and passive devices in the optical network), it is likely that multiple actual paths are to be advertised as one transport segment. Of course, in the degenerate case, it is possible that there is a one-to-one correspondence between an optical path and a transport segment. Given this view of network operation, the POG is not expected to handle a large number of transport segments (and identifiers). This framework does leave open the possibility of handling a large number of transport segments in future. For instance, a hierarchical partitioning of the optical domain along with stacking of multiple transport segment identifiers could be explored towards reducing the overall number of transport segment identifiers.11.9. Summary The motivation for introducing a new type of segment - transport segment - is to integrate transport networks with the segment routing domain and expose characteristics of the transport domain into the packet domain. An end-to-end path across packet and transport domains can then be specified by attaching appropriate SIDs to the packet. An instance of transport segments has been defined here for optical networks, where paths between packet-optical gateway deviceshashave been abstracted using binding SIDs. Extensions to various protocols to announce the transport segment have been proposed in this document.12.10. Security Considerations This document does not introduce any new security considerations.1311 IANA Considerations This documents request allocation for the following TLVs and subTLVs.13.111.1 PCEP Packet-Optical Gateway capability of the device Value Meaning Reference -------- ------------------------------------ ----------------- 27 TRANSPORT-SR-PCE-CAPABILITY This document A new type of TLV to accommodate a transport segment is defined by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01] Value Description Reference 32 TRANSPORT-SR-PCEP-TLV This document This document requests that a registry is created to manage the value of the Binding Type field in the TRANSPORT-SR-PCEP TLV. Value Description Reference 1 Transport Segment Label This document13.2 OSPF Transport-Segment SubTLV of OSPF Extended Prefix LSA Value Description Reference 9 TRANSPORT-SR-OSPF-SUBTLV This document 13.3 OSPFv3 Transport-Segment SubTLV of OSPFv3 Extend-LSA Sub-TLV registry Value Description Reference 12 TRANSPORT-SR-OSPFv3-SUBTLV This document 13.4 IS-IS Transport-Segment SubTLV of Segment Identifier / Label Binding TLV Value Description Reference 151 TRANSPORT-SR-ISIS-SUBTLV This document 13.511.2 BGP-LS Node Attributes TLV: Value Description Reference 1172 TRANSPORT-SR-BGPLS-CAPABILITY This document Prefix Attribute Binding SID SubTLV: Value Description Reference 1173 TRANSPORT-SR-BGPLS-TLV This document1412 Acknowledgements We would like to thank Peter Psenak, and Radhakrishna Valiveti for their comments and review of this document. 13 References14.113.1 Normative References [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., andr. rjs@rob.sh,R. Shakir, "Segment Routing Architecture",draft- ietf-spring-segment-routing-04 (work in progress), July 2015. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment- routing-extensions-05 (work in progress), June 2015. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-05draft-ietf- spring-segment-routing-12 (work in progress), June2015. [RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915, <http://tools.ietf.org/html/rfc4915>. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3- segment-routing-extensions-03 (work in progress), June 2015. [I-D.ietf-idr-ls-distribution]2017. [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State andTETraffic Engineering (TE) InformationusingUsing BGP",draft-ietf-idr-ls-distribution-13 (work in progress), October 2015. [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities",RFC4970,7752, DOI10.17487/RFC4970, July 2007, <http://www.rfc-editor.org/info/rfc4970>.10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>. [I-D.sivabalan-pce-binding-label-sid] Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J., Hardwick, J., andM. Nanduri,Dhody, D., "Carrying Binding Label/ Segment-ID in PCE-based Networks.", draft-sivabalan-pce-binding-label-sid-01binding-label-sid-03 (work in progress),March 2016.July 2017. [I-D.ietf-pce-segment-routing] Sivabalan, S.,Medved, J.,Filsfils, C.,Crabbe, E., Lopez, V.,Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing",draft-ietf-pce- segment-routing-07draft-ietf-pce-segment-routing-10 (work in progress),March 2016. 14.2October 2017. [I-D.filsfils-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad, F., Lin, S., bogdanov@google.com, b., Horneffer, M., Steinberg, D., Decraene, B., and S. Litkowski, "Segment Routing Policy for Traffic Engineering", draft-filsfils- spring-segment-routing-policy-01 (work in progress), July 2017. 13.2 Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. Authors' Addresses Madhukar Anand Infinera Corporation 169 W Java Dr, Sunnyvale, CA 94089 Email: manand@infinera.com Sanjoy Bardhan Infinera Corporation 169 W Java Dr, Sunnyvale, CA 94089 Email: sbardhan@infinera.com Ramesh SubrahmaniamInfinera Corporation 169 W Java Dr, Sunnyvale, CA 94089Email:RSubrahmaniam@infinera.comsvr_fremont@yahoo.com Jeff Tantsura Email: jefftant.ietf@gmail.com Utpal Mukhopadhyaya Equinix Inc 1188 E. Arques, Sunnyvale, CA 94085 Email: umukhopadhyaya@equinix.com Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com