< draft-ietf-spring-segment-routing-ldp-interop-03.txt		draft-ietf-spring-segment-routing-ldp-interop-04.txt >
	Network Working Group C. Filsfils, Ed.		Network Working Group C. Filsfils, Ed.
	Internet-Draft S. Previdi, Ed.		Internet-Draft S. Previdi, Ed.
	Intended status: Standards Track A. Bashandy		Intended status: Standards Track A. Bashandy
	Expires: November 18, 2016 Cisco Systems, Inc.		Expires: January 5, 2017 Cisco Systems, Inc.
	B. Decraene		B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	May 17, 2016		July 4, 2016
	Segment Routing interworking with LDP		Segment Routing interworking with LDP
	draft-ietf-spring-segment-routing-ldp-interop-03		draft-ietf-spring-segment-routing-ldp-interop-04
	Abstract		Abstract
	A Segment Routing (SR) node steers a packet through a controlled set		A Segment Routing (SR) node steers a packet through a controlled set
	of instructions, called segments, by prepending the packet with an SR		of instructions, called segments, by prepending the packet with an SR
	header. A segment can represent any instruction, topological or		header. A segment can represent any instruction, topological or
	service-based. SR allows to enforce a flow through any topological		service-based. SR allows to enforce a flow through any topological
	path and service chain while maintaining per-flow state only at the		path and service chain while maintaining per-flow state only at the
	ingress node to the SR domain.		ingress node to the SR domain.
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 18, 2016.		This Internet-Draft will expire on January 5, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7. Manageability Considerations . . . . . . . . . . . . . . . . 15		7. Manageability Considerations . . . . . . . . . . . . . . . . 15
	7.1. SR and LDP co-existence . . . . . . . . . . . . . . . . . 15		7.1. SR and LDP co-existence . . . . . . . . . . . . . . . . . 15
	7.2. SRMS Management . . . . . . . . . . . . . . . . . . . . . 16		7.2. SRMS Management . . . . . . . . . . . . . . . . . . . . . 16
	7.3. Dataplane Verification . . . . . . . . . . . . . . . . . 16		7.3. Dataplane Verification . . . . . . . . . . . . . . . . . 16
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	10. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 17		10. Contributors' Addresses . . . . . . . . . . . . . . . . . . . 17
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	11.1. Normative References . . . . . . . . . . . . . . . . . . 17		11.1. Normative References . . . . . . . . . . . . . . . . . . 17
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Segment Routing, as described in [I-D.ietf-spring-segment-routing],		Segment Routing, as described in [I-D.ietf-spring-segment-routing],
	can be used on top of the MPLS data plane without any modification as		can be used on top of the MPLS data plane without any modification as
	described in [I-D.ietf-spring-segment-routing-mpls].		described in [I-D.ietf-spring-segment-routing-mpls].
	Segment Routing control plane can co-exist with current label		Segment Routing control plane can co-exist with current label
	distribution protocols such as LDP ([RFC5036]).		distribution protocols such as LDP ([RFC5036]).
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	As a result, PE1 sends its traffic to the ODD service route		As a result, PE1 sends its traffic to the ODD service route
	advertised by PE3 to next-hop A with two labels: the top label is		advertised by PE3 to next-hop A with two labels: the top label is
	1037 and the bottom label is 10001. A swaps 1037 with 2048 and		1037 and the bottom label is 10001. A swaps 1037 with 2048 and
	forwards to B. B swaps 2048 with 3059 and forwards to C. C pops		forwards to B. B swaps 2048 with 3059 and forwards to C. C pops
	3059 and forwards to PE3.		3059 and forwards to PE3.
	PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN		PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN
	label 10002.		label 10002.
	From an SR viewpoint: PE1 maps the IGP route 192.0.2.204/32 onto		From an SR viewpoint: PE2 maps the IGP route 192.0.2.204/32 onto
	Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204		Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204
	with 204 and forwards to C; C pops 204 and forwards to PE4.		with 204 and forwards to C; C pops 204 and forwards to PE4.
	As a result, PE2 sends its traffic to the VPN service route		As a result, PE2 sends its traffic to the VPN service route
	advertised by PE4 to next-hop A with two labels: the top label is 204		advertised by PE4 to next-hop A with two labels: the top label is 204
	and the bottom label is 10002. A swaps 204 with 204 and forwards to		and the bottom label is 10002. A swaps 204 with 204 and forwards to
	B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards		B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards
	to PE4.		to PE4.
	The two modes of MPLS tunneling co-exist.		The two modes of MPLS tunneling co-exist.
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 28 ¶
	The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6		The end-to-end MPLS tunnel is built from an LDP LSP from PE3 to P6
	and the related node segment from P6 to PE1.		and the related node segment from P6 to PE1.
	4.1.1. LDP to SR Behavior		4.1.1. LDP to SR Behavior
	It has to be noted that no additional signaling or state is required		It has to be noted that no additional signaling or state is required
	in order to provide interworking in the direction LDP to SR.		in order to provide interworking in the direction LDP to SR.
	A SR node having LDP neighbors MUST create LDP bindings for each		A SR node having LDP neighbors MUST create LDP bindings for each
	Prefix-SID and Node-SID learned in the SR domain and, for each FEC,		Prefix-SID and Node-SID learned in the SR domain and, for each FEC,
	stitch the incoming LDP label to the outgoing SR label.		stitch the incoming LDP label to the outgoing SR label. This has to
			be done in both LDP independent and ordered label distribution
			control modes as defined in [RFC5036].
			If the SR/LDP node operates in LDP ordered label distribution control
			mode (as defined in [RFC5036], then the SR/DLP node MUST consider SR
			learned labels as if they were learned through an LDP neighbor and
			create LDP bindings for each Prefix-SID and Node-SID learned in the
			SR domain.
	4.2. SR to LDP		4.2. SR to LDP
	In this section, we analyze the left-to-right traffic flow.		In this section, we analyze the left-to-right traffic flow.
	We assume that the operator configures P5 to act as a Segment Routing		We assume that the operator configures P5 to act as a Segment Routing
	Mapping Server (SRMS) and advertises the following mappings: (P7,		Mapping Server (SRMS) and advertises the following mappings: (P7,
	107), (P8, 108), (PE3, 103) and (PE4, 104).		107), (P8, 108), (PE3, 103) and (PE4, 104).
	These mappings are advertised as Remote-Binding SID as described in		These mappings are advertised as Remote-Binding SID as described in
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 14 ¶
	At least one SRMS MUST be present in the routing domain. Multiple		At least one SRMS MUST be present in the routing domain. Multiple
	SRMSs SHOULD be present for redundancy.		SRMSs SHOULD be present for redundancy.
	Each SR capable router installs in the MPLS data plane Node-SIDs		Each SR capable router installs in the MPLS data plane Node-SIDs
	learned from the SRMS exactly like if these SIDs had been advertised		learned from the SRMS exactly like if these SIDs had been advertised
	by the nodes themselves.		by the nodes themselves.
	A SR node having LDP neighbors MUST create LDP bindings for each		A SR node having LDP neighbors MUST create LDP bindings for each
	Prefix-SID and Node-SID learned in the SR domain and, for each FEC,		Prefix-SID and Node-SID learned in the SR domain and, for each FEC,
	stitch the incoming SR label to the outgoing LDP label.		stitch the incoming SR label to the outgoing LDP label. This has to
			be done in both LDP independent and ordered label distribution
			control modes as defined in [RFC5036].
			If the SR/LDP node operates in LDP ordered label distribution control
			mode (as defined in [RFC5036], then the SR/DLP node MUST consider SR
			learned labels as if they were learned through an LDP neighbor and
			create LDP bindings for each Prefix-SID and Node-SID learned in the
			SR domain.
	The encodings of the SRMS advertisements are specific to the routing		The encodings of the SRMS advertisements are specific to the routing
	protocol. See [I-D.ietf-isis-segment-routing-extensions],		protocol. See [I-D.ietf-isis-segment-routing-extensions],
	[I-D.ietf-ospf-segment-routing-extensions] and		[I-D.ietf-ospf-segment-routing-extensions] and
	[I-D.ietf-ospf-ospfv3-segment-routing-extensions] for details of SRMS		[I-D.ietf-ospf-ospfv3-segment-routing-extensions] for details of SRMS
	encodings. See also [I-D.ginsberg-spring-conflict-resolution] for		encodings. See also [I-D.ietf-spring-conflict-resolution] for the
	the specific rules on SRMS advertisements.		specific rules on SRMS advertisements.
	It has to be noted, The SR to LDP behavior does not propagate the		It has to be noted, The SR to LDP behavior does not propagate the
	status of the LDP FEC which was signaled if LDP was configured to use		status of the LDP FEC which was signaled if LDP was configured to use
	the ordered mode.		the ordered mode.
	It has to be noted that in the case of SR to LDP, the label binding		It has to be noted that in the case of SR to LDP, the label binding
	is equivalent to the LDP Label Distribution Control Mode ([RFC5036])		is equivalent to the LDP Label Distribution Control Mode ([RFC5036])
	where a label in bound to a FEC independently from the received		where a label in bound to a FEC independently from the received
	binding for the same FEC.		binding for the same FEC.
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 28 ¶
	Multiple SRMSs can be provisioned in a network for redundancy.		Multiple SRMSs can be provisioned in a network for redundancy.
	Moreover, a preference mechanism may also be used among SRMSs so to		Moreover, a preference mechanism may also be used among SRMSs so to
	deploy a primary/secondary SRMS scheme allowing controlled		deploy a primary/secondary SRMS scheme allowing controlled
	modification or migration of SIDs.		modification or migration of SIDs.
	The content of SRMS advertisement (i.e.: mappings) are a matter of		The content of SRMS advertisement (i.e.: mappings) are a matter of
	local policy determined by the operator. When multiple SRMSs are		local policy determined by the operator. When multiple SRMSs are
	active, it is necessary that the information (mappings) advertised by		active, it is necessary that the information (mappings) advertised by
	the different SRMSs is aligned and consistent.		the different SRMSs is aligned and consistent.
	[I-D.ginsberg-spring-conflict-resolution] illustrates mechanisms		[I-D.ietf-spring-conflict-resolution] illustrates mechanisms through
	through which such consistency is achieved.		which such consistency is achieved.
	When the SRMS advertise mappings, an implementation SHOULD provide a		When the SRMS advertise mappings, an implementation SHOULD provide a
	mechanism through which the operator determines which of the IP2MPLS		mechanism through which the operator determines which of the IP2MPLS
	mappings are preferred among the one advertised by the SRMS and the		mappings are preferred among the one advertised by the SRMS and the
	ones advertised by LDP.		ones advertised by LDP.
	7.3. Dataplane Verification		7.3. Dataplane Verification
	When Label switch paths (LSPs) are defined by stitching LDP LSPs with		When Label switch paths (LSPs) are defined by stitching LDP LSPs with
	SR LSPs, it is necessary to have mechanisms allowing the verification		SR LSPs, it is necessary to have mechanisms allowing the verification
	skipping to change at page 17, line 43 ¶		skipping to change at page 17, line 43 ¶
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@alcatel-lucent.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
	Email: Jeff.Tantsura@ericsson.com		Email: Jeff.Tantsura@ericsson.com
	11. References		11. References
	11.1. Normative References		11.1. Normative References
			[I-D.ietf-spring-conflict-resolution]
			Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
			"Segment Routing Conflict Resolution", draft-ietf-spring-
			conflict-resolution-01 (work in progress), June 2016.
			[I-D.ietf-spring-segment-routing]
			Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
			and R. Shakir, "Segment Routing Architecture", draft-ietf-
			spring-segment-routing-08 (work in progress), May 2016.
			[I-D.ietf-spring-segment-routing-mpls]
			Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
			Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
			and E. Crabbe, "Segment Routing with MPLS data plane",
			draft-ietf-spring-segment-routing-mpls-04 (work in
			progress), March 2016.
	[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>.
	11.2. Informative References		11.2. Informative References
	[I-D.francois-rtgwg-segment-routing-ti-lfa]		[I-D.francois-rtgwg-segment-routing-ti-lfa]
	Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,		Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
	"Topology Independent Fast Reroute using Segment Routing",		"Topology Independent Fast Reroute using Segment Routing",
	draft-francois-rtgwg-segment-routing-ti-lfa-01 (work in		draft-francois-rtgwg-segment-routing-ti-lfa-01 (work in
	progress), May 2016.		progress), May 2016.
	[I-D.ginsberg-spring-conflict-resolution]
	Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
	"Segment Routing Conflict Resolution", draft-ginsberg-
	spring-conflict-resolution-01 (work in progress), April
	2016.
	[I-D.ietf-isis-segment-routing-extensions]		[I-D.ietf-isis-segment-routing-extensions]
	Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,		Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
	Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS		Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
	Extensions for Segment Routing", draft-ietf-isis-segment-		Extensions for Segment Routing", draft-ietf-isis-segment-
	routing-extensions-06 (work in progress), December 2015.		routing-extensions-07 (work in progress), June 2016.
	[I-D.ietf-mpls-spring-lsp-ping]		[I-D.ietf-mpls-spring-lsp-ping]
	Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,		Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
	S., Gredler, H., and M. Chen, "Label Switched Path (LSP)		S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
	Ping/Trace for Segment Routing Networks Using MPLS		Ping/Trace for Segment Routing Networks Using MPLS
	Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in		Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in
	progress), May 2016.		progress), May 2016.
	[I-D.ietf-ospf-ospfv3-segment-routing-extensions]		[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
	Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,		Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	skipping to change at page 18, line 43 ¶		skipping to change at page 19, line 5 ¶
	Extensions for Segment Routing", draft-ietf-ospf-ospfv3-		Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
	segment-routing-extensions-05 (work in progress), March		segment-routing-extensions-05 (work in progress), March
	2016.		2016.
	[I-D.ietf-ospf-segment-routing-extensions]		[I-D.ietf-ospf-segment-routing-extensions]
	Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,		Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	Shakir, R., Henderickx, W., and J. Tantsura, "OSPF		Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
	Extensions for Segment Routing", draft-ietf-ospf-segment-		Extensions for Segment Routing", draft-ietf-ospf-segment-
	routing-extensions-08 (work in progress), April 2016.		routing-extensions-08 (work in progress), April 2016.
	[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and R. Shakir, "Segment Routing Architecture", draft-ietf-
	spring-segment-routing-08 (work in progress), May 2016.
	[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
	and E. Crabbe, "Segment Routing with MPLS data plane",
	draft-ietf-spring-segment-routing-mpls-04 (work in
	progress), March 2016.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <http://www.rfc-editor.org/info/rfc4364>.		2006, <http://www.rfc-editor.org/info/rfc4364>.
	[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,		[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
	"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,		"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
	October 2007, <http://www.rfc-editor.org/info/rfc5036>.		October 2007, <http://www.rfc-editor.org/info/rfc5036>.
	[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS		[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
	Transport Profile Data Plane Architecture", RFC 5960,		Transport Profile Data Plane Architecture", RFC 5960,
End of changes. 14 change blocks.
	31 lines changed or deleted		46 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/