DRIAD Follow-up: Toerless's mic comments

Hi mboned,

Thanks to all who read the driad draft, especially those who
read it again in its latest incarnation.
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-02

I tried to transcribe Toerless's microphone comments to follow
up on the parsing of words that Greg asked for.

Here's the link to the discussion at that time, on about page 7,
if you want more context:
Video: https://www.youtube.com/watch?v=jIDYHFpJYV8&t=58m31s
Slide: https://datatracker.ietf.org/meeting/104/materials/slides-104-mboned-draft-jholland-mboned-driad-amt-discovery-00#page=7

Here's what I think was said that I didn't understand at the time:

"If they're in the same provider space it's fairly easy, right?
The AMT relay here would use an AMT tunnel but it couldn't use the
anycast address but would need to use the unicast addresses.  That's
kind of exactly what we did in MSDP."

If I'm understanding correctly, Toerless and I almost agree,
but there's one point I want to write out and check that we
agree on, because I'm not fully sure after trying to understand
the comment.  My position is thus:

When an ISP wants to provide an AMT relay at its edge, local
to end users, in order to propagate joins through its multicast-
capable network;

choice #1 is to provide a unicast address for a relay and to
provide it through the amt service with DNS-SD, inside the
ISP's search domain:

amt_.udp_.awesomeisp.com. 
		^-- points to local AMT relay operated
	by the ISP, end device will discover it with DNS-SD (RFC 6763),
	and join through here, because the ISP passed "awesomeisp.com."
	into the end network as a search domain.  This would be searched
	in addition to "local.", and any search domains added by the end
	network.

However, in the case that the ISP cannot propagate a search
domain into the end user's network, the ISP still has:

choice #2 (after writing up the proposed change), is to deploy
a local AMT relay and give it the AMT anycast address.*

I agree that if there is not multicast connectivity upstream
from the AMT relay inside the ISP, this deployment strategy
will prevent the end user's device from reaching a remote
AMT relay, if there is a remote AMT relay on the anycast
address that has multicast connectivity instead.

However, I'll argue that:

1. When an ISP is deploying this kind of local AMT relay,
they're hopefully also providing multicast access through
this relay.

2. If they're providing multicast access but not access to
the same set of streams the remote relay can forward, the
end user can still discover a remote relay with DRIAD, so
the overall discovery process still finds the content.

Does this make sense, and does it speak to the point you
were raising here Toerless?

If I've understood correctly, I think it means I should go
forward with the proposed change of moving the anycast IP
lookup preference after DNS-SD and before DRIAD.

HTH,
Jake

*: The IP is in Section 7 of RFC 7450.

By the way, I believe this deployment approach is in line with
the existing advice from RFC 7450:
https://tools.ietf.org/html/rfc7450#section-4.1.4.2

   AMT service providers are
   expected to deploy AMT relays near the provider's network border and
   its interface with edge routers.  The provider must limit relay
   address advertisements to those edges to prevent distant gateways
   from being able to access a relay and potentially generate flows that
   consume or exceed the capacity of intervening links.

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned