Diff: draft-ietf-isis-segment-routing-extensions-05.txt - draft-ietf-isis-segment-routing-extensions-06.txt

	< draft-ietf-isis-segment-routing-extensions-05.txt	draft-ietf-isis-segment-routing-extensions-06.txt >

	IS-IS for IP Internets S. Previdi, Ed.	IS-IS for IP Internets S. Previdi, Ed.
	Internet-Draft C. Filsfils	Internet-Draft C. Filsfils
	Intended status: Standards Track A. Bashandy	Intended status: Standards Track A. Bashandy

	Expires: January 1, 2016 Cisco Systems, Inc.	Expires: June 16, 2016 Cisco Systems, Inc.
	H. Gredler	H. Gredler

	Juniper Networks, Inc.	Individual
	S. Litkowski	S. Litkowski
	B. Decraene	B. Decraene
	Orange	Orange
	J. Tantsura	J. Tantsura
	Ericsson	Ericsson

	June 30, 2015	December 14, 2015

	IS-IS Extensions for Segment Routing	IS-IS Extensions for Segment Routing

	draft-ietf-isis-segment-routing-extensions-05	draft-ietf-isis-segment-routing-extensions-06

	Abstract	Abstract

	Segment Routing (SR) allows for a flexible definition of end-to-end	Segment Routing (SR) allows for a flexible definition of end-to-end
	paths within IGP topologies by encoding paths as sequences of	paths within IGP topologies by encoding paths as sequences of
	topological sub-paths, called "segments". These segments are	topological sub-paths, called "segments". These segments are
	advertised by the link-state routing protocols (IS-IS and OSPF).	advertised by the link-state routing protocols (IS-IS and OSPF).

	This draft describes the necessary IS-IS extensions that need to be	This draft describes the necessary IS-IS extensions that need to be
	introduced for Segment Routing.	introduced for Segment Routing.

	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 January 1, 2016.	This Internet-Draft will expire on June 16, 2016.

	Copyright Notice	Copyright Notice

	Copyright (c) 2015 IETF Trust and the persons identified as the	Copyright (c) 2015 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 3, line 15 ¶	skipping to change at page 3, line 15 ¶
	4. Non backward compatible changes with prior versions of this	4. Non backward compatible changes with prior versions of this
	document . . . . . . . . . . . . . . . . . . . . . . . . . . 29	document . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 29	4.1. Encoding of Multiple SRGBs . . . . . . . . . . . . . . . 29
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	5.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 30	5.1. Sub TLVs for Type 22,23,222 and 223 . . . . . . . . . . . 30
	5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 31	5.2. Sub TLVs for Type 135,235,236 and 237 . . . . . . . . . . 31
	5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 31	5.3. Sub TLVs for Type 242 . . . . . . . . . . . . . . . . . . 31
	5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 31	5.4. New TLV Codepoint and Sub-TLV registry . . . . . . . . . 31
	6. Manageability Considerations . . . . . . . . . . . . . . . . 34	6. Manageability Considerations . . . . . . . . . . . . . . . . 34
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 34	7. Security Considerations . . . . . . . . . . . . . . . . . . . 34

	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	10.1. Normative References . . . . . . . . . . . . . . . . . . 34	10.1. Normative References . . . . . . . . . . . . . . . . . . 35
	10.2. Informative References . . . . . . . . . . . . . . . . . 35	10.2. Informative References . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37

	1. Introduction	1. Introduction

	Segment Routing (SR) allows for a flexible definition of end-to-end	Segment Routing (SR) allows for a flexible definition of end-to-end
	paths within IGP topologies by encoding paths as sequences of	paths within IGP topologies by encoding paths as sequences of
	topological sub-paths, called "segments". These segments are	topological sub-paths, called "segments". These segments are
	advertised by the link-state routing protocols (IS-IS and OSPF). Two	advertised by the link-state routing protocols (IS-IS and OSPF). Two
	types of segments are defined, Prefix segments and Adjacency	types of segments are defined, Prefix segments and Adjacency
	segments. Prefix segments represent an ecmp-aware shortest-path to a	segments. Prefix segments represent an ecmp-aware shortest-path to a
	prefix, as per the state of the IGP topology. Adjacency segments	prefix, as per the state of the IGP topology. Adjacency segments

	skipping to change at page 18, line 25 ¶	skipping to change at page 18, line 25 ¶
	\| 51 \|	\| 51 \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	It is not expected that a network operator will be able to keep fully	It is not expected that a network operator will be able to keep fully
	continuous FEC Prefix / SID/Index mappings. In order to support	continuous FEC Prefix / SID/Index mappings. In order to support
	noncontinuous mapping ranges an implementation MAY generate several	noncontinuous mapping ranges an implementation MAY generate several
	instances of Binding TLVs.	instances of Binding TLVs.

	For example if a router wants to advertise the following ranges:	For example if a router wants to advertise the following ranges:


	Range 16: { 192.168.1.1-15, Index 1-15 }	Range 16: { 192.0.2.1-15, Index 1-15 }


	Range 6: { 192.168.1.22-27, Index 22-27 }	Range 6: { 192.0.2.22-27, Index 22-27 }


	Range 41: { 192.168.1.44-84, Index 80-120 }	Range 41: { 192.0.2.44-84, Index 80-120 }

	A router would need to advertise three instances of the Binding TLV.	A router would need to advertise three instances of the Binding TLV.

	2.4.4. Prefix Length, Prefix	2.4.4. Prefix Length, Prefix

	The 'FEC Prefix' represents the Forwarding equivalence class at the	The 'FEC Prefix' represents the Forwarding equivalence class at the
	tail-end of the advertised path. The 'FEC Prefix' does not need to	tail-end of the advertised path. The 'FEC Prefix' does not need to
	correspond to a routable prefix of the originating node.	correspond to a routable prefix of the originating node.

	The 'Prefix Length' field contains the length of the prefix in bits.	The 'Prefix Length' field contains the length of the prefix in bits.

	skipping to change at page 27, line 40 ¶	skipping to change at page 27, line 40 ¶
	advertised descriptors will create label churn in the FIB and	advertised descriptors will create label churn in the FIB and
	blackhole / misdirect some traffic during the IGP convergence. In	blackhole / misdirect some traffic during the IGP convergence. In
	particular, if a range which is not the last is extended it's	particular, if a range which is not the last is extended it's
	preferable to add a new range rather than extending the previously	preferable to add a new range rather than extending the previously
	advertised range.	advertised range.

	The originating router MUST ensure the order is same after a graceful	The originating router MUST ensure the order is same after a graceful
	restart (using checkpointing, non-volatile storage or any other	restart (using checkpointing, non-volatile storage or any other
	mechanism) in order to guarantee the same order before and after GR.	mechanism) in order to guarantee the same order before and after GR.


	The originating router MUST NOT advertise overlapping ranges. A	The originating router MUST NOT advertise overlapping ranges.
	router receiving multiple overlapping ranges MUST ignore all of them
	and SHOULD log an error message.	When a router receives multiple overlapping ranges, it MUST conform
		to the procedures defined in
		[I-D.ginsberg-spring-conflict-resolution].

	Here follows an example of advertisement of multiple ranges:	Here follows an example of advertisement of multiple ranges:

	The originating router advertises following ranges:	The originating router advertises following ranges:
	SR-Cap: range: 100, SID value: 100	SR-Cap: range: 100, SID value: 100
	SR-Cap: range: 100, SID value: 1000	SR-Cap: range: 100, SID value: 1000
	SR-Cap: range: 100, SID value: 500	SR-Cap: range: 100, SID value: 500

	The receiving routers concatenate the ranges in the received	The receiving routers concatenate the ranges in the received
	order and build the SRGB as follows:	order and build the SRGB as follows:

	skipping to change at page 34, line 18 ¶	skipping to change at page 34, line 18 ¶
	Reference: This document (Section 2.4.13)	Reference: This document (Section 2.4.13)

	6. Manageability Considerations	6. Manageability Considerations

	TBD	TBD

	7. Security Considerations	7. Security Considerations

	TBD	TBD


	8. Contributors	8. Acknowledgements

		We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
		Francois and Jesper Skrivers for their contribution to the content of
		this document.

		Many thanks to Yakov Rekhter and Ina Minei for their contribution on
		earlier definition of the "Binding / MPLS Label TLV".

		9. Contributors

	The following people gave a substantial contribution to the content	The following people gave a substantial contribution to the content

	of this document: Les Ginsberg, Martin Horneffer, Igor Milojevic, Rob	of this document and should be considered as co-authors:
	Shakir, Saku Ytti, Wim Henderickx, Steven Luong and Jesper Skriver.


	9. Acknowledgements	Les Ginsberg
		Cisco Systems Inc.
		US


	We would like to thank Dave Ward, Dan Frost, Stewart Bryant and	Email: ginsberg@cisco.com
	Pierre Francois for their contribution to the content of this
	document.


	Many thanks to Yakov Rekhter and Ina Minei for their contribution on	Martin Horneffer
	earlier incarnations of the "Binding / MPLS Label TLV".	Deutsche Telekom
		DE

		Email: Martin.Horneffer@telekom.de

		Wim Henderickx
		Alcatel-Lucent
		BE

		Email: wim.henderickx@alcatel-lucent.com
		Edward Crabbe
		Individual
		US

		Email: edward.crabbe@gmail.com

		Rob Shakir
		Individual
		UK

		Email: rjs@rob.sh

		Igor Milojevic
		Individual
		RS

		Email: milojevicigor@gmail.com

		Saku Ytti
		TDC
		FI

		Email: saku@ytti.fi

		Steven Luong
		Cisco Systems Inc.
		US

		Email: sluong@cisco.com

	10. References	10. References

	10.1. Normative References	10.1. Normative References


		[I-D.ginsberg-spring-conflict-resolution]
		Ginsberg, L., Psenak, P., and S. Previdi, "Segment Routing
		Conflict Resolution", draft-ginsberg-spring-conflict-
		resolution-00 (work in progress), October 2015.

	[I-D.ietf-isis-prefix-attributes]	[I-D.ietf-isis-prefix-attributes]
	Ginsberg, L., Decraene, B., Filsfils, C., Litkowski, S.,	Ginsberg, L., Decraene, B., Filsfils, C., Litkowski, S.,
	Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix	Previdi, S., Xu, X., and U. Chunduri, "IS-IS Prefix
	Attributes for Extended IP and IPv6 Reachability", draft-	Attributes for Extended IP and IPv6 Reachability", draft-

	ietf-isis-prefix-attributes-01 (work in progress), June	ietf-isis-prefix-attributes-02 (work in progress),
	2015.	December 2015.

	[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. Shakir, "Segment Routing Architecture", draft-ietf-	and r. rjs@rob.sh, "Segment Routing Architecture", draft-
	spring-segment-routing-03 (work in progress), May 2015.	ietf-spring-segment-routing-06 (work in progress), October
		2015.

	[ISO10589]	[ISO10589]
	International Organization for Standardization,	International Organization for Standardization,
	"Intermediate system to Intermediate system intra-domain	"Intermediate system to Intermediate system intra-domain
	routeing information exchange protocol for use in	routeing information exchange protocol for use in
	conjunction with the protocol for providing the	conjunction with the protocol for providing the

	connectionless-mode Network Service (ISO 8473)", ISO/IEC	connectionless-mode Network Service (ISO 8473)", ISO/
	10589:2002, Second Edition, Nov 2002.	IEC 10589:2002, Second Edition, Nov 2002.

	[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, March 1997.	Requirement Levels", BCP 14, RFC 2119,
		DOI 10.17487/RFC2119, March 1997,
		<http://www.rfc-editor.org/info/rfc2119>.


	[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate	[RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
	System to Intermediate System (IS-IS) Extensions for	"Intermediate System to Intermediate System (IS-IS)
	Advertising Router Information", RFC 4971, July 2007.	Extensions for Advertising Router Information", RFC 4971,
		DOI 10.17487/RFC4971, July 2007,
		<http://www.rfc-editor.org/info/rfc4971>.

	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	Topology (MT) Routing in Intermediate System to	Topology (MT) Routing in Intermediate System to

	Intermediate Systems (IS-ISs)", RFC 5120, February 2008.	Intermediate Systems (IS-ISs)", RFC 5120,
		DOI 10.17487/RFC5120, February 2008,
		<http://www.rfc-editor.org/info/rfc5120>.

	[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic	[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic

	Engineering", RFC 5305, October 2008.	Engineering", RFC 5305, DOI 10.17487/RFC5305, October
		2008, <http://www.rfc-editor.org/info/rfc5305>.


	[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October	[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
	2008.	DOI 10.17487/RFC5308, October 2008,
		<http://www.rfc-editor.org/info/rfc5308>.

	[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic	[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic

	Engineering in IS-IS", RFC 6119, February 2011.	Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
		February 2011, <http://www.rfc-editor.org/info/rfc6119>.

	10.2. Informative References	10.2. Informative References

	[I-D.filsfils-spring-segment-routing-use-cases]	[I-D.filsfils-spring-segment-routing-use-cases]
	Filsfils, C., Francois, P., Previdi, S., Decraene, B.,	Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
	Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.	Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
	Crabbe, "Segment Routing Use Cases", draft-filsfils-	Crabbe, "Segment Routing Use Cases", draft-filsfils-
	spring-segment-routing-use-cases-01 (work in progress),	spring-segment-routing-use-cases-01 (work in progress),
	October 2014.	October 2014.

	[I-D.ietf-spring-resiliency-use-cases]	[I-D.ietf-spring-resiliency-use-cases]

	Francois, P., Filsfils, C., Decraene, B., and R. Shakir,	Francois, P., Filsfils, C., Decraene, B., and r.
	"Use-cases for Resiliency in SPRING", draft-ietf-spring-	rjs@rob.sh, "Use-cases for Resiliency in SPRING", draft-
	resiliency-use-cases-01 (work in progress), March 2015.	ietf-spring-resiliency-use-cases-02 (work in progress),
		December 2015.

	[I-D.previdi-6man-segment-routing-header]	[I-D.previdi-6man-segment-routing-header]

	Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6	Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
	Segment Routing Header (SRH)", draft-previdi-6man-segment-	J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
	routing-header-06 (work in progress), May 2015.	Routing Header (SRH)", draft-previdi-6man-segment-routing-
		header-08 (work in progress), October 2015.

	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP

	Tunnels", RFC 3209, December 2001.	Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
		<http://www.rfc-editor.org/info/rfc3209>.

	[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links	[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
	in Resource ReSerVation Protocol - Traffic Engineering	in Resource ReSerVation Protocol - Traffic Engineering

	(RSVP-TE)", RFC 3477, January 2003.	(RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
		<http://www.rfc-editor.org/info/rfc3477>.


	[RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand,	[RFC5311] McPherson, D., Ed., Ginsberg, L., Previdi, S., and M.
	"Simplified Extension of Link State PDU (LSP) Space for	Shand, "Simplified Extension of Link State PDU (LSP) Space
	IS-IS", RFC 5311, February 2009.	for IS-IS", RFC 5311, DOI 10.17487/RFC5311, February 2009,
		<http://www.rfc-editor.org/info/rfc5311>.

	[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in	[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
	Support of Inter-Autonomous System (AS) MPLS and GMPLS	Support of Inter-Autonomous System (AS) MPLS and GMPLS

	Traffic Engineering", RFC 5316, December 2008.	Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
		December 2008, <http://www.rfc-editor.org/info/rfc5316>.

	Authors' Addresses	Authors' Addresses


	Stefano Previdi (editor)	Stefano Previdi (editor)
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Via Del Serafico, 200	Via Del Serafico, 200
	Rome 00142	Rome 00142
	Italy	Italy

	Email: sprevidi@cisco.com	Email: sprevidi@cisco.com

	Clarence Filsfils	Clarence Filsfils
	Cisco Systems, Inc.	Cisco Systems, Inc.

	skipping to change at page 37, line 4 ¶	skipping to change at page 38, line 26 ¶

	Email: cfilsfil@cisco.com	Email: cfilsfil@cisco.com

	Ahmed Bashandy	Ahmed Bashandy
	Cisco Systems, Inc.	Cisco Systems, Inc.
	170, West Tasman Drive	170, West Tasman Drive
	San Jose, CA 95134	San Jose, CA 95134
	US	US

	Email: bashandy@cisco.com	Email: bashandy@cisco.com


	Hannes Gredler	Hannes Gredler

	Juniper Networks, Inc.	Individual
	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089
	US


	Email: hannes@juniper.net	Email: hannes@gredler.at

	Stephane Litkowski	Stephane Litkowski
	Orange	Orange
	FR	FR

	Email: stephane.litkowski@orange.com	Email: stephane.litkowski@orange.com

	Bruno Decraene	Bruno Decraene
	Orange	Orange
	FR	FR

End of changes. 35 change blocks.
	59 lines changed or deleted	125 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/