draft-ietf-lisp-alt-01.txt		draft-ietf-lisp-alt-02.txt
	Network Working Group V. Fuller		Network Working Group V. Fuller
	Internet-Draft D. Farinacci		Internet-Draft D. Farinacci
	Intended status: Experimental D. Meyer		Intended status: Experimental D. Meyer
	Expires: November 27, 2009 D. Lewis		Expires: July 29, 2010 D. Lewis
	Cisco		Cisco
	May 26, 2009		January 25, 2010
	LISP Alternative Topology (LISP+ALT)		LISP Alternative Topology (LISP+ALT)
	draft-ietf-lisp-alt-01.txt		draft-ietf-lisp-alt-02.txt
			Abstract
			This document describes a method of building an alternative, logical
			topology for managing Endpoint Identifier to Routing Locator mappings
			using the Locator/ID Separation Protocol. The logical network is
			built as an overlay on the public Internet using existing
			technologies and tools, specifically the Border Gateway Protocol and
			the Generic Routing Encapsulation. An important design goal for
			LISP+ALT is to allow for the relatively easy deployment of an
			efficient mapping system while minimizing changes to existing
			hardware and software.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 34		skipping to change at page 1, line 46
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 27, 2009.		This Internet-Draft will expire on July 29, 2010.
	Copyright Notice		Copyright Notice
			Copyright (c) 2010 IETF Trust and the persons identified as the
	Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document describes a method of building an alternative, logical		described in the BSD License.
	topology for managing Endpoint Identifier to Routing Locator mappings
	using the Locator/ID Separation Protocol. The logical network is
	built as an overlay on the public Internet using existing
	technologies and tools, specifically the Border Gateway Protocol and
	the Generic Routing Encapsulation. An important design goal for
	LISP+ALT is to allow for the relatively easy deployment of an
	efficient mapping system while minimizing changes to existing
	hardware and software.
	Table of Contents		Table of Contents
	1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4		1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
	4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 8		4. The LISP 1.5 model . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Connectivity to non-LISP sites . . . . . . . . . . . . . . 8		4.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8
	4.2. Caveats on the use of Data Probes . . . . . . . . . . . . 9		4.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9
			4.3. Caveats on the use of Data Probes . . . . . . . . . . . . 9
	5. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 10		5. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 10		5.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 11
	5.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 11		5.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 11
	5.3. LISP+ALT Router . . . . . . . . . . . . . . . . . . . . . 12		5.3. LISP+ALT Router (or ALT router for short) . . . . . . . . 12
	5.4. ITR and ETR in a LISP+ALT Environment . . . . . . . . . . 12		5.4. ITR and ETR in a LISP+ALT Environment . . . . . . . . . . 13
	5.5. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 13		5.5. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 13
	6. EID Prefix Propagation and Map-Request Forwarding . . . . . . 14		6. EID Prefix Propagation and Map-Request Forwarding . . . . . . 14
	6.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 14		6.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 14
	6.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 14		6.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 14
	7. BGP configuration and protocol considerations . . . . . . . . 16		7. BGP configuration and protocol considerations . . . . . . . . 16
	7.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 16		7.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 16
	7.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 16		7.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 16
	8. EID-Prefix Aggregation . . . . . . . . . . . . . . . . . . . . 17		8. EID-Prefix Aggregation . . . . . . . . . . . . . . . . . . . . 17
	8.1. Traffic engineering with LISP and LISP+ALT . . . . . . . . 17		8.1. Traffic engineering with LISP and LISP+ALT . . . . . . . . 17
	8.2. Edge aggregation and dampening . . . . . . . . . . . . . . 18		8.2. Edge aggregation and dampening . . . . . . . . . . . . . . 18
	skipping to change at page 6, line 14		skipping to change at page 6, line 14
	3. Definition of Terms		3. Definition of Terms
	LISP+ALT operates on two name spaces and introduces a new network		LISP+ALT operates on two name spaces and introduces a new network
	element, the LISP+ALT Router (see below). This section provides		element, the LISP+ALT Router (see below). This section provides
	high-level definitions of the LISP+ALT name spaces, network elements,		high-level definitions of the LISP+ALT name spaces, network elements,
	and message types.		and message types.
	The Alternative Logical Topology (ALT): The virtual overlay network		The Alternative Logical Topology (ALT): The virtual overlay network
	made up of tunnels between EID Prefix Aggregators. The Border		made up of tunnels between EID Prefix Aggregators. The Border
	Gateway Protocol (BGP) runs between LISP+ALT routers and is used		Gateway Protocol (BGP) runs between ALT routers and is used to
	to carry reachability information for EID prefixes.		carry reachability information for EID prefixes.
	Legacy Internet: The portion of the Internet which does not run LISP		Legacy Internet: The portion of the Internet which does not run LISP
	and does not participate in LISP+ALT.		and does not participate in LISP+ALT.
	LISP+ALT Router: The devices which run on the ALT. The ALT is a		LISP+ALT Router: The devices which run on the ALT. The ALT is a
	static network built using tunnels between LISP+ALT routers.		static network built using tunnels between LISP+ALT routers.
	These routers are deployed in a hierarchy in which routers at each		These routers are deployed in a hierarchy in which routers at each
	level in the this hierarchy are responsible for aggregating all		level in the this hierarchy are responsible for aggregating all
	EID prefixes learned from those logically "below" them and		EID prefixes learned from those logically "below" them and
	advertising summary prefixes to the routers logically "above"		advertising summary prefixes to the routers logically "above"
	them. All prefix learning and propagation between levels is done		them. All prefix learning and propagation between levels is done
	using BGP. LISP+ALT routers at the lowest level, or "edge", of		using BGP. A LISP+ALT router at the lowest level, or "edge" of
	the ALT learn EID prefixes either over a BGP session to ETRs or		the ALT, learns EID prefixes from its "client" ETRs. See
	through static routes (in the case of the "low-opex ETR"). See		Section 4.1 for a description of how EID prefixes are learned at
	Section 7 for details on how BGP is configured between the		the "edge" of the ALT. See also Section 7 for details on how BGP
	different network elements.		is configured between the different network elements.
	The primary function of LISP+ALT routers is to provide a		The primary function of LISP+ALT routers is to provide a
	lightweight forwarding infrastructure for LISP control-plane		lightweight forwarding infrastructure for LISP control-plane
	messages (Map-Request and Map-Reply), and to transport data		messages (Map-Request and Map-Reply), and to transport data
	packets when the packet has the same destination address in both		packets when the packet has the same destination address in both
	the inner (encapsulating) destination and outer destination		the inner (encapsulating) destination and outer destination
	addresses ((i.e., a Data Probe packet).		addresses ((i.e., a Data Probe packet).
	Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for ipv6) value		Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for ipv6) value
	used in the source and destination address fields of the first		used in the source and destination address fields of the first
	skipping to change at page 7, line 29		skipping to change at page 7, line 29
	EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that		EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that
	can be used to reach the EID. The term "mapping" refers to an		can be used to reach the EID. The term "mapping" refers to an
	EID-to-RLOC mapping.		EID-to-RLOC mapping.
	EID Prefix Reachability: An EID prefix is said to be "reachable" if		EID Prefix Reachability: An EID prefix is said to be "reachable" if
	one or more of its locators are reachable. That is, an EID prefix		one or more of its locators are reachable. That is, an EID prefix
	is reachable if the ETR (or its proxy) that is authoritative for a		is reachable if the ETR (or its proxy) that is authoritative for a
	given EID-to-RLOC mapping is reachable.		given EID-to-RLOC mapping is reachable.
	Default Mapping: A Default Mapping is a mapping entry for EID-		Default Mapping: A Default Mapping is a mapping entry for EID-
	prefix 0.0.0.0/0. It maps to a locator-set used for all EIDs in		prefix 0.0.0.0/0 (0::/0 for ipv6). It maps to a locator-set used
	the Internet. If there is a more specific EID-prefix in the		for all EIDs in the Internet. If there is a more specific EID-
	mapping cache it overrides the Default Mapping entry. The Default		prefix in the mapping cache it overrides the Default Mapping
	Mapping route can be learned by configuration or from a Map-Reply		entry. The Default Mapping route can be learned by configuration
	message.		or from a Map-Reply message.
	Default Route: A Default Route in the context of LISP+ALT is a EID-		Default Route: A Default Route in the context of LISP+ALT is a EID-
	prefix value of 0.0.0.0/0 which is advertised by BGP on top of the		prefix value of 0.0.0.0/0 (or 0::/0 for ipv6) which is advertised
	ALT. The Default Route is used to realize a path for Data Probe		by BGP on top of the ALT. The Default Route is used to create a
	or Map-Request packets.		forwarding path for a packet to be sent into the ALT (and ALT
			datagram) on a router which does not have a full ALT forwarding
			database.
	4. The LISP 1.5 model		4. The LISP 1.5 model
	As documented in [LISP], the LISP 1.5 model uses the same basic		As documented in [LISP], the LISP 1.5 model uses the same basic
	query/response protocol machinery as LISP 1.0. In particular, LISP+		query/response protocol machinery as LISP 1.0. In particular, LISP+
	ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings		ALT provides two mechanisms for an ITR to obtain EID-to-RLOC mappings
	(both of these techniques are described in more detail in		(both of these techniques are described in more detail in
	Section 9.2):		Section 9.2):
	Data Probe: An ITR may send the first few data packets into the ALT		Data Probe: An ITR may send the first few data packets into the ALT
	to minimize packet loss and to probe for the mapping; the		to minimize packet loss and to probe for the mapping; the
	authoritative ETR will respond to the ITR with a Map-Reply message		authoritative ETR will respond to the ITR with a Map-Reply message
	when it receives the data packet over the ALT. Note that in this		when it receives the data packet over the ALT. Note that in this
	case, the inner Destination Address (DA), which is an EID, is		case, the inner Destination Address (DA), which is an EID, is
	copied to the outer DA and is routed over the ALT.		copied to the outer DA and is routed over the ALT.
	Map-Request: An ITR may also send a Map-Request message into the ALT		Map-Request: An ITR may also send a Map-Request message into the ALT
	to request the mapping. As in the Data Probe case, the		to request the mapping. As in the Data Probe case, the
	authoritative ETR will respond to the ITR with a Map-Reply		authoritative ETR will respond to the ITR with a Map-Reply
	message. In this case, the DA of the Map-Request MUST be an EID.		message. Since the ALT only forwards on EID destinations, the DA
	See [LISP] for the format of Map-Request and Map-Reply packets.		of the Map-Request sent in to the ALT MUST be an EID. See [LISP]
			for the format of Map-Request and Map-Reply packets.
			ALT datagram: A Map-Request or Data Probe to be sent into or
			forwarded on the ALT.
			4.1. Routeability of EIDs
	As with LISP 1.0, EIDs are routable and can be used, unaltered, as		As with LISP 1.0, EIDs are routable and can be used, unaltered, as
	the source and destination addresses in IP datagrams. Unlike in LISP		the source and destination addresses in IP datagrams. Unlike in LISP
	1.0, LISP 1.5 EIDs are not routable on the public Internet; instead,		1.0, LISP 1.5 EIDs are not routable on the public Internet; instead,
	they are only routed over a separate, virtual topology referred to as		they are only routed over a separate, virtual topology referred to as
	the LISP Alternative Virtual Network. This network is built as an		the LISP Alternative Virtual Network. This network is built as an
	overlay on the public Internet using tunnels to interconnect LISP+ALT		overlay on the public Internet using tunnels to interconnect LISP+ALT
	routers. BGP is run over these tunnels to propagate the information		routers. BGP is run over these tunnels to propagate the information
	needed to route Data Probes and Map-Request/Replies. Importantly,		needed to route ALT datagrams. Importantly, while the ETRs are the
	while the ETRs are the source(s) of the unaggregated EID prefix data,		source(s) of the unaggregated EID prefix data, LISP+ALT uses existing
	LISP+ALT uses existing BGP mechanisms to aggressively aggregate this		BGP mechanisms to aggressively aggregate this information. Note that
	information. Note that ETRs are not required to participate (or		an ETR is not required to participate (or prevented from
	prevented from participating) in LISP+ALT; they may choose		participating) in LISP+ALT; an ETR may choose to communicate its
	communicate their mappings to their serving LISP+ALT router(s) at		mappings to its serving LISP+ALT router(s) using subscription time
	subscription time via configuration. ITRs are also not required to		static configuration or through a dynamic mechanism such as that
	participate in (nor prevented from participating in) LISP+ALT.		described in [LISP-MS]. An ITR may similarly use a static EID
			"default route" or other configuration as described in [LISP-MS] to
			avoid the complexity of participating in the ALT.
	4.1. Connectivity to non-LISP sites		4.2. Connectivity to non-LISP sites
	As stated above, EIDs used as IP addresses by LISP sites are not		As stated above, EIDs used as IP addresses by LISP sites are not
	routable on the public Internet. This implies that, absent a		routable on the public Internet. This implies that, absent a
	mechanism for communication between LISP and non-LISP sites,		mechanism for communication between LISP and non-LISP sites,
	connectivity between them is not possible. To resolve this problem,		connectivity between them is not possible. To resolve this problem,
	an "interworking" technology has been defined; see [Interworking] for		an "interworking" technology has been defined; see [Interworking] for
	details.		details.
	4.2. Caveats on the use of Data Probes		4.3. Caveats on the use of Data Probes
	It is worth noting that there has been a great deal of discussion and		It is worth noting that there has been a great deal of discussion and
	controversy about whether Data Probes are a good idea. On the one		controversy about whether Data Probes are a good idea. On the one
	hand, using them offers a method of avoiding the "first packet drop"		hand, using them offers a method of avoiding the "first packet drop"
	problem when an ITR does not have a mapping for a particular EID-		problem when an ITR does not have a mapping for a particular EID-
	prefix. On the other hand, forwarding data packets on the ALT would		prefix. On the other hand, forwarding data packets on the ALT would
	require that it either be engineered to support relatively high		require that it either be engineered to support relatively high
	traffic rates, which is not generally feasible for a tunneled		traffic rates, which is not generally feasible for a tunneled
	network, or that it be carefully designed to aggressively rate- limit		network, or that it be carefully designed to aggressively rate- limit
	traffic to avoid congestion or DoS attacks. There are also other		traffic to avoid congestion or DoS attacks. There are also other
	skipping to change at page 10, line 17		skipping to change at page 10, line 17
	LISP+ALT is a hybrid push/pull architecture. Aggregated EID prefixes		LISP+ALT is a hybrid push/pull architecture. Aggregated EID prefixes
	are "pushed" among the LISP+ALT routers and, optionally, out to ITRs		are "pushed" among the LISP+ALT routers and, optionally, out to ITRs
	(which may elect to receive the aggregated information, as opposed to		(which may elect to receive the aggregated information, as opposed to
	simply using a default mapping). Specific EID-to-RLOC mappings are		simply using a default mapping). Specific EID-to-RLOC mappings are
	"pulled" by ITRs when they either send explicit LISP requests or data		"pulled" by ITRs when they either send explicit LISP requests or data
	packets on the alternate topology that result in triggered replies		packets on the alternate topology that result in triggered replies
	being generated by ETRs.		being generated by ETRs.
	The basic idea embodied in LISP+ALT is to use BGP, running over		The basic idea embodied in LISP+ALT is to use BGP, running over
	tunneled overlay network, to establish reachability required to route		tunneled overlay network, to establish reachability required to route
	Data Probes and Map-Requests over an alternate logical topology		ALT datagrams over an alternate logical topology (ALT). The ALT
	(ALT). The ALT BGPRoute Information Base (RIB) is comprised of EID		BGPRoute Information Base (RIB) is comprised of EID prefixes and
	prefixes and associated next hops. LISP+ALT routers interconnect		associated next hops. LISP+ALT routers interconnect using eBGP and
	using eBGP and propagate EID prefix updates, which are learned over		propagate EID prefix updates, which are learned over eBGP connections
	eBGP connections to authoritative ETRs, or by static configuration.		to authoritative ETRs, or by static configuration. ITRs may also
	ITRs may also eBGP peer with one or more LISP+ALT to learn the best		eBGP peer with one or more LISP+ALT to learn the best ALT router to
	ALT router to use to forward a Data Proble or Map-Request for a		use to forward an ALT datagram for a particular prefix; in most
	particular prefix; in most cases, an ITR will have a default EID		cases, an ITR will have a default EID mapping pointing to one or more
	mapping pointing to one or more LISP+ALT routers.		LISP+ALT routers.
	Note that while this document specifies the use of Generic Routing		Note that while this document specifies the use of Generic Routing
	Encapsulation (GRE) as a tunneling mechanism, there is no reason that		Encapsulation (GRE) as a tunneling mechanism, there is no reason that
	an ALT cannot be built using other tunneling technologies. In cases		an ALT cannot be built using other tunneling technologies. In cases
	where GRE does not meet security, management, or other operational		where GRE does not meet security, management, or other operational
	requirements, it is reasonable to use another tunneling technology		requirements, it is reasonable to use another tunneling technology
	that does. References to "GRE tunnel" in later sections of this		that does. References to "GRE tunnel" in later sections of this
	document should therefore not be taken as prohibiting or precluding		document should therefore not be taken as prohibiting or precluding
	the use of other, available tunneling mechanisms.		the use of other, available tunneling mechanisms. Note also that two
			LISP+ALT routers that are directly adjacent (with no layer-3 router
			hops between them) need not use a tunnel between them; in this case,
			BGP may be configured across the interfaces that connect to their
			common subnet and that subnet is considered to be part of the ALT
			topology. Use of techniques, such as "eBGP multihop", to forward ALT
			datagrams through routers that do not participate in ALT routing, is
			not recommended.
	In summary, LISP+ALT uses BGP to propagate EID-prefix update		In summary, LISP+ALT uses BGP to propagate EID-prefix update
	information to facilitate forwarding a Map-Reqeusts or Data Probe to		information to facilitate forwarding an ALT datagram to the ETR that
	the ETR that holds the EID-to-RLOC mapping for that EID-prefix. This		holds the EID-to-RLOC mapping for that EID-prefix. This reachability
	reachability is carried as IPv4 or IPv6 NLRI without modification		is carried as IPv4 or IPv6 NLRI without modification (since an EID
	(since an EID prefix has the same syntax as IPv4 or IPv6 address		prefix has the same syntax as IPv4 or IPv6 address prefix). LISP+ALT
	prefix). LISP+ALT routers eBGP peer with one another, forming the		routers eBGP peer with one another, forming the ALT. A LISP+ALT
	ALT. A LISP+ALT router near the edge learns EID prefixes originated		router near the edge learns EID prefixes originated by authoritative
	by authoritative ETRs, either by eBGP peering with them or by		ETRs. This may be via eBGP with the ETRs, by static configuration,
	configuration. LISP+ALT routers aggregate EID prefixes, and forward		or through some other dynamic mechanism such as that defined in
	Data Probes and Map-Requests.		[LISP-MS]. A LISP+ALT router may also be configured to aggregate EID
			prefixes received from ETRs or from other LISP+ALT routers that are
			topologically "downstream" from it.
	5.1. ITR traffic handling		5.1. ITR traffic handling
	When an ITR receives a packet originated by an end system within its		When an ITR receives a packet originated by an end system within its
	site (i.e. a host for which the ITR is the exit path out of the site)		site (i.e. a host for which the ITR is the exit path out of the site)
	and the destination for that packet is not known in the ITR's mapping		and the destination for that packet is not known in the ITR's mapping
	cache, the ITR encapsulates the packet in a LISP header, copying the		cache, the ITR encapsulates the packet in a LISP header, copying the
	inner destination address (EID) to the outer destination address		inner destination address (EID) to the outer destination address
	(RLOC), and transmits it through a GRE tunnel to a LISP+ALT router in		(RLOC), and transmits it through a GRE tunnel to a LISP+ALT router in
	the ALT. This "first hop" LISP+ALT router uses EID-prefix routing		the ALT (see also [LISP-MS] for non-ALT-connected ITRs, noting that
	information learned from other LISP+ALT routers via BGP to guide the		an ITR cannot send Data Probes to a Map-Server). This "first hop"
	packet to the ETR which "owns" the prefix. Upon receipt by the ETR,		LISP+ALT router uses EID-prefix routing information learned from
	normal LISP processing occurs: the ETR responds to the ITR with a		other LISP+ALT routers via BGP to guide the packet to the ETR which
	LISP Map-Reply that lists the RLOCs (and, thus, the ETRs to use) for		"owns" the prefix. Upon receipt by the ETR, normal LISP processing
	the EID prefix. The ETR also de-encapsulates the packet and		occurs: the ETR responds to the ITR with a LISP Map-Reply that lists
	transmits it toward its destination.		the RLOCs (and, thus, the ETRs to use) for the EID prefix. The ETR
			also de-encapsulates the packet and transmits it toward its
			destination.
	Upon receipt of the Map-Reply, the ITR installs the RLOC information		Upon receipt of the Map-Reply, the ITR installs the RLOC information
	for a given prefix into a local mapping database. With these mapping		for a given prefix into a local mapping database. With these mapping
	entries stored, additional packets destined to the given EID prefix		entries stored, additional packets destined to the given EID prefix
	are routed directly to a viable ETR without use of the ALT, until		are routed directly to a viable ETR without use of the ALT, until
	either the entry's TTL has expired, or the ITR can otherwise find no		either the entry's TTL has expired, or the ITR can otherwise find no
	reachable ETR. Note that a valid mapping (not timed-out) may exist		reachable ETR. Note that a valid mapping (not timed-out) may exist
	that contains no reachable RLOCs (i.e. all paths to that ETR are		that contains no reachable RLOCs (i.e. all paths to that ETR are
	down); in this case, packets destined to the EID prefix are dropped,		down); in this case, packets destined to the EID prefix are dropped,
	not routed through the ALT.		not routed through the ALT.
	skipping to change at page 11, line 47		skipping to change at page 12, line 11
	aggregation at merge points in the tree. Building such a structure		aggregation at merge points in the tree. Building such a structure
	should minimize the number of EID-prefixes carried by LISP+ALT nodes		should minimize the number of EID-prefixes carried by LISP+ALT nodes
	near the top of the hierarchy.		near the top of the hierarchy.
	Since the ALT will not need to change due to subscription or policy		Since the ALT will not need to change due to subscription or policy
	reasons, the topology can remain relatively static and aggregation		reasons, the topology can remain relatively static and aggregation
	can be sustained. Because routing on the ALT uses BGP, the same		can be sustained. Because routing on the ALT uses BGP, the same
	rules apply for generating aggregates; in particular, a LISP+ALT		rules apply for generating aggregates; in particular, a LISP+ALT
	router should only be configured to generate an aggregate if it is		router should only be configured to generate an aggregate if it is
	configured with BGP sessions to all of the originators of components		configured with BGP sessions to all of the originators of components
	(more-specifics prefixes) of that aggregae; not all of the components		(more-specifics prefixes) of that aggregate; not all of the
	of need to be present for the aggregate to be originated (some may be		components of need to be present for the aggregate to be originated
	holes in the covering prefix and some may be down) but the		(some may be holes in the covering prefix and some may be down) but
	aggregating router must be configured to learn the state of all of		the aggregating router must be configured to learn the state of all
	the components.		of the components.
	As an example, consider ETRs that are originating EID prefixes for		As an example, consider ETRs that are originating EID prefixes for
	10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24. An ALT		10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24. An ALT
	router should only be configured to generate an aggregate for		router should only be configured to generate an aggregate for
	10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,		10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,
	in other words, only if it has sufficient knowledge about the state		in other words, only if it has sufficient knowledge about the state
	of those prefixes to summarize them.		of those prefixes to summarize them.
	Under what circumstances the ALT router actually generates the		Under what circumstances the ALT router actually generates the
	aggregate is a matter of local policy: in some cases, it will be		aggregate is a matter of local policy: in some cases, it will be
	statically configured to do so at all times with a "static discard"		statically configured to do so at all times with a "static discard"
	route. In other cases, it may be configured to only generate the		route. In other cases, it may be configured to only generate the
	aggregate prefix if at least one of the components of the aggregate		aggregate prefix if at least one of the components of the aggregate
	is learned via BGP.		is learned via BGP.
	This implies that two ALTs that share an overlapping set of prefixes		This implies that two ALT routers that share an overlapping set of
	must exchange those prefixes if either is to generate and export a		prefixes must exchange those prefixes if either is to generate and
	covering aggregate for those prefixes. It also implies that an ETR		export a covering aggregate for those prefixes. It also implies that
	that originates a prefix must maintain BGP sessions with all ALT		an ETR which connects to the ALT using BGP must maintain BGP sessions
	routers that are configured to originate an aggregate which covers		with all of the ALT routers that are configured to originate an
	that prefix.		aggregate which covers that prefix. See also [LISP-MS] for an
			example of other ways that prefix origin consistency and aggregation
			are maintained.
	Note: much is currently uncertain about the best way to build the ALT		Note: much is currently uncertain about the best way to build the ALT
	network; as testing and prototype deployment proceeds, a guide to how		network; as testing and prototype deployment proceeds, a guide to how
	to best build the ALT network will be developed.		to best build the ALT network will be developed.
	5.3. LISP+ALT Router		5.3. LISP+ALT Router (or ALT router for short)
	A LISP+ALT Router has the following functionality:		A LISP+ALT Router has the following functionality:
	1. It runs, at a minimum, the eBGP part of the BGP protocol.		1. It runs, at a minimum, the eBGP part of the BGP protocol.
	2. It supports a separate RIB which uses next-hop GRE tunnel		2. It supports a separate RIB which uses next-hop GRE tunnel
	interfaces for forwarding Data Probes and Map-Requests.		interfaces for forwarding ALT datagrams.
	3. It can act as a "proxy-ITR" to support non-LISP sites.		3. It can act as a "proxy-ITR" to support non-LISP sites.
	4. It can act as an ETR, or as a recursive or re-encapsulating ITR		4. It can act as an ETR, or as a recursive or re-encapsulating ITR
	to reduce mapping tables in site-based LISP routers.		to reduce mapping tables in site-based LISP routers.
	5.4. ITR and ETR in a LISP+ALT Environment		5.4. ITR and ETR in a LISP+ALT Environment
	An ITR using LISP+ALT may have additional functionality as follows:		An ITR using LISP+ALT may have additional functionality as follows:
	1. If it is also acting as a LISP+ALT Router, it sends Data Probes		1. If it is also acting as a LISP+ALT Router, it sends ALT datagrams
	or Map-Requests on the BGP best path computed GRE tunnel for each		on the BGP best path computed GRE tunnel for each EID prefix.
	EID prefix.
	2. When acting solely as a ITR, it sends Data Probes or Map-Requests		2. When acting solely as a ITR, it sends ALT datagrams directly to a
	directly to a configured LISP+ALT router.		configured LISP+ALT router.
	An ETR using LISP+ALT may also behave slightly differently:		An ETR using LISP+ALT may also behave slightly differently:
	1. If it is also acting as a LISP+ALT router, it advertises its		1. If it is also acting as a LISP+ALT router, it advertises its
	configured EID-prefixes into BGP for distribution through the		configured EID-prefixes into BGP for distribution through the
	ALT.		ALT.
	2. It receives Data Probes and Map-Requests only over GRE tunnel(s)		2. It receives ALT datagrams only from its "upstream" LISP+ALT
	to its "upstream" LISP+ALT router(s) and responds with Map-		routers over the GRE tunnel(s) configured to it/them. It
	Replies for the EID prefixes that it "owns".		responds with Map-Replies for the EID prefixes that it "owns".
	5.5. Use of GRE and BGP between LISP+ALT Routers		5.5. Use of GRE and BGP between LISP+ALT Routers
	The ALT network is built using GRE tunnels between LISP+ALT routers.		The ALT network is built using GRE tunnels between LISP+ALT routers.
	eBGP sessions are configured over those tunnels, with each LISP+ALT		eBGP sessions are configured over those tunnels, with each LISP+ALT
	router acting as a separate AS "hop" in a Path Vector for BGP. For		router acting as a separate AS "hop" in a Path Vector for BGP. For
	the purposes of LISP+ALT, the AS-path is used solely as a shortest-		the purposes of LISP+ALT, the AS-path is used solely as a shortest-
	path determination and loop-avoidance mechanism. Because all next-		path determination and loop-avoidance mechanism. Because all next-
	hops are on tunnel interfaces, no IGP is required to resolve those		hops are on tunnel interfaces, no IGP is required to resolve those
	next-hops to exit interfaces.		next-hops to exit interfaces.
	skipping to change at page 14, line 23		skipping to change at page 14, line 23
	the ALT - an ETR sends a Map-Reply to the source RLOC learned from		the ALT - an ETR sends a Map-Reply to the source RLOC learned from
	the original Map-Request. There may be scenarios, perhaps to		the original Map-Request. There may be scenarios, perhaps to
	encourage caching of EID-to-RLOC mappings by ALT routers, where Map-		encourage caching of EID-to-RLOC mappings by ALT routers, where Map-
	Replies could be sent over the ALT or where a "first-hop" ALT router		Replies could be sent over the ALT or where a "first-hop" ALT router
	might modify the originating RLOC on a Map-Request received from an		might modify the originating RLOC on a Map-Request received from an
	ITR to force the Map-Reply to be sent to it; these cases will not be		ITR to force the Map-Reply to be sent to it; these cases will not be
	supported by initial LISP+ALT implementations but may be subject to		supported by initial LISP+ALT implementations but may be subject to
	future experimentation.		future experimentation.
	LISP+ALT routers propagate mapping information for use by ITRs (when		LISP+ALT routers propagate mapping information for use by ITRs (when
	making Map-Requests or sending Data Probes) using eBGP [RFC4271].		sending ALT datagrams) using eBGP [RFC4271]. eBGP is run on the
	eBGP is run on the inter-LISP+ALT router links, and and possibly		inter-LISP+ALT router links, and possibly between an edge ("last
	between an edge ("last hop") LISP+ALT router and an ETR or between an		hop") LISP+ALT router and an ETR or between an edge ("first hop")
	edge ("first hop") LISP+ALT router and an ITR. The ALT eBGP RIB		LISP+ALT router and an ITR. The ALT eBGP RIB consists of aggregated
	consists of aggregated EID prefixes and their next hops toward the		EID prefixes and their next hops toward the authoritative ETR for
	authoritative ETR for that EID prefix.		that EID prefix.
	6.1. Changes to ITR behavior with LISP+ALT		6.1. Changes to ITR behavior with LISP+ALT
	When using LISP+ALT, an ITR always sends either Data Probes or Map-		When using LISP+ALT, an ITR sends ALT datagrams to one of its
	Requests to one of its "upstream" LISP+ALT routers. As in basic		"upstream" LISP+ALT routers; these are sent only to obtain new EID-
	LISP, it should use one of its RLOCs as the source address of these		to-RLOC mappings - RLOC probe and cache TTL refresh Map-Requests are
	queries; it should explicitly not use a tunnel interface as the		not sent on the ALT. As in basic LISP, it should use one of its
	source address as doing so will cause replies to be forwarded over		RLOCs as the source address of these queries; it should explicitly
	the tunneled topology and may be problematic if the tunnel interface		not use a tunnel interface as the source address as doing so will
	address is not explicitly routed throughout the ALT. If the ITR is		cause replies to be forwarded over the tunneled topology and may be
	running BGP with the LISP+ALT router(s), it selects the appropriate		problematic if the tunnel interface address is not explicitly routed
	LISP+ALT router based on the BGP information received. If it is not		throughout the ALT. If the ITR is running BGP with the LISP+ALT
	running BGP, it uses static configuration to select a LISP+ALT		router(s), it selects the appropriate LISP+ALT router based on the
	router; in the general case, this will effectively be an "EID-prefix		BGP information received. If it is not running BGP, it uses static
	default route".		configuration to select a LISP+ALT router; in the general case, this
			will effectively be an "EID-prefix default route".
	6.2. Changes to ETR behavior with LISP+ALT		6.2. Changes to ETR behavior with LISP+ALT
	If an ETR connects using BGP to one or more LISP+ALT router(s), it		If an ETR connects using BGP to one or more LISP+ALT router(s), it
	simply announces its EID-prefix to those LISP+ALT routers. In the		simply announces its EID-prefix to those LISP+ALT routers. Note that
	"low-opex" case, where the ETR does not use BGP, it will still have a		when an ETR generates a Map-Reply message to return to a querying
	GRE tunnel to one or more LISP+ALT routers; these LISP+ALT router(s)		ITR, it sends it to the ITR's source-RLOC (i.e., on the underlying
	the ETR must route Map-Requests and Data Probes to the ETR and		Internet topology, not on the ALT; this avoids any latency penalty
	contain configuration (in effect, static routes) for the ETR's EID-		(or "stretch") that might be incurred by routing over the ALT).
	prefixes. Note that in either case, when an ETR generates a Map-
	Reply message to return to a querying ITR, it sends it to the ITR's
	source-RLOC (i.e., on the underlying Internet topology, not on the
	ALT; this avoids any latency penalty that might be incurred by
	routing over the ALT).
	See also Section 9 for more details about the "low-opex" ETR and ITR
	configurations.
	7. BGP configuration and protocol considerations		7. BGP configuration and protocol considerations
	7.1. Autonomous System Numbers (ASNs) in LISP+ALT		7.1. Autonomous System Numbers (ASNs) in LISP+ALT
	The primary use of BGP today is to define the global Internet routing		The primary use of BGP today is to define the global Internet routing
	topology in terms of its participants, known as Autonomous Systems.		topology in terms of its participants, known as Autonomous Systems.
	LISP+ALT specifies the use of BGP to create a global EID-to-RLOC		LISP+ALT specifies the use of BGP to create a global EID-to-RLOC
	mapping database which, while related to the global routing database,		mapping database which, while related to the global routing database,
	serves a very different purpose and is organized into a very		serves a very different purpose and is organized into a very
	skipping to change at page 18, line 16		skipping to change at page 18, line 16
	Note also that normal BGP best common practices apply to the ALT		Note also that normal BGP best common practices apply to the ALT
	network. In particular, first-hop ALT routers will aggregate EID		network. In particular, first-hop ALT routers will aggregate EID
	prefixes and dampen changes to them in the face of excessive updates.		prefixes and dampen changes to them in the face of excessive updates.
	Since EID prefix assignments are not expected to change with anywhere		Since EID prefix assignments are not expected to change with anywhere
	as frequently BGP prefix reachability on the Internet, such dampening		as frequently BGP prefix reachability on the Internet, such dampening
	should be very rare and might be worthy of logging as an exceptional		should be very rare and might be worthy of logging as an exceptional
	event. It is again worth noting that the ALT carries only EID		event. It is again worth noting that the ALT carries only EID
	prefixes, along with BGP-generated paths to the ETRs that source		prefixes, along with BGP-generated paths to the ETRs that source
	those prefixes as advertisements travel over the logical topology;		those prefixes as advertisements travel over the logical topology;
	this set of information is considerablly less volitile than the		this set of information is considerablly less volatile than the
	actual EID-to-RLOC mappings.		actual EID-to-RLOC mappings.
	9. Connecting sites to the ALT network		9. Connecting sites to the ALT network
	9.1. ETRs originating information into the ALT		9.1. ETRs originating information into the ALT
	EID prefix information is originated into the ALT by two different		EID prefix information is originated into the ALT by two different
	mechanisms:		mechanisms:
	eBGP: An ETR may participate in the LISP+ALT overlay network by		eBGP: An ETR usually participates in the LISP+ALT overlay network by
	running eBGP to one or more LISP+ALT router(s) over GRE tunnel(s).		running eBGP to one or more LISP+ALT router(s) over tunnel(s).
	In this case, the ETR advertises reachability for its EID prefixes		The ETR advertises reachability for its EID prefixes over these
	over these eBGP connection(s). The LISP+ALT router(s) that		eBGP connection(s). The LISP+ALT router(s) that receive(s) these
	receive(s) these prefixes then propagate(s) them into the ALT.		prefixes then propagate(s) them into the ALT. Here the ETR is
	Here the ETR is simply an eBGP peer of LISP+ALT router(s) at the		simply an eBGP peer of LISP+ALT router(s) at the edge of the ALT.
	edge of the ALT. Where possible, a LISP+ALT router that receives		Where possible, a LISP+ALT router that receives EID prefixes from
	EID prefixes from an ETR via eBGP should aggregate that		an ETR via eBGP should aggregate that information.
	information.
	Configuration: One or more LISP+ALT router(s) may be configured to		Configuration: One or more LISP+ALT router(s) may be configured to
	originate an EID prefix on behalf of the non-BGP-speaking ETR that		originate an EID prefix on behalf of the non-BGP-speaking ETR that
	is authoritative for a prefix. As in the case above, the ETR is		is authoritative for a prefix. As in the case above, the ETR is
	connected to LISP+ALT router(s) using GRE tunnel(s) but rather		connected to LISP+ALT router(s) using GRE tunnel(s) but rather
	than BGP being used, the LISP+ALT router(s) are configured with		than BGP being used, the LISP+ALT router(s) are configured with
	what are in effect "static routes" for the EID prefixes "owned" by		what are in effect "static routes" for the EID prefixes "owned" by
	the ETR. The GRE tunnel is used to route Map-Requests to the ETR.		the ETR. The GRE tunnel is used to route Map-Requests to the ETR.
	Note that the LISP+ALT router could also serve as a proxy for its		Note that the LISP+ALT router could also serve as a proxy for its
	TCP-connected ETRs.		TCP-connected ETRs.
	skipping to change at page 20, line 19		skipping to change at page 20, line 18
	In the case in which the ITR is connected to some set of LISP+ALT		In the case in which the ITR is connected to some set of LISP+ALT
	routers without eBGP, the ITR sends Map-Requests to any of its		routers without eBGP, the ITR sends Map-Requests to any of its
	connected LISP+ALT routers.		connected LISP+ALT routers.
	An ITR may also choose to send the first few data packets over the		An ITR may also choose to send the first few data packets over the
	ALT to minimize packet loss and reduce mapping latency. In this		ALT to minimize packet loss and reduce mapping latency. In this
	case, the data packet serves as a mapping probe (Data Probe) and the		case, the data packet serves as a mapping probe (Data Probe) and the
	ETR which receives the data packet (over the ALT) responds with a		ETR which receives the data packet (over the ALT) responds with a
	Map-Reply is sent to the ITR's source-RLOC using the underlying		Map-Reply is sent to the ITR's source-RLOC using the underlying
	topology. Note that the use of Data Probes is discouraged at this		topology. Note that the use of Data Probes is discouraged at this
	time (see Section 4.2).		time (see Section 4.3).
	In general, an ITR will establish connections only to LISP+ALT		In general, an ITR will establish connections only to LISP+ALT
	routers at the "edge" of the ALT (typically two for redundancy) but		routers at the "edge" of the ALT (typically two for redundancy) but
	there may also be situations where an ITR would connect to other		there may also be situations where an ITR would connect to other
	LISP+ALT routers to receive additional, shorter path information		LISP+ALT routers to receive additional, shorter path information
	about a portion of the ALT of interest to it. This can be		about a portion of the ALT of interest to it. This can be
	accomplished by establishing GRE tunnels between the ITR and the set		accomplished by establishing GRE tunnels between the ITR and the set
	of LISP+ALT routers with the additional information. This is a		of LISP+ALT routers with the additional information. This is a
	purely local policy issue between the ITR and the LISP+ALT routers in		purely local policy issue between the ITR and the LISP+ALT routers in
	question.		question.
	skipping to change at page 22, line 45		skipping to change at page 22, line 45
	about a LISP destination sites' TE policy by sending legitimate		about a LISP destination sites' TE policy by sending legitimate
	mapping requests messages and then observing the RLOC mapping		mapping requests messages and then observing the RLOC mapping
	replies? Is this information useful in attacking or subverting		replies? Is this information useful in attacking or subverting
	peer relationships? Note that LISP 1.0 has a similar data-plane		peer relationships? Note that LISP 1.0 has a similar data-plane
	reconnaissance issue.		reconnaissance issue.
	Scaling of LISP+ALT router Resources: Paths through the ALT may be		Scaling of LISP+ALT router Resources: Paths through the ALT may be
	of lesser bandwidth than more "direct" paths; this may make them		of lesser bandwidth than more "direct" paths; this may make them
	more prone to high-volume denial-of-service attacks. For this		more prone to high-volume denial-of-service attacks. For this
	reason, all components of the ALT (ETRs and ALT routers) should be		reason, all components of the ALT (ETRs and ALT routers) should be
	prepared to rate-limit traffic that could be received across the		prepared to rate-limit traffic (ALT datagrams) that could be
	ALT (Map-Requests and Data Probes).		received across the ALT.
	UDP Map-Reply from ETR: Since Map-Replies packets are sent directly		UDP Map-Reply from ETR: Since Map-Replies packets are sent directly
	from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable		from the ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable
	to various types of DoS attacks.		to various types of DoS attacks.
	11.2. Survey of LISP+ALT Security Mechanisms		11.2. Survey of LISP+ALT Security Mechanisms
	Explicit peering: The devices themselves can both prioritize		Explicit peering: The devices themselves can both prioritize
	incoming packets as well as potentially do key checks in hardware		incoming packets as well as potentially do key checks in hardware
	to protect the control plane.		to protect the control plane.
	skipping to change at page 24, line 9		skipping to change at page 24, line 9
	For example, should either sBGP [I-D.murphy-bgp-secr] or soBGP		For example, should either sBGP [I-D.murphy-bgp-secr] or soBGP
	[I-D.white-sobgparchitecture] become widely deployed it expected that		[I-D.white-sobgparchitecture] become widely deployed it expected that
	LISP+ALT could use these mechanisms to provide authentication of EID-		LISP+ALT could use these mechanisms to provide authentication of EID-
	to-RLOC mappings, and EID origination.		to-RLOC mappings, and EID origination.
	12. Acknowledgments		12. Acknowledgments
	Many of the ideas described in this document were developed during		Many of the ideas described in this document were developed during
	detailed discussions with Scott Brim and Darrel Lewis, who made many		detailed discussions with Scott Brim and Darrel Lewis, who made many
	insightful comments on earlier versions of this document.		insightful comments on earlier versions of this document. Additional
			thanks are due to Hannu Flinck and Amit Jain who offered many helpful
			suggestions for the -02 version.
	13. References		13. References
	13.1. Normative References		13.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.
	[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.		[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
	Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,		Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
	skipping to change at page 25, line 42		skipping to change at page 25, line 42
	[I-D.white-sobgparchitecture]		[I-D.white-sobgparchitecture]
	White, R., "Architecture and Deployment Considerations for		White, R., "Architecture and Deployment Considerations for
	Secure Origin BGP (soBGP)",		Secure Origin BGP (soBGP)",
	draft-white-sobgparchitecture-00 (work in progress),		draft-white-sobgparchitecture-00 (work in progress),
	May 2004.		May 2004.
	[Interworking]		[Interworking]
	Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking LISP with IPv4 and ipv6",		"Interworking LISP with IPv4 and ipv6",
	draft-ietf-lisp-interworking-00.txt (work in progress),		draft-ietf-lisp-interworking-01.txt (work in progress),
	May 2009.		January 2010.
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-00.txt (work in progress), May 2009.		draft-ietf-lisp-06.txt (work in progress), January 2010.
			[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
			draft-ietf-lisp-ms-04.txt (work in progress),
			October 2009.
	Authors' Addresses		Authors' Addresses
	Vince Fuller		Vince Fuller
	Cisco		Cisco
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: vaf@cisco.com		Email: vaf@cisco.com
End of changes. 38 change blocks.
	149 lines changed or deleted		173 lines changed or added
This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/