Re: DRIAD Follow-up: Toerless's mic comments

Hi mboned,

Hearing no objections, I went ahead and made the proposed changes,
and have uploaded the latest proposed version of the DRIAD draft.

https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-03

As discussed in Prague, I'd like to request that the chairs start a
working group last call with this version.

Thanks again to everyone who read the draft and especially to those
who commented.

Cheers,
Jake

On 2019-04-01, 17:40, "Holland, Jake" <[email protected]> wrote:

    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
    

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