< draft-ietf-mboned-driad-amt-discovery-07.txt   draft-ietf-mboned-driad-amt-discovery-08.txt >
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Updates: 7450 (if approved) June 13, 2019 Updates: 7450 (if approved) June 14, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: December 15, 2019 Expires: December 16, 2019
DNS Reverse IP AMT Discovery DNS Reverse IP AMT Discovery
draft-ietf-mboned-driad-amt-discovery-07 draft-ietf-mboned-driad-amt-discovery-08
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 December 15, 2019. This Internet-Draft will expire on December 16, 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 2, line 34 skipping to change at page 2, line 34
2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13 2.4.3. Connecting to Multiple Relays . . . . . . . . . . . . 13
2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13 2.5. Guidelines for Restarting Discovery . . . . . . . . . . . 13
2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13 2.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14 2.5.2. Updates to Restarting Events . . . . . . . . . . . . 14
2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15 2.5.3. Tunnel Stability . . . . . . . . . . . . . . . . . . 15
2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15 2.5.4. Traffic Health . . . . . . . . . . . . . . . . . . . 15
2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17 2.5.5. Relay Loaded or Shutting Down . . . . . . . . . . . . 17
2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17 2.5.6. Relay Discovery Messages vs. Restarting Discovery . . 17
2.5.7. Independent Discovery Per Traffic Source . . . . . . 18 2.5.7. Independent Discovery Per Traffic Source . . . . . . 18
2.6. DNS Configuration . . . . . . . . . . . . . . . . . . . . 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. Example Deployments . . . . . . . . . . . . . . . . . . . . . 19
3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19 3.1. Example Receiving Networks . . . . . . . . . . . . . . . 19
3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19 3.1.1. Tier 3 ISP . . . . . . . . . . . . . . . . . . . . . 19
3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20 3.1.2. Small Office . . . . . . . . . . . . . . . . . . . . 20
3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22 3.2. Example Sending Networks . . . . . . . . . . . . . . . . 22
3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22 3.2.1. Sender-controlled Relays . . . . . . . . . . . . . . 22
3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23 3.2.2. Provider-controlled Relays . . . . . . . . . . . . . 23
4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24 4. AMTRELAY Resource Record Definition . . . . . . . . . . . . . 24
4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24 4.1. AMTRELAY RRType . . . . . . . . . . . . . . . . . . . . . 24
4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24 4.2. AMTRELAY RData Format . . . . . . . . . . . . . . . . . . 24
skipping to change at page 12, line 46 skipping to change at page 12, line 46
The gateway MAY introduce a bias in the non-deterministic choice The gateway MAY introduce a bias in the non-deterministic choice
according to information obtained out of band or from a historical according to information obtained out of band or from a historical
record about network topology, timing information, or the response to record about network topology, timing information, or the response to
a probing mechanism, that indicates some expected benefits from a probing mechanism, that indicates some expected benefits from
selecting some relays in preference to others. Details about the selecting some relays in preference to others. Details about the
structure and collection of this information are out of scope for structure and collection of this information are out of scope for
this document, but a gateway in possession of such information MAY this document, but a gateway in possession of such information MAY
use it to prefer topologically closer relays. 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 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
of [RFC8305] for successively launched concurrent connection of [RFC8305] for successively launched concurrent connection
attempts. attempts.
skipping to change at page 17, line 26 skipping to change at page 17, line 26
NOT be considered for the relay selection. NOT be considered for the relay selection.
It is also RECOMMENDED that gateways avoid choosing a relay that has It is also RECOMMENDED that gateways avoid choosing a relay that has
recently sent an L flag, with approximately a 10-minute hold-down. 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 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 hold-down in Section 2.5.4.1, so that the relay is removed from
consideration for short-term subsequent rounds of discovery. consideration for short-term subsequent rounds of discovery.
2.5.6. Relay Discovery Messages vs. Restarting Discovery 2.5.6. Relay Discovery Messages vs. Restarting Discovery
A gateway should only send DNS queries with the AMTRELAY RRType or All AMT relays are required by [RFC7450] to support handling of Relay
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
Discovery messages (e.g. in Section 5.3.3.2 of [RFC7450]). 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 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 Discovery message to the unicast address of that AMT relay. Under
stable conditions with an unloaded relay, it's expected that the stable conditions with an unloaded relay, it's expected that the
relay will return its own unicast address in the Relay Advertisement, relay will return its own unicast address in the Relay Advertisement,
in response to such a Relay Discovery message. Since this will not in response to such a Relay Discovery message. Since this will not
result in the gateway changing to another relay unless the relay result in the gateway changing to another relay unless the relay
directs the gateway away, this is a reasonable exception to the directs the gateway away, this is a reasonable exception to the
advice against handling event #3 described in Section 2.5.3. advice against handling event #3 described in Section 2.5.3.
skipping to change at page 18, line 8 skipping to change at page 18, line 4
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
address, as described in Section 4.1.2.1 of [RFC7450]. address, as described in Section 4.1.2.1 of [RFC7450].
 End of changes. 8 change blocks. 
12 lines changed or deleted 8 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/