--- 1/draft-ietf-mboned-driad-amt-discovery-03.txt 2019-04-22 17:13:12.323118181 -0700 +++ 2/draft-ietf-mboned-driad-amt-discovery-04.txt 2019-04-22 17:13:12.391119976 -0700 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) April 04, 2019 +Updates: 7450 (if approved) April 22, 2019 Intended status: Standards Track -Expires: October 6, 2019 +Expires: October 24, 2019 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-03 + draft-ietf-mboned-driad-amt-discovery-04 Abstract This document updates RFC 7450 (Automatic Multicast Tunneling, or AMT) by extending the relay discovery process to use a new DNS resource record named AMTRELAY when discovering AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -376,22 +376,23 @@ 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 following normative definition: o An AMT connection is completed successfully when the gateway receives from a newly discovered relay a valid Membership Query message (Section 5.1.4 of [RFC7450]) that does not have the L flag set. - See Section 2.5.5 for further information about the relevance of the - L flag to the establishment of a Happy Eyeballs connection. + See Section 2.5.5 of this document for further information about the + relevance of the L flag to the establishment of a Happy Eyeballs + connection. 2.4. Optimal Relay Selection 2.4.1. Overview 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. 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 @@ -459,91 +460,94 @@ a Happy Eyeballs algorithm to reduce the join latency, while still prioritizing network efficiency considerations over Address Selection considerations. Section 4 of [RFC8305] requires a Happy Eyeballs algorithm to sort the addresses with the Destination Address Selection defined in Section 6 of [RFC6724], but for the above reasons, that requirement is superseded in the AMT discovery use case by the following considerations: - 1. Prefer Local Relays + o Prefer Local Relays Figure 5 and Section 3.1.2 provide a motivating example to prefer DNS-SD [RFC6763] for discovery strictly ahead of using the AMTRELAY RR controlled by the sender for AMT discovery. For this reason, it's RECOMMENDED that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD) [RFC6763] for _amt._udp. (with chosen as described in Section 11 of [RFC6763]) and use the AMT relays discovered that way in preference to AMT relays discoverable via 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 the case that a relay local to the receiver is operated by the network providing transit services to the receiver. In this case, when the network cannot make the relay discoverable via DNS-SD, the network SHOULD use the well-known anycast addresses from Section 7 of [RFC7450] to route discovery traffic to the relay most appropriate to the receiver's gateway. Accordingly, the gateway SHOULD by default discover a relay with the well-known AMT anycast addresses as the second preference 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 provided by considering a sender which needs to instruct the gateways on how to select between connecting to Figure 6 or Figure 7 (from Section 3.2), in order to manage load and failover scenarios in a manner that operates well with the sender's provisioning strategy for horizontal scaling of AMT relays. In this example about the sending-side network, the precedence field described in Section 4.2.1 is a critical method of control so that senders can provide the appropriate guidance to gateways during the discovery process. Therefore, after DNS-SD, the precedence from the RR MUST be used for sorting preference ahead of the Destination Address Selection ordering from Section 6 of [RFC6724], so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering. - Accordingly, AMT gateways SHOULD by default prefer relays first by - DNS-SD if available, then with the anycast addresses defined in - 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 - described in Section 4.2.1). + Accordingly, AMT gateways SHOULD by default prefer relays in this + order: + + 1. DNS-SD + 2. Anycast addresses from Section 7 of [RFC7450] + 3. DRIAD This default behavior MAY be overridden by administrative configuration where other behavior is more appropriate for the gateway within its network. Among relay addresses that have an equivalent preference as described above, a Happy Eyeballs algorithm for AMT MUST use the Destination Address Selection defined in Section 6 of [RFC6724], as required by [RFC8305]. Among relay addresses that still have an equivalent preference after the above orderings, a gateway MUST make a non-deterministic choice for relay preference ordering, in order to support load balancing by - DNS configurations that provide many relay options. (Note that - gateways not implementing a Happy Eyeballs algorithm are not required - to use the Destination Address Selection ordering, but are still - required to use non-deterministic ordering among equally preferred - relays.) + DNS configurations that provide many relay options. + + The gateway MAY introduce a bias in the non-deterministic choice + according to network topology or timing information obtained out of + 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 consideration by the hold-down timers described in Section 2.5.4.1 or Section 2.5.5. These relays constitute "unusable destinations" under Rule 1 of the Destination Address Selection, and are also not part of the superseding considerations described above. The discovery and connection process for the relay addresses in the above described ordering MAY operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described in Section 5 @@ -552,21 +556,21 @@ 2.4.3. Connecting to Multiple Relays In some deployments, it may be useful for a gateway to connect to multiple upstream relays and subscribe to the same traffic, in order to support an active/active failover model. A gateway SHOULD NOT be configured to do so without guaranteeing that adequate bandwidth is available. 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 configuration where required.) 2.5. Guidelines for Restarting Discovery 2.5.1. Overview It's expected that gateways deployed in different environments will use a variety of heuristics to decide when it's appropriate to restart the relay discovery process, in order to meet different @@ -980,21 +985,21 @@ capabilities of the network in Figure 3. 3.2. Example Sending Networks 3.2.1. Sender-controlled Relays When a sender network is also operating AMT relays to distribute 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 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 | | AMT | | AMT | | | +--------+ | relay | | relay | | | | +=======+ +=======+ | | | | | | | +-----+------+----------+ |