< draft-ietf-spring-nsh-sr-00.txt		draft-ietf-spring-nsh-sr-01.txt >
	SPRING J. Guichard, Ed.		SPRING J. Guichard, Ed.
	Internet-Draft H. Song		Internet-Draft H. Song
	Intended status: Standards Track Futurewei Technologies		Intended status: Standards Track Futurewei Technologies
	Expires: February 8, 2020 J. Tantsura		Expires: April 6, 2020 J. Tantsura
	Apstra inc.		Apstra inc.
	J. Halpern		J. Halpern
	Ericsson		Ericsson
	W. Henderickx		W. Henderickx
	Nokia		Nokia
	M. Boucadair		M. Boucadair
	Orange		Orange
	S. Hassan		S. Hassan
	Cisco Systems		Cisco Systems
	August 7, 2019		October 4, 2019
	Network Service Header (NSH) and Segment Routing Integration for Service		Network Service Header (NSH) and Segment Routing Integration for Service
	Function Chaining (SFC)		Function Chaining (SFC)
	draft-ietf-spring-nsh-sr-00		draft-ietf-spring-nsh-sr-01
	Abstract		Abstract
	This document describes two application scenarios where Network		This document describes two application scenarios where Network
	Service Header (NSH) and Segment Routing (SR) techniques can be		Service Header (NSH) and Segment Routing (SR) techniques can be
	deployed together to support Service Function Chaining (SFC) in an		deployed together to support Service Function Chaining (SFC) in an
	efficient manner while maintaining separation of the service and		efficient manner while maintaining separation of the service and
	transport planes as originally intended by the SFC architecture.		transport planes as originally intended by the SFC architecture.
	In the first scenario, an NSH-based SFC is created using SR as the		In the first scenario, an NSH-based SFC is created using SR as the
	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 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 February 8, 2020.		This Internet-Draft will expire on April 6, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 2, line 43 ¶		skipping to change at page 2, line 43 ¶
	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. SFC Overview and Rationale . . . . . . . . . . . . . . . 3		1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.3. SFC within SR Networks . . . . . . . . . . . . . . . . . 4		1.3. SFC within SR Networks . . . . . . . . . . . . . . . . . 4
	2. NSH-based SFC with SR-based transport tunnel . . . . . . . . 5		2. NSH-based SFC with SR-based Transport Tunnel . . . . . . . . 5
	3. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9		3. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9
	4. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11		4. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11
	4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11		4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11
	4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12		4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13		6.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13
	6.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14		6.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	1.1. SFC Overview and Rationale		1.1. SFC Overview and Rationale
	The dynamic enforcement of a service-derived, adequate forwarding		The dynamic enforcement of a service-derived, adequate forwarding
	policy for packets entering a network that supports advanced Service		policy for packets entering a network that supports advanced Service
	Functions (SFs) has become a key challenge for operators and service		Functions (SFs) has become a key challenge for network operators.
	providers. Particularly, cascading SFs, for example at the Gi		Particularly, cascading SFs, for example at the Gi interface in the
	interface in the context of mobile network infrastructure, have shown		context of mobile network infrastructure, have shown their limits,
	their limits, such as the same redundant classification features must		such as the same redundant classification features must be supported
	be supported by many SFs in order to execute their function, some SFs		by many SFs in order to execute their function, some SFs are
	are receiving traffic that they are not supposed to process (e.g.,		receiving traffic that they are not supposed to process (e.g., TCP
	TCP proxies receiving UDP traffic), which inevitably affects their		proxies receiving UDP traffic), which inevitably affects their
	dimensioning and performance, an increased design complexity related		dimensioning and performance, an increased design complexity related
	to the properly ordered invocation of several SFs, etc.		to the properly ordered invocation of several SFs, etc.
	In order to solve those problems and to avoid the adherence with the		In order to solve those problems and to avoid the adherence with the
	underlying physical network topology while allowing for simplified		underlying physical network topology while allowing for simplified
	service delivery, Service Function Chaining (SFC) techniques have		service delivery, Service Function Chaining (SFC) techniques have
	been introduced.		been introduced.
	SFC techniques are meant to rationalize the service delivery logic		SFC techniques are meant to rationalize the service delivery logic
	and master the companion complexity while optimizing service		and master the companion complexity while optimizing service
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	1.2. Requirements Language		1.2. 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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	RFC2119 [RFC2119] when, and only when, they appear in all capitals,		RFC2119 [RFC2119] when, and only when, they appear in all capitals,
	as shown here.		as shown here.
	1.3. SFC within SR Networks		1.3. SFC within SR Networks
	As described in [I-D.ietf-spring-segment-routing], Segment Routing		As described in [RFC8402], Segment Routing (SR) leverages the source
	(SR) leverages the source routing technique. Concretely, a node		routing technique. Concretely, a node steers a packet through an SR
	steers a packet through an SR policy instantiated as an ordered list		policy instantiated as an ordered list of instructions called
	of instructions called segments. While initially designed for		segments. While initially designed for policy-based source routing,
	policy-based source routing, SR also finds its application in		SR also finds its application in supporting SFC
	supporting SFC [I-D.xu-clad-spring-sr-service-chaining]. The two SR		[I-D.xuclad-spring-sr-service-programming]. The two SR flavors,
	flavors, namely MPLS-SR [I-D.ietf-spring-segment-routing-mpls] and		namely MPLS-SR [I-D.ietf-spring-segment-routing-mpls] and SRv6
	SRv6 [I-D.ietf-6man-segment-routing-header], can both encode a		[I-D.ietf-6man-segment-routing-header], can both encode a Service
	Service Function (SF) as a segment so that an SFC can be specified as		Function (SF) as a segment so that an SFC can be specified as a
	a segment list. Nevertheless, and as discussed in [RFC7498], traffic		segment list. Nevertheless, and as discussed in [RFC7498], traffic
	steering is only a subset of the issues that motivated the design of		steering is only a subset of the issues that motivated the design of
	the SFC architecture. Further considerations such as simplifying		the SFC architecture. Further considerations such as simplifying
	classification at intermediate SFs and allowing for coordinated		classification at intermediate SFs and allowing for coordinated
	behaviors among SFs by means of supplying context information should		behaviors among SFs by means of supplying context information should
	be taken into account when designing an SFC data plane solution.		be taken into account when designing an SFC data plane solution.
	While each scheme (i.e., NSH-based SFC and SR-based SFC) can work		While each scheme (i.e., NSH-based SFC and SR-based SFC) can work
	independently, this document describes how the two can be used		independently, this document describes how the two can be used
	together in concert and complement each other through two		together in concert and complement each other through two
	representative application scenarios. Both application scenarios may		representative application scenarios. Both application scenarios may
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	o SR-based SFC with integrated NSH service plane: in this scenario		o SR-based SFC with integrated NSH service plane: in this scenario
	each service hop of the SFC is represented as a segment of the SR		each service hop of the SFC is represented as a segment of the SR
	segment-list. SR is responsible for steering traffic through the		segment-list. SR is responsible for steering traffic through the
	necessary SFFs as part of the segment routing path and NSH is		necessary SFFs as part of the segment routing path and NSH is
	responsible for maintaining the service plane, and holding the SFC		responsible for maintaining the service plane, and holding the SFC
	instance context and associated metadata.		instance context and associated metadata.
	It is of course possible to combine both of these two scenarios so as		It is of course possible to combine both of these two scenarios so as
	to support specific deployment requirements and use cases.		to support specific deployment requirements and use cases.
	2. NSH-based SFC with SR-based transport tunnel		A classifier SHOULD assign an NSH Service Path Identifier (SPI) per
			SR policy so that different traffic flows that use the same NSH
			Service Function Path (SFP) but different SR policy can coexist on
			the same SFP without conflict during SFF processing.
			2. NSH-based SFC with SR-based Transport Tunnel
	Because of the transport-independent nature of NSH-based service		Because of the transport-independent nature of NSH-based service
	chains, it is expected that the NSH has broad applicability across		chains, it is expected that the NSH has broad applicability across
	different domains of a network. By way of illustration the various		different domains of a network. By way of illustration the various
	SFs involved in a service chain are available in a single data		SFs involved in a service chain are available in a single data
	center, or spread throughout multiple locations (e.g., data centers,		center, or spread throughout multiple locations (e.g., data centers,
	different POPs), depending upon the operator preference and/or		different POPs), depending upon the operator preference and/or
	availability of service resources. Regardless of where the service		availability of service resources. Regardless of where the service
	resources are deployed it is necessary to provide traffic steering		resources are deployed it is necessary to provide traffic steering
	through a set of SFFs and NSH-based service chains provide the		through a set of SFFs and NSH-based service chains provide the
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 28 ¶
	end-to-end service plane through use of the SFC context. The SFC		end-to-end service plane through use of the SFC context. The SFC
	context (e.g., the service plane path referenced by the SPI) is used		context (e.g., the service plane path referenced by the SPI) is used
	by an SFF to determine the SR segment list for forwarding the packet		by an SFF to determine the SR segment list for forwarding the packet
	to the next-hop SFFs. The packet is then encapsulated using the		to the next-hop SFFs. The packet is then encapsulated using the
	(transport-specific) SR header and forwarded in the SR domain		(transport-specific) SR header and forwarded in the SR domain
	following normal SR operation.		following normal SR operation.
	When a packet has to be forwarded to an SF attached to an SFF, the		When a packet has to be forwarded to an SF attached to an SFF, the
	SFF performs a lookup on the prefix SID associated with the SF to		SFF performs a lookup on the prefix SID associated with the SF to
	retrieve the next-hop context between the SFF and SF. E.g. to		retrieve the next-hop context between the SFF and SF. E.g. to
	retrieve the destination MAC address in case native ethernet		retrieve the destination MAC address in case native Ethernet
	encapsulation is used between SFF and SF. How the next-hop context		encapsulation is used between SFF and SF. How the next-hop context
	is populated is out of the scope of this document. The SFF strips		is populated is out of the scope of this document. The SFF strips
	the SR information of the packet, updates the SR information, and		the SR information of the packet, updates the SR information, and
	saves it to a cache indexed by the NSH SPI. This saved SR		saves it to a cache indexed by the NSH SPI. This saved SR
	information is used to encapsulate and forward the packet(s) coming		information is used to encapsulate and forward the packet(s) coming
	back from the SF.		back from the SF.
	When the SF receives the packet, it processes it as usual and sends		When the SF receives the packet, it processes it as usual and sends
	it back to the SFF. Once the SFF receives this packet, it extracts		it back to the SFF. Once the SFF receives this packet, it extracts
	the SR information using the NSH SPI as the index into the cache.		the SR information using the NSH SPI as the index into the cache.
	skipping to change at page 11, line 34 ¶		skipping to change at page 11, line 34 ¶
	+------------------+		+------------------+
	| NSH Base Hdr |		| NSH Base Hdr |
	+------------------+		+------------------+
	| Service Path Hdr |		| Service Path Hdr |
	+------------------+		+------------------+
	~ Metadata ~		~ Metadata ~
	+------------------+		+------------------+
	Figure 5: NSH using MPLS-SR Transport		Figure 5: NSH using MPLS-SR Transport
	As described in [I-D.ietf-spring-segment-routing] the IGP signaling		As described in [RFC8402] the IGP signaling extension for IGP-Prefix
	extension for IGP-Prefix segment includes a flag to indicate whether		segment includes a flag to indicate whether directly connected
	directly connected neighbors of the node on which the prefix is		neighbors of the node on which the prefix is attached should perform
	attached should perform the NEXT operation or the CONTINUE operation		the NEXT operation or the CONTINUE operation when processing the SID.
	when processing the SID. When NSH is carried beneath MPLS-SR it is		When NSH is carried beneath MPLS-SR it is necessary to terminate the
	necessary to terminate the NSH-based SFC at the tail-end node of the		NSH-based SFC at the tail-end node of the MPLS-SR label stack. This
	MPLS-SR label stack. This is the equivalent of MPLS Ultimate Hop		is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore
	Popping (UHP) and therefore the prefix-SID associated with the tail-		the prefix-SID associated with the tail-end of the SFC MUST be
	end of the SFC MUST be advertised with the CONTINUE operation so that		advertised with the CONTINUE operation so that the penultimate hop
	the penultimate hop node does not pop the top label of the MPLS-SR		node does not pop the top label of the MPLS-SR label stack and
	label stack and thereby expose NSH to the wrong SFF. It is		thereby expose NSH to the wrong SFF. It is RECOMMENDED that a
	RECOMMENDED that a specific prefix-SID be allocated at each node for		specific prefix-SID be allocated at each node for use by the SFC
	use by the SFC application for this purpose.		application for this purpose.
	At the end of the MPLS-SR path it is necessary to provide an		At the end of the MPLS-SR path it is necessary to provide an
	indication to the tail-end that NSH follows the MPLS-SR label stack.		indication to the tail-end that NSH follows the MPLS-SR label stack.
	There are several ways to achieve this but its specification is		There are several ways to achieve this but its specification is
	outside the scope of this document.		outside the scope of this document.
	4.2. NSH using SRv6 Transport		4.2. NSH using SRv6 Transport
	When carrying NSH within an SRv6 transport the full encapsulation is		When carrying NSH within an SRv6 transport the full encapsulation is
	skipping to change at page 14, line 27 ¶		skipping to change at page 14, line 27 ¶
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	7. Acknowledgments		7. Acknowledgments
	TBD.		TBD.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-12		data plane", draft-ietf-spring-segment-routing-mpls-12
	(work in progress), February 2018.		(work in progress), February 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
			[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
			Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015,		DOI 10.17487/RFC7665, October 2015,
	<https://www.rfc-editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-		[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
	in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,		in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
	March 2017, <https://www.rfc-editor.org/info/rfc8086>.		March 2017, <https://www.rfc-editor.org/info/rfc8086>.
	[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,		[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300,		"Network Service Header (NSH)", RFC 8300,
	DOI 10.17487/RFC8300, January 2018,		DOI 10.17487/RFC8300, January 2018,
	<https://www.rfc-editor.org/info/rfc8300>.		<https://www.rfc-editor.org/info/rfc8300>.
			[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
			Decraene, B., Litkowski, S., and R. Shakir, "Segment
			Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
			July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-6man-segment-routing-header]		[I-D.ietf-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,		Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
	Field, B., daniel.voyer@bell.ca, d.,		Field, B., daniel.voyer@bell.ca, d.,
	daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,		daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
	Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,		Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
	D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing		D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
	Header (SRH)", draft-ietf-6man-segment-routing-header-09		Header (SRH)", draft-ietf-6man-segment-routing-header-09
	(work in progress), March 2018.		(work in progress), March 2018.
	[I-D.xu-clad-spring-sr-service-chaining]		[I-D.xuclad-spring-sr-service-programming]
	Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,		Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
	d., Decraene, B., Yadlapalli, C., Henderickx, W., Salsano,		d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
	S., and S. Ma, "Segment Routing for Service Chaining",		Henderickx, W., and S. Salsano, "Service Programming with
	draft-xu-clad-spring-sr-service-chaining-00 (work in		Segment Routing", draft-xuclad-spring-sr-service-
	progress), December 2017.		programming-02 (work in progress), April 2019.
	[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for		[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
	Service Function Chaining", RFC 7498,		Service Function Chaining", RFC 7498,
	DOI 10.17487/RFC7498, April 2015,		DOI 10.17487/RFC7498, April 2015,
	<https://www.rfc-editor.org/info/rfc7498>.		<https://www.rfc-editor.org/info/rfc7498>.
	Authors' Addresses		Authors' Addresses
	James N Guichard (editor)		James N Guichard (editor)
	Futurewei Technologies		Futurewei Technologies
End of changes. 15 change blocks.
	48 lines changed or deleted		56 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/