< draft-ietf-spring-segment-routing-mpls-03.txt		draft-ietf-spring-segment-routing-mpls-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: August 4, 2016 Cisco Systems, Inc.		Expires: September 19, 2016 Cisco Systems, Inc.
	B. Decraene		B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	M. Horneffer		M. Horneffer
	Deutsche Telekom		Deutsche Telekom
	R. Shakir		R. Shakir
	Jive Communications		Jive Communications
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	E. Crabbe		E. Crabbe
	Individual		Individual
	February 1, 2016		March 18, 2016
	Segment Routing with MPLS data plane		Segment Routing with MPLS data plane
	draft-ietf-spring-segment-routing-mpls-03		draft-ietf-spring-segment-routing-mpls-04
	Abstract		Abstract
	Segment Routing (SR) leverages the source routing paradigm. A node		Segment Routing (SR) leverages the source routing paradigm. A node
	steers a packet through a controlled set of instructions, called		steers a packet through a controlled set of instructions, called
	segments, by prepending the packet with an SR header. A segment can		segments, by prepending the packet with an SR header. A segment can
	represent any instruction, topological or service-based. SR allows		represent any instruction, topological or service-based. SR allows
	to enforce a flow through any topological path and service chain		to enforce a flow through any topological path and service chain
	while maintaining per-flow state only at the ingress node to the SR		while maintaining per-flow state only at the ingress node to the SR
	domain.		domain.
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 12 ¶
	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 August 4, 2016.		This Internet-Draft will expire on September 19, 2016.
	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 10, line 6 ¶		skipping to change at page 10, line 6 ¶
	o SL1, SL3, L4 and SL5 are LDP capable.		o SL1, SL3, L4 and SL5 are LDP capable.
	o SL1 has a directed LDP session with SL3 and is able to retrieve		o SL1 has a directed LDP session with SL3 and is able to retrieve
	the SL3 local LDP mapping for FEC SL5: 35		the SL3 local LDP mapping for FEC SL5: 35
	o The following source-routed policy is defined in SL1 for the		o The following source-routed policy is defined in SL1 for the
	traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of		traffic destined to S6: use path SL1-S2-SL3-L4-SL5-S6 (instead of
	shortest-path SL1-S2-SL3-S6).		shortest-path SL1-S2-SL3-S6).
	This is realized by programming the following segment-routing policy		This is realized by programming the following segment-routing policy
	at S1: for traffic destined to S6, push the ordered segment list:		at SL1: for traffic destined to S6, push the ordered segment list:
	{1003, 35, 1006}, where:		{1003, 35, 1006}, where:
	o 1003 gets the packets from S1 to SL3 via S2.		o 1003 gets the packets from SL1 to SL3 via S2.
	o 35 gets the packets from SL3 to SL5 via L4.		o 35 gets the packets from SL3 to SL5 via L4.
	o 1006 gets the packets from SL5 to S6.		o 1006 gets the packets from SL5 to S6.
	The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6		The above allows to steer the traffic into path SL1-S2-SL3-L4-SL5-S6
	instead of the shortest path SL1-S2-SL3-S6.		instead of the shortest path SL1-S2-SL3-S6.
	5.2. RSVP-TE LSP segment combined with IGP segments		5.2. RSVP-TE LSP segment combined with IGP segments
	skipping to change at page 10, line 36 ¶		skipping to change at page 10, line 36 ¶
	Figure 5: RSVP-TE LSP segment combined with IGP segments		Figure 5: RSVP-TE LSP segment combined with IGP segments
	We assume that:		We assume that:
	o All links have an IGP cost of 1 except link RS3-S6 which has cost		o All links have an IGP cost of 1 except link RS3-S6 which has cost
	2.		2.
	o All nodes are IGP-SR capable except R4.		o All nodes are IGP-SR capable except R4.
	o RS3 and R6 have, respectively, index 3 and 6 assigned to them.		o RS3 and S6 have, respectively, index 3 and 6 assigned to them.
	o All SR nodes have the same SRGB consisting of: [1000, 1999]		o All SR nodes have the same SRGB consisting of: [1000, 1999]
	o RS3, R4 and RS5 are RSVP-TE capable.		o RS3, R4 and RS5 are RSVP-TE capable.
	o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4.		o An RSVP-TE LSP has been provisioned from RS3 to RS5 via R4.
	o RS3 allocates a binding SID (with value of 135) for this RSVP-TE		o RS3 allocates a binding SID (with value of 135) for this RSVP-TE
	LSP and signals it in the igp.		LSP and signals it in the igp.
	skipping to change at page 12, line 9 ¶		skipping to change at page 12, line 9 ¶
	Wim Henderickx		Wim Henderickx
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@alcatel-lucent.com
	Igor Milojevic		Igor Milojevic
	Email: milojevicigor@gmail.com		Email: milojevicigor@gmail.com
	Saku Ytti		Saku Ytti
	Email: saku@ytti.fi		Email: saku@ytti.fi
	11. Acknowledgements		11. Acknowledgements
			The authors would like to thank Les Ginsberg and Shah Himanshu for
			their comments on this document.
	12. References		12. References
	12.1. Normative References		12.1. Normative 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>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	skipping to change at page 13, line 20 ¶		skipping to change at page 13, line 20 ¶
	2015.		2015.
	[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-06 (work in progress), December 2015.		routing-extensions-06 (work in progress), December 2015.
	[I-D.ietf-spring-problem-statement]		[I-D.ietf-spring-problem-statement]
	Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,		Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
	Horneffer, M., and r. rjs@rob.sh, "SPRING Problem		Horneffer, M., and R. Shakir, "SPRING Problem Statement
	Statement and Requirements", draft-ietf-spring-problem-		and Requirements", draft-ietf-spring-problem-statement-07
	statement-06 (work in progress), December 2015.		(work in progress), March 2016.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and r. rjs@rob.sh, "Segment Routing Architecture", draft-		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	ietf-spring-segment-routing-07 (work in progress),		spring-segment-routing-07 (work in progress), December
	December 2015.		2015.
	[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.		[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
	Zappala, "Source Demand Routing: Packet Format and		Zappala, "Source Demand Routing: Packet Format and
	Forwarding Specification (Version 1)", RFC 1940,		Forwarding Specification (Version 1)", RFC 1940,
	DOI 10.17487/RFC1940, May 1996,		DOI 10.17487/RFC1940, May 1996,
	<http://www.rfc-editor.org/info/rfc1940>.		<http://www.rfc-editor.org/info/rfc1940>.
	[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP		[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
	Synchronization", RFC 5443, DOI 10.17487/RFC5443, March		Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
	2009, <http://www.rfc-editor.org/info/rfc5443>.		2009, <http://www.rfc-editor.org/info/rfc5443>.
End of changes. 10 change blocks.
	13 lines changed or deleted		16 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/