--- 1/draft-ietf-mboned-driad-amt-discovery-07.txt 2019-06-14 21:13:10.355527688 -0700 +++ 2/draft-ietf-mboned-driad-amt-discovery-08.txt 2019-06-14 21:13:10.423529401 -0700 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) June 13, 2019 +Updates: 7450 (if approved) June 14, 2019 Intended status: Standards Track -Expires: December 15, 2019 +Expires: December 16, 2019 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-07 + draft-ietf-mboned-driad-amt-discovery-08 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 December 15, 2019. + This Internet-Draft will expire on December 16, 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 @@ -69,21 +69,21 @@ 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 2.5.7. Independent Discovery Per Traffic Source . . . . . . 18 2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 18 - 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 19 + 2.7. Waiting for DNS resolution . . . . . . . . . . . . . . . 18 3. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24 @@ -539,21 +539,21 @@ The gateway MAY introduce a bias in the non-deterministic choice according to information obtained out of band or from a historical record about network topology, timing information, or the response to a probing mechanism, that indicates some expected benefits from selecting some relays in preference to others. Details about the structure and collection of this information are 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 might 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 of [RFC8305] for successively launched concurrent connection attempts. @@ -759,25 +759,21 @@ NOT be considered for the relay selection. It is also RECOMMENDED that gateways avoid choosing a relay that has recently sent an L flag, with approximately a 10-minute hold-down. Gateways SHOULD treat this hold-down timer in the same way as the hold-down in Section 2.5.4.1, so that the relay is removed from consideration for short-term subsequent rounds of discovery. 2.5.6. Relay Discovery Messages vs. Restarting Discovery - A gateway should only send DNS queries with the AMTRELAY RRType or - the DNS-SD DNS queries for an AMT service as part of starting or - restarting the discovery process. - - However, all AMT relays are required to support handling of Relay + All AMT relays are required by [RFC7450] to support handling of Relay Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). So a gateway with an existing connection to a relay can send a Relay Discovery message to the unicast address of that AMT relay. Under stable conditions with an unloaded relay, it's expected that the relay will return its own unicast address in the Relay Advertisement, in response to such a Relay Discovery message. Since this will not result in the gateway changing to another relay unless the relay directs the gateway away, this is a reasonable exception to the advice against handling event #3 described in Section 2.5.3. @@ -790,21 +786,21 @@ messages regularly. When a relay is under load or has started a graceful shutdown, it may respond with a different relay address, which the gateway can use to connect to a different relay. This kind of coordinated handoff will likely result in a smaller disruption to the traffic than if the relay simply stops responding to Request messages, and stops forwarding traffic. This style of Relay Discovery message (one sent to the unicast address of a relay that's already forwarding traffic to this gateway) 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 during event #3 may help mitigate service degradation when relays become unstable. 2.5.7. Independent Discovery Per Traffic Source Relays discovered via the AMTRELAY RR are source-specific relay addresses, and may use different pseudo-interfaces from each other and from relays discovered via DNS-SD or a non-source-specific address, as described in Section 4.1.2.1 of [RFC7450].