< draft-mrw-homenet-rtg-comparison-00.txt		draft-mrw-homenet-rtg-comparison-01.txt >
	Homenet Working Group M. Wasserman		Homenet Working Group M. Wasserman
	Internet-Draft Painless Security		Internet-Draft Painless Security
	Intended status: Standards Track C. Hopps		Intended status: Informational C. Hopps
	Expires: August 13, 2015 Deutsche Telekom		Expires: August 19, 2015 Deutsche Telekom
	J. Chroboczek		J. Chroboczek
	University of Paris-Diderot (Paris 7)		University of Paris-Diderot (Paris 7)
	February 9, 2015		February 15, 2015
	HOMENET IS-IS and Babel Comparison		HOMENET IS-IS and Babel Comparison
	draft-mrw-homenet-rtg-comparison-00.txt		draft-mrw-homenet-rtg-comparison-01.txt
	Abstract		Abstract
	This document is intended to provide information to members of the		This document is intended to provide information to members of the
	IETF Home Networks Working Group (HOMENET WG), so that we can make an		IETF Home Networks Working Group (HOMENET WG), so that we can make an
	informed decision regarding which routing protocol to use in home		informed decision regarding which routing protocol to use in home
	networks. The routing protocols compared in this document are: The		networks. The routing protocols compared in this document are: The
	Babel Routing Protocol (Babel) and The Intermediate System to		Babel Routing Protocol (Babel) and The Intermediate System to
	Intermediate System Intra-Domain Routing Protocol (IS-IS).		Intermediate System Intra-Domain Routing Protocol (IS-IS).
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 August 13, 2015.		This Internet-Draft will expire on August 19, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocols and Extensions Included in Comparison . . . . . . . 3		2. Protocols and Extensions Included in Comparison . . . . . . . 4
	2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 3		2.1. IS-IS Protocol and Extensions . . . . . . . . . . . . . . 5
	2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 4		2.2. Babel Protocol and Extensions . . . . . . . . . . . . . . 5
	3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 4		3. Routing Algorithms . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 4		3.1. Link State Algorithm . . . . . . . . . . . . . . . . . . 5
	3.2. Distance-Vector Algorithm (Babel) . . . . . . . . . . . . 4		3.2. Loop-Avoiding Distance-Vector Algorithm (Babel) . . . . . 6
	3.3. Algorithm Comparison . . . . . . . . . . . . . . . . . . 4		3.3. Algorithm Comparison . . . . . . . . . . . . . . . . . . 6
	4. Support for Source-Specific Routing . . . . . . . . . . . . . 5		4. Convergence Times . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Source Specific Routing in IS-IS . . . . . . . . . . . . 5		4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Source Specific Routing in Babel . . . . . . . . . . . . 5		4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 5		4.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Support for Link Metrics . . . . . . . . . . . . . . . . . . 6		5. Autoconfiguration . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 6		5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 6		5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Support for Attached Stub Networks . . . . . . . . . . . . . 6		5.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. IS-IS Support for Stub Networks . . . . . . . . . . . . . 6		6. Support for Source-Specific Routing . . . . . . . . . . . . . 8
	6.2. Babel Supportt for Stub Networks . . . . . . . . . . . . 6		6.1. Source-Specific Routing in IS-IS . . . . . . . . . . . . 8
	7. Security Features . . . . . . . . . . . . . . . . . . . . . . 6		6.2. Source-Specific Routing in Babel . . . . . . . . . . . . 8
	7.1. Security Features in IS-IS . . . . . . . . . . . . . . . 6		6.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
	7.2. Security Features in Babel . . . . . . . . . . . . . . . 7		7. Support for Link Metrics . . . . . . . . . . . . . . . . . . 8
	8. Support for Multicast . . . . . . . . . . . . . . . . . . . . 7		7.1. Link Metrics in IS-IS . . . . . . . . . . . . . . . . . . 9
	8.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 7		7.2. Link Metrics in Babel . . . . . . . . . . . . . . . . . . 9
	8.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 7		8. Support for Attached Stub Networks . . . . . . . . . . . . . 9
	9. Implementation Status . . . . . . . . . . . . . . . . . . . . 7		8.1. IS-IS Support for Stub Networks . . . . . . . . . . . . . 9
	10. Code and State Size . . . . . . . . . . . . . . . . . . . . . 7		8.2. Babel Support for Stub Networks . . . . . . . . . . . . . 10
	10.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 7		9. Security Features . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Babel Code and State Size . . . . . . . . . . . . . . . 8		9.1. Security Features in IS-IS . . . . . . . . . . . . . . . 10
	11. Scalablity on IEEE 802.11 Wireless Networks . . . . . . . . . 9		9.2. Security Features in Babel . . . . . . . . . . . . . . . 10
	11.1. IS-IS Scalability on 802.11 . . . . . . . . . . . . . . 9		10. Support for Multicast . . . . . . . . . . . . . . . . . . . . 10
	11.2. Babel Scalability on 802.11 . . . . . . . . . . . . . . 9		10.1. Multicast Routing in IS-IS . . . . . . . . . . . . . . . 10
	12. Standardization Status . . . . . . . . . . . . . . . . . . . 9		10.2. Multicast Routing in Babel . . . . . . . . . . . . . . . 10
	12.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 9		11. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
	12.2. Babel Standardization Status . . . . . . . . . . . . . . 10		12. Code and State Size . . . . . . . . . . . . . . . . . . . . . 11
	13. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 10		12.1. IS-IS Code and State Size . . . . . . . . . . . . . . . 11
	13.1. Critical Success Factors . . . . . . . . . . . . . . . . 10		12.2. Babel Code and State Size . . . . . . . . . . . . . . . 12
	13.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 10		12.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . 12
	13.1.2. Babel Success Factos . . . . . . . . . . . . . . . . 11		13. Performance on IEEE 802.11 Wireless Networks . . . . . . . . 13
	13.2. Willing Implementors . . . . . . . . . . . . . . . . . . 11		13.1. IS-IS Performance on 802.11 . . . . . . . . . . . . . . 13
	13.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 11		13.2. Babel Performance on 802.11 . . . . . . . . . . . . . . 13
	13.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 12		14. Standardization Status . . . . . . . . . . . . . . . . . . . 13
			14.1. IS-IS Standardization . . . . . . . . . . . . . . . . . 13
	13.3. Willing Customers . . . . . . . . . . . . . . . . . . . 12		14.2. Babel Standardization Status . . . . . . . . . . . . . . 13
	13.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 12		15. Evaluation of RFC 5218 Criteria . . . . . . . . . . . . . . . 14
	13.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 12		15.1. Critical Success Factors . . . . . . . . . . . . . . . . 14
	13.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 12		15.1.1. IS-IS Success Factors . . . . . . . . . . . . . . . 14
	13.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 12		15.1.2. Babel Success Factos . . . . . . . . . . . . . . . . 15
	13.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 12		15.2. Willing Implementors . . . . . . . . . . . . . . . . . . 15
	13.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 13		15.2.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 15
	13.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 13		15.2.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16
	13.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 13		15.3. Willing Customers . . . . . . . . . . . . . . . . . . . 16
	13.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 13		15.3.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 16
	13.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 13		15.3.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16
	13.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 13		15.4. Potential Niches . . . . . . . . . . . . . . . . . . . . 16
	13.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 13		15.4.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 16
	13.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 14		15.4.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 16
	13.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 14		15.5. Complexity Removal . . . . . . . . . . . . . . . . . . . 16
	13.8. Success Predictable . . . . . . . . . . . . . . . . . . 14		15.5.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17
	13.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 14		15.5.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 17
	13.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 14		15.6. Killer App . . . . . . . . . . . . . . . . . . . . . . . 17
	14. Informative References . . . . . . . . . . . . . . . . . . . 14		15.6.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		15.6.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 17
			15.7. Extensible . . . . . . . . . . . . . . . . . . . . . . . 17
			15.7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 17
			15.7.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 18
			15.8. Success Predictable . . . . . . . . . . . . . . . . . . 18
			15.8.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . 18
			15.8.2. Babel . . . . . . . . . . . . . . . . . . . . . . . 18
			16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
			17. Informative References . . . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel		This document compares IS-IS (ISO/IEC 10589:2002) [RFC1142] and Babel
	[RFC6126] across several criteria related to their use in home		[RFC6126] according to several criteria related to their use in home
	networks, as defined by the HOMENET WG (HOMENETs).		networks (HOMENETs), as defined by the HOMENET WG.
	Although there are substantial differences between the IS-IS and		Please note that this document does not represent the consenus of any
	Babel routing protocols, both routing protocols work well, and either		group, not even the authors. It is an organized collection of facts
	of them could be used in a home network. There are many		and well-informed opinions provided by experts on Babel and IS-IS
	characteristics of these protocols that make them more or less		that may be useful to the HOMENET WG in choosing a routing protocol.
	suitable for use in HOMENETs, as defined in (reference homenet
	architecture and HNCP documents), and those characteristics are		The HOMENET environment is different from the environment of a
	explored in this document.		professionally administered network. The most obvious difference is
			that a HOMENET is not administered: any protocols used must be robust
			and fully self-configuring, and any tuning knobs that they provide
			will be unused in the vast majority of deployments.
			Another difference is that HOMENETs are usually built out of a
			specific class of cheap device, the "Plastic Home Router". A Plastic
			Home Router's firmware is installed at the factory, and is most
			likely never updated. Additionally, experience shows that home
			routers are often used way beyond their warranty period, and even
			after their manufacturer leaves the router business. This, again,
			argues in favour of simple, robust protocols that are easy to
			implement and can be expected to keep functioning without software
			updates.
			HOMENETs are built and grow organically, and often end up consisting
			of multiple link technologies with widely different performance
			characteristics (twisted-pair Ethernet, IEEE 802.11 and its multiple
			variants, Powerline Ethernet, etc.). It is desirable for a HOMENET
			routing protocol to be able to dynamically optimise paths according
			to the link characteristics.
			Contrary to popular perception, the Plastic Home Router is usually
			equipped with a reasonably fast CPU and reasonable amounts of flash
			and RAM; at the time of writing, a (non-superscalar) 700MHz MIPS CPU
			with 16MB of flash and 64MB of RAM is typical. However, we expect
			smaller devices to participate in the HOMENET protocols, at least as
			stub routers. The ability to scale down the HOMENET protocols is
			therefore likely to encourage their wider adoption.
			[Isn't it also the case that the HOMENET routing protocol will be
			implemented on lower-end embedded devices, such as nodes in a low-
			power wireless network? What is considered to be a reasonable low-
			end system requirement for a HOMENET router? -- mrw]
			Experts appear to disagree on the expected size of a HOMENET; we have
			heard estimates ranging from just one router up to 250 routers. In
			any case, while scaling beyond a few thousand nodes is not likely to
			be relevant to HOMENET in the foreseeable future, the HOMENET
			protocols, if successful, will be repurposed to larger networks,
			whether we like it or not, and using a protocol that scales well from
			the outset may be desirable.
	2. Protocols and Extensions Included in Comparison		2. Protocols and Extensions Included in Comparison
	Both IS-IS and Babel are living protocols that are updated and		Both IS-IS and Babel are living protocols that are updated and
	extended over time. This section lists the extensions that were		extended over time. This section lists the extensions that were
	considered in this comparison. Additional protocol extensions could		considered in this comparison. Additional protocol extensions could
	affect some of the information included in this document.		affect some of the information included in this document.
	2.1. IS-IS Protocol and Extensions		2.1. IS-IS Protocol and Extensions
	In addition to the base IS-IS protocol specification (ISO/IEC		In addition to the base IS-IS protocol specification (ISO/IEC
	10589:2002), this comparison considers the following IS-IS		10589:2002), this comparison considers the following IS-IS
	extensions:		extensions:
			o ISIS Auto-Configuration [ISIS-AUTOCONF];
			o Source-Specific routing in IS-IS [ISIS-SS].
	2.2. Babel Protocol and Extensions		2.2. Babel Protocol and Extensions
	In addition to the base Babel Protocol specification (RFC 6126), this		In addition to the base Babel Protocol specification (RFC 6126), this
	comparison considers the following Babel extensions:		comparison considers the following Babel extensions:
	Source-Specific Routing [BABEL-SS], described in more detail in		o Extension Mechanism for the Babel Routing Protocol [BABEL-EXT];
	[SS-ROUTING].
	Extension Mechanism for the Babel Routing Protocol[BABEL-EXT]		o Source-Specific Routing [BABEL-SS], described in more detail in
			[SS-ROUTING].
	3. Routing Algorithms		3. Routing Algorithms
	IS-IS is a Link State routing protocol, and Babel is a Loop-avoiding		IS-IS is a Link State routing protocol, and Babel is a Loop-Avoiding
	Distance Vector routing protocol. There are some differences between		Distance Vector routing protocol. There are some differences between
	these algorithms, particularly in terms of scalability, how much		these algorithms, particularly in terms of scalability, how much
	information is exchanged when the routing topology changes, and how		information is exchanged when the routing topology changes, and how
	far topology changes are propagated. [chopps: Perhaps we should see		far topology changes are propagated.
	if we can find an external reference for comparing DVRP to link-state
	RPs for this section].
	3.1. Link State Algorithm		3.1. Link State Algorithm
	Link state algorithms distribute information for each node to compute		Link state algorithms distribute information for each node to all
	a tree representing the entire network.		other nodes in the network using a flooding algorithm. This database
			of information is then used by each node to compute the best path to
			the other nodes in the network.
	Link state algorithms scale well in both very large and very dense		One benefit of this algorithm is that each node contains the full
	networks.		knowledge of the topology of the network. This information can be
			used by other applications outside the routing protocol itself.
	3.2. Distance-Vector Algorithm (Babel)		Additionally the flooding algorithm has been found as an efficient
			method for other applications to distribute node-specific application
			data, although some care must be taken with this use so as not to
			disrupt the fundamental routing function.
			3.2. Loop-Avoiding Distance-Vector Algorithm (Babel)
	Distance-vector algorithms distribute information about the path		Distance-vector algorithms distribute information about the path
	length to reach each destination through a given neighbor. Packets		length to reach each destination through a given neighbor. Packets
	are forwarded to the neighbor who is advertising the shortest path to		are forwarded to the neighbor who is advertising the best path
	reach the destination.		towards the destination.
			Babel, like EIGRP, DSDV, and to a certain extent BGP, uses a loop-
			avoiding distance-vector algorithm: it avoids creating a loop even
			during reconvergence (there is no "counting to infinity", and even
			short-lived "microloops" are avoided in most cases).
	3.3. Algorithm Comparison		3.3. Algorithm Comparison
	Loop-avoiding Distance Vector scales beautifully to very large		Loop-Avoiding Distance Vector scales to very large networks -- the
	networks -- the amount of state is linear in the number of nodes, and		amount of state is linear in the number of nodes, and, due to the
	does not need to be propagated in a timely manner. It scales badly		absence of pathologies during reconvergence, does not need to be
	in extremely dense deployments, where a single node has thousands of		propagated in a timely manner. It scales badly in extremely dense
	direct neighbours; such deployments are unlikely, and clearly outside		deployments, where a single node has thousands of direct neighbours;
	the scope of Homenet.		such deployments are unlikely, and clearly outside the scope of
			HOMENET.
	Naive link state has somewhat worse scaling properties, since it has		Link state algorithms scales to very large, very dense networks.
	state that is proportional to the number of edges in the network
	graph, and requires strict state synchronisation between nodes.
	Real-world link-state protocols work around that issue by splitting
	the network into multiple "areas", and performing distance-vector
	routing between areas. It is unclear whether this workaround is
	suitable for Homenet.
	4. Support for Source-Specific Routing		IS-IS distributes link and prefix information for each node in a
			single Logical LSP (possibly fragmented). It uses these LSPs to
			compute a tree representing the entire network. There is no
			duplication of state based on the number of adjacencies or unique
			paths to a given prefix.
			4. Convergence Times
			Convergence time is defined as the amount of time after a link
			failure is detected during which the network is not fully
			operational. It does not include the time necessary to detect a link
			failure.
			4.1. IS-IS
			Given fast flooding of any change in the network, IS-IS has been
			shown to acheive sub 200ms end-to-end convergence even in very large
			provider networks (single area 900+ nodes). Basically the time for
			convergence is the time to propagate a new LSP from one end of the
			network to the other plus the SPF (tree computation interval) and FIB
			loading time. The flooding is done without delay and prior to
			running the SPF (tree-calculation) algorithm. Thus is roughly
			proportional to propagation delay across the diameter of the network.
			The tree calculation is sub 20ms on modern CPUs. FIB load time
			depends on the FIB hardware and design and not the routing protocol
			choice.
			We easily should expect sub-second convergence for any change in
			reachability (addition or subtraction) in any conceivable homenet
			deployment.
			4.2. Babel
			Since Babel maintains a redundant routing table, it is most often
			able to reconverge almost instantaneously after a link failure (this
			is similar to e.g. EIGRP). In the case where no feasible routes are
			available, Babel reconverges in 20ms per hop to the source.
			4.3. Discussion
			Both protocols enjoy fast convergence. However, unless there is a
			high level of integration between the routing protocol and the link
			layer, the time needed to reconverge is dwarfed by the amount of time
			needed to detect a link failure, which is the hold time in IS-IS (30s
			by default), and two hello intervals on Babel wired links (8s by
			default). (Babel performs link quality estimation on wireless links,
			so the delay is somewhat more difficult to quantify there.)
			5. Autoconfiguration
			Home networks are not administered, so a routing protocol needs to be
			entirely self-configuring in order to be suitable for HOMENETs.
			5.1. IS-IS
			The only required configuration for IS-IS is a unique area/system
			identifier. The HOMENET implementation of IS-IS uses an
			autoconfiguration extension defined in an Internet Draft
			[ISIS-AUTOCONF], to set this value.
			5.2. Babel
			Babel is a fully self-configuring protocol -- the standard
			implementation of Babel only requires a list of interfaces in order
			to start routing.
			5.3. Discussion
			6. Support for Source-Specific Routing
	Source-Specific Routing is a hard requirement for HOMENETs, as it		Source-Specific Routing is a hard requirement for HOMENETs, as it
	will allow traffic to be routed to the correct outbound network based		will allow traffic to be routed to the correct outbound network based
	on host source address selection. Routing packets to the wrong		on host source address selection. Routing packets to the wrong
	outbound network could result in packets being dropped due to ISP		outbound network could result in packets being dropped due to ISP
	ingress filtering rules.		ingress filtering rules.
	Both Babel and IS-IS have extensions for source-specific routing.		Both Babel and IS-IS have extensions for source-specific routing.
	4.1. Source Specific Routing in IS-IS		6.1. Source-Specific Routing in IS-IS
	[XXX: chopps]
	Reports indicate that IS-IS has critical issues (routing loops) in a		IS-IS support for source specific routing is implemented with the
	mixed environment where some routers support Source-Specific Routing,		addition of a sub-TLV to a reachability (prefix) TLV. The
	and some routers do not. However, this is not likely to be a problem		implementation assumes that all IS-IS routers have support for the
	for Homenet, as we will require Source-Specific Routing on all		sub-TLV. This assumption is safe to make due to the requirement that
	routers.		all homenet IS-IS routers also use a homenet specific area ID and
			cleartext password. Mixing in IS-IS routers without support for
			source specific routing is not supported as it may cause routing
			loops.
	4.2. Source Specific Routing in Babel		6.2. Source-Specific Routing in Babel
	The Source-specific extension to the Babel routing protocol		The Source-specific extension to the Babel routing protocol
	[BABEL-SS] has been implemented for over a year, has been made widely		[BABEL-SS] has been implemented for over a year, has been made widely
	available and has seen a fair amount deployment as part of OpenWRT		available and has seen a fair amount deployment as part of OpenWRT
	and CeroWRT. The implementation is currently being merged into the		and CeroWRT. The source-specific code is currently in the process of
	standard Babel implementation, and is scheduled to be included in		being merged into the standard Babel implementation, and is scheduled
	version 1.6 (planned for March 2015).		to be included in version 1.6 (planned for March 2015).
	4.3. Discussion
	Babel's source-specific extensions were carefully designed so that		Babel's source-specific extensions were carefully designed so that
	source-specific and ordinary (non-specific) routers can coexist in a		source-specific and ordinary (non-specific) routers can coexist in a
	single routing domain, without routing pathologies such as routing		single routing domain, without causing routing loops. However,
	loops. Interoperability between plain Babel and Source-Specific		unless there is a connected backbone of source-specific routers, any
			non-specific routers present in the HOMENET may experience
			blackholes. Interoperability between plain Babel and Source-Specific
	Babel is described in detail in Section VI.A of [SS-ROUTING].		Babel is described in detail in Section VI.A of [SS-ROUTING].
	Reports indicate that source-specific IS-IS has critical issues		6.3. Discussion
	(routing loops) in a mixed environment where some routers support
	Source-Specific Routing, and some routers do not. However, this is
	not likely to be a problem for Homenet, as we will require Source-
	Specific Routing on all routers.
	[How will we enforce that? -- jch]		7. Support for Link Metrics
	5. Support for Link Metrics		Typical HOMENETs are built out of multiple link technologies with
			very different performance characteristics -- Gigabit Ethernet can
			easily have three orders of magnitude higher throughput than a
			marginal wireless link. Both IS-IS and Babel quantify the
			desirability of a link by assigning a metric to it.
	5.1. Link Metrics in IS-IS		7.1. Link Metrics in IS-IS
	IS-IS supports 2 types of link metrics a legacy link metric (which		The HOMENET implementation of IS-IS uses the wide-metric (24-bit)
	should probably not be considered for HOMENET use) and a modern		link metric. Additionally IS-IS includes multi-topology support
	extended (24-bit) link metric. Additionally multi-topology support		allowing for a variable number of metrics per link, as well as per-
	allows for a variable number of metrics per link.		link and per-prefix tags allowing for coloring of links and
			reachability, and finally per-link and per-prefix sub-tlv's allowing
			for any future additional extensions.
	5.2. Link Metrics in Babel		7.2. Link Metrics in Babel
	In Babel, metrics are unsigned 16-bit integers, which means that		Since Babel was originally designed for heterogeneous networks, it is
	metrics are arbitrary integers between 0 and 65534 (the value 65535		able to dynamically assign metrics to links depending on their lower-
	is reserved to mean "infinity"); this has been found to be sufficient		layer characteristics. In practice, Babel assigns lower (better)
	even in the chaotic environment of wireless mesh networks. If		metrics to wired links than to wireless ones, dynamically measures
	needed, the Babel extension mechanism can be used to extend the		loss rates in order to favour lossless wireless links, favours routes
	metric space in arbitrary ways (not just integers), which has already		with non-interfering radio frequencies, and avoids high-latency
	been done by the radio interference extensions to Babel [BABEL-Z].		tunnels.
	6. Support for Attached Stub Networks		Obviously, such a wealth of information can lead to contradictory
			data in edge cases; however, Babel's loop-avoidance mechanisms ensure
			that the network remains in a consistent state in all cases, and a
			hysteresis mechanism ensures that, should a feedback loop occur, the
			frequency of oscillations remains bounded [DELAY-BASED].
	[I don't understand why this issue is important for Homenet. -- jch]		8. Support for Attached Stub Networks
	6.1. IS-IS Support for Stub Networks		A stub network is one that is attached to a HOMENET, possibly through
			multiple HOMENET routers, but must not be used for transit. For
			example, a stub network could be a sensor network which would
			collapse under the HOMENET traffic should it ever be used for
			transit.
	A stub network in IS-IS is supported by the advertisement of		In the following example, if the dotted link between C and D is a
	reachability to a prefix by a router in its LSP. [How does this		stub network, then it must not be used for transit even if the link
	prevent the network from being used for transit? -- jch]		between A and B fails:
	6.2. Babel Supportt for Stub Networks		---- A ----- B -----
			| |
			| |
			C ..... D
			8.1. IS-IS Support for Stub Networks
			In IS-IS reachability (prefixes) and topology (links/adjacencies) are
			separate things. IS-IS supports stub-networks as defined above
			simply by advertising the prefix associated with a link, but not the
			link itself. This is sometimes referred to as a "passive link".
			8.2. Babel Support for Stub Networks
	Babel supports flexible filtering of routes, and a stub network can		Babel supports flexible filtering of routes, and a stub network can
	be designated by simply setting up the necessary filtering rules.		be designated by simply setting up the necessary filtering rules.
	For resource-limited deployments, a minimalistic, stub-only		For resource-limited deployments, a minimalistic, stub-only
	implementation of Babel is available.		implementation of Babel is available.
	7. Security Features		9. Security Features
	7.1. Security Features in IS-IS		[I think this section is badly written. We should just state whether
			each protocol supports auth or encryption, and whether it supports
			symmetric or something more exciting. -- jch]
			9.1. Security Features in IS-IS
	IS-IS offers multiple levels of security from none, to simple clear-		IS-IS offers multiple levels of security from none, to simple clear-
	text (password) authentication, to fully generic cryptographic		text (password) authentication, to fully generic cryptographic
	authentication using any number of hashing algorithms (e.g., HMAC-		authentication using any number of hashing algorithms (e.g., HMAC-
	MD5, HMAC-SHA1, ... HMAC-SHA512) based on security associations		MD5, HMAC-SHA1, ... HMAC-SHA512). Currently, the HOMENET
	(link, area and domain scoped).		implementation of IS-IS uses the cleartext password set to a
			predefined value for auto-configuration purposes.
	[What does that mean? Just support for HMAC-based authentication, or
	am I missing something? -- jch]
	7.2. Security Features in Babel		9.2. Security Features in Babel
	Babel supports an extensible HMAC-based cryptographic authentication		Babel supports symmetric key authentication using an extensible HMAC-
	mechanism [RFC7298].		based cryptographic authentication mechanism [RFC7298].
	8. Support for Multicast		10. Support for Multicast
	Although the HOMENET WG has not yet determined how/if to support		Although the HOMENET WG has not yet determined whether to support
	multicast in HOMENET Networks, it might be desirable to pick a		multicast in HOMENET Networks, it might be desirable to pick a
	routing protocol that supports multicast, so that it will be easier		routing protocol that supports multicast, so that it will be easier
	to add multicast support in the future.		to add multicast support in the future.
	8.1. Multicast Routing in IS-IS		10.1. Multicast Routing in IS-IS
	The IS-IS protocol supports multicast routing. However, none of the		The IS-IS protocol supports multicast routing. However, none of the
	available implementations include support for multicast. [XXX:		available implementations include support for multicast.
	chopps: what do we mean by supporting multicast routing?]
	[Does the Homenet implementation support multicast? Does any open
	source implementation support multicast? -- jch]
	8.2. Multicast Routing in Babel		10.2. Multicast Routing in Babel
	There is no support for multicast routing in Babel.		There is no support for multicast routing in Babel.
	9. Implementation Status		11. Implementation Status
	There are Homenet implementations of both IS-IS and Babel.		There are HOMENET implementations of both IS-IS and Babel.
	Only the Homenet implementation of IS-IS supports source-specific		The HOMENET implementation of IS-IS is the only IS-IS implementation
	routing, which is a hard requirement for Homenet. If source-specific		that supports source-specific routing, which is a hard requirement
	routing is not required, there are several independent, interoperable		for HOMENET. If source-specific routing is not required, there are
	implementations of IS-IS (all major router vendors implement IS-IS),		several independent, interoperable proprietary implementations of IS-
	including some open source implementations.		IS (all major router vendors implement IS-IS). We are not aware of
			any production-quality open-source implementation of IS-IS other than
			the HOMENET one.
	There are multiple open source implementations of Babel, two of which		There are multiple open source implementations of Babel, two of which
	support source-specific routing. However, they were both originally		support source-specific routing. All implementations (except the
	derived from the same codebase.		stub-only version) were originally derived from the same codebase.
	10. Code and State Size		12. Code and State Size
	10.1. IS-IS Code and State Size		12.1. IS-IS Code and State Size
	The Homenet implementation of IS-IS consists of 7000 lines of Erlang		The HOMENET implementation of IS-IS consists of 7000 lines of Erlang
	code and has an installed size of over 11MB. Its initial memory		code and has an installed size of over 11MB. Its initial memory
	usage (as reported by the operating system) is 22MB, and its working		usage (as reported by the operating system) is 22MB, and its working
	set increases by XXX bytes for each new edge in the network graph.		set increases by XXX bytes for each new edge in the network graph.
	To put these numbers into perspective, in a network with XXX nodes		To put these numbers into perspective, in a network with XXX nodes
	each of which has XXX neighbours, the Homenet implementation of IS-IS		each of which has XXX neighbours, the HOMENET implementation of IS-IS
	requires XXX bytes for its data structures.		requires XXX bytes for its data structures.
	[I suggest removing the rest of this section, since it consists of
	unsubstantiated, vague claims depending on a not-yet-implemented
	version of a not-yet-specified subset of a large protocol. -- jch]
	The code size of IS-IS depends greatly on what aspects of the		The code size of IS-IS depends greatly on what aspects of the
	protocol have been implemented. IS-IS supports multiple address		protocol have been implemented. IS-IS supports multiple address
	families as well as completely different protocol stacks (OSI and		families as well as completely different protocol stacks (OSI and
	IP), multiple area hierachical operation with automatic virtual link		IP), multiple area hierachical operation with automatic virtual link
	support for repairing area partitions, and multiple link types.		support for repairing area partitions, and multiple link types.
	Additionally many other protocol features have been added over time		Additionally many other protocol features have been added over time
	to augment the protocol or replace previous behavior. The protocol		to augment the protocol or replace previous behavior. The protocol
	lends itself well to not only extension, but pairing down of		lends itself well to not only extension, but pairing down of
	features.		features.
	For HOMENET we could use a very simple level-2 only implementation		For HOMENET we need a level-1 only implementation supporting a common
	supporting a common topology supporting IPv4 and IPv6 over broadcast		topology for IPv4 and IPv6 over broadcast (i.e., ethernet) link
	(i.e., ethernet) link types. Additionally, we would need only		types. Additionally, we only require support of the latest extended
	support the latest extended metric TLV (i.e., not implement legacy		metric TLVs (i.e., not implement legacy metric support).
	metric support). Implemented as such the code size should be very
	manageable.
	The state actually required by IS-IS is not large, and primarily		The operational state required by IS-IS is proportional to the number
	correlates to the number of routers in the network (for LSP storage).		of routers, links, and prefixes in the network. Each router in the
	The protocol stores it's own link and adjacency data which is		network generates and advertises a Link State Protocol Data Unit
	expected to be negligible. Additionally, the protocol stores		(LSP) that describes it's attached links and prefixes. A copy of
	received and generated LSPs, and typically an SPF tree with prefix		each of these LSPs is stored by each router in the network. IS-IS
	information attached. This state correlates directly to the number		uses these LSPs to construct a shortest-path-first (SPF) tree with
	of routers and prefixes in the network. Each router in the network		attached prefix information from which routes to the prefixes are
	generates, a single LSP (possibly fragmented into segments) with		created.
	prefix information, a single copy of these LSPs is stored by each
	router in the network regardless of the number of links, adjacencies
	or the distance (or number of hops) from the storing router to the
	advertising router.
	10.2. Babel Code and State Size		Concrete numbers lacking.
			12.2. Babel Code and State Size
	The source-specific implementation of Babel, which implements many		The source-specific implementation of Babel, which implements many
	non-Homenet extensions to the protocol, consists of roughly 10000		non-HOMENET extensions to the protocol, consists of roughly 10000
	lines of C and has an installed size of less than 130kB on AMD-64.		lines of C and has an installed size of less than 130kB on AMD-64.
	Its initial memory usage (as reported by the operating system) is		Its initial memory usage (as reported by the operating system) is
	300kB.		300kB.
	The amount of state stored by a Babel router is at worst one routing		The amount of state stored by a Babel router is at worst one routing
	table entry for each destination through each neighbour. In the		table entry for each destination through each neighbour. In the
	source-specific implementation, one routing entry occupies roughly		source-specific implementation, one routing entry occupies roughly
	100 bytes of memory. To put these figures into perspective, in a		100 bytes of memory. To put these figures into perspective, in a
	network with 1000 nodes, a Babel router with 10 neighbours needs		network with 1000 nodes, a Babel router with 10 neighbours needs
	roughly a megabyte of memory to store its routing table (not counting		roughly a megabyte of memory to store its routing table (not counting
	malloc overhead).		malloc overhead).
	The stub-only implementation of Babel consists of 900 lines of C and		The stub-only implementation of Babel consists of 900 lines of C and
	compiles to 12kB (dynamically linked). Its memory usage (as reported		compiles to 12kB (dynamically linked). Its memory usage (as reported
	by the operating system) is 200kB, and remains constant (it doesn't		by the operating system) is 200kB, and remains constant (it doesn't
	perform any dynamic memory allocation).		perform any dynamic memory allocation).
	11. Scalablity on IEEE 802.11 Wireless Networks		12.3. Comparison
	[I suggest renaming this section to "Performance on 802.11 wireless		Table 1 summarises the sizes of the available HOMENET routing
	networks. Are we trying to get homenets to scale to millions of		protocol implementations. (Data courtesy of Steven Barth and Markus
	nodes? -- jch]		Stenberg.)
	11.1. IS-IS Scalability on 802.11		+----------------+--------------------+----------------+------------+
			| | babeld (source- | sbabeld (stub- | AutoISIS |
			| | specific) | only) | |
			+----------------+--------------------+----------------+------------+
			| Version | 2598774 | cc7d681 | 0.8.0 |
			| Date | 2014-09-08 | 2014-11-21 | 2014-08-26 |
			| License | MIT | MIT | Apache 2.0 |
			| Lines of Code | 10.000 (C) | 1.000 (C) | 7.000 |
			| | | | (Erlang) |
			| Installed size | 129kB | 13kB | 11,385kB |
			| (AMD64) | | | |
			| Total | 129kB | 13kB | 14,155kB |
			| installed size | | | |
			| Baseline RSS | ~300kB | ~200kB | ~22,000kB |
			+----------------+--------------------+----------------+------------+
			Table 1: Comparison of HOMENET implementation size
			In this table, "Installed size" is the size reported by the package
			manager for the routing daemon's package(s) (including the 1.6MB of
			the "Beam" Erlang VM in the case of IS-IS), while "Total installed
			size" is the sum of the size of the deamon's packages and all its
			dependencies, excluding the C library.
			13. Performance on IEEE 802.11 Wireless Networks
			13.1. IS-IS Performance on 802.11
	IS-IS is in active use in in the Internet in large non-hierachical		IS-IS is in active use in in the Internet in large non-hierachical
	(i.e., level-2 or single area level-1) deployments with hundreds of		(i.e., level-2 or single area level-1) deployments with hundreds of
	nodes. The protocol has proven to be very scalable.		nodes. The protocol has proven to be very scalable.
	Do we have any information about the scaling of IS-IS on 802.11		[Do we have any information about the performance of IS-IS on 802.11
	networks, in particular?		networks, in particular? -- mrw]
	11.2. Babel Scalability on 802.11		13.2. Babel Performance on 802.11
	Babel was carefully optimised for 802.11 networks. In particular, it		Babel has been carefully optimised for 802.11 networks. In
	has (optional) provisions for link quality estimation and (optional)		particular, it performs link quality estimations of wireless links in
	provisions for radio-interference sensitive routing.		a manner that works well with the 802.11 MAC. In addition, Babel has
			provisions for estimating radio interference [BABEL-Z], which is
			essential for providing decent throughput on multi-hop radio routes.
	Babel was designed to work well on pure mesh networks (networks where		Babel was designed to work well on pure mesh networks (networks where
	a packet might exit through the same interface as the one it came		a packet might exit through the same interface as the one it came
	from), but this is probably out of scope for Homenet.		from), but this is probably out of scope for HOMENET.
	12. Standardization Status		14. Standardization Status
	12.1. IS-IS Standardization		14.1. IS-IS Standardization
	IS-IS is an ISO Standard documented in ISO/IEC 10589:2002. There is		IS-IS is an ISO Standard documented in ISO/IEC 10589:2002. There is
	an active IETF IS-IS Working Group (ISIS) that maintains and extends		an active IETF IS-IS Working Group (ISIS) that maintains and extends
	the IS-IS protocol, and the IS-IS protocol has been extended in		the IS-IS protocol, and the IS-IS protocol has been extended in
	several ISIS Working Group documents.		several ISIS Working Group documents.
	The source-specific extension to IS-IS is standardized as XXX. [Will		The autoconfiguration and source-specific extensions to IS-IS, which
	it require a downref? -- jch]		are both hard requirements for HOMENET, are documented in (non-WG)
			Internet Drafts [ISIS-AUTOCONF] [ISIS-SS].
	12.2. Babel Standardization Status		14.2. Babel Standardization Status
	Babel is documented in an Experimental RFC (RFC 6126) published in		Babel is documented in an Experimental RFC (RFC 6126) published in
	2011, and it has been updated in several individual-submission RFCs		2011, and it has been updated in several individual-submission RFCs
	and Internet Drafts.		and Internet Drafts. An Internet Draft establishing an IANA registry
			of Babel extensions has been submitted for publication as an RFC
			[BABEL-EXT].
	The use of Babel in a Standards Track HOMENET RFC would require a		The use of Babel in a Standards Track HOMENET RFC would require a
	"downref" to non-Standards Track documents. It would also be		"downref" to non-Standards Track documents. It would also be
	necessary to publish the extensions that are needed for the HOMENET		necessary to finish publishing the extensions that are needed for the
	use case as RFCs.		HOMENET use case as RFCs.
	13. Evaluation of RFC 5218 Criteria		15. Evaluation of RFC 5218 Criteria
	13.1. Critical Success Factors		15.1. Critical Success Factors
	Does the protocol exhibit one or more of the critical initial success		Does the protocol exhibit one or more of the critical initial success
	factors as defined in RFC 5218?		factors as defined in RFC 5218?
	13.1.1. IS-IS Success Factors		15.1.1. IS-IS Success Factors
	IS-IS exhibits the following critical initial success factors:		IS-IS exhibits the following critical initial success factors:
	Positive Net Value:		Positive Net Value:
	Hardware cost: None.		Hardware cost: None.
	Operational interface: Existing and extensive.		Operational interface: Existing and extensive.
	Retraining: None.		Retraining: None.
	Business dependencies: None.		Business dependencies: None.
	Incremental Deployment: Yes.		Incremental Deployment: Yes.
	Open Code Availability: Yes. Multiple implementations.		Open Code Availability: Yes. One implementation of the HOMENET
			extensions, multiple proprietary implementations of the base
			protocol.
	Freedom from Usage Restrictions: Yes.		Freedom from Usage Restrictions: Yes.
	Open Specification Availability: Yes.		Open Specification Availability: Yes.
	Open Maintenance Processes: Yes.		Open Maintenance Processes: Yes.
	Good Technical Design: Proven with extensive deployment and		Good Technical Design: Proven with extensive deployment and
	experience.		experience with the base protocol, little deployment of the
			HOMENET extensions.
	Extensible: Yes.		Extensible: Yes.
	No Hard Scalability bound: Yes.		No Hard Scalability bound: Yes.
	Threats Sufficiently Mitigated: Yes.		Threats Sufficiently Mitigated: Yes.
	13.1.2. Babel Success Factos		15.1.2. Babel Success Factos
	Babel exhibits the following critical initial success factors:		Babel exhibits the following critical initial success factors:
	Positive Net Value:		Positive Net Value:
	Hardware cost: None.		Hardware cost: None.
	Operational interface: ??.		Operational interface: tcpdump and wireshark support, dedicated
			monitoring software.
	Retraining: None.		Retraining: None.
	Business dependencies: None.		Business dependencies: None.
	Incremental Deployment: Yes.		Incremental Deployment: Yes.
	Open Code Availability: Yes. One implementation.		Open Code Availability: Yes. Multiple implementations derived
			from a common source.
	Freedom from Usage Restrictions: Yes.		Freedom from Usage Restrictions: Yes.
	Open Specification Availability: Yes.		Open Specification Availability: Yes.
	Open Maintenance Processes: No.		Open Maintenance Processes: IANA registry in the process of being
			created.
	Good Technical Design: Yes, but less widely deployed/proven than		Good Technical Design: Yes.
	IS-IS.
	Extensible: Yes.		Extensible: Yes.
	No Hard Scalability bound: No.		No Hard Scalability bound: Yes.
	Threats Sufficiently Mitigated: ??.		Threats Sufficiently Mitigated: probably.
	13.2. Willing Implementors		15.2. Willing Implementors
	Are there implementers who are ready to implement the technology in		Are there implementers who are ready to implement the technology in
	ways that are likely to be deployed?		ways that are likely to be deployed?
	13.2.1. IS-IS		15.2.1. IS-IS
	There is only one implementation of source-specific routing for IS-		There is only one implementation of autoconfiguration and source-
	IS. [Has it ever been extended by people who are not the authors?		specific routing for IS-IS. There are some other open source
	If so, who? -- jch]		implementations of the base protocol, but they are incomplete (as of
			February 2015).
	[I suggest the rest of this section should be removed. -- jch]		As all major routing vendors have (proprietary) IS-IS
	As all major routing vendors have IS-IS implementations as well as		implementations, the barrier for implmeneting IS-IS for HOMENET use
	the existence of for sale and open source implementations, the		is probably manageable, assuming that the willingness to implement
	barrier for implmeneting IS-IS for homenet use is quite low. Given		modifications needed for HOMENET use is present.
	this we can assume that willingness to implement modifications (if
	any) for homenet use is present and strong.
	13.2.2. Babel		15.2.2. Babel
	The Babel implementation is open source software (MIT licensed, non-		The Babel implementation is open source software (MIT licensed), and
	copyleft), and the codebase has proven of sufficiently high quality		the codebase has proven of sufficiently high quality to be easily
	to be easily extended by people who were not in direct contact with		extended by people who were not in direct contact with the author
	the author [RFC7298].		[RFC7298].
	13.3. Willing Customers		15.3. Willing Customers
	Are there customers (especially high-profile customers) who are ready		Are there customers (especially high-profile customers) who are ready
	to deploy the technology?		to deploy the technology?
	13.3.1. IS-IS		15.3.1. IS-IS
	Yes. IS-IS is already widely deployed in operational networks.		Yes. IS-IS is already widely deployed in operational networks.
	[I suggest more details should be given. Recall that we're speaking		15.3.2. Babel
	of source-specific IS-IS here. -- jch]
	13.3.2. Babel
	Babel is currently deployed as part of the OpenWRT and CeroWRT		Source-Specific Babel is currently deployed as part of the OpenWRT
	operating systems. Additionally, the current version is used as a		and CeroWRT operating systems. Additionally, the current version is
	testbed for the Homenet configuration protocol.		used as a testbed for the HOMENET configuration protocol.
	13.4. Potential Niches		15.4. Potential Niches
	Are there potential niches where the technology is compelling?		Are there potential niches where the technology is compelling?
	13.4.1. IS-IS		15.4.1. IS-IS
	13.4.2. Babel		15.4.2. Babel
	Babel is a simple and flexible routing protocol. Like most distance-		Babel is a simple and flexible routing protocol. Like most distance-
	vector protocols, it requires little to no configuration in most		vector protocols, it requires little to no configuration in most
	topologies, and has proved popular in scenarios where competent		topologies, and has proved popular in scenarios where competent
	network administration was not available. In addition, it has been		network administration was not available. In addition, it has been
	shown to be particularly useful in scenarios where non-standard		shown to be particularly useful in scenarios where non-standard
	metrics were needed, notably wireless mesh networks and overlay		dynamically computed metrics are beneficial, notably wireless mesh
	networks.		networks and overlay networks.
	13.5. Complexity Removal		15.5. Complexity Removal
	If so, can complexity be removed to reduce cost?		If so, can complexity be removed to reduce cost?
	13.5.1. IS-IS		15.5.1. IS-IS
	As mentioned previously IS-IS can be significantly and easily paired
	down to fit the more limited scope of homenet use.
	[Any actual implementations the reader can examine? -- jch]		As mentioned previously IS-IS can be significantly and easily pared
			down to fit the more limited scope of homenet use. However, no such
			pared down implementation exists, and the subset of the protocol that
			needs to be implemented has never been formally defined.
	13.5.2. Babel		15.5.2. Babel
	Babel is a fairly simple protocol -- RFC 6126 is just 40 pages long		Babel is a fairly simple protocol -- RFC 6126 is just 40 pages long
	(not counting informative appendices), and it has been successfully		(not counting informative appendices), and it has been successfully
	explained to fourth year university students in less than two hours.		explained to fourth year university students in less than two hours.
	The stub-only implementation of Babel consists of 900 lines of C		The stub-only implementation of Babel consists of 900 lines of C
	code, and has deliberately been kept as simple as possible. We		code, and has deliberately been kept as simple as possible. We
	expect a competent engineer to get up to speed with it within hours.		expect a competent engineer to get up to speed with it within hours.
	13.6. Killer App		15.6. Killer App
	Is there a potential killer app? Or can the technology work		Is there a potential killer app? Or can the technology work
	underneath existing unmodified applications?		underneath existing unmodified applications?
	13.6.1. IS-IS		15.6.1. IS-IS
	As IS-IS already qualifies as successful (bordering on wildly) a		As IS-IS already qualifies as successful (bordering on wildly) a
	killer app is not particularly relevant.		killer app is not particularly relevant.
	13.6.2. Babel		15.6.2. Babel
	Since Babel requires virtually no configuration, it is particularly		Since Babel requires virtually no configuration, it is particularly
	suitable to scenarios where a dedicated network administrator is not		suitable to scenarios where a dedicated network administrator is not
	available. Additionally, its support for link quality sensing and		available. Additionally, its support for dynamically computed non-
	non-standard metrics makes it particularly appealing in highly		standard metrics makes it particularly appealing in highly
	heterogeneous networks, (networks built on multiple link-layer		heterogeneous networks, (networks built on multiple link-layer
	technologies with widely varying performance characteristics).		technologies with widely varying performance characteristics).
	13.7. Extensible		15.7. Extensible
	Is the protocol sufficiently extensible to allow potential		Is the protocol sufficiently extensible to allow potential
	deficiencies to be addressed in the future?		deficiencies to be addressed in the future?
	13.7.1. IS-IS		15.7.1. IS-IS
	IS-IS has been shown to be incredibly extensible, originally designed		IS-IS has been shown to be incredibly extensible, originally designed
	for a completely different protocol stack (OSI) it was easily adapted		for a completely different protocol stack (OSI) it was easily adapted
	for IP use, then to multiple address families (IPv4, IPv6) and multi-		for IP use, then to multiple address families (IPv4, IPv6) and multi-
	topology. Indeed one of the major drivers of IS-IS's success is its		topology. Indeed one of the major drivers of IS-IS's success is its
	extensibility and adaptability.		extensibility and adaptability.
	13.7.2. Babel		15.7.2. Babel
	The extension mechanisms built into the Babel protocol [BABEL-EXT]		The extension mechanisms built into the Babel protocol [BABEL-EXT]
	have been shown to be a solid basis on which many backwards-		have been shown to be a solid basis on which many backwards-
	compatible extensions have been built, including one that		compatible extensions have been built, including one that
	fundamentally changes the structure of announcements [BABEL-SS] and		fundamentally changes the structure of announcements [BABEL-SS] and
	one that needed a non-trivial extension to the space of metrics		one that needs a non-trivial extension to the space of metrics
	[BABEL-Z].		[BABEL-Z].
	13.8. Success Predictable		15.8. Success Predictable
	If it is not known whether the protocol will be successful, should		If it is not known whether the protocol will be successful, should
	the market decide first? Or should the IETF work on multiple		the market decide first? Or should the IETF work on multiple
	alternatives and let the market decide among them? Are there factors		alternatives and let the market decide among them? Are there factors
	listed in this document that may predict which is more likely to		listed in this document that may predict which is more likely to
	succeed?		succeed?
	13.8.1. IS-IS		15.8.1. IS-IS
	For IS-IS the market has already decided that the protocol is		For IS-IS the market has already decided that the protocol is
	successful in a fairly wide variety of deployments.		successful in a fairly wide variety of deployments. [We're speaking
			of source-specific, autoconfiguring IS-IS here? And are we speaking
			of small, unadministered networks? -- jch]
	13.8.2. Babel		15.8.2. Babel
	Source-specific Babel is probably the only source-specific routing		Source-specific Babel is probably the only source-specific routing
	protocol that has seen a fair amount of deployment and is being used		protocol that has seen deployment and is being used in production.
	in production.
	Plain Babel has seen a modest amount of deployment, most notably for		Plain Babel has seen a modest amount of deployment, most notably for
	routing over wireless mesh networks and large-scale overlay networks.		routing over wireless mesh networks and large-scale overlay networks.
	However, it remains a young protocol, certainly much younger than IS-		However, it remains a young protocol, certainly much younger than IS-
	IS.		IS.
	14. Informative References		16. Acknowledgments
			The authors are grateful for the input of Steven Barth, Denis
			Ovsienko and Mark Townsley.
			17. Informative References
	[BABEL-EXT]		[BABEL-EXT]
	Chroboczek, J., "Extension Mechanism for the Babel Routing		Chroboczek, J., "Extension Mechanism for the Babel Routing
	Protocol", Internet Draft draft-chroboczek-babel-		Protocol", Internet Draft draft-chroboczek-babel-
	extension-mechanism-03, June 2013.		extension-mechanism-03, June 2013.
	[BABEL-SS]		[BABEL-SS]
	Boutier, M. and J. Chroboczek, "Source-Specific Routing in		Boutier, M. and J. Chroboczek, "Source-Specific Routing in
	Babel", Internet Draft draft-boutier-babel-source-		Babel", Internet Draft draft-boutier-babel-source-
	specific-00, November 2014.		specific-00, November 2014.
	[BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing		[BABEL-Z] Chroboczek, J., "Diversity Routing for the Babel Routing
	Protocol", Internet Draft draft-chroboczek-babel-		Protocol", Internet Draft draft-chroboczek-babel-
	diversity-routing-00, July 2014.		diversity-routing-00, July 2014.
			[DELAY-BASED]
			Jonglez, B. and M. Boutier, "A delay-based routing
			metric", March 2014, <http://arxiv.org/abs/1403.3488>.
			[ISIS-AUTOCONF]
			Liu, B., "ISIS Auto-Configuration", Internet Draft draft-
			liu-isis-auto-conf-03, October 2014.
			[ISIS-SS] Baker, F. and D. Lamparter, "IPv6 Source/Destination
			Routing using IS-IS", Internet Draft draft-baker-ipv6-
			isis-dst-src-routing-02, October 2014.
	[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC		[RFC1142] Oran, D., "OSI IS-IS Intra-domain Routing Protocol", RFC
	1142, February 1990.		1142, February 1990.
	[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,		[RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
	April 2011.		April 2011.
	[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code		[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
	(HMAC) Cryptographic Authentication", RFC 7298, July 2014.		(HMAC) Cryptographic Authentication", RFC 7298, July 2014.
	[SS-ROUTING]		[SS-ROUTING]
	skipping to change at page 15, line 38 ¶		skipping to change at page 20, line 4 ¶
	Margaret Wasserman		Margaret Wasserman
	Painless Security		Painless Security
	356 Abbott Street		356 Abbott Street
	North Andover, MA 01845		North Andover, MA 01845
	USA		USA
	Phone: +1 781 405-7464		Phone: +1 781 405-7464
	Email: mrw@painless-security.com		Email: mrw@painless-security.com
	URI: http://www.painless-security.com		URI: http://www.painless-security.com
	Christian E. Hopps		Christian E. Hopps
	Deutsche Telekom		Deutsche Telekom
	Email: chopps@rawdofmt.org		Email: chopps@chopps.org
	Juliusz Chroboczek		Juliusz Chroboczek
	University of Paris-Diderot (Paris 7)		University of Paris-Diderot (Paris 7)
	Email: jch@pps.univ-paris-diderot.fr		Email: jch@pps.univ-paris-diderot.fr
End of changes. 119 change blocks.
	290 lines changed or deleted		481 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/