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

On Thu, 25 Apr 2019, Holland, Jake wrote:

| On 2019-04-25, 11:59, "Leonard Giuliano" <[email protected]> wrote:
| 
|     
|     The scenario you describe does make most sense for the local SP to use the 
|     global anycast address for their relays.  But consider another scenario:
|     
|     -local ISP does not use global anycast
|     -relays are available via DRIAD
|     -somewhere in the far reaches of the Internet there is someone advertising 
|     the global anycast address in an attempt to blackhole AMT (or maybe they 
|     just have a low capacity/impaired relay)
|     
|     Or would this scenario be resolved by 2.5.4?
| 
| [JH] Yes, I expect this scenario would be resolved by 2.5.4.
|     
|     If not, then global anycast is good if your local SP is using it, but 
|     potentially bad if it's a non-local SP advertising it.  And there's no way 
|     to really know if they are local or not.  Hence my suggestion to make 
|     local relays #2 before DRIAD, but leave it up to the local SP/apps/future 
|     smarter engineers to decide if they should or shouldn't use the global 
|     address.
| 
| [JH] I agree "local" is the goal.
| 
| DNS-SD is already an attempt to discover "local", and the global anycast suggestion
| is meant as a sort of fallback for "local" if DNS-SD fails, and the choice of global
| anycast in particular is just an attempt to make it normalized enough that ISPs can
| bet on it working.
|     
|     Another option is to punt, and just mention all the options with no 
|     order of pref, or suggest the order as RECOMMENDED/MAY, so there's 
|     guidance with flexibility to do something else if the need arises.  Just 
|     seems premature to mandate an order now before we have tons of operational 
|     experience and are guessing what things could be like in the future.
| 
| [JH] Yes, this is what I was trying to do in my earlier iteration of 2.4.2, basically.
| I added a clear list because you complained it wasn't clear enough. :)
| 
| That said, I think this kind of punt is still what this section is doing, really.
| 
| Please note that the current list in -04 is only a "SHOULD by default", so I think
| this is already guidance with flexibility if the need arises, as I think you just
| suggested.

OK, then ignore my first suggestion and go with my second one :)  Or 
rather, perhaps a clear list with SHOULD for the order along with an 
explanation/rationale for the order and some flexibility for future apps.


| 
|     
|     On Tue, 23 Apr 2019, Holland, Jake wrote:
|     
|     | 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