< draft-anand-spring-poi-sr-03.txt		draft-anand-spring-poi-sr-04.txt >
	SPRING Working Group Madhukar Anand		SPRING Working Group Madhukar Anand
	Internet-Draft Sanjoy Bardhan		Internet-Draft Sanjoy Bardhan
	Intended Status: Informational Ramesh Subrahmaniam		Intended Status: Informational Infinera Corporation
	Infinera Corporation
			Ramesh Subrahmaniam
			Individual
	Jeff Tantsura		Jeff Tantsura
	Individual		Individual
	Utpal Mukhopadhyaya		Utpal Mukhopadhyaya
	Equinix Inc		Equinix Inc
	Expires: December 28, 2017 June 26, 2017		Clarence Filsfils
			Cisco Systems, Inc.
			Expires: May 18, 2018 November 14, 2017
	Packet-Optical Integration in Segment Routing		Packet-Optical Integration in Segment Routing
	draft-anand-spring-poi-sr-03		draft-anand-spring-poi-sr-04
	Abstract		Abstract
	This document illustrates a way to integrate a new class of nodes and		This document illustrates a way to integrate a new class of nodes and
	links in segment routing to represent transport networks in an opaque		links in segment routing to represent transport networks in an opaque
	way into the segment routing domain. An instance of this class would		way into the segment routing domain. An instance of this class would
	be optical networks that are typically transport centric. In the IP		be optical networks that are typically transport centric. In the IP
	centric network, this will help in defining a common control protocol		centric network, this will help in defining a common control protocol
	for packet optical integration that will include optical paths as		for packet optical integration that will include optical paths as
	'transport segments' or sub-paths as an augmentation to the defined		'transport segments' or sub-paths as an augmentation to packet paths.
	extensions of segment routing. The transport segment option also		The transport segment option also defines a general mechanism to
	defines a general mechanism to allow for future extensibility of		allow for future extensibility of segment routing into non-packet
	segment routing into non-packet domains.		domains.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 42 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4		2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 4
	3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5		3. Use case - Packet Optical Integration . . . . . . . . . . . . . 5
	4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8		4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 8
	5. PCEP-LS extensions for supporting the transport segment . . . 8		5. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9
	6. OSPF extensions for supporting the transport segment . . . . . 10		6. PCEP extensions for supporting the transport segment . . . . . 10
	7. OSPFv3 extensions for supporting the transport segment . . . . 11		7. BGP-LS extensions for supporting the transport segment . . . . 11
	8. IS-IS extensions for supporting the transport segment . . . . 12		8. Note about Transport Segments and Scalability . . . . . . . . . 13
	9. BGP-LS extensions for supporting the transport segment . . . . 14		9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10. Note about Transport Segments and Scalability . . . . . . . . 17		10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	11. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 17		11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	13.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	13.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	13.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 18		13.1 Normative References . . . . . . . . . . . . . . . . . . . 15
	13.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		13.2 Informative References . . . . . . . . . . . . . . . . . . 16
	13.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
	14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	14.1 Normative References . . . . . . . . . . . . . . . . . . . 19
	14.2 Informative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	1 Introduction		1 Introduction
	Packet and optical transport networks have evolved independently with		Packet and optical transport networks have evolved independently with
	different control plane mechanisms that have to be provisioned and		different control plane mechanisms that have to be provisioned and
	maintained separately. Consequently, coordinating packet and optical		maintained separately. Consequently, coordinating packet and optical
	networks for delivering services such as end-to-end traffic		networks for delivering services such as end-to-end traffic
	engineering or failure response has proved challenging. To address		engineering or failure response has proved challenging. To address
	this challenge, a unified control and management paradigm that		this challenge, a unified control and management paradigm that
	provides an incremental path to complete packet-optical integration		provides an incremental path to complete packet-optical integration
	while leveraging existing signaling and routing protocols in either		while leveraging existing signaling and routing protocols in either
	domains is needed. This document introduces such a paradigm based on		domains is needed. This document introduces such a paradigm based on
	Segment Routing (SR) [I-D.ietf-spring-segment-routing].		Segment Routing (SR) [I-D.ietf-spring-segment-routing].
	This document introduces a new type of segment, Transport segment.		This document introduces a new type of segment, Transport 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		Transport segment can be used to model abstracted paths through the
	optical transport domain and integrate it with the packet network for		optical transport domain and integrate it with the packet network for
	delivering end-to-end services. In addition, this also introduces a		delivering end-to-end services. In addition, this also introduces a
	notion of a Packet optical gateway (POG). These are nodes in the		notion of a Packet optical gateway (POG). These are nodes in the
	network that map packet services to the optical domain that originate		network that map packet services to the optical domain that originate
	and terminate these transport segments. Given a transport segment, a		and terminate these transport segments. Given a transport segment, a
	POG will expand it to a path in the optical transport network.		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		The concept of POG introduced here allows for multiple instantiations
	of the concept. In one case, the packet device is distinct from the		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		optical transport device, and the POG is a logical entity that spans
	these two devices. In this case, the POG functionality is achieved		these two devices. In this case, the POG functionality is achieved
	with the help of external coordination between the packet and optical		with the help of external coordination between the packet and optical
	devices. In another case, the packet and optical components are		devices. In another case, the packet and optical components are
	integrated into one physical device, and the co-ordination required		integrated into one physical device, and the co-ordination required
	for functioning of the POG is performed by this integrated device.		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		It must be noted that in either case, it is the packet/optical data
	plane that is either disaggregated or integrated. Control of the		plane that is either disaggregated or integrated. Control of the
	devices can be logically centralized or distributed in either		devices can be logically centralized or distributed in either
	scenario. The focus of this document is to define the logical		scenario. The focus of this document is to define the logical
	skipping to change at page 4, line 47 ¶		skipping to change at page 5, line 4 ¶
	devices can be logically centralized or distributed in either		devices can be logically centralized or distributed in either
	scenario. The focus of this document is to define the logical		scenario. The focus of this document is to define the logical
	functions of a POG without going into the exact instantiations of the		functions of a POG without going into the exact instantiations of the
	concept.		concept.
	2. Reference Taxonomy		2. Reference Taxonomy
	POG - Packet optical gateway Device		POG - Packet optical gateway Device
	SR Edge Router - The Edge Router which is the ingress device		SR Edge Router - The Edge Router which is the ingress device
	CE - Customer Edge Device that is outside of the SR domain		CE - Customer Edge Device that is outside of the SR domain
	PCE - Path Computation Engine		PCE - Path Computation Engine
	Controller - A network controller		Controller - A network controller
	3. Use case - Packet Optical Integration		3. Use case - Packet Optical Integration
	Many operators build and operate their networks that are both multi-		Many operators build and operate their networks that are both multi-
	layer and multi-domain. Services are built around these layers and		layer and multi-domain. Services are built around these layers and
	domains to provide end-to-end services. Due to the nature of the		domains to provide end-to-end services. Due to the nature of the
	different domains, such as packet and optical, the management and		different domains, such as packet and optical, the management and
	service creation has always been problematic and time consuming. With		service creation has always been problematic and time consuming. With
	segment routing, enabling a head-end node to select a path and embed		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		the information in the packet is a powerful construct that would be
	used in the Packet Optical Gateways (POG). The path is usually		used in the Packet Optical Gateways (POG). The path is usually
	constructed for each domain that may be manually derived or through a		constructed for each domain that may be manually derived or through a
	stateful PCE which is run specifically in that domain.		stateful PCE which is run specifically in that domain.
	P5		P5
	P1 _ .-'-._ ,'P4		P1 _ .-'-._ ,'P4
	`._ .-' `-. ,'		`._ .-' `-. ,'
	`. _.-' `-._ ,'		`. _.-' `-._ ,'
	`-. .-' `-. ,'		`-. .-' `-. ,'
	P2`.-'--------------------------`-.- P3		P2`.-'--------------------------`-.- P3
	|\ /|		|\ /|
	| \ / | Packet		| \ / | Packet
	,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,		,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
	| \ / |		| \ / |
	| \ / | Transport		| \ / | Transport
	| \ / |		| \ / |
	| ................../ |		| ................./ |
	| ,'O2 O3`. |		| ,'O2 O3`. |
	| ,' `. |		| ,' `. |
	|,' `. |		|,' `.|
	O1\ | O4		O1\ | O4
	\ ,'		\ ,'
	\ ,'		\ ,'
	.......................-		.......................-
	O6 O5		O6 O5
	Figure 1: Representation of a packet-optical path		Figure 1: Representation of a packet-optical path
	In Figure 1 above, the nodes represent a packet optical network.		In Figure 1 above, the nodes represent a packet optical network.
	P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical		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		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		communicate with other packet devices and also with the devices in the
	optical transport domain. In defining a link in the packet domain		optical transport domain. In defining a path between nodes P2 and P3, we
	between P2 and P3, we will need to specify both the nodes and the links		will need to specify the nodes and the links in both the packet and
	in the optical transport domain that establish this link.		optical transport domains.
	To leverage segment routing to define a service between P1 and P4, the		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		ingress node P1 would append all outgoing packets in a SR header
	consisting of the SIDs that constitute the path. In the packet domain		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		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		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		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		the optical paths comprising the nodes O1, O2 and O3. Each POG would
	announce the active optical path as a transport segment - for example,		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		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		optical path {O2, O3} could be represented as a transport label On. Both
	Om and On will be advertised by Packet node P1. These paths are not		Om and On will be advertised by Packet node P2. These paths are not
	known to the packet SR domain and is only relevant to the optical domain		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		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		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,		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		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.		and P3 in the optical domain involving optical nodes O5, O6, and O4.
	There is no requirement that every path between P2 and P3 be represented		There may be multiple optical paths between P2 and P3 corresponding to
	as transport segments. A discussion on transport segments and		multiple SR policies. For example, some optical paths can be low-cost,
	scalability can be found in Section 10.		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 Section 8.
	Use-case examples of transport segments.		Use-case examples of transport segments.
	1. Consider the scenario where there are multiple fibers between two		1. Consider the scenario where there are multiple fibers between two
	packet end points. The network operator may choose to route packet		packet end points. The network operator may choose to route packet
	traffic on the first fiber, and reserve the second fiber only to		traffic on the first fiber, and reserve the second fiber only for
	maintenance or low priority traffic.		maintenance or low priority traffic.
	2. As a second use-case, consider the case where the packet end points		2. As a second use-case, consider the case where the packet end points
	are connected by optical transport provided by two different service		are connected by optical transport provided by two different service
	providers. The packet operator wants to preferentially route traffic		providers. The packet operator wants to preferentially route traffic
	over one of the providers and use the second provider as a backup.		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 that		3. Finally, let the packet end points be connected by optical paths that
	lie in different geographies. For instance, one optical transport path		may span multiple optical domains i.e. different administrative control.
	may lie completely in one country while the other optical transport path		For instance, one optical transport path may lie completely in one
	transits another country. Weather, tariffs, security considerations and		country while the other optical transport path transits another country.
	other factors may determine how the packet operator wants to route		Weather, tariffs, security considerations and other factors may
	different types of traffic on this network.		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		All of the above use-cases can be supported by first mapping distinct
	optical transport paths to different transport segments and then,		optical transport paths to different transport segments and then,
	depending on the need, affixing appropriate transport segment identifier		depending on the need, affixing appropriate transport segment identifier
	to the specific packet to route it appropriately through the transport		to the specific packet to route it appropriately through the transport
	domain.		domain.
	+------------------------+		+------------------------+
	| |		| |
	+--------------+----' PCE or Controller |----+---------------+		+--------------+----' PCE or Controller |----+---------------+
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	+---+.--+ +-------+ ( ) +-------+ +---+.--+		+---+.--+ +-------+ ( ) +-------+ +---+.--+
	| '--( )--' |		| '--( )--' |
	,--+. ( ) ,-+-.		,--+. ( ) ,-+-.
	( CE ) '-----' ( CE )		( CE ) '-----' ( CE )
	`---' `---'		`---' `---'
	Figure 3. Reference Topology for Transport Segment Mechanism		Figure 3. Reference Topology for Transport Segment Mechanism
	4. Mechanism overview		4. Mechanism overview
	The current proposal assumes that the SR domains run standard IGP		The current proposal assumes that the SR domains run standard
	protocols to discover the topology and distribute labels without any		protocols without any modification to discover the topology and
	modification. There are also no modifications to the control plane		distribute labels. There are also no modifications necessary in the
	mechanisms in the Optical transport domains. For example, the optical		control plane mechanisms in the optical transport domains. The only
	paths may be setup using a domain-specific controller or PCE based on		requirement of a transport segment is that the optical path be setup
	requirements from the packet domain (such as bandwidth, QoS, latency		before they are announced to the packet network. For example, the
	and cost). The mechanism for supporting the transport segment in the		optical paths may be setup using a domain-specific controller or a
	packet domain is as follows.		PCE based on requirements from the packet domain (such as bandwidth,
			QoS, latency and cost) taking into consideration the constraints in
			the optical network.
	1. Firstly, the Packet Optical Gateway (POG) devices announce		The mechanism for supporting the transport segment is as follows.
	themselves in the SR 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 paths to other POGs through the		1. Firstly, the Packet Optical Gateway (POG) devices are announced
	optical transport domain as a transport segment (transport segment		in the packet domain. This is indicated by advertising a new SR node
	binding SID) in the SR domain. The paths are announced with an		capability flag. The exact extensions to support this capability are
	appropriate optical transport domain ID, and a label (Packet-Optical		described in the subsequent sections of this document.
	Label) to be used to bind to the transport segment. The appropriate
	IGP segment routing extensions to carry this information is described
	in the subsequent sections of this document.
	3. The transport segment can also optionally be announced with a		2. Then, the POG devices announce candidate optical transport
			paths between that POG (Source POG) and other POGs (Destination POG)
			via appropriate mechanisms in the packet domain. The paths are
			announced with an appropriate optical transport domain ID and a
			Binding SID representing the transport segment from a source POG to a
			destination POG. The appropriate protocol-specific extensions to
			carry path characteristics and Binding SID corresponding to a optical
			path are described in the subsequent sections of this document.
			3.The transport SR policy can also optionally be announced with a
	set of attributes that characterizes the path in the optical		set of attributes that characterizes the path in the optical
	transport domain between the two POG devices. For instance, those		transport domain between the two POG devices. For instance, those
	attributes could define the OTN mapping used (e.g., ODU4,		could define the path attributes such as path identifier, latency,
	ODU3,ODU3e1....ODU1), timeslots (1-8 or 4,6,7 or 1-2,5), or optical		bandwidth, quality, directionality, or optical path protection
	path protection schemes.		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		4. The POG device is also responsible for programming its
	forwarding table to map every transport segment label entry into an		forwarding table to map every transport segment Binding SID entry
	appropriate forwarding action relevant in the optical domain, such as		into an appropriate forwarding action relevant in the optical domain,
	mapping it to a label-switched path.		such as mapping it to a optical label-switched path.
	5. The transport segment is communicated to the PCE or Controller		5. The transport SR policy is communicated to the PCE or
	using extensions to BGP-LS or PCEP-LS as described in subsequent		Controller using extensions to BGP-LS or PCEP as described in
	sections of this document.		subsequent sections of this document.
	6. Finally, the PCE or Controller then uses the transport segment		6. Finally, the PCE or Controller in the packet domain then uses
	label to influence the path leaving the SR domain into the optical
	domain, thereby defining the end-to-end path for a given service.
	5. PCEP-LS extensions for supporting the transport segment		the transport segment binding SID in the overall SR policy to
	To communicate the Packet-Optical Gateway capability of the device,		influence the path traversed by the packet in the optical domain,
	we introduce a new PCEP capabilities TLV is defined as		thereby defining the end-to-end path for a given service.
	follows(extensions to [I-D.draft-sivabalan-pce-segment-routing]):
			In the next few sections, we outline a few representative protocol
			specific extensions to carry the transport segment.
			5. Transport 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		Value Meaning Reference
	-------- ------------------------------------ -----------------		-------- ------------------------------------ -----------------
	27 TRANSPORT-SR-PCE-CAPABILITY This document		27 TRANSPORT-SR-PCE-CAPABILITY This document
	A new type of TLV to accommodate a transport segment is defined		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]		by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01]
	0 1 2 3		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		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
	skipping to change at page 9, line 39 ¶		skipping to change at page 11, line 4 ¶
	Type: TBD, suggested value 32		Type: TBD, suggested value 32
	Length: variable.		Length: variable.
	Binding Type: 0 or 1 as defined in		Binding Type: 0 or 1 as defined in
	[I-D.draft-sivabalan-pce-binding-label-sid-01]		[I-D.draft-sivabalan-pce-binding-label-sid-01]
	Domain ID: An identifier for the transport domain		Domain ID: An identifier for the transport domain
	Binding Value: is the transport segment label		Binding Value: is the transport segment label
	Transport Segment Sub TLVs: TBD		Transport Segment Sub TLVs: TBD
	IANA will be requested to allocate a new TLV type (recommended value		IANA will be requested to allocate a new TLV type (recommended value
	is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document:		is 32) for TRANSPORT-SEGMENT-BINDING-TLV as specified in this document:
	1 Transport Segment Label (This document)		1 Transport Segment Label (This document)
	6. OSPF extensions for supporting the transport segment		7. BGP-LS 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 domain
	7. 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 segment
	9.1 Node Attribuites TLV		7.1 Node Attribuites TLV
	To communicate the Packet-Optical Gateway capability of the		To communicate the Packet-Optical Gateway capability of the
	device, we introduce an new optical informational capability		device, we introduce an new optical informational capability
	the following new Node Attribute TLV is defined:		the following new Node Attribute TLV is defined:
	+-----------+----------------------------+----------+---------------+		+-----------+----------------------------+----------+---------------+
	| TLV Code | Description | Length | Section |		| TLV Code | Description | Length | Section |
	| Point | | | |		| Point | | | |
	+-----------+----------------------------+----------+---------------+		+-----------+----------------------------+----------+---------------+
	| 1172 | SR-Optical-Node-Capability | variable | |		| 1172 | SR-Optical-Node-Capability | variable | |
	| | TLV | | |		| | TLV | | |
	+-----------+----------------------------+----------+---------------+		+-----------+----------------------------+----------+---------------+
	Table 1: Node Attribute TLVs		Table 1: Node Attribute TLVs
	These TLVs can ONLY be added to the Node Attribute associated with		These TLVs can ONLY be added to the Node Attribute associated with
	the node NLRI that originates the corresponding SR TLV.		the node NLRI that originates the corresponding SR TLV.
	9.2 SR-Optical-Node-Capability TLV		7.2 SR-Optical-Node-Capability TLV
	The SR Capabilities sub-TLV has following format:		The SR Capabilities sub-TLV has following format:
	0 1 2 3		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		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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Flags | RESERVED |		| Flags | RESERVED |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 15, line 46 ¶		skipping to change at page 12, line 29 ¶
	| 1173 | TRANSPORT-SEGMENT-SID | 12 | |		| 1173 | TRANSPORT-SEGMENT-SID | 12 | |
	| | | | |		| | | | |
	+------------+-------------------------+----------+-----------------+		+------------+-------------------------+----------+-----------------+
	Table 4: Prefix Attribute - Binding SID Sub-TLVs		Table 4: Prefix Attribute - Binding SID Sub-TLVs
	The Transport segment TLV allows a node to advertise an transport		The Transport segment TLV allows a node to advertise an transport
	segment within a single IGP domain. The transport segment SID TLV		segment within a single IGP domain. The transport segment SID TLV
	TRANSPORT-SEGMENT-TLV has the following format:		TRANSPORT-SEGMENT-TLV has the following format:
	9.3.1 Transport Segment SID Sub-TLV		7.3.1 Transport Segment SID Sub-TLV
	Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of		Further, a new sub-TLV (similar to the IPV4 ERO SubTLV) of
	Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the		Binding SID Sub-TLV (TRANSPORT-SEGMENT-BINDING-SUBTLV) to carry the
	transport segment label is defined as follows.		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		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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Domain ID | Flags | Reserved |		| Domain ID | Flags | Reserved |
	skipping to change at page 17, line 8 ¶		skipping to change at page 13, line 34 ¶
	* A 4 octet index defining the offset in the label space		* A 4 octet index defining the offset in the label space
	advertised by this router. In this case V and L flags MUST		advertised by this router. In this case V and L flags MUST
	be unset.		be unset.
	Transport Segment Sub TLVs: TBD		Transport Segment Sub TLVs: TBD
	Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair		Multiple TRANSPORT-SEGMENT-TLV MAY be associated with a pair
	of POG devices to represent multiple paths within the optical domain		of POG devices to represent multiple paths within the optical domain
	10. Note about Transport Segments and Scalability		8. Note about Transport Segments and Scalability
	In most operational scenarios, there would be multiple, distinct paths		In most operational scenarios, there would be multiple, distinct paths
	between the POGs. There is no requirement that every distinct path in		between the POGs. There is no requirement that every distinct path in
	the optical domain be advertised as a separate transport segment.		the optical domain be advertised as a separate transport segment.
	Transport segments are designed to be consumed in the packet domain,		Transport segments are designed to be consumed in the packet domain,
	and the correspondence between transport segments and exact paths in		and the correspondence between transport segments and exact paths in
	the optical domain are determined by their utility to the packet world.		the optical domain are determined by their utility to the packet world.
	Therefore, the number of transport segments is to be determined by the		Therefore, the number of transport segments is to be determined by the
	individual packet-optical use-case. The number of actual paths in 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		optical domain between the POG is expected to be large (counting the
	skipping to change at page 17, line 31 ¶		skipping to change at page 14, line 13 ¶
	segment. Of course, in the degenerate case, it is possible that there		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		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		segment. Given this view of network operation, the POG is not expected
	to handle a large number of transport segments (and identifiers). This		to handle a large number of transport segments (and identifiers). This
	framework does leave open the possibility of handling a large number		framework does leave open the possibility of handling a large number
	of transport segments in future. For instance, a hierarchical		of transport segments in future. For instance, a hierarchical
	partitioning of the optical domain along with stacking of multiple		partitioning of the optical domain along with stacking of multiple
	transport segment identifiers could be explored towards reducing		transport segment identifiers could be explored towards reducing
	the overall number of transport segment identifiers.		the overall number of transport segment identifiers.
	11. Summary		9. Summary
	The motivation for introducing a new type of segment - transport		The motivation for introducing a new type of segment - transport
	segment - is to integrate transport networks with the segment routing		segment - is to integrate transport networks with the segment routing
	domain and expose characteristics of the transport domain into the		domain and expose characteristics of the transport domain into the
	packet domain. An end-to-end path across packet and transport domains		packet domain. An end-to-end path across packet and transport domains
	can then be specified by attaching appropriate SIDs to the packet.		can then be specified by attaching appropriate SIDs to the packet.
	An instance of transport segments has been defined here for optical		An instance of transport segments has been defined here for optical
	networks, where paths between packet-optical gateway devices has been		networks, where paths between packet-optical gateway devices have been
	abstracted using binding SIDs. Extensions to various protocols to		abstracted using binding SIDs. Extensions to various protocols to
	announce the transport segment have been proposed in this document.		announce the transport segment have been proposed in this document.
	12. Security Considerations		10. Security Considerations
	This document does not introduce any new security considerations.		This document does not introduce any new security considerations.
	13 IANA Considerations		11 IANA Considerations
	This documents request allocation for the following TLVs and subTLVs.		This documents request allocation for the following TLVs and subTLVs.
	13.1 PCEP		11.1 PCEP
	Packet-Optical Gateway capability of the device		Packet-Optical Gateway capability of the device
	Value Meaning Reference		Value Meaning Reference
	-------- ------------------------------------ -----------------		-------- ------------------------------------ -----------------
	27 TRANSPORT-SR-PCE-CAPABILITY This document		27 TRANSPORT-SR-PCE-CAPABILITY This document
	A new type of TLV to accommodate a transport segment is defined		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]		by extending Binding SIDs [I-D.draft-sivabalan-pce-binding-label-sid-01]
	Value Description Reference		Value Description Reference
	32 TRANSPORT-SR-PCEP-TLV This document		32 TRANSPORT-SR-PCEP-TLV This document
	This document requests that a registry is created to manage the value		This document requests that a registry is created to manage the value
	of the Binding Type field in the TRANSPORT-SR-PCEP TLV.		of the Binding Type field in the TRANSPORT-SR-PCEP TLV.
	Value Description Reference		Value Description Reference
	1 Transport Segment Label This document		1 Transport Segment Label This document
	13.2 OSPF		11.2 BGP-LS
	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.5 BGP-LS
	Node Attributes TLV:		Node Attributes TLV:
	Value Description Reference		Value Description Reference
	1172 TRANSPORT-SR-BGPLS-CAPABILITY This document		1172 TRANSPORT-SR-BGPLS-CAPABILITY This document
	Prefix Attribute Binding SID SubTLV:		Prefix Attribute Binding SID SubTLV:
	Value Description Reference		Value Description Reference
	1173 TRANSPORT-SR-BGPLS-TLV This document		1173 TRANSPORT-SR-BGPLS-TLV This document
	14 References		12 Acknowledgements
			We would like to thank Peter Psenak, and Radhakrishna
	14.1 Normative References		Valiveti for their comments and review of this document.
	[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and r. rjs@rob.sh, "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-05 (work in progress), June 2015.
	[RFC4915] L. Nguyen, P. Psenak, S. Mirtorabi, P. Pillay-Esnault, and		13 References
	A. Roy, "Multi-Topology (MT) Routing in OSPF.", RFC4915,
	<http://tools.ietf.org/html/rfc4915>.
	[I-D.ietf-ospf-ospfv3-segment-routing-extensions]		13.1 Normative References
	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]		[I-D.ietf-spring-segment-routing]
	Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	Ray, "North-Bound Distribution of Link-State and TE		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	Information using BGP", draft-ietf-idr-ls-distribution-13		spring-segment-routing-12 (work in progress), June 2017.
	(work in progress), October 2015.
	[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Shaffer, "Extensions to OSPF for Advertising Optional		S. Ray, "North-Bound Distribution of Link-State and
	Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	2007, <http://www.rfc-editor.org/info/rfc4970>.		DOI 10.17487/RFC7752, March 2016,
			<http://www.rfc-editor.org/info/rfc7752>.
	[I-D.sivabalan-pce-binding-label-sid]		[I-D.sivabalan-pce-binding-label-sid]
	Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J.,		Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J.,
	Hardwick, J., and M. Nanduri, "Carrying Binding Label/		Hardwick, J., and Dhody, D., "Carrying Binding Label/
	Segment-ID in PCE-based Networks.", draft-sivabalan-pce-		Segment-ID in PCE-based Networks.", draft-sivabalan-pce-
	binding-label-sid-01 (work in progress), March 2016.		binding-label-sid-03 (work in progress), July 2017.
	[I-D.ietf-pce-segment-routing]		[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,		Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
	Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,		and J. Hardwick, "PCEP Extensions for Segment Routing",
	"PCEP Extensions for Segment Routing", draft-ietf-pce-		draft-ietf-pce-segment-routing-10 (work in progress),
	segment-routing-07 (work in progress), March 2016.		October 2017.
	14.2 Informative References		[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		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	Authors' Addresses		Authors' Addresses
	Madhukar Anand		Madhukar Anand
	Infinera Corporation		Infinera Corporation
	skipping to change at page 21, line 9 ¶		skipping to change at page 16, line 39 ¶
	Email: manand@infinera.com		Email: manand@infinera.com
	Sanjoy Bardhan		Sanjoy Bardhan
	Infinera Corporation		Infinera Corporation
	169 W Java Dr, Sunnyvale, CA 94089		169 W Java Dr, Sunnyvale, CA 94089
	Email: sbardhan@infinera.com		Email: sbardhan@infinera.com
	Ramesh Subrahmaniam		Ramesh Subrahmaniam
	Infinera Corporation		Email: svr_fremont@yahoo.com
	169 W Java Dr, Sunnyvale, CA 94089
	Email: RSubrahmaniam@infinera.com
	Jeff Tantsura		Jeff Tantsura
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Utpal Mukhopadhyaya		Utpal Mukhopadhyaya
	Equinix Inc		Equinix Inc
	1188 E. Arques, Sunnyvale, CA 94085		1188 E. Arques, Sunnyvale, CA 94085
	Email: umukhopadhyaya@equinix.com		Email: umukhopadhyaya@equinix.com
			Clarence Filsfils
			Cisco Systems, Inc.
			Brussels
			BE
			Email: cfilsfil@cisco.com
End of changes. 49 change blocks.
	374 lines changed or deleted		196 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/