< draft-anand-spring-poi-sr-05.txt		draft-anand-spring-poi-sr-06.txt >
	skipping to change at page 1, line 19 ¶		skipping to change at page 1, line 19 ¶
	Jeff Tantsura		Jeff Tantsura
	Nuage Networks		Nuage Networks
	Utpal Mukhopadhyaya		Utpal Mukhopadhyaya
	Equinix Inc		Equinix Inc
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Expires: August 10, 2018 February 6, 2018		Expires: January 31, 2019 July 30, 2018
	Packet-Optical Integration in Segment Routing		Packet-Optical Integration in Segment Routing
	draft-anand-spring-poi-sr-05		draft-anand-spring-poi-sr-06
	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 packet paths.		'transport segments' or sub-paths as an augmentation to packet paths.
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	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. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9		5. Transport Segments as SR Policy . . . . . . . . . . . . . . . 9
	6. PCEP extensions for supporting the transport segment . . . . . 10		6. PCEP extensions for supporting the transport segment . . . . . 10
	7. BGP-LS extensions for supporting the transport segment . . . . 11		7. BGP-LS extensions for supporting the transport segment . . . . 11
			7.1 Node Attribuites TLV . . . . . . . . . . . . . . . . . . . . 11
			7.2 SR-Optical-Node-Capability TLV . . . . . . . . . . . . . . . 11
			7.3 Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . . 12
			7.3.1 Transport Segment SID Sub-TLV . . . . . . . . . . . . . 12
	8. Note about Transport Segments and Scalability . . . . . . . . . 13		8. Note about Transport Segments and Scalability . . . . . . . . . 13
	9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 14		10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		11.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15		11.2 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	13.1 Normative References . . . . . . . . . . . . . . . . . . . 15		13.1 Normative References . . . . . . . . . . . . . . . . . . . 15
	13.2 Informative References . . . . . . . . . . . . . . . . . . 16		13.2 Informative References . . . . . . . . . . . . . . . . . . 16
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 16 ¶
	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) [RFC8402].
	This document introduces a new type of segment, Transport segment, as		This document introduces a new type of segment, Transport segment, as
	a special case of SR traffic engineering (SR-TE) policy (Type 1, Sec		a special case of SR traffic engineering (SR-TE) policy (Type 1, Sec
	5. [I-D.filsfils-spring-segment-routing-policy]). Specifically, the		5. [I-D.draft-ietf-spring-segment-routing-policy]). Specifically, the
	structure of SR-TE policy and constraints associated in the transport		structure of SR-TE policy and constraints associated in the transport
	network are different from those outlined for the packet networks.		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. A POG		POG will expand it to a path in the optical transport network. A POG
	can be viewed as SR traffic engineering policy headend.		can be viewed as SR traffic engineering policy headend.
	skipping to change at page 9, line 14 ¶		skipping to change at page 9, line 14 ¶
	the transport segment binding SID in the overall SR policy to		the transport segment binding SID in the overall SR policy to
	influence the path traversed by the packet in the optical domain,		influence the path traversed by the packet in the optical domain,
	thereby defining the end-to-end path for a given service.		thereby defining the end-to-end path for a given service.
	In the next few sections, we outline a few representative protocol		In the next few sections, we outline a few representative protocol
	specific extensions to carry the transport segment.		specific extensions to carry the transport segment.
	5. Transport Segments as SR Policy		5. Transport Segments as SR Policy
	The Segment Routing Traffic Engineering (SRTE) [I-D.filsfils-spring-		The Segment Routing Traffic Engineering (SRTE) [ietf-spring-segment-
	segment-routing-policy] process installs the transport segment SR		routing-policy] process installs the transport segment SR policy in
	policy in the forwarding plane of the POG. The Transport SR policy is		the forwarding plane of the POG. The Transport SR policy is
	identified by using a transport segment Binding SID. Corresponding to		identified by using a transport segment Binding SID. Corresponding to
	each transport segment Binding SID, the SRTE process MAY learn about		each transport segment Binding SID, the SRTE process MAY learn about
	multiple candidate paths. The SRTE-DB includes information about the		multiple candidate paths. The SRTE-DB includes information about the
	candidate paths including optical domain, topology and path		candidate paths including optical domain, topology and path
	characteristics. All of the information can be learned from different		characteristics. All of the information can be learned from different
	sources including but not limited to: Netconf/Restconf, PCEP and BGP-		sources including but not limited to: Netconf/Restconf, PCEP and BGP-
	LS.		LS.
	The information model for Transport SR policy is as follows:		The information model for Transport SR policy is as follows:
	skipping to change at page 9, line 50 ¶		skipping to change at page 9, line 50 ¶
	candidate paths, each of them associated with a (locally) unique Binding		candidate paths, each of them associated with a (locally) unique Binding
	SID and a path preference. For each transport SR policy, the candidate		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		path with the highest path preference (at most one) is selected and used
	for forwarding traffic that is being steered onto that policy. When		for forwarding traffic that is being steered onto that policy. When
	candidate paths change (or a new candidate path is set up), the path		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		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		verified by the POG before announcement in the packet domain. If there
	are no valid paths, then the transport SR policy is deemed invalid.		are no valid paths, then the transport SR policy is deemed invalid.
	The allocation of BSID to a path can include dynamic, explicit or		The allocation of BSID to a path can include dynamic, explicit or
	generic allocation strategies as discussed in [I-D.filsfils-spring-		generic allocation strategies as discussed in [ietf-spring-segment-
	segment-routing-policy]. We discuss PCEP and BGP-LS specific extensions		routing-policy]. We discuss PCEP and BGP-LS specific extensions in the
	in the subsequent section.		subsequent section.
	6. PCEP extensions for supporting the transport segment		6. PCEP extensions for supporting the transport segment
	To communicate the Packet-Optical Gateway capability of the device, we		To communicate the Packet-Optical Gateway capability of the device, we
	introduce a new PCEP capabilities TLV is defined as follows(extensions		introduce a new PCEP capabilities TLV is defined as follows(extensions
	to [I-D.ietf-pce-segment-routing]):		to [I-D.ietf-pce-segment-routing]):
	Value Meaning Reference		Value Meaning Reference
	-------- ------------------------------------ -----------------		-------- ------------------------------------ -----------------
	27 TRANSPORT-SR-PCE-CAPABILITY This document		27 TRANSPORT-SR-PCE-CAPABILITY This document
	skipping to change at page 10, line 37 ¶		skipping to change at page 10, line 37 ¶
	~ Transport Segment Sub TLVs (variable length) ~		~ Transport Segment Sub TLVs (variable length) ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	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]		[I-D.sivabalan-pce-binding-label-sid]
	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)
	skipping to change at page 12, line 6 ¶		skipping to change at page 12, line 4 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where:		where:
	Type : TBD, Suggested Value 1157		Type : TBD, Suggested Value 1157
	Length: variable.		Length: variable.
	Flags: The Flags field currently has only one bit defined. If the bit		Flags: The Flags field currently has only one bit defined. If the bit
	is set it has the capability of an Packet Optical Gateway.		is set it has the capability of an Packet Optical Gateway.
	9.3 Prefix Attribute TLVs		7.3 Prefix Attribute TLVs
	The following Prefix Attribute Binding SID Sub-TLVs have been added:		The following Prefix Attribute Binding SID Sub-TLVs have been added:
	+------------+-------------------------+----------+-----------------+		+------------+-------------------------+----------+-----------------+
	| TLV Code | Description | Length | Section |		| TLV Code | Description | Length | Section |
	| Point | | | |		| Point | | | |
	+------------+-------------------------+----------+-----------------+		+------------+-------------------------+----------+-----------------+
	| 1173 | TRANSPORT-SEGMENT-SID | 12 | |		| 1173 | TRANSPORT-SEGMENT-SID | 12 | |
	| | | | |		| | | | |
	+------------+-------------------------+----------+-----------------+		+------------+-------------------------+----------+-----------------+
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 14 ¶
	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.
	9. 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
	domain and expose characteristics of the transport domain into the		routing domain and expose characteristics of the transport domain into
	packet domain. An end-to-end path across packet and transport domains		the packet domain. An end-to-end path across packet and transport
	can then be specified by attaching appropriate SIDs to the packet.		domains can then be specified by attaching appropriate SIDs to the
	An instance of transport segments has been defined here for optical		packet. An instance of transport segments has been defined here for
	networks, where paths between packet-optical gateway devices have been		optical networks, where paths between packet-optical gateway devices
	abstracted using binding SIDs. Extensions to various protocols to		have been abstracted using binding SIDs. Extensions to various
	announce the transport segment have been proposed in this document.		protocols to announce the transport segment have been proposed
			in this document.
	10. Security Considerations		10. Security Considerations
	This document does not introduce any new security considerations.		This document does not introduce any new security considerations.
	11 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.
	11.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]		by extending Binding SIDs [I-D.sivabalan-pce-binding-label-sid]
	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
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 30 ¶
	1173 TRANSPORT-SR-BGPLS-TLV This document		1173 TRANSPORT-SR-BGPLS-TLV This document
	12 Acknowledgements		12 Acknowledgements
	We would like to thank Peter Psenak, and Radhakrishna		We would like to thank Peter Psenak, and Radhakrishna
	Valiveti for their comments and review of this document.		Valiveti for their comments and review of this document.
	13 References		13 References
	13.1 Normative References		13.1 Normative References
	[I-D.ietf-spring-segment-routing]		[RFC8402]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing Architecture",		Litkowski, S., and R. Shakir, "Segment Routing Architecture",
	draft-ietf-spring-segment-routing-15 (work in progress),		RFC 8402, July 2018.
	January 2018.
	[I-D.sivabalan-pce-binding-label-sid]		[I-D.sivabalan-pce-binding-label-sid]
	Sivabalan, S., Filsfils, C., Previdi, S., Tantsura, J.,		Sivabalan, S., Tantsura, J., Filsfils, C., Previdi, S.,
	Hardwick, J., and Dhody, D., "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-03 (work in progress), July 2017.		binding-label-sid-04 (work in progress), Mar 2018.
	[I-D.ietf-pce-segment-routing]		[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,		Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
	and J. Hardwick, "PCEP Extensions for Segment Routing",		and J. Hardwick, "PCEP Extensions for Segment Routing",
	draft-ietf-pce-segment-routing-11 (work in progress),		draft-ietf-pce-segment-routing-12 (work in progress),
	November 2017.		June 2018.
	[I-D.filsfils-spring-segment-routing-policy]		[I-D.draft-ietf-spring-segment-routing-policy]
	Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,		Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A.,
	F., Talaulikar,K., Hegde, S., Voyer, D., Lin, S.,		and Mattes, P., "Segment Routing Policy Architecture",
	Bogdanov, A., Horneffer, M., Steinberg, D., Decraene, B.,		draft-ietf-spring-segment-routing-policy-01.txt
	Litkowski, S., and Mattes, P., "Segment Routing Policy for		(work in progress), June 2018.
	Traffic Engineering",
	draft-filsfils-spring-segment-routing-policy-04
	(work in progress), December 2017.
	13.2 Informative References		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
End of changes. 18 change blocks.
	37 lines changed or deleted		37 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/