--- 1/draft-ietf-mboned-driad-amt-discovery-06.txt 2019-06-13 18:13:09.433740833 -0700 +++ 2/draft-ietf-mboned-driad-amt-discovery-07.txt 2019-06-13 18:13:09.501742557 -0700 @@ -1,19 +1,19 @@ Mboned J. Holland Internet-Draft Akamai Technologies, Inc. -Updates: 7450 (if approved) May 06, 2019 +Updates: 7450 (if approved) June 13, 2019 Intended status: Standards Track -Expires: November 7, 2019 +Expires: December 15, 2019 DNS Reverse IP AMT Discovery - draft-ietf-mboned-driad-amt-discovery-06 + draft-ietf-mboned-driad-amt-discovery-07 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 November 7, 2019. + This Internet-Draft will expire on December 15, 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 @@ -248,40 +248,40 @@ gateway, and conditions match the requirements outlined in Section 2.4. Some detailed example use cases are provided in Section 3, and other applicable example topologies appear in Section 3.3 of [RFC8313], Section 3.4 of [RFC8313], and Section 3.5 of [RFC8313]. 2.2. Signaling and Discovery 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. The example in Figure 2 contains 2 multicast-enabled networks that are both connected to the internet with non-multicast-capable links, and which have no direct association with each other. A content provider operates a sender, which is a source of multicast traffic inside a multicast-capable network. An end user who is a customer of the content provider has a multicast-capable internet service provider, which operates a receiving network that uses an AMT gateway. The AMT gateway is DRIAD-capable. The content provider provides the user with a receiving application that tries to subscribe to at least one (S,G). This receiving application could for example be a file transfer system using FLUTE [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 | | | | 198.51.100.15 | | | +---------------+ |Data| | |Flow| Multicast | \| |/ Network | \ / | 5: Propagate RPF for Join(S,G) \ / +---------------+ @@ -353,21 +353,21 @@ 2.3. Happy Eyeballs 2.3.1. Overview Often, multiple choices of relay will exist for a gateway using DRIAD for relay discovery. It is RECOMMENDED that DRIAD-capable gateways implement a Happy Eyeballs [RFC8305] algorithm to support connecting to multiple relays in parallel. 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 Happy Eyeballs algorithm for the case of establishing AMT connections. 2.3.2. Connection Definition Section 5 of [RFC8305] non-normatively describes success at a connection attempt as "generally when the TCP handshake completes". There is no normative definition of a connection in the AMT @@ -492,21 +492,21 @@ 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. 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 + provided by considering a sender that 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. @@ -605,38 +605,38 @@ guidelines to operators and implementors working with AMT systems that can use DRIAD as part of the relay discovery process. 2.5.2. Updates to Restarting Events Section 5.2.3.4.1 of [RFC7450] lists several events that may cause a gateway to start or restart the discovery procedure. This document provides some updates and recommendations regarding the handling of these and similar events. The first 5 events are copied - here and numbered for easier reference, and the following events are - newly added for consideration in this document: + here and numbered for easier reference, and the remaining 4 events + are newly added for consideration in this document: 1. When a gateway pseudo-interface is started (enabled). 2. When the gateway wishes to report a group subscription when none currently exist. 3. Before sending the next Request message in a membership update cycle. 4. After the gateway fails to receive a response to a Request message. 5. After the gateway receives a Membership Query message with the L 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 subscriptions. 7. When there is a network change detected, for example when a gateway is operating inside an end user device or application, and the device joins a different network, or when the domain portion of a DNS-SD domain name changes in response to a DHCP message or administrative configuration. 8. When congestion or substantial loss is detected in the stream of @@ -650,22 +650,22 @@ 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 have sufficient information to use DRIAD, since no source is known. 2.5.3. Tunnel Stability In general, subscribers to active traffic flows that are being forwarded by an AMT gateway are less likely to experience a degradation in service (for example, from missing or duplicated - packets) when the gateway continues using the same relay, as long the - relay is not overloaded and the network conditions remain stable. + packets) when the gateway continues using the same relay, as long as + the relay is not overloaded and the network conditions remain stable. Therefore, gateways SHOULD avoid performing a full restart of the discovery process during routine cases of event #3 (sending a new 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 more information about exceptional cases when it may be appropriate to use event #3. 2.5.4. Traffic Health @@ -789,21 +789,21 @@ a disruption in the forwarded traffic by sending such Relay Discovery 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 + SHOULD NOT be considered a full restart of the relay discovery 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 @@ -1287,22 +1287,22 @@ that don't follow UDP congestion control principles, or deliberate attack. 7. Acknowledgements This specification was inspired by the previous work of Doug Nortz, Robert Sayko, David Segelstein, and Percy Tarapore, presented in the MBONED working group at IETF 93. Thanks to Jeff Goldsmith, Toerless Eckert, Mikael Abrahamsson, Lenny - Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, and Ben Kaduk for - their very helpful comments. + Giuliano, Mark Andrews, Sandy Zheng, Kyle Rose, Ben Kaduk, and Bill + Atwood for their very helpful comments. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and