Diff: draft-filsfils-spring-srv6-network-programming-04.txt - draft-filsfils-spring-srv6-network-programming-05.txt

	< draft-filsfils-spring-srv6-network-programming-04.txt	draft-filsfils-spring-srv6-network-programming-05.txt >

	SPRING C. Filsfils	SPRING C. Filsfils

	Internet-Draft Cisco Systems, Inc.	Internet-Draft P. Camarillo, Ed.
	Intended status: Standards Track Z. Li	Intended status: Standards Track Cisco Systems, Inc.
	Expires: September 5, 2018 Huawei Technologies	Expires: January 3, 2019 J. Leddy
	J. Leddy
	Comcast	Comcast
	D. Voyer	D. Voyer

	D. Bernier
	Bell Canada	Bell Canada

	D. Steinberg
	Steinberg Consulting
	R. Raszuk
	Bloomberg LP
	S. Matsushima	S. Matsushima
	SoftBank	SoftBank

	D. Lebrun	Z. Li
	Universite catholique de Louvain	Huawei Technologies
	B. Decraene	July 2, 2018
	Orange
	B. Peirens
	Proximus
	S. Salsano
	Universita di Roma "Tor Vergata"
	G. Naik
	Drexel University
	H. Elmalky
	Ericsson
	P. Jonnalagadda
	M. Sharif
	Barefoot Networks
	A. Ayyangar
	Arista
	S. Mynam
	Innovium Inc.
	W. Henderickx
	Nokia
	S. Ma
	Juniper
	A. Bashandy
	K. Raza
	D. Dukes
	F. Clad
	P. Camarillo, Ed.
	Cisco Systems, Inc.
	March 4, 2018

	SRv6 Network Programming	SRv6 Network Programming

	draft-filsfils-spring-srv6-network-programming-04	draft-filsfils-spring-srv6-network-programming-05

	Abstract	Abstract

	This document describes the SRv6 network programming concept and its	This document describes the SRv6 network programming concept and its
	most basic functions.	most basic functions.

	Requirements Language	Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

	skipping to change at page 2, line 31 ¶	skipping to change at page 1, line 45 ¶
	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 https://datatracker.ietf.org/drafts/current/.	Drafts is at https://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 September 5, 2018.	This Internet-Draft will expire on January 3, 2019.

	Copyright Notice	Copyright Notice

	Copyright (c) 2018 IETF Trust and the persons identified as the	Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of	(https://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
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . 5	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 6	3. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Functions associated with a SID . . . . . . . . . . . . . . . 8	4. Functions associated with a SID . . . . . . . . . . . . . . . 7
	4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 10	4.1. End: Endpoint . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 10	4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 9
	4.3. End.T: Endpoint with specific IPv6 table lookup . . . . . 11	4.3. End.T: Endpoint with specific IPv6 table lookup . . . . . 10
	4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross-	4.4. End.DX2: Endpoint with decapsulation and Layer-2 cross-

	connect . . . . . . . . . . . . . . . . . . . . . . . . . 12	connect . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.5. End.DX2V: Endpoint with decapsulation and VLAN L2 table	4.5. End.DX2V: Endpoint with decapsulation and VLAN L2 table

	lookup . . . . . . . . . . . . . . . . . . . . . . . . . 12	lookup . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.6. End.DT2U: Endpoint with decapsulation and unicast MAC L2	4.6. End.DT2U: Endpoint with decapsulation and unicast MAC L2

	table lookup . . . . . . . . . . . . . . . . . . . . . . 13	table lookup . . . . . . . . . . . . . . . . . . . . . . 12
	4.7. End.DT2M: Endpoint with decapsulation and L2 table	4.7. End.DT2M: Endpoint with decapsulation and L2 table

	flooding . . . . . . . . . . . . . . . . . . . . . . . . 14	flooding . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.8. End.DX6: Endpoint with decapsulation and IPv6 cross-	4.8. End.DX6: Endpoint with decapsulation and IPv6 cross-

	connect . . . . . . . . . . . . . . . . . . . . . . . . . 14	connect . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.9. End.DX4: Endpoint with decapsulation and IPv4 cross-	4.9. End.DX4: Endpoint with decapsulation and IPv4 cross-

	connect . . . . . . . . . . . . . . . . . . . . . . . . . 15	connect . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.10. End.DT6: Endpoint with decapsulation and specific IPv6	4.10. End.DT6: Endpoint with decapsulation and specific IPv6

	table lookup . . . . . . . . . . . . . . . . . . . . . . 16	table lookup . . . . . . . . . . . . . . . . . . . . . . 15
	4.11. End.DT4: Endpoint with decapsulation and specific IPv4	4.11. End.DT4: Endpoint with decapsulation and specific IPv4

	table lookup . . . . . . . . . . . . . . . . . . . . . . 16	table lookup . . . . . . . . . . . . . . . . . . . . . . 15
	4.12. End.DT46: Endpoint with decapsulation and specific IP	4.12. End.DT46: Endpoint with decapsulation and specific IP

	table lookup . . . . . . . . . . . . . . . . . . . . . . 17	table lookup . . . . . . . . . . . . . . . . . . . . . . 16
	4.13. End.B6: Endpoint bound to an SRv6 policy . . . . . . . . 18	4.13. End.B6: Endpoint bound to an SRv6 policy . . . . . . . . 17
	4.14. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation	4.14. End.B6.Red: Endpoint bound to an SRv6 reduced policy . . 17
		4.15. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation
	policy . . . . . . . . . . . . . . . . . . . . . . . . . 18	policy . . . . . . . . . . . . . . . . . . . . . . . . . 18

	4.15. End.B6.Encaps.Red: Endpoint bound to an SRv6 reduced	4.16. End.B6.Encaps.Red: Endpoint bound to an SRv6 reduced
	encapsulation policy . . . . . . . . . . . . . . . . . . 19	encapsulation policy . . . . . . . . . . . . . . . . . . 18
	4.16. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 19
	4.17. End.S: Endpoint in search of a target in table T . . . . 20	4.17. End.BM: Endpoint bound to an SR-MPLS policy . . . . . . . 18
	4.18. SR-aware application . . . . . . . . . . . . . . . . . . 20	4.18. End.S: Endpoint in search of a target in table T . . . . 19
	4.19. Non SR-aware application . . . . . . . . . . . . . . . . 21	4.19. SR-aware application . . . . . . . . . . . . . . . . . . 19
	4.20. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 21	4.20. Non SR-aware application . . . . . . . . . . . . . . . . 20
	4.20.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 21	4.21. Flavours . . . . . . . . . . . . . . . . . . . . . . . . 20
	4.20.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 21	4.21.1. PSP: Penultimate Segment Pop of the SRH . . . . . . 20
	5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 22	4.21.2. USP: Ultimate Segment Pop of the SRH . . . . . . . . 21
	5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 22	5. Transit behaviors . . . . . . . . . . . . . . . . . . . . . . 21
		5.1. T: Transit behavior . . . . . . . . . . . . . . . . . . . 21
	5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 22	5.2. T.Insert: Transit with insertion of an SRv6 Policy . . . 22
	5.3. T.Insert.Red: Transit with reduced insertion of an SRv6	5.3. T.Insert.Red: Transit with reduced insertion of an SRv6

	Policy . . . . . . . . . . . . . . . . . . . . . . . . . 23	Policy . . . . . . . . . . . . . . . . . . . . . . . . . 22
	5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy . 23	5.4. T.Encaps: Transit with encapsulation in an SRv6 Policy . 23
	5.5. T.Encaps.Red: Transit with reduce encaps in an SRv6	5.5. T.Encaps.Red: Transit with reduce encaps in an SRv6

	Policy . . . . . . . . . . . . . . . . . . . . . . . . . 24	Policy . . . . . . . . . . . . . . . . . . . . . . . . . 23
	5.6. T.Encaps.L2: Transit with encapsulation of L2 frames . . 25	5.6. T.Encaps.L2: Transit with encapsulation of L2 frames . . 24
	5.7. T.Encaps.L2.Red: Transit with reduce encaps of L2 frames	5.7. T.Encaps.L2.Red: Transit with reduce encaps of L2 frames

	in an SRv6 Policy . . . . . . . . . . . . . . . . . . . . 25	in an SRv6 Policy . . . . . . . . . . . . . . . . . . . . 24
	6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 25	6. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 25	6.1. Counters . . . . . . . . . . . . . . . . . . . . . . . . 25

	6.2. Flow-based hash computation . . . . . . . . . . . . . . . 26	6.2. Flow-based hash computation . . . . . . . . . . . . . . . 25
	6.3. O-bit processing . . . . . . . . . . . . . . . . . . . . 26	6.3. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	6.4. End.OTP: OAM Endpoint with Timestamp and Punt . . . . . . 27	7. Basic security for intra-domain deployment . . . . . . . . . 26
	7. Basic security for intra-domain deployment . . . . . . . . . 27	7.1. SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	7.1. SEC 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 28	7.2. SEC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.2. SEC 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 28	7.3. SEC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.3. SEC 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 29	7.4. SEC 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	7.4. SEC 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 29	8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 27
	8. Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 29	8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	8.1. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 29	8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 28
	8.2. BGP-LS . . . . . . . . . . . . . . . . . . . . . . . . . 30	8.3. BGP IP/VPN . . . . . . . . . . . . . . . . . . . . . . . 28
	8.3. BGP IP/VPN . . . . . . . . . . . . . . . . . . . . . . . 30	8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 28
	8.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 30	9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 30
	9. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 32	9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 30
	9.1. Simplified SID allocation . . . . . . . . . . . . . . . . 32	9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 31
	9.2. Reference diagram . . . . . . . . . . . . . . . . . . . . 33	9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 31
	9.3. Basic security . . . . . . . . . . . . . . . . . . . . . 33	9.4. SR-IPVPN . . . . . . . . . . . . . . . . . . . . . . . . 31
	9.4. SR-IPVPN . . . . . . . . . . . . . . . . . . . . . . . . 33	9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 32
	9.5. SR-Ethernet-VPWS . . . . . . . . . . . . . . . . . . . . 34	9.6. SR-EVPN-FXC . . . . . . . . . . . . . . . . . . . . . . . 33
	9.6. SR-EVPN-FXC . . . . . . . . . . . . . . . . . . . . . . . 35	9.7. SR-EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 34
	9.7. SR-EVPN . . . . . . . . . . . . . . . . . . . . . . . . . 36	9.7.1. EVPN Bridging . . . . . . . . . . . . . . . . . . . . 34
	9.7.1. EVPN Bridging . . . . . . . . . . . . . . . . . . . . 36	9.7.2. EVPN Multi-homing with ESI filtering . . . . . . . . 36
	9.7.2. EVPN Multi-homing with ESI filtering . . . . . . . . 38	9.7.3. EVPN Layer-3 . . . . . . . . . . . . . . . . . . . . 37
	9.7.3. EVPN Layer-3 . . . . . . . . . . . . . . . . . . . . 39	9.7.4. EVPN Integrated Routing Bridging (IRB) . . . . . . . 37
	9.7.4. EVPN Integrated Routing Bridging (IRB) . . . . . . . 39	9.8. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 38
	9.8. SR TE for Underlay SLA . . . . . . . . . . . . . . . . . 40	9.8.1. SR policy from the Ingress PE . . . . . . . . . . . . 38
	9.8.1. SR policy from the Ingress PE . . . . . . . . . . . . 40	9.8.2. SR policy at a midpoint . . . . . . . . . . . . . . . 39
	9.8.2. SR policy at a midpoint . . . . . . . . . . . . . . . 41	9.9. End-to-End policy with intermediate BSID . . . . . . . . 40
	9.9. End-to-End policy with intermediate BSID . . . . . . . . 42	9.10. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 41
	9.10. TI-LFA . . . . . . . . . . . . . . . . . . . . . . . . . 43	9.11. SR TE for Service programming . . . . . . . . . . . . . . 42
	9.11. SR TE for Service chaining . . . . . . . . . . . . . . . 44	10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 43
	9.12. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 45	10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 43
	9.12.1. Ping to a SID function . . . . . . . . . . . . . . . 45	10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 44
	9.12.2. End-to-end ping using End.OTP . . . . . . . . . . . 46	10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 44
	9.12.3. Segment-by-segment ping using the O-bit . . . . . . 46	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
	10. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 47	12. Work in progress . . . . . . . . . . . . . . . . . . . . . . 46
	10.1. Seamless deployment . . . . . . . . . . . . . . . . . . 47	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
	10.2. Integration . . . . . . . . . . . . . . . . . . . . . . 48	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47
	10.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 48	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48	15.1. Normative References . . . . . . . . . . . . . . . . . . 49
	12. Work in progress . . . . . . . . . . . . . . . . . . . . . . 50	15.2. Informative References . . . . . . . . . . . . . . . . . 50
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
	15.1. Normative References . . . . . . . . . . . . . . . . . . 51
	15.2. Informative References . . . . . . . . . . . . . . . . . 51
	Appendix A. Additional Contributors . . . . . . . . . . . . . . 53
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53

	1. Introduction	1. Introduction

	Segment Routing leverages the source routing paradigm. An ingress	Segment Routing leverages the source routing paradigm. An ingress
	node steers a packet through a ordered list of instructions, called	node steers a packet through a ordered list of instructions, called
	segments. Each one of these instructions represents a function to be	segments. Each one of these instructions represents a function to be
	called at a specific location in the network. A function is locally	called at a specific location in the network. A function is locally
	defined on the node where it is executed and may range from simply	defined on the node where it is executed and may range from simply
	moving forward in the segment list to any complex user-defined	moving forward in the segment list to any complex user-defined
	behavior. The network programming consists in combining segment	behavior. The network programming consists in combining segment
	routing functions, both simple and complex, to achieve a networking	routing functions, both simple and complex, to achieve a networking
	objective that goes beyond mere packet routing.	objective that goes beyond mere packet routing.

	This document illustrates the SRv6 Network Programming concept and	This document illustrates the SRv6 Network Programming concept and
	aims at standardizing the main segment routing functions to enable	aims at standardizing the main segment routing functions to enable
	the creation of interoperable overlays with underlay optimization and	the creation of interoperable overlays with underlay optimization and

	service chaining.	service programming.

	Familiarity with the Segment Routing Header	Familiarity with the Segment Routing Header
	[I-D.ietf-6man-segment-routing-header] is assumed.	[I-D.ietf-6man-segment-routing-header] is assumed.

	2. Terminology	2. Terminology

	SRH is the abbreviation for the Segment Routing Header. We assume	SRH is the abbreviation for the Segment Routing Header. We assume
	that the SRH may be present multiple times inside each packet.	that the SRH may be present multiple times inside each packet.

	NH is the abbreviation of the IPv6 next-header field.	NH is the abbreviation of the IPv6 next-header field.

	skipping to change at page 18, line 45 ¶	skipping to change at page 17, line 45 ¶

	Ref2: In case that an SRH already exists, the new SRH is inserted in	Ref2: In case that an SRH already exists, the new SRH is inserted in
	between the IPv6 header and the received SRH	between the IPv6 header and the received SRH

	Note: Instead of the term "insert", "push" may also be used.	Note: Instead of the term "insert", "push" may also be used.

	The End.B6 function is required to express scalable traffic-	The End.B6 function is required to express scalable traffic-
	engineering policies across multiple domains. This is the SRv6	engineering policies across multiple domains. This is the SRv6
	instantiation of a Binding SID [I-D.ietf-spring-segment-routing].	instantiation of a Binding SID [I-D.ietf-spring-segment-routing].


	4.14. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation policy	4.14. End.B6.Red: Endpoint bound to an SRv6 reduced policy

		This is an optimization of the End.B6 function.

		End.B6.Red will reduce the size of the SRH by one segment by avoiding
		the insertion of the first SID in the pushed SRH. In this way, the
		first segment is only introduced in the DA and the packet is
		forwarded according to it.

		Note that SL value is initially pointing to a non-existing segment in
		the SRH.

		4.15. End.B6.Encaps: Endpoint bound to an SRv6 encapsulation policy

	This is a variation of the End.B6 behavior where the SRv6 Policy also	This is a variation of the End.B6 behavior where the SRv6 Policy also
	includes an IPv6 Source Address A.	includes an IPv6 Source Address A.

	When N receives a packet destined to S and S is a local End.B6.Encaps	When N receives a packet destined to S and S is a local End.B6.Encaps
	SID, N does:	SID, N does:

	1. IF NH=SRH and SL > 0	1. IF NH=SRH and SL > 0
	2. decrement SL and update the IPv6 DA with SRH[SL]	2. decrement SL and update the IPv6 DA with SRH[SL]
	3. push an outer IPv6 header with its own SRH	3. push an outer IPv6 header with its own SRH
	4. set the outer IPv6 SA to A	4. set the outer IPv6 SA to A
	5. set the outer IPv6 DA to the first segment of the SRv6 Policy	5. set the outer IPv6 DA to the first segment of the SRv6 Policy
	6. forward according to the first segment of the SRv6 Policy	6. forward according to the first segment of the SRv6 Policy
	7. ELSE	7. ELSE
	8. drop the packet	8. drop the packet

	Instead of simply inserting an SRH with the policy (End.B6), this	Instead of simply inserting an SRH with the policy (End.B6), this
	behavior also adds an outer IPv6 header. The source address defined	behavior also adds an outer IPv6 header. The source address defined
	for the outer header does not have to be a local SID of the node.	for the outer header does not have to be a local SID of the node.


	4.15. End.B6.Encaps.Red: Endpoint bound to an SRv6 reduced	4.16. End.B6.Encaps.Red: Endpoint bound to an SRv6 reduced
	encapsulation policy	encapsulation policy

	This is an optimization of the End.B6.Encaps function.	This is an optimization of the End.B6.Encaps function.

	End.B6.Encaps.Red will reduce the size of the SRH by one segment by	End.B6.Encaps.Red will reduce the size of the SRH by one segment by
	avoiding the insertion of the first SID in the pushed SRH. In this	avoiding the insertion of the first SID in the pushed SRH. In this
	way, the first segment is only introduced in the DA and the packet is	way, the first segment is only introduced in the DA and the packet is
	forwarded according to it.	forwarded according to it.

	Note that SL value is initially pointing to a non-existing segment in	Note that SL value is initially pointing to a non-existing segment in
	the SRH.	the SRH.


	4.16. End.BM: Endpoint bound to an SR-MPLS policy	4.17. End.BM: Endpoint bound to an SR-MPLS policy

	The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6	The "Endpoint bound to an SR-MPLS Policy" is a variant of the End.B6
	function.	function.

	When N receives a packet destined to S and S is a local End.BM SID, N	When N receives a packet destined to S and S is a local End.BM SID, N
	does:	does:

	1. IF NH=SRH and SL > 0 ;; Ref1	1. IF NH=SRH and SL > 0 ;; Ref1
	2. decrement SL and update the IPv6 DA with SRH[SL]	2. decrement SL and update the IPv6 DA with SRH[SL]
	3. push an MPLS label stack <L1, L2, L3> on the received packet	3. push an MPLS label stack <L1, L2, L3> on the received packet

	skipping to change at page 20, line 8 ¶	skipping to change at page 19, line 21 ¶

	Ref1: an End.BM SID, by definition, is never the last SID.	Ref1: an End.BM SID, by definition, is never the last SID.

	The End.BM function is required to express scalable traffic-	The End.BM function is required to express scalable traffic-
	engineering policies across multiple domains where some domains	engineering policies across multiple domains where some domains
	support the MPLS instantiation of Segment Routing.	support the MPLS instantiation of Segment Routing.

	This is an SRv6 instantiation of a SR-MPLS Binding SID	This is an SRv6 instantiation of a SR-MPLS Binding SID
	[I-D.ietf-spring-segment-routing].	[I-D.ietf-spring-segment-routing].


	4.17. End.S: Endpoint in search of a target in table T	4.18. End.S: Endpoint in search of a target in table T

	The "Endpoint in search of a target in Table T" function (End.S for	The "Endpoint in search of a target in Table T" function (End.S for
	short) is a variant of the End function.	short) is a variant of the End function.

	When N receives a packet destined to S and S is a local End.S SID, N	When N receives a packet destined to S and S is a local End.S SID, N
	does:	does:

	1. IF NH=SRH and SL = 0 ;; Ref1	1. IF NH=SRH and SL = 0 ;; Ref1
	2. drop the packet	2. drop the packet
	3. ELSE IF match(last SID) in specified table T	3. ELSE IF match(last SID) in specified table T

	skipping to change at page 20, line 33 ¶	skipping to change at page 19, line 46 ¶
	Ref1: By definition, an End.S SID cannot be the last SID, as the last	Ref1: By definition, an End.S SID cannot be the last SID, as the last
	SID is the targeted object.	SID is the targeted object.

	The End.S function is required in information-centric networking	The End.S function is required in information-centric networking
	(ICN) use-cases where the last SID in the SRv6 SID list represents a	(ICN) use-cases where the last SID in the SRv6 SID list represents a
	targeted object. If the identification of the object would require	targeted object. If the identification of the object would require
	more than 128 bits, then obvious customization of the End.S function	more than 128 bits, then obvious customization of the End.S function
	may either use multiple SIDs or a TLV of the SR header to encode the	may either use multiple SIDs or a TLV of the SR header to encode the
	searched object ID.	searched object ID.


	4.18. SR-aware application	4.19. SR-aware application

	Generally, any SR-aware application can be bound to an SRv6 SID.	Generally, any SR-aware application can be bound to an SRv6 SID.
	This application could represent anything from a small piece of code	This application could represent anything from a small piece of code
	focused on topological/tenant function to a much larger process	focused on topological/tenant function to a much larger process
	focusing on higher-level applications (e.g. video compression,	focusing on higher-level applications (e.g. video compression,
	transcoding etc.).	transcoding etc.).

	The ways in which an SR-aware application can binds itself on a local	The ways in which an SR-aware application can binds itself on a local
	SID depends on the operating system. Let us consider an SR-aware	SID depends on the operating system. Let us consider an SR-aware
	application running on a Linux operating system. A possible approach	application running on a Linux operating system. A possible approach

	skipping to change at page 21, line 7 ¶	skipping to change at page 20, line 20 ¶
	target interface. In this approach, the SR-aware application can	target interface. In this approach, the SR-aware application can
	simply listen to all packets received on the interface.	simply listen to all packets received on the interface.

	A different approach for the SR-aware app is to listen to packets	A different approach for the SR-aware app is to listen to packets
	received with a specific SRv6 SID as IPv6 DA on a given transport	received with a specific SRv6 SID as IPv6 DA on a given transport
	port (i.e. corresponding to a TCP or UDP socket). In this case, the	port (i.e. corresponding to a TCP or UDP socket). In this case, the
	app can read the SRH information with a getsockopt Linux system call	app can read the SRH information with a getsockopt Linux system call
	and can set the SRH information to be added to the outgoing packets	and can set the SRH information to be added to the outgoing packets
	with a setsocksopt system call.	with a setsocksopt system call.


	4.19. Non SR-aware application	4.20. Non SR-aware application


	[I-D.xu-clad-spring-sr-service-chaining] defines a set of additional	[I-D.xuclad-spring-sr-service-programming] defines a set of
	functions in order to enable non SR-aware applications to be	additional functions in order to enable non SR-aware applications to
	associated with a SRv6 Local SID.	be associated with a SRv6 Local SID.


	4.20. Flavours	4.21. Flavours

	We present the PSP and USP variants of the functions End, End.X and	We present the PSP and USP variants of the functions End, End.X and
	End.T. For each of these functions these variants can be enabled or	End.T. For each of these functions these variants can be enabled or
	disabled either individually or together.	disabled either individually or together.


	4.20.1. PSP: Penultimate Segment Pop of the SRH	4.21.1. PSP: Penultimate Segment Pop of the SRH

	After the instruction 'update the IPv6 DA with SRH[SL]' is executed,	After the instruction 'update the IPv6 DA with SRH[SL]' is executed,
	the following instructions must be added:	the following instructions must be added:

	1. IF updated SL = 0 & PSP is TRUE & O-bit = 0 & A-bit = 0 ;; Ref1	1. IF updated SL = 0 & PSP is TRUE & O-bit = 0 & A-bit = 0 ;; Ref1
	2. pop the top SRH ;; Ref2	2. pop the top SRH ;; Ref2

	Ref1: If the SRH.Flags.O-bit or SRH.Flags.A-bit is set, PSP of the	Ref1: If the SRH.Flags.O-bit or SRH.Flags.A-bit is set, PSP of the
	SRH is disabled. Section 6.1 specifies the pseudocode needed to	SRH is disabled. Section 6.1 specifies the pseudocode needed to
	process the SRH.Flags.O-bit.	process the SRH.Flags.O-bit.

	Ref2: The received SRH had SL=1. When the last SID is written in the	Ref2: The received SRH had SL=1. When the last SID is written in the
	DA, the End, End.X and End.T functions with the PSP flavour pop the	DA, the End, End.X and End.T functions with the PSP flavour pop the
	first (top-most) SRH. Subsequent stacked SRH's may be present but	first (top-most) SRH. Subsequent stacked SRH's may be present but
	are not processed as part of the function.	are not processed as part of the function.


	4.20.2. USP: Ultimate Segment Pop of the SRH	4.21.2. USP: Ultimate Segment Pop of the SRH

	We insert at the beginning of the pseudo-code the following	We insert at the beginning of the pseudo-code the following
	instructions:	instructions:

	1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1	1. IF NH=SRH & SL = 0 & USP=TRUE ;; Ref1
	2. pop the top SRH	2. pop the top SRH
	3. restart the function processing on the modified packet ;; Ref2	3. restart the function processing on the modified packet ;; Ref2

	Ref1: The next header is an SRH header	Ref1: The next header is an SRH header


	skipping to change at page 26, line 31 ¶	skipping to change at page 25, line 44 ¶
	This occurs when the destination address is updated, a FIB lookup is	This occurs when the destination address is updated, a FIB lookup is
	performed and multiple ECMP paths exist to the updated destination	performed and multiple ECMP paths exist to the updated destination
	address.	address.

	This occurs when End.X is bound to an array of adjacencies.	This occurs when End.X is bound to an array of adjacencies.

	This occurs when the packet is steered in an SR policy whose selected	This occurs when the packet is steered in an SR policy whose selected
	path has multiple SID lists	path has multiple SID lists
	[I-D.filsfils-spring-segment-routing-policy].	[I-D.filsfils-spring-segment-routing-policy].


	6.3. O-bit processing	6.3. OAM

	[I-D.ietf-6man-segment-routing-header] defines the Segment Routing
	Header (SRH) Flag O-bit. This document defines the usage of the
	O-bit in the SRH.

	Implementation of the O-bit is optional. If a node does not support
	the O-bit, then upon reception it simply ignores it. If a node
	supports the O-bit, it can optionally advertise its potential via
	node capability advertisement in IGP.

	The SRH.Flags.O-bit implements the "punt a timestamped copy and
	forward" behavior. We insert at the beginning of the pseudo-code the
	following instructions:

	1. Timestamp a local copy of the packet. ;; Ref1
	2. Punt the copied packet to CPU for SW processing (slow-path);; Ref2

	Ref1: Timestamping is done ASAP at the ingress pipeline (in
	hardware). As timestamping is done on a copy of the packet which is
	locally punted, timestamp value can be carried in the local packet
	header.

	Ref2: Hardware (microcode) just punts the packet. There is no
	requirement for the hardware to manipulate any TLV in SRH (or
	elsewhere). Software (slow path) implements the required OAM
	mechanism. Timestamp is not carried in the packet forwarded to the
	next hop.

	6.4. End.OTP: OAM Endpoint with Timestamp and Punt

	Many scenarios require punting of SRv6 OAM packets at the desired
	nodes in the network. The "OAM Endpoint with Timestamp and Punt"
	function (End.OTP for short) represents a special OAM function to
	implement the timestamp and punt behavior for an OAM packet.

	When N receives a packet destined to S and S is a local End.OTP SID,
	N does:

	1. Timestamp the packet ;; Ref1
	2. Punt the packet to CPU for SW processing (slow-path) ;; Ref2

	Ref1: Timestamping is done ASAP at the ingress pipeline (in
	hardware). A timestamped packet is locally punted, timestamp value
	can be carried in local packet header.


	Ref2: Hardware (microcode) only punts the packet. There is no	[I-D.ali-spring-srv6-oam] defines the OAM behavior for SRv6. This
	requirement for the hardware to manipulate any TLV in the SRH (or	includes the definition of the SRH Flag 'O-bit', as well as
	elsewhere). Software (slow path) implements the required OAM	additional OAM Endpoint functions.
	mechanisms.

	7. Basic security for intra-domain deployment	7. Basic security for intra-domain deployment

	We use the following terminology:	We use the following terminology:

	An internal node is a node part of the domain of trust.	An internal node is a node part of the domain of trust.

	A border router is an internal node at the edge of the domain of	A border router is an internal node at the edge of the domain of
	trust.	trust.


	skipping to change at page 31, line 24 ¶	skipping to change at page 29, line 24 ¶
	\| End.DT2M \| \| X \| X \|	\| End.DT2M \| \| X \| X \|
	\| End.DX6 \| X \| X \| X \|	\| End.DX6 \| X \| X \| X \|
	\| End.DX4 \| \| X \| X \|	\| End.DX4 \| \| X \| X \|
	\| End.DT6 \| X \| X \| X \|	\| End.DT6 \| X \| X \| X \|
	\| End.DT4 \| \| X \| X \|	\| End.DT4 \| \| X \| X \|
	\| End.DT46 \| \| X \| X \|	\| End.DT46 \| \| X \| X \|
	\| End.B6 \| \| X \| \|	\| End.B6 \| \| X \| \|
	\| End.B6.Encaps \| \| X \| \|	\| End.B6.Encaps \| \| X \| \|
	\| End.B6.BM \| \| X \| \|	\| End.B6.BM \| \| X \| \|
	\| End.S \| \| X \| \|	\| End.S \| \| X \| \|

	\| End.OTP \| X \| X \| X \|
	+------------------+-----+--------+------------+	+------------------+-----+--------+------------+

	Table 1: SRv6 LocalSID signaling	Table 1: SRv6 LocalSID signaling

	The following table summarizes which transit capability would be	The following table summarizes which transit capability would be
	signaled in which signaling protocol.	signaled in which signaling protocol.

	+-------------+-----+--------+------------+	+-------------+-----+--------+------------+
	\| \| IGP \| BGP-LS \| BGP IP/VPN \|	\| \| IGP \| BGP-LS \| BGP IP/VPN \|
	+-------------+-----+--------+------------+	+-------------+-----+--------+------------+

	skipping to change at page 42, line 47 ¶	skipping to change at page 40, line 47 ¶

	Node 7 would send the following packet to 8: (A1::, A8::D100)	Node 7 would send the following packet to 8: (A1::, A8::D100)

	9.9. End-to-End policy with intermediate BSID	9.9. End-to-End policy with intermediate BSID

	Let us now describe a case where the ingress VPN edge node steers the	Let us now describe a case where the ingress VPN edge node steers the
	packet destined to 20.20.20.20 towards the egress edge node connected	packet destined to 20.20.20.20 towards the egress edge node connected
	to the tenant100 site with 20/8, but via an intermediate SR Policy	to the tenant100 site with 20/8, but via an intermediate SR Policy
	represented by a single routable Binding SID. Let us illustrate this	represented by a single routable Binding SID. Let us illustrate this
	case with an intermediate policy which both encodes underlay	case with an intermediate policy which both encodes underlay

	optimization for low-latency and the service chaining via two SR-	optimization for low-latency and the service programming via two SR-
	aware container-based apps.	aware container-based apps.

	Let us assume that the End.B6 SID A2::B1 is configured at node 2 and	Let us assume that the End.B6 SID A2::B1 is configured at node 2 and
	is associated with midpoint T.Insert policy <A4::C5, A9::A1, A6::A2>.	is associated with midpoint T.Insert policy <A4::C5, A9::A1, A6::A2>.

	A4::C5 realizes the low-latency path from the ingress PE to the	A4::C5 realizes the low-latency path from the ingress PE to the
	egress PE. This is the underlay optimization part of the	egress PE. This is the underlay optimization part of the
	intermediate policy.	intermediate policy.

	A9::A1 and A6::A2 represent two SR-aware NFV applications residing in	A9::A1 and A6::A2 represent two SR-aware NFV applications residing in

	skipping to change at page 44, line 26 ¶	skipping to change at page 42, line 26 ¶

	Node 4 then sends the following modified packets to 5:	Node 4 then sends the following modified packets to 5:

	P1: (A1::, A7::1)	P1: (A1::, A7::1)

	P2: (A1::, A7::1)(A8::D100, A7::1; SL=1)	P2: (A1::, A7::1)(A8::D100, A7::1; SL=1)

	Then these packets follow the rest of their post-convergence path	Then these packets follow the rest of their post-convergence path
	towards node 7 and then go to node 8 for the VPN decaps.	towards node 7 and then go to node 8 for the VPN decaps.


	9.11. SR TE for Service chaining	9.11. SR TE for Service programming


	We have illustrated the service chaining through SR-aware apps in a	We have illustrated the service programming through SR-aware apps in
	previous section.	a previous section.

	We illustrate the use of End.AS function	We illustrate the use of End.AS function

	[I-D.xu-clad-spring-sr-service-chaining] to service chain an IP flow	[I-D.xuclad-spring-sr-service-programming] to service chain an IP
	bound to the internet through two SR-unaware applications hosted in	flow bound to the internet through two SR-unaware applications hosted
	containers.	in containers.

	Let us assume that servers 20 and 70 are respectively connected to	Let us assume that servers 20 and 70 are respectively connected to
	nodes 2 and 7. They are respectively configured with SID spaces	nodes 2 and 7. They are respectively configured with SID spaces
	A020::/40 and A070::/40. Their connected routers advertise the	A020::/40 and A070::/40. Their connected routers advertise the
	related prefixes in the IGP. Two SR-unaware container-based	related prefixes in the IGP. Two SR-unaware container-based
	applications App2 and App7 are respectively hosted on server 20 and	applications App2 and App7 are respectively hosted on server 20 and
	70. Server 20 (70) is configured explicitly with an End.AS SID	70. Server 20 (70) is configured explicitly with an End.AS SID
	A020::2 for App2 (A070::7 for App7).	A020::2 for App2 (A070::7 for App7).

	Let us assume a broadband customer with a home gateway CE-A connected	Let us assume a broadband customer with a home gateway CE-A connected

	skipping to change at page 45, line 32 ¶	skipping to change at page 43, line 32 ¶
	outer IPv6 header with SRH (A1::0, A8::D0)(A8::D0, A070::7, A020::2;	outer IPv6 header with SRH (A1::0, A8::D0)(A8::D0, A070::7, A020::2;
	SL=0; NH=4) and sends the (whole) IPv6 packet with the encapsulated	SL=0; NH=4) and sends the (whole) IPv6 packet with the encapsulated
	IPv4 packet back to 7.	IPv4 packet back to 7.

	7 forwards to 8.	7 forwards to 8.

	8 receives (A1::0, A8::D0)(A8::D0, A070::7, A020::2; SL=0; NH=4)(X,	8 receives (A1::0, A8::D0)(A8::D0, A070::7, A020::2; SL=0; NH=4)(X,
	Y) and performs the End.DT4 function and sends the IP packet (X, Y)	Y) and performs the End.DT4 function and sends the IP packet (X, Y)
	towards its internet destination.	towards its internet destination.


	9.12. OAM

	This section illustrates the use of O-bit and End.OTP SID by
	describing the ping use-case.

	9.12.1. Ping to a SID function

	Consider the case where the user wants to ping a remote SID function
	A8::DC4B, via A4::C5, from node 1. Node 1 constructs the ping packet
	(B1::0, A4::C5)(A8::DC4B, A4::C5, SL=1; NH=ICMPv6)(ICMPv6 Echo
	Request). When node 8 receives the ICMPv6 echo request with DA set
	to A8::DC4B and next header set to ICMPv6, it silently drops it (see
	security section for details). To solve this problem, the initiator
	needs to mark the ICMPv6 echo request as an OAM packet. The OAM
	packets are identified either by setting the O-bit in the SRH or by
	inserting an End.OTP SID at the appropriate place in the SRH.

	9.12.2. End-to-end ping using End.OTP

	Consider the same example where the user wants to ping a remote SID
	function A8::DC4B , via A4::C5, from node 1. To force a punt of the
	ICMPv6 echo request at the node 8, node 1 inserts the End.OTP SID
	just before the target SID A8::DC4B in the SRH, i.e., packet as it
	leaves node 1 looks like (B1::0, A4::C5)(A8::DC4B, A8::OTP, A4::C5;
	SL=2; NH=ICMPv6)(ICMPv6 Echo Request).

	When the node 8 receives the packet (B1::0, A8::OTP)(A8::DC4B,
	A8::OTP, A4::C5 ; SL=1; NH=ICMPv6)(ICMPv6 Echo Request), it processes
	the End.OTP SID. The packet gets punted to ICMPv6 process for
	processing. The ICMPv6 process checks if the next SID in SRH (target
	SID A8::DC4B) is locally programmed or not and responds to the ICMPv6
	Echo Request, accordingly.

	9.12.3. Segment-by-segment ping using the O-bit

	Consider the same example where the user wants to ping a remote SID
	function A8::DC4B, via A4::C5, from node 1. However, in this ping,
	the node1 wants to get a response from each segment node in the SRH.
	In other words, in the segment-by-segment ping case, the node 1
	expects a response from node 4 and node 8 for their respective local
	SID function.

	To force a punt of the ICMPv6 echo request at node 4 and node 8, node
	1 sets the O-bit in the SRH. The packet, as it leaves node 1, looks
	like (B1::0, A4::C5)(A8::DC4B, A4::C5; SL=1, Flags.O=1;
	NH=ICMPv6)(ICMPv6 Echo Request).

	When the node 4 receives the packet (B1::0, A4::C5)(A8::DC4B, A4::C5;
	SL=1, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request) packet a time-
	stamped copy of the packet gets punted to the ICMPv6 process for
	processing. Node 4 continues to apply the A4::C5 SID function on the
	original packet and forwards it, accordingly. As SRH.Flags.O=1,
	Node4 also disables the PSP flavour, i.e., does not remove the SRH.
	The ICMPv6 process at node4 checks if its local SID (A4::C5) is
	locally programmed or not and responds to the ICMPv6 Echo Request,
	accordingly. Please note that if node 4 does not support the O-bit,
	it simply ignores it and process the local SID, A4::C5.

	When the node 8 receives the packet (B1::0, A8::DC4B)(A8::DC4B,
	A4::C5; SL=0, Flags.O=1; NH=ICMPv6)(ICMPv6 Echo Request), it
	processes the O-bit in SRH. A time-stamped copy of the packet gets
	punted to the ICMPv6 process for processing. The ICMPv6 process at
	node 8 checks if its local SID (A8::DC4B) is locally programmed or
	not and responds to the ICMPv6 Echo Request, accordingly.

	Support for the O-bit is part of the node capability advertisement.
	That enables node 1 to know which segment nodes are capable of
	responding to the ICMPv6 echo request.

	10. Benefits	10. Benefits

	10.1. Seamless deployment	10.1. Seamless deployment

	The VPN use-case can be realized with SRv6 capability deployed solely	The VPN use-case can be realized with SRv6 capability deployed solely
	at the ingress and egress PE's.	at the ingress and egress PE's.

	All the nodes in between these PE's act as transit routers as per	All the nodes in between these PE's act as transit routers as per
	[RFC8200]. No software/hardware upgrade is required on all these	[RFC8200]. No software/hardware upgrade is required on all these
	nodes. They just need to support IPv6 per [RFC8200].	nodes. They just need to support IPv6 per [RFC8200].

	skipping to change at page 47, line 48 ¶	skipping to change at page 44, line 22 ¶
	free and does not depend on the presence of any remote SRv6 SID.	free and does not depend on the presence of any remote SRv6 SID.
	In the vast majority of cases, a single segment is enough to	In the vast majority of cases, a single segment is enough to
	encode the post-convergence path in a loop-free manner. If the	encode the post-convergence path in a loop-free manner. If the
	required segment is available (that node has been upgraded) then	required segment is available (that node has been upgraded) then
	the related back-up path is installed in FIB, else the pre-	the related back-up path is installed in FIB, else the pre-
	existing situation (no backup) continues. Hence, as the SRv6	existing situation (no backup) continues. Hence, as the SRv6
	deployment progresses, the coverage incrementally increases.	deployment progresses, the coverage incrementally increases.
	Eventually, when the core network is SRv6 capable, the TI-LFA	Eventually, when the core network is SRv6 capable, the TI-LFA
	coverage is complete.	coverage is complete.


	The service chaining use-case can be realized with SRv6 capability	The service programming use-case can be realized with SRv6 capability
	deployed at few strategic nodes.	deployed at few strategic nodes.


	The service-chaining deployment is again incremental and does not	The service-programming deployment is again incremental and does
	require any pre-deployment of SRv6 in the network. When an NFV	not require any pre-deployment of SRv6 in the network. When an
	app A1 needs to be enabled for inclusion in an SRv6 service chain,	NFV app A1 needs to be enabled for inclusion in an SRv6 service
	all what is required is to install that app in a container or VM	chain, all what is required is to install that app in a container
	on an SRv6-capable server (Linux 4.10 or FD.io 17.04 release).	or VM on an SRv6-capable server (Linux 4.10 or FD.io 17.04
	The app can either be SR-aware or not, leveraging the proxy	release). The app can either be SR-aware or not, leveraging the
	functions described in this document.	proxy functions described in this document.

	By leveraging the various END functions it can also be used to	By leveraging the various END functions it can also be used to
	support any current PNF/VNF implementations and their forwarding	support any current PNF/VNF implementations and their forwarding
	methods (e.g. Layer 2).	methods (e.g. Layer 2).

	The ability to leverage SR TE policies and BSIDs also permits	The ability to leverage SR TE policies and BSIDs also permits
	building scalable, hierarchical service-chains.	building scalable, hierarchical service-chains.

	10.2. Integration	10.2. Integration

	The SRv6 network programming concept allows integrating all the	The SRv6 network programming concept allows integrating all the
	application and service requirements: multi-domain underlay SLA	application and service requirements: multi-domain underlay SLA
	optimization with scale, overlay VPN/Tenant, sub-50msec automated	optimization with scale, overlay VPN/Tenant, sub-50msec automated

	FRR, security and service chaining.	FRR, security and service programming.

	10.3. Security	10.3. Security

	The combination of well-known techniques (SEC1, SEC2, SEC4) and	The combination of well-known techniques (SEC1, SEC2, SEC4) and
	carefully chosen architectural rules (SEC3) ensure a secure	carefully chosen architectural rules (SEC3) ensure a secure
	deployment of SRv6 inside a multi-domain network managed by a single	deployment of SRv6 inside a multi-domain network managed by a single
	organization.	organization.

	Inter-domain security will be described in a companion document.	Inter-domain security will be described in a companion document.


	skipping to change at page 50, line 32 ¶	skipping to change at page 46, line 32 ¶
	\| 15 \| 0x000F \| End.BM \| [This.ID] \|	\| 15 \| 0x000F \| End.BM \| [This.ID] \|
	\| 16 \| 0x0010 \| End.DX6 \| [This.ID] \|	\| 16 \| 0x0010 \| End.DX6 \| [This.ID] \|
	\| 17 \| 0x0011 \| End.DX4 \| [This.ID] \|	\| 17 \| 0x0011 \| End.DX4 \| [This.ID] \|
	\| 18 \| 0x0012 \| End.DT6 \| [This.ID] \|	\| 18 \| 0x0012 \| End.DT6 \| [This.ID] \|
	\| 19 \| 0x0013 \| End.DT4 \| [This.ID] \|	\| 19 \| 0x0013 \| End.DT4 \| [This.ID] \|
	\| 20 \| 0x0014 \| End.DT46 \| [This.ID] \|	\| 20 \| 0x0014 \| End.DT46 \| [This.ID] \|
	\| 21 \| 0x0015 \| End.DX2 \| [This.ID] \|	\| 21 \| 0x0015 \| End.DX2 \| [This.ID] \|
	\| 22 \| 0x0016 \| End.DX2V \| [This.ID] \|	\| 22 \| 0x0016 \| End.DX2V \| [This.ID] \|
	\| 23 \| 0x0017 \| End.DT2U \| [This.ID] \|	\| 23 \| 0x0017 \| End.DT2U \| [This.ID] \|
	\| 24 \| 0x0018 \| End.DT2M \| [This.ID] \|	\| 24 \| 0x0018 \| End.DT2M \| [This.ID] \|

	\| 25 \| 0x0019 \| End.OTP \| [This.ID] \|	\| 25 \| 0x0019 \| End.S \| [This.ID] \|
	\| 26 \| 0x001A \| End.S \| [This.ID] \|	\| 26 \| 0x001A \| End.B6.Red \| [This.ID] \|
		\| 27 \| 0x001B \| End.B6.Encaps.Red \| [This.ID] \|
	+-------+--------+------------------------+-----------+	+-------+--------+------------------------+-----------+

	Table 4: SRv6 Endpoint Types	Table 4: SRv6 Endpoint Types

	12. Work in progress	12. Work in progress

	We are working on a extension of this document to provide Yang	We are working on a extension of this document to provide Yang
	modelling for all the functionality described in this document. This	modelling for all the functionality described in this document. This
	work is ongoing in [I-D.raza-spring-srv6-yang].	work is ongoing in [I-D.raza-spring-srv6-yang].

	13. Acknowledgements	13. Acknowledgements


	TBD.	The authors would like to acknowledge Stefano Previdi, Dave Barach,
		Mark Townsley, Peter Psenak, Paul Wells, Robert Hanzl, Dan Ye, Gaurav
		Dawra, Faisal Iqbal, Jaganbabu Rajamanickam, David Toscano, Asif
		Islam, Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc
		Gourty, Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John
		Bettink, Kishore Nandyala Veera Venk, Jisu Bhattacharya and Saleem
		Hafeez.

	14. Contributors	14. Contributors


	Stefano Previdi, Dave Barach, Mark Townsley, Peter Psenak, Paul
	Wells, Robert Hanzl, Dan Ye, Patrice Brissette, Gaurav Dawra, Faisal
	Iqbal, Zafar Ali, Jaganbabu Rajamanickam, David Toscano, Asif Islam,
	Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc Gourty,
	Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink,
	Kishore Nandyala Veera Venk, Jisu Bhattacharya and Saleem Hafeez
	substantially contributed to the content of this document.

	15. References

	15.1. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.

	15.2. Informative References

	[I-D.bashandy-isis-srv6-extensions]
	Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene,
	"IS-IS Extensions to Support Routing over IPv6 Dataplane",
	draft-bashandy-isis-srv6-extensions-01 (work in progress),
	September 2017.

	[I-D.dawra-idr-srv6-vpn]
	Dawra, G., Filsfils, C., Dukes, D., Brissette, P.,
	Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d.,
	daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
	Decraene, B., and S. Matsushima, "BGP Signaling of IPv6-
	Segment-Routing-based VPN Networks", draft-dawra-idr-
	srv6-vpn-03 (work in progress), December 2017.

	[I-D.filsfils-spring-segment-routing-policy]
	Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,
	F., Talaulikar, K., Ali, Z., Hegde, S.,
	daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
	b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
	Litkowski, S., and P. Mattes, "Segment Routing Policy for
	Traffic Engineering", draft-filsfils-spring-segment-
	routing-policy-05 (work in progress), February 2018.

	[I-D.ietf-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
	Field, B., daniel.voyer@bell.ca, d.,
	daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
	Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
	D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
	Header (SRH)", draft-ietf-6man-segment-routing-header-08
	(work in progress), January 2018.

	[I-D.ietf-idr-bgp-ls-segment-routing-ext]
	Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
	and M. Chen, "BGP Link-State extensions for Segment
	Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-04
	(work in progress), January 2018.

	[I-D.ietf-idr-te-lsp-distribution]
	Previdi, S., Dong, J., Chen, M., Gredler, H., and J.
	Tantsura, "Distribution of Traffic Engineering (TE)
	Policies and State using BGP-LS", draft-ietf-idr-te-lsp-
	distribution-08 (work in progress), December 2017.

	[I-D.ietf-isis-l2bundles]
	Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
	E. Aries, "Advertising L2 Bundle Member Link Attributes in
	IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
	May 2017.

	[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), January 2018.

	[I-D.raza-spring-srv6-yang]
	Raza, K., Rajamanickam, J., Liu, X., Hussain, I., Shah,
	H., Voyer, D., Elmalky, H., and A. Abdelsalam, "YANG Data
	Model for SRv6", draft-raza-spring-srv6-yang-00 (work in
	progress), November 2017.

	[I-D.xu-clad-spring-sr-service-chaining]
	Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
	d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,
	S., and S. Ma, "Segment Routing for Service Chaining",
	draft-xu-clad-spring-sr-service-chaining-00 (work in
	progress), December 2017.

	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <https://www.rfc-editor.org/info/rfc2473>.

	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/info/rfc4364>.

	[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification", RFC 6437,
	DOI 10.17487/RFC6437, November 2011,
	<https://www.rfc-editor.org/info/rfc6437>.

	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.

	Appendix A. Additional Contributors

	Patrice Brissete
	Cisco Systems, Inc.
	Canada

	Email: pbrisset@cisco.com

	Zafar Ali
	Cisco Systems, Inc.
	United States of America

	Email: zali@cisco.com

	Ahmed AbdelSalam
	Gran Sasso Science Institute
	Italy

	Email: ahmed.abdelsalam@gssi.it

	Authors' Addresses

	Clarence Filsfils
	Cisco Systems, Inc.
	Belgium

	Email: cf@cisco.com

	Zhenbin Li
	Huawei Technologies
	China

	Email: lizhenbin@huawei.com
	John Leddy
	Comcast
	United States of America

	Email: john_leddy@cable.comcast.com

	Daniel Voyer
	Bell Canada
	Canada

	Email: daniel.voyer@bell.ca

	Daniel Bernier	Daniel Bernier
	Bell Canada	Bell Canada
	Canada	Canada

	Email: daniel.bernier@bell.ca	Email: daniel.bernier@bell.ca

	Dirk Steinberg	Dirk Steinberg
	Steinberg Consulting	Steinberg Consulting
	Germany	Germany

	Email: dws@dirksteinberg.de	Email: dws@dirksteinberg.de

	Robert Raszuk	Robert Raszuk
	Bloomberg LP	Bloomberg LP
	United States of America	United States of America

	Email: robert@raszuk.net	Email: robert@raszuk.net


	Satoru Matsushima
	SoftBank
	1-9-1,Higashi-Shimbashi,Minato-Ku
	Tokyo 105-7322
	Japan

	Email: satoru.matsushima@g.softbank.co.jp
	David Lebrun
	Universite catholique de Louvain
	Belgium

	Email: david.lebrun@uclouvain.be

	Bruno Decraene	Bruno Decraene
	Orange	Orange

	France	Frence

	Email: bruno.decraene@orange.com	Email: bruno.decraene@orange.com

	Bart Peirens	Bart Peirens
	Proximus	Proximus
	Belgium	Belgium

	Email: bart.peirens@proximus.com	Email: bart.peirens@proximus.com


	Stefano Salsano
	Universita di Roma "Tor Vergata"
	Italy

	Email: stefano.salsano@uniroma2.it

	Gaurav Naik
	Drexel University
	United States of America

	Email: gn@drexel.edu

	Hani Elmalky	Hani Elmalky
	Ericsson	Ericsson
	United States of America	United States of America

	Email: hani.elmalky@gmail.com	Email: hani.elmalky@gmail.com

	Prem Jonnalagadda	Prem Jonnalagadda
	Barefoot Networks	Barefoot Networks
	United States of America	United States of America


	skipping to change at page 56, line 4 ¶	skipping to change at page 47, line 50 ¶
	Ericsson	Ericsson
	United States of America	United States of America

	Email: hani.elmalky@gmail.com	Email: hani.elmalky@gmail.com

	Prem Jonnalagadda	Prem Jonnalagadda
	Barefoot Networks	Barefoot Networks
	United States of America	United States of America

	Email: prem@barefootnetworks.com	Email: prem@barefootnetworks.com


	Milad Sharif	Milad Sharif
	Barefoot Networks	Barefoot Networks
	United States of America	United States of America

	Email: msharif@barefootnetworks.com	Email: msharif@barefootnetworks.com


		David Lebrun
		Universite catholique de Louvain
		Belgium

		Email: david.lebrun@uclouvain.be

		Stefano Salsano
		Universita di Roma "Tor Vergata"
		Italy

		Email: stefano.salsano@uniroma2.it

		Ahmed AbdelSalam
		Gran Sasso Science Institute
		Italy

		Email: ahmed.abdelsalam@gssi.it

		Gaurav Naik
		Drexel University
		United States of America

		Email: gn@drexel.edu

	Arthi Ayyangar	Arthi Ayyangar
	Arista	Arista
	United States of America	United States of America

	Email: arthi@arista.com	Email: arthi@arista.com

	Satish Mynam	Satish Mynam
	Innovium Inc.	Innovium Inc.
	United States of America	United States of America


	skipping to change at page 56, line 35 ¶	skipping to change at page 49, line 10 ¶

	Email: wim.henderickx@nokia.com	Email: wim.henderickx@nokia.com

	Shaowen Ma	Shaowen Ma
	Juniper	Juniper
	Singapore	Singapore

	Email: mashao@juniper.net	Email: mashao@juniper.net

	Ahmed Bashandy	Ahmed Bashandy

	Cisco Systems, Inc.	Individual
	United States of America	United States of America


	Email: bashandy@cisco.com	Email: abashandy.ietf@gmail.com

		Francois Clad
		Cisco Systems, Inc.
		France

		Email: fclad@cisco.com

	Kamran Raza	Kamran Raza
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Canada	Canada

	Email: skraza@cisco.com	Email: skraza@cisco.com


	Darren Dukes	Darren Dukes
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Canada	Canada

	Email: ddukes@cisco.com	Email: ddukes@cisco.com


	Francois Clad	Patrice Brissete
	Cisco Systems, Inc.	Cisco Systems, Inc.

	France	Canada


	Email: fclad@cisco.com	Email: pbrisset@cisco.com

		Zafar Ali
		Cisco Systems, Inc.
		United States of America

		Email: zali@cisco.com

		15. References

		15.1. Normative References

		[I-D.ali-spring-srv6-oam]
		Ali, Z., Filsfils, C., Kumar, N., Pignataro, C.,
		faiqbal@cisco.com, f., Gandhi, R., Leddy, J., Matsushima,
		S., Raszuk, R., Peirens, B., and G. Naik, "Operations,
		Administration, and Maintenance (OAM) in Segment Routing
		Networks with IPv6 Data plane (SRv6)", draft-ali-spring-
		srv6-oam-00 (work in progress), February 2018.

		[I-D.ietf-6man-segment-routing-header]
		Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
		d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
		(SRH)", draft-ietf-6man-segment-routing-header-14 (work in
		progress), June 2018.

		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
		Requirement Levels", BCP 14, RFC 2119,
		DOI 10.17487/RFC2119, March 1997,
		<https://www.rfc-editor.org/info/rfc2119>.

		15.2. Informative References

		[I-D.bashandy-isis-srv6-extensions]
		Ginsberg, L., Psenak, P., Filsfils, C., Bashandy, A.,
		Decraene, B., and Z. Hu, "IS-IS Extensions to Support
		Routing over IPv6 Dataplane", draft-bashandy-isis-
		srv6-extensions-03 (work in progress), June 2018.

		[I-D.dawra-idr-srv6-vpn]
		Dawra, G., Filsfils, C., Dukes, D., Brissette, P.,
		Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d.,
		daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
		Decraene, B., Matsushima, S., and S. Zhuang, "BGP
		Signaling of IPv6-Segment-Routing-based VPN Networks",
		draft-dawra-idr-srv6-vpn-04 (work in progress), June 2018.

		[I-D.filsfils-spring-segment-routing-policy]
		Filsfils, C., Sivabalan, S., Hegde, S.,
		daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
		b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
		Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
		J., Clad, F., and K. Raza, "Segment Routing Policy
		Architecture", draft-filsfils-spring-segment-routing-
		policy-06 (work in progress), May 2018.

		[I-D.ietf-idr-bgp-ls-segment-routing-ext]
		Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H.,
		and M. Chen, "BGP Link-State extensions for Segment
		Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08
		(work in progress), May 2018.

		[I-D.ietf-idr-te-lsp-distribution]
		Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler,
		H., and J. Tantsura, "Distribution of Traffic Engineering
		(TE) Policies and State using BGP-LS", draft-ietf-idr-te-
		lsp-distribution-09 (work in progress), June 2018.

		[I-D.ietf-isis-l2bundles]
		Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
		E. Aries, "Advertising L2 Bundle Member Link Attributes in
		IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
		May 2017.

		[I-D.ietf-spring-segment-routing]
		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
		Litkowski, S., and R. Shakir, "Segment Routing
		Architecture", draft-ietf-spring-segment-routing-15 (work
		in progress), January 2018.

		[I-D.raza-spring-srv6-yang]
		Raza, K., Rajamanickam, J., Liu, X., Hu, Z., Hussain, I.,
		Shah, H., daniel.voyer@bell.ca, d., Elmalky, H.,
		Matsushima, S., Horiba, K., and A. Abdelsalam, "YANG Data
		Model for SRv6 Base and Static", draft-raza-spring-
		srv6-yang-01 (work in progress), March 2018.

		[I-D.xuclad-spring-sr-service-programming]
		Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
		Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
		S. Salsano, "Service Programming with Segment Routing",
		draft-xuclad-spring-sr-service-programming-00 (work in
		progress), July 2018.

		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
		December 1998, <https://www.rfc-editor.org/info/rfc2473>.

		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
		2006, <https://www.rfc-editor.org/info/rfc4364>.

		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
		"IPv6 Flow Label Specification", RFC 6437,
		DOI 10.17487/RFC6437, November 2011,
		<https://www.rfc-editor.org/info/rfc6437>.

		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
		(IPv6) Specification", STD 86, RFC 8200,
		DOI 10.17487/RFC8200, July 2017,
		<https://www.rfc-editor.org/info/rfc8200>.

		Authors' Addresses

		Clarence Filsfils
		Cisco Systems, Inc.
		Belgium

		Email: cf@cisco.com

	Pablo Camarillo Garvia (editor)	Pablo Camarillo Garvia (editor)
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Spain	Spain

	Email: pcamaril@cisco.com	Email: pcamaril@cisco.com


		John Leddy
		Comcast
		United States of America

		Email: john_leddy@cable.comcast.com

		Daniel Voyer
		Bell Canada
		Canada

		Email: daniel.voyer@bell.ca

		Satoru Matsushima
		SoftBank
		1-9-1,Higashi-Shimbashi,Minato-Ku
		Tokyo 105-7322
		Japan

		Email: satoru.matsushima@g.softbank.co.jp
		Zhenbin Li
		Huawei Technologies
		China

		Email: lizhenbin@huawei.com

End of changes. 58 change blocks.
	455 lines changed or deleted	296 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/