draft-ietf-mboned-driad-amt-discovery-06.txt		draft-ietf-mboned-driad-amt-discovery-07.txt
	Mboned J. Holland		Mboned J. Holland
	Internet-Draft Akamai Technologies, Inc.		Internet-Draft Akamai Technologies, Inc.
	Updates: 7450 (if approved) May 06, 2019		Updates: 7450 (if approved) June 13, 2019
	Intended status: Standards Track		Intended status: Standards Track
	Expires: November 7, 2019		Expires: December 15, 2019
	DNS Reverse IP AMT Discovery		DNS Reverse IP AMT Discovery
	draft-ietf-mboned-driad-amt-discovery-06		draft-ietf-mboned-driad-amt-discovery-07
	Abstract		Abstract
	This document updates RFC 7450 (Automatic Multicast Tunneling, or		This document updates RFC 7450 (Automatic Multicast Tunneling, or
	AMT) by extending the relay discovery process to use a new DNS		AMT) by extending the relay discovery process to use a new DNS
	resource record named AMTRELAY when discovering AMT relays for		resource record named AMTRELAY when discovering AMT relays for
	source-specific multicast channels. The reverse IP DNS zone for a		source-specific multicast channels. The reverse IP DNS zone for a
	multicast sender's IP address is configured to use AMTRELAY resource		multicast sender's IP address is configured to use AMTRELAY resource
	records to advertise a set of AMT relays that can receive and forward		records to advertise a set of AMT relays that can receive and forward
	multicast traffic from that sender over an AMT tunnel.		multicast traffic from that sender over an AMT tunnel.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 7, 2019.		This Internet-Draft will expire on December 15, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 6, line 44 ¶		skipping to change at page 6, line 44 ¶
	gateway, and conditions match the requirements outlined in		gateway, and conditions match the requirements outlined in
	Section 2.4.		Section 2.4.
	Some detailed example use cases are provided in Section 3, and other		Some detailed example use cases are provided in Section 3, and other
	applicable example topologies appear in Section 3.3 of [RFC8313],		applicable example topologies appear in Section 3.3 of [RFC8313],
	Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].		Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313].
	2.2. Signaling and Discovery		2.2. Signaling and Discovery
	This section describes a typical example of the end-to-end process		This section describes a typical example of the end-to-end process
	for signaling a receiver's join of a SSM channel that relies on an		for signaling a receiver's join of an SSM channel that relies on an
	AMTRELAY RR.		AMTRELAY RR.
	The example in Figure 2 contains 2 multicast-enabled networks that		The example in Figure 2 contains 2 multicast-enabled networks that
	are both connected to the internet with non-multicast-capable links,		are both connected to the internet with non-multicast-capable links,
	and which have no direct association with each other.		and which have no direct association with each other.
	A content provider operates a sender, which is a source of multicast		A content provider operates a sender, which is a source of multicast
	traffic inside a multicast-capable network.		traffic inside a multicast-capable network.
	An end user who is a customer of the content provider has a		An end user who is a customer of the content provider has a
	multicast-capable internet service provider, which operates a		multicast-capable internet service provider, which operates a
	receiving network that uses an AMT gateway. The AMT gateway is		receiving network that uses an AMT gateway. The AMT gateway is
	DRIAD-capable.		DRIAD-capable.
	The content provider provides the user with a receiving application		The content provider provides the user with a receiving application
	that tries to subscribe to at least one (S,G). This receiving		that tries to subscribe to at least one (S,G). This receiving
	application could for example be a file transfer system using FLUTE		application could for example be a file transfer system using FLUTE
	[RFC6726] or a live video stream using RTP [RFC3550], or any other		[RFC6726] or a live video stream using RTP [RFC3550], or any other
	application that might subscribe to a SSM channel.		application that might subscribe to an SSM channel.
	+---------------+		+---------------+
	| Sender |		| Sender |
	| | | 198.51.100.15 |		| | | 198.51.100.15 |
	| | +---------------+		| | +---------------+
	|Data| |		|Data| |
	|Flow| Multicast |		|Flow| Multicast |
	\| |/ Network |		\| |/ Network |
	\ / | 5: Propagate RPF for Join(S,G)		\ / | 5: Propagate RPF for Join(S,G)
	\ / +---------------+		\ / +---------------+
	skipping to change at page 9, line 6 ¶		skipping to change at page 9, line 6 ¶
	2.3. Happy Eyeballs		2.3. Happy Eyeballs
	2.3.1. Overview		2.3.1. Overview
	Often, multiple choices of relay will exist for a gateway using DRIAD		Often, multiple choices of relay will exist for a gateway using DRIAD
	for relay discovery. It is RECOMMENDED that DRIAD-capable gateways		for relay discovery. It is RECOMMENDED that DRIAD-capable gateways
	implement a Happy Eyeballs [RFC8305] algorithm to support connecting		implement a Happy Eyeballs [RFC8305] algorithm to support connecting
	to multiple relays in parallel.		to multiple relays in parallel.
	The parallel discovery logic of a Happy Eyeballs algorithm serves to		The parallel discovery logic of a Happy Eyeballs algorithm serves to
	reduce join latency for the initial join of a SSM channel. This		reduce join latency for the initial join of an SSM channel. This
	section and Section 2.4.2 taken together provide guidance on use of a		section and Section 2.4.2 taken together provide guidance on use of a
	Happy Eyeballs algorithm for the case of establishing AMT		Happy Eyeballs algorithm for the case of establishing AMT
	connections.		connections.
	2.3.2. Connection Definition		2.3.2. Connection Definition
	Section 5 of [RFC8305] non-normatively describes success at a		Section 5 of [RFC8305] non-normatively describes success at a
	connection attempt as "generally when the TCP handshake completes".		connection attempt as "generally when the TCP handshake completes".
	There is no normative definition of a connection in the AMT		There is no normative definition of a connection in the AMT
	skipping to change at page 11, line 48 ¶		skipping to change at page 11, line 48 ¶
	addresses from Section 7 of [RFC7450] to route discovery traffic		addresses from Section 7 of [RFC7450] to route discovery traffic
	to the relay most appropriate to the receiver's gateway.		to the relay most appropriate to the receiver's gateway.
	Accordingly, the gateway SHOULD by default discover a relay with		Accordingly, the gateway SHOULD by default discover a relay with
	the well-known AMT anycast addresses as the second preference		the well-known AMT anycast addresses as the second preference
	after DNS-SD when searching for a local relay.		after DNS-SD when searching for a local relay.
	o Let Sender Manage Relay Provisioning		o Let Sender Manage Relay Provisioning
	A related motivating example in the sending-side network is		A related motivating example in the sending-side network is
	provided by considering a sender which needs to instruct the		provided by considering a sender that needs to instruct the
	gateways on how to select between connecting to Figure 6 or		gateways on how to select between connecting to Figure 6 or
	Figure 7 (from Section 3.2), in order to manage load and failover		Figure 7 (from Section 3.2), in order to manage load and failover
	scenarios in a manner that operates well with the sender's		scenarios in a manner that operates well with the sender's
	provisioning strategy for horizontal scaling of AMT relays.		provisioning strategy for horizontal scaling of AMT relays.
	In this example about the sending-side network, the precedence		In this example about the sending-side network, the precedence
	field described in Section 4.2.1 is a critical method of control		field described in Section 4.2.1 is a critical method of control
	so that senders can provide the appropriate guidance to gateways		so that senders can provide the appropriate guidance to gateways
	during the discovery process.		during the discovery process.
	skipping to change at page 14, line 16 ¶		skipping to change at page 14, line 16 ¶
	guidelines to operators and implementors working with AMT systems		guidelines to operators and implementors working with AMT systems
	that can use DRIAD as part of the relay discovery process.		that can use DRIAD as part of the relay discovery process.
	2.5.2. Updates to Restarting Events		2.5.2. Updates to Restarting Events
	Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a		Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a
	gateway to start or restart the discovery procedure.		gateway to start or restart the discovery procedure.
	This document provides some updates and recommendations regarding the		This document provides some updates and recommendations regarding the
	handling of these and similar events. The first 5 events are copied		handling of these and similar events. The first 5 events are copied
	here and numbered for easier reference, and the following events are		here and numbered for easier reference, and the remaining 4 events
	newly added for consideration in this document:		are newly added for consideration in this document:
	1. When a gateway pseudo-interface is started (enabled).		1. When a gateway pseudo-interface is started (enabled).
	2. When the gateway wishes to report a group subscription when none		2. When the gateway wishes to report a group subscription when none
	currently exist.		currently exist.
	3. Before sending the next Request message in a membership update		3. Before sending the next Request message in a membership update
	cycle.		cycle.
	4. After the gateway fails to receive a response to a Request		4. After the gateway fails to receive a response to a Request
	message.		message.
	5. After the gateway receives a Membership Query message with the L		5. After the gateway receives a Membership Query message with the L
	flag set to 1.		flag set to 1.
	6. When the gateway wishes to report a (S,G) subscription with a		6. When the gateway wishes to report an (S,G) subscription with a
	source address that does not currently have other group		source address that does not currently have other group
	subscriptions.		subscriptions.
	7. When there is a network change detected, for example when a		7. When there is a network change detected, for example when a
	gateway is operating inside an end user device or application,		gateway is operating inside an end user device or application,
	and the device joins a different network, or when the domain		and the device joins a different network, or when the domain
	portion of a DNS-SD domain name changes in response to a DHCP		portion of a DNS-SD domain name changes in response to a DHCP
	message or administrative configuration.		message or administrative configuration.
	8. When congestion or substantial loss is detected in the stream of		8. When congestion or substantial loss is detected in the stream of
	skipping to change at page 15, line 13 ¶		skipping to change at page 15, line 13 ¶
	strictly required to always force a restart of the discovery process.		strictly required to always force a restart of the discovery process.
	Note that during event #1, a gateway may use DNS-SD, but does not		Note that during event #1, a gateway may use DNS-SD, but does not
	have sufficient information to use DRIAD, since no source is known.		have sufficient information to use DRIAD, since no source is known.
	2.5.3. Tunnel Stability		2.5.3. Tunnel Stability
	In general, subscribers to active traffic flows that are being		In general, subscribers to active traffic flows that are being
	forwarded by an AMT gateway are less likely to experience a		forwarded by an AMT gateway are less likely to experience a
	degradation in service (for example, from missing or duplicated		degradation in service (for example, from missing or duplicated
	packets) when the gateway continues using the same relay, as long the		packets) when the gateway continues using the same relay, as long as
	relay is not overloaded and the network conditions remain stable.		the relay is not overloaded and the network conditions remain stable.
	Therefore, gateways SHOULD avoid performing a full restart of the		Therefore, gateways SHOULD avoid performing a full restart of the
	discovery process during routine cases of event #3 (sending a new		discovery process during routine cases of event #3 (sending a new
	Request message), since it occurs frequently in normal operation.		Request message), since it occurs frequently in normal operation.
	However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for		However, see Section 2.5.4, Section 2.5.6, and Section 2.5.4.3 for
	more information about exceptional cases when it may be appropriate		more information about exceptional cases when it may be appropriate
	to use event #3.		to use event #3.
	2.5.4. Traffic Health		2.5.4. Traffic Health
	skipping to change at page 18, line 7 ¶		skipping to change at page 18, line 7 ¶
	a disruption in the forwarded traffic by sending such Relay Discovery		a disruption in the forwarded traffic by sending such Relay Discovery
	messages regularly. When a relay is under load or has started a		messages regularly. When a relay is under load or has started a
	graceful shutdown, it may respond with a different relay address,		graceful shutdown, it may respond with a different relay address,
	which the gateway can use to connect to a different relay. This kind		which the gateway can use to connect to a different relay. This kind
	of coordinated handoff will likely result in a smaller disruption to		of coordinated handoff will likely result in a smaller disruption to
	the traffic than if the relay simply stops responding to Request		the traffic than if the relay simply stops responding to Request
	messages, and stops forwarding traffic.		messages, and stops forwarding traffic.
	This style of Relay Discovery message (one sent to the unicast		This style of Relay Discovery message (one sent to the unicast
	address of a relay that's already forwarding traffic to this gateway)		address of a relay that's already forwarding traffic to this gateway)
	should not be considered a full restart of the relay discovery		SHOULD NOT be considered a full restart of the relay discovery
	process. It is recommended for gateways to support the L flag, but		process. It is recommended for gateways to support the L flag, but
	for gateways that do not support the L flag, sending this message		for gateways that do not support the L flag, sending this message
	during event #3 may help mitigate service degradation when relays		during event #3 may help mitigate service degradation when relays
	become unstable.		become unstable.
	2.5.7. Independent Discovery Per Traffic Source		2.5.7. Independent Discovery Per Traffic Source
	Relays discovered via the AMTRELAY RR are source-specific relay		Relays discovered via the AMTRELAY RR are source-specific relay
	addresses, and may use different pseudo-interfaces from each other		addresses, and may use different pseudo-interfaces from each other
	and from relays discovered via DNS-SD or a non-source-specific		and from relays discovered via DNS-SD or a non-source-specific
	skipping to change at page 29, line 28 ¶		skipping to change at page 29, line 28 ¶
	that don't follow UDP congestion control principles, or deliberate		that don't follow UDP congestion control principles, or deliberate
	attack.		attack.
	7. Acknowledgements		7. Acknowledgements
	This specification was inspired by the previous work of Doug Nortz,		This specification was inspired by the previous work of Doug Nortz,
	Robert Sayko, David Segelstein, and Percy Tarapore, presented in the		Robert Sayko, David Segelstein, and Percy Tarapore, presented in the
	MBONED working group at IETF 93.		MBONED working group at IETF 93.
	Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny		Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny
	Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, and Ben Kaduk for		Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, and Bill
	their very helpful comments.		Atwood for their very helpful comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
End of changes. 13 change blocks.
	16 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/