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

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.

    
    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