< draft-filsfils-spring-segment-routing-ldp-interop-01.txt		draft-filsfils-spring-segment-routing-ldp-interop-02.txt >
	Network Working Group C. Filsfils, Ed.		Network Working Group C. Filsfils, Ed.
	Internet-Draft S. Previdi, Ed.		Internet-Draft S. Previdi, Ed.
	Intended status: Standards Track A. Bashandy		Intended status: Standards Track A. Bashandy
	Expires: October 20, 2014 Cisco Systems, Inc.		Expires: March 16, 2015 Cisco Systems, Inc.
	B. Decraene		B. Decraene
	S. Litkowski		S. Litkowski
	Orange		Orange
	M. Horneffer		M. Horneffer
	Deutsche Telekom		Deutsche Telekom
	I. Milojevic		I. Milojevic
	Telekom Srbija		Telekom Srbija
	R. Shakir		R. Shakir
	British Telecom		British Telecom
	S. Ytti		S. Ytti
	TDC Oy		TDC Oy
	W. Henderickx		W. Henderickx
	Alcatel-Lucent		Alcatel-Lucent
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	E. Crabbe		E. Crabbe
	Google, Inc.		Individual Contributor
	April 18, 2014		September 12, 2014
	Segment Routing interoperability with LDP		Segment Routing interoperability with LDP
	draft-filsfils-spring-segment-routing-ldp-interop-01		draft-filsfils-spring-segment-routing-ldp-interop-02
	Abstract		Abstract
	A Segment Routing (SR) node steers a packet through a controlled set		A Segment Routing (SR) node steers a packet through a controlled set
	of instructions, called segments, by prepending the packet with an SR		of instructions, called segments, by prepending the packet with an SR
	header. A segment can represent any instruction, topological or		header. A segment can represent any instruction, topological or
	service-based. SR allows to enforce a flow through any topological		service-based. SR allows to enforce a flow through any topological
	path and service chain while maintaining per-flow state only at the		path and service chain while maintaining per-flow state only at the
	ingress node to the SR domain.		ingress node to the SR domain.
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 October 20, 2014.		This Internet-Draft will expire on March 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 14 ¶		skipping to change at page 3, line 14 ¶
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 13		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . 14		11.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Segment Routing, as described in		Segment Routing, as described in
	[I-D.filsfils-rtgwg-segment-routing], can be used on top of the MPLS		[I-D.filsfils-spring-segment-routing], can be used on top of the MPLS
	data plane without any modification as described in		data plane without any modification as described in
	[draft-filsfils-rtgwg-segment-routing-mpls-00].		[I-D.filsfils-spring-segment-routing-mpls].
	Segment Routing control plane can co-exist with current label		Segment Routing control plane can co-exist with current label
	distribution protocols such as LDP.		distribution protocols such as LDP.
	This draft outlines the mechanisms through which SR provides		This draft outlines the mechanisms through which SR provides
	interoperability with LDP in cases where a mix of SR-capable and non-		interoperability with LDP in cases where a mix of SR-capable and non-
	SR-capable routers co-exist within the same network.		SR-capable routers co-exist within the same network.
	The first section describes the co-existence of SR with other MPLS		The first section describes the co-existence of SR with other MPLS
	Control Plane. The second section documents a method to migrate from		Control Plane. The second section documents a method to migrate from
	skipping to change at page 5, line 6 ¶		skipping to change at page 5, line 6 ¶
	SID's are configured to request penultimate-hop-popping.		SID's are configured to request penultimate-hop-popping.
	PE1, A, B, C and PE3 are LDP capable.		PE1, A, B, C and PE3 are LDP capable.
	PE1 and PE3 are not SR capable.		PE1 and PE3 are not SR capable.
	PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN		PE3 sends an ODD VPN route to PE1 with next-hop 192.0.2.203 and VPN
	label 10001.		label 10001.
	From an LDP viewpoint: PE1 received an LDP label binding (1037) for		From an LDP viewpoint: PE1 received an LDP label binding (1037) for
	FEC 192.0.2.203/32 from its nhop A. A received an LDP label binding		FEC 192.0.2.203/32 from its nhop A. A received an LDP label binding
	(2048) for that FEC from its nhop B. B received an LDP label binding		(2048) for that FEC from its nhop B. B received an LDP label binding
	(3059) for that FEC from its nhop C. C received implicit-null LDP		(3059) for that FEC from its nhop C. C received implicit-null LDP
	binding from its next-hop PE3.		binding from its next-hop PE3.
	As a result, PE1 sends its traffic to the ODD service route		As a result, PE1 sends its traffic to the ODD service route
	advertised by PE3 to next-hop A with two labels: the top label is		advertised by PE3 to next-hop A with two labels: the top label is
	1037 and the bottom label is 10001. A swaps 1037 with 2048 and		1037 and the bottom label is 10001. A swaps 1037 with 2048 and
	forwards to B. B swaps 2048 with 3059 and forwards to C. C pops 3059		forwards to B. B swaps 2048 with 3059 and forwards to C. C pops
	and forwards to PE3.		3059 and forwards to PE3.
	PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN		PE4 sends an EVEN VPN route to PE2 with next-hop 192.0.2.204 and VPN
	label 10002.		label 10002.
	From an SR viewpoint: PE1 maps the IGP route 192.0.2.204/32 onto		From an SR viewpoint: PE1 maps the IGP route 192.0.2.204/32 onto
	Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204		Node-SID 204; A swaps 204 with 204 and forwards to B; B swaps 204
	with 204 and forwards to C; C pops 204 and forwards to PE4.		with 204 and forwards to C; C pops 204 and forwards to PE4.
	As a result, PE2 sends its traffic to the VPN service route		As a result, PE2 sends its traffic to the VPN service route
	advertised by PE4 to next-hop A with two labels: the top label is 204		advertised by PE4 to next-hop A with two labels: the top label is 204
	and the bottom label is 10002. A swaps 204 with 204 and forwards to		and the bottom label is 10002. A swaps 204 with 204 and forwards to
	B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards to		B. B swaps 204 with 204 and forwards to C. C pops 204 and forwards
	PE4.		to PE4.
	The two modes of MPLS tunneling co-exist.		The two modes of MPLS tunneling co-exist.
	The ODD service is tunneled from PE1 to PE3 through a continuous		The ODD service is tunneled from PE1 to PE3 through a continuous
	LDP LSP traversing A, B and C.		LDP LSP traversing A, B and C.
	The EVEN service is tunneled from PE2 to PE4 through a continuous		The EVEN service is tunneled from PE2 to PE4 through a continuous
	SR node segment traversing A, B and C.		SR node segment traversing A, B and C.
	2.1. MPLS2MPLS co-existence		2.1. MPLS2MPLS co-existence
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	and the related node segment from P6 to PE1.		and the related node segment from P6 to PE1.
	4.2. SR to LDP		4.2. SR to LDP
	In this section, we analyze the left-to-right traffic flow.		In this section, we analyze the left-to-right traffic flow.
	We assume that the operator configures P5 to act as a Segment Routing		We assume that the operator configures P5 to act as a Segment Routing
	Mapping Server (SRMS) and advertise the following mappings: (P7,		Mapping Server (SRMS) and advertise the following mappings: (P7,
	107), (P8, 108), (PE3, 103) and (PE4, 104).		107), (P8, 108), (PE3, 103) and (PE4, 104).
	These mappings are advertised as Remote-Bundle SID with Flag TBD.		These mappings are advertised as Remote-Binding SID with Flag TBD.
	The mappings advertised by an SR mapping server result from local		The mappings advertised by an SR mapping server result from local
	policy information configured by the operator. IF PE3 had been SR		policy information configured by the operator. If PE3 had been SR
	capable, the operator would have configured PE3 with node segment		capable, the operator would have configured PE3 with node segment
	103. Instead, as PE3 is not SR capable, the operator configures that		103. Instead, as PE3 is not SR capable, the operator configures that
	policy at the SRMS and it is the latter which advertises the mapping.		policy at the SRMS and it is the latter which advertises the mapping.
	Multiple SRMS servers can be provisioned in a network for redundancy.		Multiple SRMS servers can be provisioned in a network for redundancy.
	The mapping server advertisements are only understood by the SR		The mapping server advertisements are only understood by the SR
	capable routers. The SR capable routers install the related node		capable routers. The SR capable routers install the related node
	segments in the MPLS data plane exactly like if the node segments had		segments in the MPLS data plane exactly like if the node segments had
	been advertised by the nodes themselves.		been advertised by the nodes themselves.
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	PE1 has a service route whose nhop is PE3. PE1 has a node segment		PE1 has a service route whose nhop is PE3. PE1 has a node segment
	for that IGP route: 103 with nhop P5. Hence PE1 sends its service		for that IGP route: 103 with nhop P5. Hence PE1 sends its service
	packet to P5 with two labels: the bottom label is the service label		packet to P5 with two labels: the bottom label is the service label
	and the top label is 103.		and the top label is 103.
	P5 swaps 103 for 103 and forwards to P6.		P5 swaps 103 for 103 and forwards to P6.
	P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not		P6's next-hop for the IGP route "PE3" is not SR capable (P7 does not
	advertise the SR capability). However, P6 has an LDP label binding		advertise the SR capability). However, P6 has an LDP label binding
	from that next-hop for the same FEC (e.g. LDP label 1037). Hence, P6		from that next-hop for the same FEC (e.g. LDP label 1037). Hence,
	swaps 103 for 1037 and forwards to P7.		P6 swaps 103 for 1037 and forwards to P7.
	P7 swaps this label with the LDP-label received from P8 and forwards		P7 swaps this label with the LDP-label received from P8 and forwards
	to P8.		to P8.
	P8 pops the LDP label and forwards to PE3.		P8 pops the LDP label and forwards to PE3.
	PE3 receives the tunneled packet and processes the service label.		PE3 receives the tunneled packet and processes the service label.
	The end-to-end MPLS tunnel is built from an SR node segment from PE1		The end-to-end MPLS tunnel is built from an SR node segment from PE1
	to P6 and an LDP LSP from P6 to PE3.		to P6 and an LDP LSP from P6 to PE3.
	Note: SR mappings advertisements cannot set Penultimate Hop Popping.		Note: SR mappings advertisements cannot set Penultimate Hop Popping.
	In the previous example, P6 requires the presence of the segment 103		In the previous example, P6 requires the presence of the segment 103
	such as to map it to the LDP label 1037. For that reason, the P flag		such as to map it to the LDP label 1037. For that reason, the P flag
	available in the Prefix-SID is not available in the Remote-Bundle		available in the Prefix-SID is not available in the Remote-Binding
	SID.		SID.
	5. Leveraging SR benefits for LDP-based traffic		5. Leveraging SR benefits for LDP-based traffic
	SR can be deployed such as to enhance LDP transport. The SR		SR can be deployed such as to enhance LDP transport. The SR
	deployment can be limited to the network region where the SR benefits		deployment can be limited to the network region where the SR benefits
	are most desired.		are most desired.
	In Figure 4, let us assume:		In Figure 4, let us assume:
	skipping to change at page 10, line 18 ¶		skipping to change at page 10, line 18 ¶
	| | \		| | \
	D---C--F--G		D---C--F--G
	30		30
	Figure 4: Leveraging SR benefits for LDP-based-traffic		Figure 4: Leveraging SR benefits for LDP-based-traffic
	The operator would like to resolve the following issues:		The operator would like to resolve the following issues:
	To protect the link BA along the shortest-path of the important		To protect the link BA along the shortest-path of the important
	flow XY, B requires an RLFA repair tunnel to D and hence a		flow XY, B requires an RLFA repair tunnel to D and hence a
	directed LDP session from B to D. The operator does not like these		directed LDP session from B to D. The operator does not like
	dynamically established multi-hop LDP sessions and would seek to		these dynamically established multi-hop LDP sessions and would
	eliminate them.		seek to eliminate them.
	There is no LFA/RLFA solution to protect the link BE along the		There is no LFA/RLFA solution to protect the link BE along the
	shortest path of the important flow XZ. The operator wants a		shortest path of the important flow XZ. The operator wants a
	guaranteed link-based FRR solution.		guaranteed link-based FRR solution.
	The operator can meet these objectives by deploying SR only on A, B,		The operator can meet these objectives by deploying SR only on A, B,
	C, D, E and F:		C, D, E and F:
	The operator configures A, B, C, D, E, F and G with SRGB (100,		The operator configures A, B, C, D, E, F and G with SRGB (100,
	200) and respective node segments 101, 102, 103, 104, 105, 106 and		200) and respective node segments 101, 102, 103, 104, 105, 106 and
	skipping to change at page 11, line 34 ¶		skipping to change at page 11, line 34 ¶
	B's MPLS entry to Y becomes:		B's MPLS entry to Y becomes:
	- Incoming label: local LDB label bound by B for FEC Y		- Incoming label: local LDB label bound by B for FEC Y
	Outgoing label: LDP label bound by A for FEC Y		Outgoing label: LDP label bound by A for FEC Y
	Backup outgoing label: SR node segment for Y {202}		Backup outgoing label: SR node segment for Y {202}
	Outgoing nhop: A		Outgoing nhop: A
	Backup nhop: repair tunnel: node segment to D {104}		Backup nhop: repair tunnel: node segment to D {104}
	with outgoing nhop: C		with outgoing nhop: C
	In steady-state, X sends its Y-destined traffic to B with a top label		In steady-state, X sends its Y-destined traffic to B with a top label
	which is the LDP label bound by B for FEC Y. B swaps that top label		which is the LDP label bound by B for FEC Y. B swaps that top label
	for the LDP label bound by A for FEC Y and forwards to A. A pops the		for the LDP label bound by A for FEC Y and forwards to A. A pops the
	LDP label and forwards to Y.		LDP label and forwards to Y.
	Upon failure of the link BA, B swaps the incoming top-label with the		Upon failure of the link BA, B swaps the incoming top-label with the
	node segment for Y (202) and sends the packet onto a repair tunnel to		node segment for Y (202) and sends the packet onto a repair tunnel to
	D (node segment 104). Thus, B sends the packet to C with the label		D (node segment 104). Thus, B sends the packet to C with the label
	stack {104, 202}. C pops the node segment 104 and forwards to D. D		stack {104, 202}. C pops the node segment 104 and forwards to D. D
	swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable		swaps 202 for 202 and forwards to A. A's nhop to Y is not SR capable
	and hence A swaps the incoming node segment 202 to the LDP label		and hence A swaps the incoming node segment 202 to the LDP label
	announced by its next-hop (in this case, implicit null).		announced by its next-hop (in this case, implicit null).
	After IGP convergence, B's MPLS entry to Y will become:		After IGP convergence, B's MPLS entry to Y will become:
	- Incoming label: local LDB label bound by B for FEC Y		- Incoming label: local LDB label bound by B for FEC Y
	Outgoing label: LDP label bound by C for FEC Y		Outgoing label: LDP label bound by C for FEC Y
	Outgoing nhop: C		Outgoing nhop: C
	And the traffic XY travels again over the LDP LSP.		And the traffic XY travels again over the LDP LSP.
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 32 ¶
	FG {9001}		FG {9001}
	Note that {106, 107} would have equally work.		Note that {106, 107} would have equally work.
	Indeed, in many case, P's shortest path to Q is		Indeed, in many case, P's shortest path to Q is
	over the link PQ. The adjacency segment from P to		over the link PQ. The adjacency segment from P to
	Q is required only in very rare topologies where		Q is required only in very rare topologies where
	the shortest-path from P to Q is not via the link		the shortest-path from P to Q is not via the link
	PQ.		PQ.
	In steady-state, X sends its Z-destined traffic to B with a top label		In steady-state, X sends its Z-destined traffic to B with a top label
	which is the LDP label bound by B for FEC Z. B swaps that top label		which is the LDP label bound by B for FEC Z. B swaps that top label
	for the LDP label bound by E for FEC Z and forwards to E. E pops the		for the LDP label bound by E for FEC Z and forwards to E. E pops the
	LDP label and forwards to Z.		LDP label and forwards to Z.
	Upon failure of the link BE, B swaps the incoming top-label with the		Upon failure of the link BE, B swaps the incoming top-label with the
	node segment for Z (203) and sends the packet onto a repair tunnel to		node segment for Z (203) and sends the packet onto a repair tunnel to
	G (node segment 106 followed by adjacency segment 9001). Thus, B		G (node segment 106 followed by adjacency segment 9001). Thus, B
	sends the packet to C with the label stack {106, 9001, 203}. C pops		sends the packet to C with the label stack {106, 9001, 203}. C pops
	the node segment 106 and forwards to F. F pops the adjacency segment		the node segment 106 and forwards to F. F pops the adjacency segment
	9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's		9001 and forwards to G. G swaps 203 for 203 and forwards to E. E's
	nhop to Z is not SR capable and hence E swaps the incoming node		nhop to Z is not SR capable and hence E swaps the incoming node
	segment 203 for the LDP label announced by its next-hop (in this		segment 203 for the LDP label announced by its next-hop (in this
	case, implicit null).		case, implicit null).
	After IGP convergence, B's MPLS entry to Z will become:		After IGP convergence, B's MPLS entry to Z will become:
	- Incoming label: local LDB label bound by B for FEC Z		- Incoming label: local LDB label bound by B for FEC Z
	Outgoing label: LDP label bound by C for FEC Z		Outgoing label: LDP label bound by C for FEC Z
	Outgoing nhop: C		Outgoing nhop: C
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 17 ¶
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	11.2. Informative References		11.2. Informative References
	[I-D.filsfils-rtgwg-segment-routing]		[I-D.filsfils-spring-segment-routing]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,		Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
	Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,		Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
	"Segment Routing Architecture", draft-filsfils-rtgwg-		"Segment Routing Architecture", draft-filsfils-spring-
	segment-routing-01 (work in progress), October 2013.		segment-routing-04 (work in progress), July 2014.
			[I-D.filsfils-spring-segment-routing-mpls]
			Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
			Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
			Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
			"Segment Routing with MPLS data plane", draft-filsfils-
			spring-segment-routing-mpls-03 (work in progress), August
			2014.
	[I-D.ietf-mpls-seamless-mpls]		[I-D.ietf-mpls-seamless-mpls]
	Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,		Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
	M., and D. Steinberg, "Seamless MPLS Architecture", draft-		M., and D. Steinberg, "Seamless MPLS Architecture", draft-
	ietf-mpls-seamless-mpls-06 (work in progress), February		ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
	2014.
	[draft-filsfils-rtgwg-segment-routing-mpls-00]
	Filsfils, C. and S. Previdi, "Segment Routing with MPLS
	data plane", October 2013.
	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		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
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	skipping to change at page 16, line 29 ¶		skipping to change at page 16, line 36 ¶
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Ericsson
	300 Holger Way		300 Holger Way
	San Jose, CA 95134		San Jose, CA 95134
	US		US
	Email: Jeff.Tantsura@ericsson.com		Email: Jeff.Tantsura@ericsson.com
	Edward Crabbe		Edward Crabbe
	Google, Inc.		Individual Contributor
	1600 Amphitheatre Parkway
	Mountain View, CA 94043
	US
	Email: edc@google.com		Email: edward.crabbe@gmail.com
End of changes. 25 change blocks.
	44 lines changed or deleted		44 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/