Re: WGLC for draft-ietf-mboned-driad-amt-discovery

Thanks, on the 2 points you agreed, I've got the changes locally, and I think we
just have the one sticking point about the global anycast...

On 2019-04-23, 14:24, "Leonard Giuliano" <[email protected]> wrote:
    | <jh2>
    | Well, this is about the behavior of the gateways performing discovery, and I
    | wanted something that the ISP can deploy which will definitely work, when
    | DNS-SD doesn't in some places.
    | 
    | My problem is that the gateway can't easily distinguish between a local relay
    | it found with the global anycast address and a remote relay it found with the
    | global anycast address.
    
    Yeah, that's why I suggested the "may or may not use the global anycast 
    address" verbage to provide enough wiggle room one way of the other.  I 
    recognize that these are vague and imprecise terms (eg, "local" is 
    relative), but I'm thinking this early in evolution might be premature to 
    optimize on a precise solution; it's more important to document the range 
    of options for understanding and provide enough flexibility for future 
    (potentially unimagined) innovations.

I'm confused how this solves the problem for the ISP though.  Maybe I'm missing
something, can you walk through a what-if for me?

Suppose we put global anycast after DRIAD, and made the "use a local relay"
advice vague enough that the gateways don't have to use the anycast address.

Suppose there's some popular apps that get out there and start using multicast
with embedded AMT gateways, and because nothing says they should check the anycast
address and it rarely does anything, they don't use it, they just let their users
configure a domain name if they want to.

Now suppose we're an ISP that wants to deploy multicast, and we've got customers
with routers that won't propagate DNS-SD.

What do we do to get these popular apps to connect to our relays instead of opening
a tunnel to the sender's AMT relays they discovered with DRIAD?  I can only think of
2 options, and one of them doesn't work:
1. ask our customers nicely to configure the domain name for our relays.  They ignore
   us, because it mostly works for them, unless there's too much traffic (in which case
   it fails for everybody, during the most popular events).
2. block the connection to remote relays.  Now the customers will complain, and for
   those who complain, we tell them when they're inside our network, they have to
   configure our hostname for their AMT relay.

Is there another option we've got besides tell the gateways in this doc they should be
using the global anycast?



| Maybe a good solution is to explicitly allow a DRIAD relay with a shorter RTT
| to be preferred to the global anycast...  Would that cover your concerns?

>Nah, probably too complex to rely upon.

| But maybe another
| similar alternative is that if there's a recent history of failing with the
| global anycast, it could be skipped--would that work too?

OK, I agree these are too complex to rely on, but I think we're not relying on it
with either of these tweaks, I'm just trying to loosen up #2 ("thou shalt check
anycast before DRIAD") a bit, without changing its ordering.  So any gateways that
think they shouldn't have to check global anycast have a way short of "administrative
config" to justify not checking the global anycast.

What I'm going for here is "OK gateways, we know global anycast is kind of weird,
so as long as you're pretty sure the global anycast is NOT getting you to a local
relay, you can skip it, but you still have to check it sometimes to make sure."

Language suggestions welcome, if you think that's a reasonable thing to demand.

Otherwise, I'm not seeing yet how we can get away with putting DRIAD ahead of
something like global anycast, while still rolling out gateways and also giving
ISPs a way to deploy multicast the gateways will find when DNS-SD doesn't work.

-Jake


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