< draft-anand-spring-poi-sr-01.txt		draft-anand-spring-poi-sr-02.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 Ramesh Subrahmaniam
	Infinera Corporation		Infinera Corporation
	Jeff Tantsura		Jeff Tantsura
	Individual		Individual
	Expires: January 7, 2017 July 6, 2016		Expires: June 25, 2017 December 22, 2016
	Packet-Optical Integration in Segment Routing		Packet-Optical Integration in Segment Routing
	draft-anand-spring-poi-sr-01		draft-anand-spring-poi-sr-02
	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 the defined
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3		2. Reference Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3		3. Use case - Packet Optical Integration . . . . . . . . . . . . . 3
	4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 5		4. Mechanism overview . . . . . . . . . . . . . . . . . . . . . . 6
	5. PCEP-LS extensions for supporting the transport segment . . . 6		5. PCEP-LS extensions for supporting the transport segment . . . 6
	6. OSPF extensions for supporting the transport segment . . . . . 7		6. OSPF extensions for supporting the transport segment . . . . . 8
	7. OSPFv3 extensions for supporting the transport segment . . . . 9		7. OSPFv3 extensions for supporting the transport segment . . . . 9
	8. IS-IS extensions for supporting the transport segment . . . . 10		8. IS-IS extensions for supporting the transport segment . . . . 10
	9. BGP-LS extensions for supporting the transport segment . . . . 12		9. BGP-LS extensions for supporting the transport segment . . . . 12
	10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 14		11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		12 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		12.1 PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		12.2 OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15		12.3 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	12.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		12.4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	12.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 16		12.5 BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	13.1 Normative References . . . . . . . . . . . . . . . . . . . 16		13.1 Normative References . . . . . . . . . . . . . . . . . . . 16
	13.2 Informative References . . . . . . . . . . . . . . . . . . 17		13.2 Informative References . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	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
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	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.
	P1---------O1---------P2---------O2---------P3---------O3---------P4		P5
			P1 _ .-'-._ ,'P4
	Figure 1: Representation of a packet-optical path		`._ .-' `-. ,'
			`. _.-' `-._ ,'
	In Figure 1 above, the nodes represent a packet optical network. P1,		`-. .-' `-. ,'
	P2, P3 and P4 are packet optical devices that are connected via		P2`.-'--------------------------`-.- P3
	optical paths O1, O2 and O3. Nodes P1 and P4 are edge devices that		|\ /|
	have customer facing devices (denoted as Border POGs) and P2 and P3		| \ / | Packet
	are core nodes (denoted as Transit POGs) in the network. A packet		,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
	service is established by specifying a path between P1 and P4. Note		| \ / |
	that in defining this path, we will need to specify both the nodes		| \ / | Transport
	and the links that make up this service. POGs advertise themselves		| \ / |
	along with their adjacencies and the domains they belong to. To		| ................../ |
	leverage segment routing to define the above service, the ingress		| ,'O2 O3`. |
	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 the segment list {P2,		O1\ | O4
	P4}. The operator would need to use a different mechanism in the		\ ,'
	optical domain to set up the optical paths denoted by O1, O2 and O3.		\ ,'
	Each POG would announce the active optical path as a transport		.......................-
	segment - for example, in the case of P1, the optical path O1 would		O6 O5
	represent an optical path that includes the optical nodes Om and On
	as shown on Figure 2. This path is not known to the packet SR domain
	and is only relevant to the optical domain D between P1 and P2. A
	PCE that is run in Domain D would be responsible for calculating path
	O1.
	|-----Om--------On-----|
	P1----| (D) |------P2
	|-----Ox---------Oy----|
	Figure 2: POG with multiple optical paths through an optical domain		Figure 1: Representation of a packet-optical path
	Similarly, the transit POGs P2 and P3 in Figure 1 would announce		In Figure 1 above, the nodes represent a packet optical network.
	transport segments O2 and O3. The border POG would include the		P1,...,P5 are packet devices. Nodes P2 and P3 are connected via optical
	optical paths O1, O2 and O3 to the segment list for P1 to P4. The		network comprising of nodes O1,...,O6. Nodes P2 and P3 are POGs that
	expanded segment list would read as {O1, P2, O2, P3, O3, P4}.		communicate with other packet devices and also with the devices in the
			optical transport domain. In defining a link in the packet domain
			between P2 and P3, we will need to specify both the nodes and the links
			in the optical transport domain that establish this link.
	There are potentially two locations for Borders POGs - one that has		To leverage segment routing to define a service between P1 and P4, the
	last-mile access nodes and the other being Data Center Interconnect		ingress node P1 would append all outgoing packets in a SR header
	nodes. The POGs that are in the core of the network which connect		consisting of the SIDs that constitute the path. In the packet domain
	with long haul optical networks are usually Transit POGs.		this would mean P1 would send its packets towards P4 using a segment
			list {P2, P3, P4}. 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, in the case of P1, the optical path
			{O1, O2, O3} would be represented as a label Om. This path is 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 path corresponding to label Om. The expanded segment
			list would read as {P2, Om, P3, P4}.
	+------------------------+		+------------------------+
	| |		| |
	+--------------+----' PCE or Controller |----+---------------+		+--------------+----' PCE or Controller |----+---------------+
	| | | | | |		| | | | | |
	| | +------------------------+ | |		| | +------------------------+ | |
	| | | |		| | | |
	| | .-----. | |		| | .-----. | |
	| | ( ) | |		| | ( ) | |
	+-------+ +-------+ .--( )--. +-------+ +-------+		+-------+ +-------+ .--( )--. +-------+ +-------+
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 17 ¶
	[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
	169 W Java Dr, Sunnyvale, CA 94089		169 W Java Dr, Sunnyvale, CA 94089
	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		Infinera Corporation
	169 W Java Dr, Sunnyvale, CA 94089		169 W Java Dr, Sunnyvale, CA 94089
	Email: RSubrahmaniam@@infinera.com		Email: RSubrahmaniam@infinera.com
	Jeff Tantsura		Jeff Tantsura
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 13 change blocks.
	52 lines changed or deleted		54 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/