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

<chair hat off>

Overall, I think this doc is very thorough, clearly written and and
addresses a much needed area of specification for AMT.  Some comments:

Sect 2.3.2: should the definition of connection completion take into 
consideration traffic health as well?  That is, the relay is up and happy, 
but has no multicast connectivity to the source, hence you could have a 
blackhole.  At the very least, should it be completion of the 3-way 
handshake?

Sect 2.3.2: “See Section 2.5.5 for further …”
        -“See Section 2.5.5 of this doctment for further…” to eliminate 
confusion, as when I first read this, I wasn't sure if it was referring to 
RFCs 7450 or 8305 (turns out, neither).

Sect 2.4.1: How about #6- The application layer includes a suggested relay
address (as a hint)
        -this is what we’ve done in the VLC with AMT GW build.
Specifically, VLC has a configurable AMT relay address, which uses a
well-known FQDN (amt-relay.m2icast.net) which has multiple A records of
known, healthy relays.  Or is this scenario covered by #3?

Sect 2.4.2: I found this sect a little tough to follow.  There are 3
enumerated options, but the text that follows includes other options (like
admin config).  Also, I found it curious that you have Global Anycast so
high in the list of prefs (before DRIAD).  Global Anycast seems very
unlikely to ever be a good deployment option since it’s so vulnerable to
DoS (recall Mikael and my comments in the mtg in Prague)

Anyway, could this section just include a simple list of all the options
in order of pref?  Something like:

1) DNS-SD
2) DRIAD
3) Admin config of GW or App level
4) Global Anycast address

Sect 3.2.1: 1st para, last sentence, “… by finding a A or AAAA records..”
        -“ by finding an A or AAAA record” or “by finding A or AAAA
records”


Other Relay discovery options- as I mentioned, in the VLC build with AMT,
we have a configurable option for the relay address with a well-known fqdn
with multiple A records as the default.  It will then receive all the A
records as an ordered list and try to use one at a time until it receives
data.  This method provides relay discovery and resilience, but not
optimality.  In Prague, got a suggestion from Tom P that you could get
optimality by pinging each of the relays from the list of A records and
choosing the one with the lowest latency (or perhaps joining all relays
and then selecting the one with the healthiest stream and pruning the
others).  Do you think these options should be mentioned anywhere in this
doc?


On Fri, 12 Apr 2019, Leonard Giuliano wrote:

| 
| In Prague, there appeared to be solid support to initiate last call, so we
| would like to officially begin working group last call for
| draft-ietf-mboned-driad-amt-discovery.  Please post whether you support/oppose
| the advancement of this draft as well as any comments you may have to the list
| by May 3.  Also, please note if you are aware of any IPR involved in this
| draft (we must hear from the author about IPR).
| 
| Most recent version of the draft can be found here:
| 
| https://datatracker.ietf.org/doc/draft-ietf-mboned-driad-amt-discovery/
| 

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