draft-ietf-mboned-driad-amt-discovery-03.txt   draft-ietf-mboned-driad-amt-discovery-04.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) April 04, 2019 Updates: 7450 (if approved) April 22, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: October 6, 2019 Expires: October 24, 2019
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-03 draft-ietf-mboned-driad-amt-discovery-04
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 October 6, 2019. This Internet-Draft will expire on October 24, 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 9, line 29 skipping to change at page 9, line 29
However, the concept of an AMT connection in the context of a Happy However, the concept of an AMT connection in the context of a Happy
Eyeballs algorithm is a useful one, and so this section provides the Eyeballs algorithm is a useful one, and so this section provides the
following normative definition: following normative definition:
o An AMT connection is completed successfully when the gateway o An AMT connection is completed successfully when the gateway
receives from a newly discovered relay a valid Membership Query receives from a newly discovered relay a valid Membership Query
message (Section 5.1.4 of [RFC7450]) that does not have the L flag message (Section 5.1.4 of [RFC7450]) that does not have the L flag
set. set.
See Section 2.5.5 for further information about the relevance of the See Section 2.5.5 of this document for further information about the
L flag to the establishment of a Happy Eyeballs connection. relevance of the L flag to the establishment of a Happy Eyeballs
connection.
2.4. Optimal Relay Selection 2.4. Optimal Relay Selection
2.4.1. Overview 2.4.1. Overview
The reverse source IP DNS query of an AMTRELAY RR is a good way for a The reverse source IP DNS query of an AMTRELAY RR is a good way for a
gateway to discover a relay that is known to the sender. gateway to discover a relay that is known to the sender.
However, it is NOT necessarily a good way to discover the best relay However, it is NOT necessarily a good way to discover the best relay
for that gateway to use, because the RR will only provide information for that gateway to use, because the RR will only provide information
skipping to change at page 11, line 17 skipping to change at page 11, line 17
a Happy Eyeballs algorithm to reduce the join latency, while still a Happy Eyeballs algorithm to reduce the join latency, while still
prioritizing network efficiency considerations over Address Selection prioritizing network efficiency considerations over Address Selection
considerations. considerations.
Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort
the addresses with the Destination Address Selection defined in the addresses with the Destination Address Selection defined in
Section 6 of [RFC6724], but for the above reasons, that requirement Section 6 of [RFC6724], but for the above reasons, that requirement
is superseded in the AMT discovery use case by the following is superseded in the AMT discovery use case by the following
considerations: considerations:
1. Prefer Local Relays o Prefer Local Relays
Figure 5 and Section 3.1.2 provide a motivating example to prefer Figure 5 and Section 3.1.2 provide a motivating example to prefer
DNS-SD [RFC6763] for discovery strictly ahead of using the DNS-SD [RFC6763] for discovery strictly ahead of using the
AMTRELAY RR controlled by the sender for AMT discovery. AMTRELAY RR controlled by the sender for AMT discovery.
For this reason, it's RECOMMENDED that AMT gateways by default For this reason, it's RECOMMENDED that AMT gateways by default
perform service discovery using DNS Service Discovery (DNS-SD) perform service discovery using DNS Service Discovery (DNS-SD)
[RFC6763] for _amt._udp.<domain> (with <domain> chosen as [RFC6763] for _amt._udp.<domain> (with <domain> chosen as
described in Section 11 of [RFC6763]) and use the AMT relays described in Section 11 of [RFC6763]) and use the AMT relays
discovered that way in preference to AMT relays discoverable via discovered that way in preference to AMT relays discoverable via
the mechanism defined in this document (DRIAD). the mechanism defined in this document (DRIAD).
2. Prefer Relays Managed by the Containing Network o Prefer Relays Managed by the Containing Network
When no local relay is discoverable with DNS-SD, it still may be When no local relay is discoverable with DNS-SD, it still may be
the case that a relay local to the receiver is operated by the the case that a relay local to the receiver is operated by the
network providing transit services to the receiver. network providing transit services to the receiver.
In this case, when the network cannot make the relay discoverable In this case, when the network cannot make the relay discoverable
via DNS-SD, the network SHOULD use the well-known anycast via DNS-SD, the network SHOULD use the well-known anycast
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.
3. 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 which 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.
Therefore, after DNS-SD, the precedence from the RR MUST be used Therefore, after DNS-SD, the precedence from the RR MUST be used
for sorting preference ahead of the Destination Address Selection for sorting preference ahead of the Destination Address Selection
ordering from Section 6 of [RFC6724], so that only relay IPs with ordering from Section 6 of [RFC6724], so that only relay IPs with
the same precedence are directly compared according to the the same precedence are directly compared according to the
Destination Address Selection ordering. Destination Address Selection ordering.
Accordingly, AMT gateways SHOULD by default prefer relays first by Accordingly, AMT gateways SHOULD by default prefer relays in this
DNS-SD if available, then with the anycast addresses defined in order:
Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by
DRIAD as described in this document (in precedence order, as 1. DNS-SD
described in Section 4.2.1). 2. Anycast addresses from Section 7 of [RFC7450]
3. DRIAD
This default behavior MAY be overridden by administrative This default behavior MAY be overridden by administrative
configuration where other behavior is more appropriate for the configuration where other behavior is more appropriate for the
gateway within its network. gateway within its network.
Among relay addresses that have an equivalent preference as described Among relay addresses that have an equivalent preference as described
above, a Happy Eyeballs algorithm for AMT MUST use the Destination above, a Happy Eyeballs algorithm for AMT MUST use the Destination
Address Selection defined in Section 6 of [RFC6724], as required by Address Selection defined in Section 6 of [RFC6724], as required by
[RFC8305]. [RFC8305].
Among relay addresses that still have an equivalent preference after Among relay addresses that still have an equivalent preference after
the above orderings, a gateway MUST make a non-deterministic choice the above orderings, a gateway MUST make a non-deterministic choice
for relay preference ordering, in order to support load balancing by for relay preference ordering, in order to support load balancing by
DNS configurations that provide many relay options. (Note that DNS configurations that provide many relay options.
gateways not implementing a Happy Eyeballs algorithm are not required
to use the Destination Address Selection ordering, but are still The gateway MAY introduce a bias in the non-deterministic choice
required to use non-deterministic ordering among equally preferred according to network topology or timing information obtained out of
relays.) band or from a historical record. The collection of this information
is out of scope for this document, but a gateway in possession of
such information MAY use it to prefer topologically closer relays.
Note also that certain relay addresses may be excluded from Note also that certain relay addresses may be excluded from
consideration by the hold-down timers described in Section 2.5.4.1 or consideration by the hold-down timers described in Section 2.5.4.1 or
Section 2.5.5. These relays constitute "unusable destinations" under Section 2.5.5. These relays constitute "unusable destinations" under
Rule 1 of the Destination Address Selection, and are also not part of Rule 1 of the Destination Address Selection, and are also not part of
the superseding considerations described above. the superseding considerations described above.
The discovery and connection process for the relay addresses in the The discovery and connection process for the relay addresses in the
above described ordering MAY operate in parallel, subject to delays above described ordering MAY operate in parallel, subject to delays
prescribed by the Happy Eyeballs requirements described in Section 5 prescribed by the Happy Eyeballs requirements described in Section 5
skipping to change at page 13, line 14 skipping to change at page 13, line 16
2.4.3. Connecting to Multiple Relays 2.4.3. Connecting to Multiple Relays
In some deployments, it may be useful for a gateway to connect to In some deployments, it may be useful for a gateway to connect to
multiple upstream relays and subscribe to the same traffic, in order multiple upstream relays and subscribe to the same traffic, in order
to support an active/active failover model. A gateway SHOULD NOT be to support an active/active failover model. A gateway SHOULD NOT be
configured to do so without guaranteeing that adequate bandwidth is configured to do so without guaranteeing that adequate bandwidth is
available. available.
A gateway configured to do this SHOULD still use the same preference A gateway configured to do this SHOULD still use the same preference
ordering logic from Section 2.4.2 for both connections. (Note that ordering logic from Section 2.4.2 for each connection. (Note that
this ordering allows for overriding by explicit administrative this ordering allows for overriding by explicit administrative
configuration where required.) configuration where required.)
2.5. Guidelines for Restarting Discovery 2.5. Guidelines for Restarting Discovery
2.5.1. Overview 2.5.1. Overview
It's expected that gateways deployed in different environments will It's expected that gateways deployed in different environments will
use a variety of heuristics to decide when it's appropriate to use a variety of heuristics to decide when it's appropriate to
restart the relay discovery process, in order to meet different restart the relay discovery process, in order to meet different
skipping to change at page 22, line 48 skipping to change at page 22, line 48
capabilities of the network in Figure 3. capabilities of the network in Figure 3.
3.2. Example Sending Networks 3.2. Example Sending Networks
3.2.1. Sender-controlled Relays 3.2.1. Sender-controlled Relays
When a sender network is also operating AMT relays to distribute When a sender network is also operating AMT relays to distribute
multicast traffic, as in Figure 6, each address could appear as an multicast traffic, as in Figure 6, each address could appear as an
AMTRELAY RR for the reverse IP of the sender, or one or more domain AMTRELAY RR for the reverse IP of the sender, or one or more domain
names could appear in AMTRELAY RRs, and the AMT relay addresses can names could appear in AMTRELAY RRs, and the AMT relay addresses can
be discovered by finding a A or AAAA records from those domain names. be discovered by finding A or AAAA records from those domain names.
Sender Network Sender Network
+-----------------------------------+ +-----------------------------------+
| | | |
| +--------+ +=======+ +=======+ | | +--------+ +=======+ +=======+ |
| | Sender | | AMT | | AMT | | | | Sender | | AMT | | AMT | |
| +--------+ | relay | | relay | | | +--------+ | relay | | relay | |
| | +=======+ +=======+ | | | +=======+ +=======+ |
| | | | | | | | | |
| +-----+------+----------+ | | +-----+------+----------+ |
 End of changes. 20 change blocks. 
55 lines changed or deleted 59 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/