draft-ietf-babel-source-specific-02.txt		draft-ietf-babel-source-specific-03.txt
	Network Working Group M. Boutier		Network Working Group M. Boutier
	Internet-Draft J. Chroboczek		Internet-Draft J. Chroboczek
	Intended status: Standards Track IRIF, University of Paris-Diderot		Intended status: Standards Track IRIF, University of Paris-Diderot
	Expires: July 24, 2018 January 20, 2018		Expires: August 4, 2018 January 31, 2018
	Source-Specific Routing in Babel		Source-Specific Routing in Babel
	draft-ietf-babel-source-specific-02		draft-ietf-babel-source-specific-03
	Abstract		Abstract
	Source-specific routing (also known as Source-Address Dependent		Source-specific routing (also known as Source-Address Dependent
	Routing, SADR) is an extension to traditional next-hop routing where		Routing, SADR) is an extension to traditional next-hop routing where
	packets are forwarded according to both their destination and their		packets are forwarded according to both their destination and their
	source address. This document describes an extension for source-		source address. This document describes an extension for source-
	specific routing to the Babel routing protocol.		specific routing to the Babel routing protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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). 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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 24, 2018.		This Internet-Draft will expire on August 4, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 and background . . . . . . . . . . . . . . . . . 2		1. Introduction and background . . . . . . . . . . . . . . . . . 2
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3		3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3		3.1. The Source Table . . . . . . . . . . . . . . . . . . . . 3
	3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4		3.2. The Route Table . . . . . . . . . . . . . . . . . . . . . 4
	3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4		3.3. The Table of Pending Seqno Requests . . . . . . . . . . . 4
	4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4		4. Data Forwarding . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5		5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6		5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
	5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6		5.2. Wildcard Messages . . . . . . . . . . . . . . . . . . . . 6
	6. Compatibility with the base protocol . . . . . . . . . . . . 7		6. Compatibility with the base protocol . . . . . . . . . . . . 7
	6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7		6.1. Loop-avoidance . . . . . . . . . . . . . . . . . . . . . 7
	6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 7		6.2. Starvation and Blackholes . . . . . . . . . . . . . . . . 8
	7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8		7. Protocol Encoding . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8		7.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8
	7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9		7.2. Source-specific Update . . . . . . . . . . . . . . . . . 9
	7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9		7.3. Source-specific (Route) Request . . . . . . . . . . . . . 9
	7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9		7.4. Source-Specific Seqno Request . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	9. Security considerations . . . . . . . . . . . . . . . . . . . 9		9. Security considerations . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 10		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
			11.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction and background		1. Introduction and background
	The Babel routing protocol [BABEL] is a distance vector routing		The Babel routing protocol [BABEL] is a distance vector routing
	protocol for next-hop routing. In next-hop routing, each node		protocol for next-hop routing. In next-hop routing, each node
	maintains a forwarding table which maps destination prefixes to next		maintains a forwarding table which maps destination prefixes to next
	hops. The forwarding decision is a per-packet operation which		hops. The forwarding decision is a per-packet operation which
	depends on the destination address of the packets and on the entries		depends on the destination address of the packets and on the entries
	of the forwarding table. When a packet is about to be routed, its		of the forwarding table. When a packet is about to be routed, its
	skipping to change at page 2, line 52 ¶		skipping to change at page 3, line 4 ¶
	address of the packet is chosen, and the packet is forwarded to the		address of the packet is chosen, and the packet is forwarded to the
	associated next-hop. Next-hop routing is a simple, well understood		associated next-hop. Next-hop routing is a simple, well understood
	paradigm that works satisfactorily in a large number of cases.		paradigm that works satisfactorily in a large number of cases.
	Source-specific routing [SS-ROUTING], or Source Address Dependent		Source-specific routing [SS-ROUTING], or Source Address Dependent
	Routing (SADR) [DSR], is a modest extension to next-hop routing where		Routing (SADR) [DSR], is a modest extension to next-hop routing where
	the forwarding decision depends not only on the destination address		the forwarding decision depends not only on the destination address
	but also on the source address of the packet being routed, which		but also on the source address of the packet being routed, which
	makes it possible for two packets with the same destination but		makes it possible for two packets with the same destination but
	different source addresses to be routed following different paths.		different source addresses to be routed following different paths.
	The forwarding tables are extended to map pairs of prefixes		The forwarding tables are extended to map pairs of prefixes
	(destination, source) to next hops. When multiple entries match a		(destination, source) to next hops. When multiple entries match a
	given packet, the one with the most specific destination prefix is		given packet, the one with the most specific destination prefix is
	chosen, and, in case of equality, the one with the most specific		chosen, and, in case of equality, the one with the most specific
	source prefix.		source prefix.
	The main application of source-specific routing is multihoming with		The main application of source-specific routing is a form of
	multiple addresses, a technique for multihoming which, unlike		multihoming known as multihoming with multiple addresses. When using
	multihoming, does not require the use of provider-independent		this technique in a network connected to multiple providers, every
	addresses and does not cause excessive growth of the global routing		host is assigned multiple addresses, one per provider. When a host
	table. In a network using this form of multihoming, each host is		sources a packet, it picks one of its addresses as the source
	given multiple addresses, one per upstream provider. When a host		address, and source-specific routing is used to route the packet to
	sources a packet, it picks one of its addresses as the source address		an edge router that is connected to the corresponding provider, which
	of the packet, and source-specific routing is used to route the		is compatible with [BCP84]. Unlike classical multihoming, this
	packet to an edge router that is connected to the corresponding		technique is applicable to small networks, as it does not require the
	provider, which is compatible with [BCP84]. More details are given		use of provider-independent addresses, or cause excessive growth of
	in [SS-ROUTING] and [DSR].		the global routing table. More details are given in [SS-ROUTING] and
			[DSR].
	This document describes a source-specific routing extension for the		This document describes a source-specific routing extension for the
	Babel routing protocol [BABEL]. This involves minor changes to the		Babel routing protocol [BABEL]. This involves minor changes to the
	data structures, which must include a source prefix in addition to		data structures, which must include a source prefix in addition to
	the destination prefix already present, and some changes to the		the destination prefix already present, and some changes to the
	Update, Route Request and Seqno Request TLVs, which are extended with		Update, Route Request and Seqno Request TLVs, which are extended with
	a source prefix. The source prefix is encoded using a mandatory sub-		a source prefix. The source prefix is encoded using a mandatory sub-
	TLV ([BABEL] Section 4.4).		TLV ([BABEL] Section 4.4).
	2. Specification of Requirements		2. Specification of Requirements
	skipping to change at page 8, line 27 ¶		skipping to change at page 8, line 35 ¶
	Since a source-specific routing entry is characterized by a single		Since a source-specific routing entry is characterized by a single
	destination prefix and a single source prefix, a source-specific		destination prefix and a single source prefix, a source-specific
	message contains exactly one Source Prefix sub-TLV. A node MUST NOT		message contains exactly one Source Prefix sub-TLV. A node MUST NOT
	send more that one Source Prefix sub-TLV in a TLV, and a node		send more that one Source Prefix sub-TLV in a TLV, and a node
	receiving more than one Source Prefix sub-TLV in a single TLV SHOULD		receiving more than one Source Prefix sub-TLV in a single TLV SHOULD
	ignore this TLV. It MAY ignore the whole packet.		ignore this TLV. It MAY ignore the whole packet.
	7.1. Source Prefix sub-TLV		7.1. Source Prefix sub-TLV
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = TBD | Length | Source Plen | Source Prefix...		| Type = 128 | Length | Source Plen | Source Prefix...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	Fields:		Fields:
	Type Set to TBD to indicate a Source Prefix sub-TLV.		Type Set to 128 to indicate a Source Prefix sub-TLV.
	Length The length of the body, exclusive of the Type and Length		Length The length of the body, exclusive of the Type and Length
	fields.		fields.
	Source Plen The length of the advertised source prefix. This MUST		Source Plen The length of the advertised source prefix. This MUST
	NOT be 0.		NOT be 0.
	Source Prefix The source prefix being advertised. This field's size		Source Prefix The source prefix being advertised. This field's size
	is (Source Plen)/8 rounded upwards.		is (Source Plen)/8 rounded upwards.
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 45 ¶
	7.4. Source-Specific Seqno Request		7.4. Source-Specific Seqno Request
	A source-specific Seqno Request is a Seqno Request TLV with a Source		A source-specific Seqno Request is a Seqno Request TLV with a Source
	Prefix sub-TLV. It requests the receiving node to perform the		Prefix sub-TLV. It requests the receiving node to perform the
	procedure described in Section 3.8.1.2 of [BABEL], but applied to a		procedure described in Section 3.8.1.2 of [BABEL], but applied to a
	pair of a destination and source prefix.		pair of a destination and source prefix.
	8. IANA Considerations		8. IANA Considerations
	IANA is requested to allocate TBD, a Babel sub-TLV type from the		IANA has allocated sub-TLV number 128 for the Source Prefix sub-TLV
	range reserved for mandatory sub-TLVs [value 128 suggested], and to		in the Babel Sub-TLV Numbers registry.
	add the following entry to the "Babel mandatory sub-TLV Types"
	registry:
	+----------+---------------+-----------------+
	| Type | Name | Reference |
	+----------+---------------+-----------------+
	| TBD[128] | Source Prefix | (this document) |
	+----------+---------------+-----------------+
	9. Security considerations		9. Security considerations
	The extension defined in this document adds a new sub-TLV to three		The extension defined in this document adds a new sub-TLV to three
	TLVs already present in the original Babel protocol, and does not in		TLVs already present in the original Babel protocol, and does not in
	itself change the security properties of the protocol. However,		itself change the security properties of the protocol. However,
	source-specific routing gives more control over routing to the		source-specific routing gives more control over routing to the
	sending hosts, which might have security implications (see Section 8		sending hosts, which might have security implications (see Section 8
	of [DSR]).		of [DSR]).
	10. References		10. Acknowledgments
	10.1. Normative References		The authors are grateful to Joel Halpern for his help with this
			document.
			11. References
			11.1. Normative References
	[BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet		[BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet
	Draft draft-ietf-babel-rfc6126bis-04, May 2017.		Draft draft-ietf-babel-rfc6126bis-04, May 2017.
	[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997.		DOI 10.17487/RFC2119, March 1997.
	10.2. Informative References		11.2. Informative References
	[DSR] Lamparter, D. and A. Smirnov, "Destination/Source		[DSR] Lamparter, D. and A. Smirnov, "Destination/Source
	Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing-		Routing", Internet Draft draft-ietf-rtgwg-dst-src-routing-
	06, May 2018.		06, May 2018.
	[RFC6126] Chroboczek, J., "The Babel Routing Protocol		[RFC6126] Chroboczek, J., "The Babel Routing Protocol
	(Experimental)", RFC 6126, February 2011.		(Experimental)", RFC 6126, February 2011.
	[SS-ROUTING]		[SS-ROUTING]
	Boutier, M. and J. Chroboczek, "Source-Specific Routing",		Boutier, M. and J. Chroboczek, "Source-Specific Routing",
End of changes. 16 change blocks.
	37 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/