< draft-ietf-spring-segment-routing-02.txt		draft-ietf-spring-segment-routing-03.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 Cisco Systems, Inc.
	Expires: November 6, 2015 Cisco Systems, Inc.		Expires: November 29, 2015 B. Decraene
	B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	M. Horneffer
	Deutsche Telekom
	R. Shakir		R. Shakir
	British Telecom		British Telecom
	J. Tantsura		May 28, 2015
	Ericsson
	E. Crabbe
	Individual
	May 5, 2015
	Segment Routing Architecture		Segment Routing Architecture
	draft-ietf-spring-segment-routing-02		draft-ietf-spring-segment-routing-03
	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 an ordered list of instructions, called		steers a packet through an ordered list of instructions, called
	segments. A segment can represent any instruction, topological or		segments. A segment can represent any instruction, topological or
	service-based. A segment can have a local semantic to an SR node or		service-based. A segment can have a local semantic to an SR node or
	global within an SR domain. SR allows to enforce a flow through any		global within an SR domain. SR allows to enforce a flow through any
	topological path and service chain while maintaining per-flow state		topological path and service chain while maintaining per-flow state
	only at the ingress node to the SR domain.		only at the ingress node to the SR domain.
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 15 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 6, 2015.		This Internet-Draft will expire on November 29, 2015.
	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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4		1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6		3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6
	3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7		3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 6
	3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7		3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7
	3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8		3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8
	3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 9		3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 8
	3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9		3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9
	3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10		3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10
	3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 11		3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 11
	3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 12		3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 11
	3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 12		3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 12
	3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 12		3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 12
	3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 12		3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 12
	4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 13		4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 13
	5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 14		5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 15		10.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	With Segment Routing (SR), a node steers a packet through an ordered		With Segment Routing (SR), a node steers a packet through an ordered
	list of instructions, called segments. A segment can represent any		list of instructions, called segments. A segment can represent any
	instruction, topological or service-based. A segment can have a		instruction, topological or service-based. A segment can have a
	local semantic to an SR node or global within an SR domain. SR		local semantic to an SR node or global within an SR domain. SR
	allows to enforce a flow through any path and service chain while		allows to enforce a flow through any path and service chain while
	maintaining per-flow state only at the ingress node of the SR domain.		maintaining per-flow state only at the ingress node of the SR domain.
	skipping to change at page 5, line 41 ¶		skipping to change at page 5, line 28 ¶
	NEXT: the active segment is completed, the next segment becomes		NEXT: the active segment is completed, the next segment becomes
	active.		active.
	CONTINUE: the active segment is not completed and hence remains		CONTINUE: the active segment is not completed and hence remains
	active. The CONTINUE instruction is implemented as the SWAP		active. The CONTINUE instruction is implemented as the SWAP
	instruction in the MPLS dataplane.		instruction in the MPLS dataplane.
	SR Global Block (SRGB): local property of an SR node. In the MPLS		SR Global Block (SRGB): local property of an SR node. In the MPLS
	architecture, SRGB is the set of local labels reserved for global		architecture, SRGB is the set of local labels reserved for global
	segments. In the IPv6 architecture, it is the set of locally		segments. In the IPv6 architecture, it is the set of locally
	relevant IPv6 addresses.		relevant IPv6 addresses. Using the same SRGB on all nodes within the
			SR domain ease operations and troubleshooting and is expected to be a
			deployment guideline.
	Global Segment: the related instruction is supported by all the SR-		Global Segment: the related instruction is supported by all the SR-
	capable nodes in the domain. In the MPLS architecture, a Global		capable nodes in the domain. In the MPLS architecture, a Global
	Segment has a globally-unique index. The related local label at a		Segment has a globally-unique index. The related local label at a
	given node N is found by adding the globally-unique index to the SRGB		given node N is found by adding the globally-unique index to the SRGB
	of node N. In the IPv6 architecture, a global segment is a globally-		of node N. In the IPv6 architecture, a global segment is a globally-
	unique IPv6 address.		unique IPv6 address.
	Local Segment: the related instruction is supported only by the node		Local Segment: the related instruction is supported only by the node
	originating it. In the MPLS architecture, this is a local label		originating it. In the MPLS architecture, this is a local label
	skipping to change at page 9, line 19 ¶		skipping to change at page 9, line 9 ¶
	Segment" or "Anycast-SID" are often used as an abbreviation.		Segment" or "Anycast-SID" are often used as an abbreviation.
	An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware		An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware
	shortest-path forwarding towards the closest node of the anycast set.		shortest-path forwarding towards the closest node of the anycast set.
	This is useful to express macro-engineering policies or protection		This is useful to express macro-engineering policies or protection
	mechanisms as described in		mechanisms as described in
	[I-D.filsfils-spring-segment-routing-use-cases].		[I-D.filsfils-spring-segment-routing-use-cases].
	The Anycast SID MUST be advertised with the N-flag unset.		The Anycast SID MUST be advertised with the N-flag unset.
			When anycast is used and multiple nodes advertise the same prefix
			(with its SID), these nodes MUST use the same SRGB.
			The SID following the anycast SID MUST be understood by all nodes
			sharing the anycast SID.
	3.5. IGP-Adjacency Segment, Adj-SID		3.5. IGP-Adjacency Segment, Adj-SID
	An IGP-Adjacency Segment is an IGP segment attached to a		An IGP-Adjacency Segment is an IGP segment attached to a
	unidirectional adjacency or a set of unidirectional adjacencies. By		unidirectional adjacency or a set of unidirectional adjacencies. By
	default, an IGP-Adjacency Segment is local to the node which		default, an IGP-Adjacency Segment is local to the node which
	advertises it. However, an Adjacency Segment can be global if		advertises it. However, an Adjacency Segment can be global if
	advertised by the IGP as such. The SID of the IGP-Adjacency Segment		advertised by the IGP as such. The SID of the IGP-Adjacency Segment
	is called the Adj-SID.		is called the Adj-SID.
	The adjacency is formed by the local node (i.e., the node advertising		The adjacency is formed by the local node (i.e., the node advertising
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	The IPv6 Segment Routing Header is defined in a way that blind		The IPv6 Segment Routing Header is defined in a way that blind
	attacks are never possible, i.e., attackers will be unable to send		attacks are never possible, i.e., attackers will be unable to send
	source routed packets that get successfully processed, without being		source routed packets that get successfully processed, without being
	part of the negations for setting up the source routes or being able		part of the negations for setting up the source routes or being able
	to eavesdrop legitimate source routed packets. In some networks this		to eavesdrop legitimate source routed packets. In some networks this
	base level security may be complemented with other mechanisms, such		base level security may be complemented with other mechanisms, such
	as packet filtering, cryptographic security, etc.		as packet filtering, cryptographic security, etc.
	8. Contributors		8. Contributors
	The following contributors have substantially helped the definition		The following people have substantially contributed to the definition
	and editing of the content of this document:		of the Segment Routing architecture and to the editing of this
			document:
			Ahmed Bashandy
			Cisco Systems, Inc.
			Email: bashandy@cisco.com
			Martin Horneffer
			Deutsche Telekom
			Email: Martin.Horneffer@telekom.de
	Wim Henderickx		Wim Henderickx
			Alcatel-Lucent
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@alcatel-lucent.com
			Jeff Tantsura
			Ericsson
			Email: Jeff.Tantsura@ericsson.com
			Edward Crabbe
			Individual
			Email: edward.crabbe@gmail.com
	Igor Milojevic		Igor Milojevic
	Email: milojevicigor@gmail.com		Email: milojevicigor@gmail.com
	Saku Ytti		Saku Ytti
			TDC
	Email: saku@ytti.fi		Email: saku@ytti.fi
	9. Acknowledgements		9. Acknowledgements
	We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre		We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
	Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes		Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes
	Gredler for their comments and review of this document.		Gredler for their comments and review of this document.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-isis-segment-routing-extensions]
	Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
	Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
	Extensions for Segment Routing", draft-ietf-isis-segment-
	routing-extensions-03 (work in progress), October 2014.
	[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
	Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
	Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
	segment-routing-extensions-02 (work in progress), February
	2015.
	[I-D.ietf-ospf-segment-routing-extensions]
	Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
	Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
	Extensions for Segment Routing", draft-ietf-ospf-segment-
	routing-extensions-04 (work in progress), February 2015.
	[I-D.previdi-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
	Segment Routing Header (SRH)", draft-previdi-6man-segment-
	routing-header-06 (work in progress), May 2015.
	[I-D.vyncke-6man-segment-routing-security]
	Vyncke, E., Previdi, S., and D. Lebrun, "IPv6 Segment
	Routing Security Considerations", draft-vyncke-6man-
	segment-routing-security-02 (work in progress), February
	2015.
	[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, March 1997.
	[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)		[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
	Hierarchy with Generalized Multi-Protocol Label Switching		Hierarchy with Generalized Multi-Protocol Label Switching
	(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.		(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
	10.2. Informative References		10.2. Informative References
	[I-D.filsfils-spring-segment-routing-central-epe]		[I-D.filsfils-spring-segment-routing-central-epe]
	skipping to change at page 17, line 11 ¶		skipping to change at page 16, line 46 ¶
	"Topology Independent Fast Reroute using Segment Routing",		"Topology Independent Fast Reroute using Segment Routing",
	draft-francois-spring-segment-routing-ti-lfa-01 (work in		draft-francois-spring-segment-routing-ti-lfa-01 (work in
	progress), October 2014.		progress), October 2014.
	[I-D.geib-spring-oam-usecase]		[I-D.geib-spring-oam-usecase]
	Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use		Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
	case for a scalable and topology aware MPLS data plane		case for a scalable and topology aware MPLS data plane
	monitoring system", draft-geib-spring-oam-usecase-04 (work		monitoring system", draft-geib-spring-oam-usecase-04 (work
	in progress), March 2015.		in progress), March 2015.
			[I-D.ietf-isis-segment-routing-extensions]
			Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
			Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
			Extensions for Segment Routing", draft-ietf-isis-segment-
			routing-extensions-04 (work in progress), May 2015.
			[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
			Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
			Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
			Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
			segment-routing-extensions-02 (work in progress), February
			2015.
			[I-D.ietf-ospf-segment-routing-extensions]
			Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
			Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
			Extensions for Segment Routing", draft-ietf-ospf-segment-
			routing-extensions-04 (work in progress), February 2015.
	[I-D.ietf-pce-segment-routing]		[I-D.ietf-pce-segment-routing]
	Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,		Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
	Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,		Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
	"PCEP Extensions for Segment Routing", draft-ietf-pce-		"PCEP Extensions for Segment Routing", draft-ietf-pce-
	segment-routing-03 (work in progress), April 2015.		segment-routing-04 (work in progress), May 2015.
	[I-D.ietf-spring-ipv6-use-cases]		[I-D.ietf-spring-ipv6-use-cases]
	Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,		Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,
	Townsley, W., Martin, C., Filsfils, C., and R. Maglione,		Townsley, W., Martin, C., Filsfils, C., and R. Maglione,
	"IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use-		"IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use-
	cases-04 (work in progress), March 2015.		cases-04 (work in progress), March 2015.
	[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. Shakir,
	"Use-cases for Resiliency in SPRING", draft-ietf-spring-		"Use-cases for Resiliency in SPRING", draft-ietf-spring-
	skipping to change at page 17, line 41 ¶		skipping to change at page 17, line 48 ¶
	and E. Crabbe, "Segment Routing with MPLS data plane",		and E. Crabbe, "Segment Routing with MPLS data plane",
	draft-ietf-spring-segment-routing-mpls-00 (work in		draft-ietf-spring-segment-routing-mpls-00 (work in
	progress), December 2014.		progress), December 2014.
	[I-D.kumar-spring-sr-oam-requirement]		[I-D.kumar-spring-sr-oam-requirement]
	Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,		Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
	and S. Litkowski, "OAM Requirements for Segment Routing		and S. Litkowski, "OAM Requirements for Segment Routing
	Network", draft-kumar-spring-sr-oam-requirement-03 (work		Network", draft-kumar-spring-sr-oam-requirement-03 (work
	in progress), March 2015.		in progress), March 2015.
			[I-D.previdi-6man-segment-routing-header]
			Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
			Segment Routing Header (SRH)", draft-previdi-6man-segment-
			routing-header-06 (work in progress), May 2015.
			[I-D.vyncke-6man-segment-routing-security]
			Vyncke, E., Previdi, S., and D. Lebrun, "IPv6 Segment
			Routing Security Considerations", draft-vyncke-6man-
			segment-routing-security-02 (work in progress), February
			2015.
	[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation		[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	of Type 0 Routing Headers in IPv6", RFC 5095, December		of Type 0 Routing Headers in IPv6", RFC 5095, December
	2007.		2007.
	Authors' Addresses		Authors' Addresses
	Clarence Filsfils (editor)		Clarence Filsfils (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Brussels		Brussels
	BE		BE
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 23 ¶
	2007.		2007.
	Authors' Addresses		Authors' Addresses
	Clarence Filsfils (editor)		Clarence Filsfils (editor)
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Brussels		Brussels
	BE		BE
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	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
	Ahmed Bashandy
	Cisco Systems, Inc.
	170, West Tasman Drive
	San Jose, CA 95134
	US
	Email: bashandy@cisco.com
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	FR		FR
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	FR		FR
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
	Martin Horneffer
	Deutsche Telekom
	Hammer Str. 216-226
	Muenster 48153
	DE
	Email: Martin.Horneffer@telekom.de
	Rob Shakir		Rob Shakir
	British Telecom		British Telecom
	London		London
	UK		UK
	Email: rob.shakir@bt.com		Email: rob.shakir@bt.com
	Jeff Tantsura
	Ericsson
	300 Holger Way
	San Jose, CA 95134
	US
	Email: Jeff.Tantsura@ericsson.com
	Edward Crabbe
	Individual
	Email: edward.crabbe@gmail.com
End of changes. 24 change blocks.
	68 lines changed or deleted		72 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/