Subject: [MBONED] WGLC for draft-ietf-mboned-driad-amt-discovery

From: Leonard Giuliano <[email-masked]>
Date: Fri, 12 Apr 2019 13:02:03 -0700

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/

---

From: "Holland, Jake" <[email-masked]>
Date: Fri, 12 Apr 2019 20:15:20 +0000

Thanks Lenny.

I don't know of any IPR for this draft.

-Jake

On 2019-04-12, 13:02, "Leonard Giuliano" <lenny=[email-masked]> wrote:

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

---

From: Leonard Giuliano <[email-masked]>
Date: Mon, 15 Apr 2019 09:10:08 -0700

<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/
|

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 15 Apr 2019 23:06:25 +0000

Thanks Lenny, much appreciated.  <jh>Responses inline.</jh>

On 2019-04-15, 09:10, "Leonard Giuliano" <lenny=[email-masked]> wrote:

    <chair hat off>

<jh>
I'm not completely sure what you mean by "3-way handshake" here, but I'm assuming
you mean the one mentioned in RFC 7450, particularly sections 5.1.3 and 5.1.4:
https://tools.ietf.org/html/rfc7450#section-5.1.3
https://tools.ietf.org/html/rfc7450#section-5.1.4

The definition in section 2.3.2 of this draft calls the connection complete
during the 2nd part of this 3-way handshake, which is receipt of the Membership
Query message.  (Since we're talking about a gateway-side decision, I don't
think there's anything the client knows about after the 3rd part of the handshake,
before starting to receive data traffic.)

I agree with you that it would be nice to have information about multicast
connectivity to the source, but I don't think this can be safely discovered when
probing connectivity of multiple connections in parallel (as described by the
Happy Eyeballs part), because if we actually forward the subscription to
one or more (S,G)s to multiple relays, we might start getting traffic from all
of them, and that traffic might be larger than we should receive, or could
result in forwarding multiple copies of packets routinely, if an implementation
doesn't take specific steps to avoid it.

Therefore, the way this doc handles it is to allow multiple connections to
start in parallel up until receiving the Membership Query (which is stage 2 of
the 3-way handshake), and then to pick the most preferred of those connections
to get the Membership Update including a subscription to data traffic, and then
after subscribing, to use the Traffic Health heuristics (section 2.5.4) to decide
whether the gateway needs to restart discovery with a hold-down for the relay that
had bad health on the traffic.

Do you think I need a reference to 2.5.4 in section 2.3.2 to make this more
clear?  Or is there a deeper objection here?
</jh>

<jh>
That sounds fine to me, my local copy is updated to add "of this document" after
the section reference and before "for further...".
</jh>

<jh>
This scenario is covered by #3.

Do you think we need a definition of "administrative configuration" in section
1.2.2 or something (and maybe "administratively" added before "configured" in
#3)?  I had assumed the concept was reasonably well understood, but  if this
wasn't clear, maybe it's not obvious enough in the text.

(Any WG opinions here on whether #3 is already clear enough on allowing this
usage?)
</jh>
    
    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)
<jh>
My presentation in Prague focused largely on why I felt the update to put the
global anycast IP before DRIAD was necessary.  For easy reference, here's a
link to the video (from 3m44s into my presentation, where I begin directly
addressing this point):
https://www.youtube.com/watch?v=jIDYHFpJYV8&t=55m44s

If that was unclear, I guess I'd like to get some more specific questions about
it?

As painful as it is to see myself speak, I re-watched that whole thing, and I
heard Toerless give some comments speaking directly to this question (to which
I responded in another thread [1]), but I think Mikael's comment was not about
this, and I didn't see any mic comments from you about this.  Were there some
other comments you meant to recall?
[1] https://mailarchive.ietf.org/arch/msg/mboned/pgw9SLTUvjSGZ4jGKDjYmyheFOA
</jh>

    1) DNS-SD
    2) DRIAD

<jh>
I like this idea, thanks, I think it will make things clearer here.

However, I don't think the ordering you've given is right.  In the absence
of administrative config, I think (pending further discussion of the above
comment) the order would look like this:

   1) DNS-SD
   2) Global Anycast (mainly to support local usage!)
   3) DRIAD

I guess one way to look at this is to just put admin config in the very front:
   0) Administrative config

However, I think in general, administrative config is also capable of doing
things like suppressing one or more of these steps, or changing the ordering
of these steps, or adding other steps that take account of other information
about the network to influence ordering.

In that sense, I'm not sure just sticking "administrative config" on the front
of the list makes as much sense as keeping it outside this list, in order to be
a super-override for the list as a whole.

So my proposed update to incorporate your excellent suggestion for making a
numbered short summary list for easy reference is to make this change:

OLD:
   Accordingly, AMT gateways SHOULD by default prefer relays first by
   DNS-SD if available, then with the anycast addresses defined in
   Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by
   DRIAD as described in this document (in precedence order, as
   described in Section 4.2.1).

   This default behavior MAY be overridden by administrative
   configuration where other behavior is more appropriate for the
   gateway within its network.

NEW:
   Accordingly, AMT gateways SHOULD by default prefer relays in this
   order:

      1. DNS-SD
      2. Anycast addresses from Section 7 of [RFC7450]
      3. DRIAD

   This default behavior MAY be overridden by administrative
   configuration where other behavior is more appropriate for the
   gateway within its network.

Additionally, I'll remove the numbers on the long-form explanations
above this piece in 2.4.2, since I think multiple different numbering
schemes in the same section would add confusion.

If you think it's better, I could also put this in front of the big
explanations, take out "Accordingly, ", and add in something like "the
reasoning for this preference ordering is described below".  That's not
done in my local copy, but if I get responses with "yes, that's better"
here I'm happy to make the change.  Whatever's most clear would be great.

(Or if that doesn't address your concerns, can you suggest some text that
would, which takes into account the above considerations?  Thanks.)
</jh>
    
<jh>
Fixed locally, thanks.
</jh>

<jh>
I like this idea, and I agree it's a good concept to get into the doc somewhere.
I think it works well as a heuristic that should be mentioned somewhere.

I think recommending ping specifically is a bad idea (it's not so clear that the
ICMP path RTT will be the same as the UDP path RTT), though I guess it's maybe
reasonable in a lot of places.  RTT of the response between sending the Request
packet and receiving the Membership Query packet (plus history of that metric
when it's known) sounds like a better approach in general, so I guess if we're
putting something in about this, I'd like it to capture that usage, or I'd at
least prefer to avoid a mention of ping in particular as compared with other
measurements.

What do you think of a change in section 2.4.2 to integrate this suggestion?
Would this cover what you're looking for?

OLD:
   Among relay addresses that still have an equivalent preference after
   the above orderings, a gateway MUST make a non-deterministic choice
   for relay preference ordering, in order to support load balancing by
   DNS configurations that provide many relay options.  (Note that
   gateways not implementing a Happy Eyeballs algorithm are not required
   to use the Destination Address Selection ordering, but are still
   required to use non-deterministic ordering among equally preferred
   relays.)

NEW:
   Among relay addresses that still have an equivalent preference after
   the above orderings, a gateway MUST make a non-deterministic choice
   for relay preference ordering, in order to support load balancing by
   DNS configurations that provide many relay options.

   The gateway MAY introduce a bias in the non-deterministic choice
   according to network topology or timing information obtained out of
   band or from a historical record.  The collection of this information
   is out of scope for this document, but a gateway in possession of
   such information MAY use it to prefer topologically closer relays.

(This suggestion also cuts out what I think having re-read this bit is
probably a useless side note that happens to be in the same spot, but if
somebody doesn't like the edit, please let me know as a separate point.)
</jh>

<jh>
Thanks very much for your comments, and please anyone feel free to jump
in here with opinions and responses.

Best regards,
Jake
</jh>    

    |

---

From: <[email-masked]>
Date: Tue, 16 Apr 2019 08:35:02 +0800 (CST)

Support the advancement of this draft.

Thanks,

Sandy

原始邮件

发件人：LeonardGiuliano <lenny=[email-masked]>
收件人：MBONED WG <[email-masked]>;
日 期 ：2019年04月13日 04:02
主 题 ：[MBONED] WGLC for draft-ietf-mboned-driad-amt-discovery

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 16 Apr 2019 10:07:34 +0200 (CEST)

On Fri, 12 Apr 2019, Leonard Giuliano wrote:

> 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).
>

I think this draft is useful and I support its publication. I have read 
the 02 / 03 diff and I previously read 02 and found it to be in good shape 
already.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mike McBride <[email-masked]>
Date: Thu, 18 Apr 2019 08:49:12 -0700

Support.

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 22 Apr 2019 23:20:37 +0000

Hi Lenny,

I went ahead and submitted the changes I had text for.
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-04

Thanks for the latest round of comments, I think they resulted in an improved
doc.  Please let me know if there's other changes you think are still necessary
or that would be helpful, or if I've misunderstood any of the concerns you raised.

Best regards,
Jake

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 23 Apr 2019 12:32:03 -0700

Jake- sorry for the delayed reply, took some time to fully digest.
Comments inline, and let me know if you already covered this in the 
lastest version:

On Mon, 15 Apr 2019, Holland, Jake wrote:

| Thanks Lenny, much appreciated.  <jh>Responses inline.</jh>
| 
| On 2019-04-15, 09:10, "Leonard Giuliano" <lenny=[email-masked]> wrote:
| 
|     
|     <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?
| 
| <jh>
| I'm not completely sure what you mean by "3-way handshake" here, but I'm assuming
| you mean the one mentioned in RFC 7450, particularly sections 5.1.3 and 5.1.4:
| https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7450-23section-2D5.1.3&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=GnlMUunygK9RB-Dv7QFmxyc6Mk8ZVbhA6DdDeV4slPA&e=
| https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7450-23section-2D5.1.4&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=9Z1ODsciEKqfCyQy8UvMrp9JOlQ8M2MzuTOAut8dee4&e=
| 
| The definition in section 2.3.2 of this draft calls the connection complete
| during the 2nd part of this 3-way handshake, which is receipt of the Membership
| Query message.  (Since we're talking about a gateway-side decision, I don't
| think there's anything the client knows about after the 3rd part of the handshake,
| before starting to receive data traffic.)
| 
| I agree with you that it would be nice to have information about multicast
| connectivity to the source, but I don't think this can be safely discovered when
| probing connectivity of multiple connections in parallel (as described by the
| Happy Eyeballs part), because if we actually forward the subscription to
| one or more (S,G)s to multiple relays, we might start getting traffic from all
| of them, and that traffic might be larger than we should receive, or could
| result in forwarding multiple copies of packets routinely, if an implementation
| doesn't take specific steps to avoid it.
| 
| Therefore, the way this doc handles it is to allow multiple connections to
| start in parallel up until receiving the Membership Query (which is stage 2 of
| the 3-way handshake), and then to pick the most preferred of those connections
| to get the Membership Update including a subscription to data traffic, and then
| after subscribing, to use the Traffic Health heuristics (section 2.5.4) to decide
| whether the gateway needs to restart discovery with a hold-down for the relay that
| had bad health on the traffic.
| 
| Do you think I need a reference to 2.5.4 in section 2.3.2 to make this more
| clear?  Or is there a deeper objection here?

Yeah, I think that would be helpful, as I didn't quite get that 
connection.  Again, I'm concerned with the case where the AMT tunnel comes 
up but the relay lacks multicast connectivity to the source, which I 
suspect will not be an uncommon case.  As you've worded above- probe the 
relays til you get a good session, then join, then pick another relay if 
you get no data, sounds reasonable to me.  I think making that clear in 
2.3.2 would be helpful.

| </jh>
|     
|     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).
| 
| <jh>
| That sounds fine to me, my local copy is updated to add "of this document" after
| the section reference and before "for further...".
| </jh>
|     
|     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?
| 
| <jh>
| This scenario is covered by #3.
| 
| Do you think we need a definition of "administrative configuration" in section
| 1.2.2 or something (and maybe "administratively" added before "configured" in
| #3)?  I had assumed the concept was reasonably well understood, but  if this
| wasn't clear, maybe it's not obvious enough in the text.
| 
| (Any WG opinions here on whether #3 is already clear enough on allowing this
| usage?)

OK, re-reading, I'm convinced #3 is good enough to get this idea across, 
though if others have an opinion, please speak up.

| </jh>
|     
|     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)
| <jh>
| My presentation in Prague focused largely on why I felt the update to put the
| global anycast IP before DRIAD was necessary.  For easy reference, here's a
| link to the video (from 3m44s into my presentation, where I begin directly
| addressing this point):
| https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DjIDYHFpJYV8-26t-3D55m44s&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=UUvXd2wmB1kONtQbcaewEPwiIY3HFmclRqqq4S_ruBo&e=
| 
| If that was unclear, I guess I'd like to get some more specific questions about
| it?
| 
| As painful as it is to see myself speak, I re-watched that whole thing, and I
| heard Toerless give some comments speaking directly to this question (to which
| I responded in another thread [1]), but I think Mikael's comment was not about
| this, and I didn't see any mic comments from you about this.  Were there some
| other comments you meant to recall?
| [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_mboned_pgw9SLTUvjSGZ4jGKDjYmyheFOA&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=rUqinpiSDianQ6D3sbqDY4e0VquYNevgB61tr3kPxeY&e=

In the same video (mboned mtg recording), I talked about this at 1:23:20 
till ~ 1:26:00 and then Mikael confirmed my suspicions that it was a bad 
idea at 1:31:20.  Bottom line is Global Anycast is a backhole waiting to 
happen, so I don't think it'll be a viable deployment option.  Now, local 
relays using anycast addresses from a provider's space, such that each AMT 
provider will have it's own anycast set (analogous to anycast RPs), does 
seem like it'll be a good deployment option.

| </jh>
|     
|     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
| 
| <jh>
| I like this idea, thanks, I think it will make things clearer here.
| 
| However, I don't think the ordering you've given is right.  In the absence
| of administrative config, I think (pending further discussion of the above
| comment) the order would look like this:
| 
|    1) DNS-SD
|    2) Global Anycast (mainly to support local usage!)
|    3) DRIAD
| 
| I guess one way to look at this is to just put admin config in the very front:
|    0) Administrative config
| 
| However, I think in general, administrative config is also capable of doing
| things like suppressing one or more of these steps, or changing the ordering
| of these steps, or adding other steps that take account of other information
| about the network to influence ordering.
| 
| In that sense, I'm not sure just sticking "administrative config" on the front
| of the list makes as much sense as keeping it outside this list, in order to be
| a super-override for the list as a whole.
| 
| So my proposed update to incorporate your excellent suggestion for making a
| numbered short summary list for easy reference is to make this change:
| 
| OLD:
|    Accordingly, AMT gateways SHOULD by default prefer relays first by
|    DNS-SD if available, then with the anycast addresses defined in
|    Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by
|    DRIAD as described in this document (in precedence order, as
|    described in Section 4.2.1).
| 
|    This default behavior MAY be overridden by administrative
|    configuration where other behavior is more appropriate for the
|    gateway within its network.
| 
| NEW:
|    Accordingly, AMT gateways SHOULD by default prefer relays in this
|    order:
| 
|       1. DNS-SD
|       2. Anycast addresses from Section 7 of [RFC7450]
|       3. DRIAD
| 
|    This default behavior MAY be overridden by administrative
|    configuration where other behavior is more appropriate for the
|    gateway within its network.
| 
| Additionally, I'll remove the numbers on the long-form explanations
| above this piece in 2.4.2, since I think multiple different numbering
| schemes in the same section would add confusion.
| 
| If you think it's better, I could also put this in front of the big
| explanations, take out "Accordingly, ", and add in something like "the
| reasoning for this preference ordering is described below".  That's not
| done in my local copy, but if I get responses with "yes, that's better"
| here I'm happy to make the change.  Whatever's most clear would be great.
| 
| (Or if that doesn't address your concerns, can you suggest some text that
| would, which takes into account the above considerations?  Thanks.)

OK, what you suggest for the admin config sounds reasonable and does 
provide ample wiggle room for flexibility.  I am still a bit nervous about 
having Global Anycast, a mechanism so fraught with peril, ahead of DRIAD, 
though I do understand your pref for local relays.  What if you mentioned 
something like "#2 Locally deployed relays in the receiver's ISP, which 
may (or may not) utilize the Anycast addresses from Section 7 of 
[RFC7450]"?  Or must it use the global anycast addresses?

And having a simple numbered list with explanations for each, and perhaps 
rationalization for the order, sounds like agood approach.

| </jh>
|     
|     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”
| <jh>
| Fixed locally, thanks.
| </jh>
|     
|     
|     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?
| <jh>
| I like this idea, and I agree it's a good concept to get into the doc somewhere.
| I think it works well as a heuristic that should be mentioned somewhere.
| 
| I think recommending ping specifically is a bad idea (it's not so clear that the
| ICMP path RTT will be the same as the UDP path RTT), though I guess it's maybe
| reasonable in a lot of places.  RTT of the response between sending the Request
| packet and receiving the Membership Query packet (plus history of that metric
| when it's known) sounds like a better approach in general, so I guess if we're
| putting something in about this, I'd like it to capture that usage, or I'd at
| least prefer to avoid a mention of ping in particular as compared with other
| measurements.
| 
| What do you think of a change in section 2.4.2 to integrate this suggestion?
| Would this cover what you're looking for?
| 
| OLD:
|    Among relay addresses that still have an equivalent preference after
|    the above orderings, a gateway MUST make a non-deterministic choice
|    for relay preference ordering, in order to support load balancing by
|    DNS configurations that provide many relay options.  (Note that
|    gateways not implementing a Happy Eyeballs algorithm are not required
|    to use the Destination Address Selection ordering, but are still
|    required to use non-deterministic ordering among equally preferred
|    relays.)
| 
| NEW:
|    Among relay addresses that still have an equivalent preference after
|    the above orderings, a gateway MUST make a non-deterministic choice
|    for relay preference ordering, in order to support load balancing by
|    DNS configurations that provide many relay options.
| 
|    The gateway MAY introduce a bias in the non-deterministic choice
|    according to network topology or timing information obtained out of
|    band or from a historical record.  The collection of this information
|    is out of scope for this document, but a gateway in possession of
|    such information MAY use it to prefer topologically closer relays.

How about "... according to network topology or response to some sort of 
probing mechanism obtained ..."?

| 
| (This suggestion also cuts out what I think having re-read this bit is
| probably a useless side note that happens to be in the same spot, but if
| somebody doesn't like the edit, please let me know as a separate point.)
| </jh>
| 
| <jh>
| Thanks very much for your comments, and please anyone feel free to jump
| in here with opinions and responses.
| 
| Best regards,
| Jake
| </jh>    
|     
|     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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dmboned-2Ddriad-2Damt-2Ddiscovery_&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=bdXOvMCVQ0eopeNSHcSHJLpx0E8A_abVYFeOYvbtwVw&e=
|     | 
|     
|     _______________________________________________
|     MBONED mailing list
|     [email-masked]
|     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mboned&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=cfmFRgGtQ5R5k-SgsRnt8-P5lkvvJ_5apkUetxJjkm0&e=
|     
| 
|

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 23 Apr 2019 21:06:14 +0000

<jh2>replies inline, and thanks Lenny!</jh2>

On 2019-04-23, 12:32, "Leonard Giuliano" <[email-masked]> wrote:
    Jake- sorry for the delayed reply, took some time to fully digest.
    Comments inline, and let me know if you already covered this in the 
    lastest version:

    
<jh2>
Does this work for you?

OLD:
   See Section 2.5.5 of this document for further information about the
   relevance of the L flag to the establishment of a Happy Eyeballs
   connection.

NEW:
   See Section 2.5.5 of this document for further information about the
   relevance of the L flag to the establishment of a Happy Eyeballs
   connection.  See Section 2.5.4 for an overview of how to respond if
   the connection does not provide multicast connectivity to the source.
</jh2>

<jh2>
Ah, I see.  Thanks for pointing me there, now I remember.

Yes, I agree global anycast is a blackhole waiting to happen, and won't
see wide deployment until at least after there's a way to do good brokering
somehow.

What I'm trying to suggest here is that if you're an ISP providing multicast
connectivity, and you're deploying a relay near the end user edge, you can put
the global anycast address on that AMT relay and expect it to be discovered by
gateways inside your customers' networks.*  (I think you've got that picture,
just wanted to check to make sure.)

In the case when the ISP isn't supporting multicast and hasn't deployed a relay,
this means the gateway will try to discover the global anycast, hopefully in parallel
with the DRIAD discovery, with a slight head start (under the happy eyeballs logic).

But yes, if it gets a response from the global anycast about the discovery, it'll use
that by preference under the latest proposal, maybe discover it's a black hole, and
then fail over to the DRIAD version according to 2.5.5.

Do I understand correctly that this 2nd case is what you're most concerned about
with the preference ordering that puts the global anycast ahead of DRIAD?

I agree that this can also be solved by administrative configuration, so that ISPs
operating a relay local to their customers can tell their customers to configure a
particular address or hostname on their gateways.

However, by specifying that gateways should search for one particular thing (such as
the existing anycast address), we can hopefully make it possible for the ISPs to deploy
a relay without having to get all their customers to configure their gateways, even
where DNS-SD doesn't work (which I think is up to the router in the customer network,
which the ISP might not control).

I see this as especially important for ISPs with customers that may have a lot of
mobile devices coming and going, with wifi hotspots or something, because you can't
get those devices to configure the gateway, so if the ISP can't capture the joins
when the customer network isn't operating its own local AMT relay, the ISP can't
really get those devices to make use of its multicast-enabled network instead of
discovering their own unicast tunnels.
</jh2>

    | </jh>
    |     
...

<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.

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?

I think this is allowed already with happy eyeballs--the gateway would have to
give the global anycast a particular minimum head start, but I think if the
connection finishes with DRIAD first, that could be used.  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?
</jh2>

    | NEW:
...
    
    How about "... according to network topology or response to some sort of 
    probing mechanism obtained ..."?
<jh2>
I like adding "probing mechanism", thanks.  Do you object to keeping "timing
information"?  I'm thinking maybe a minor refinement here to make a bigger list
work better:

NEW:
"
... according to information obtained out of band or from a historical
record about network topology, timing information, or the response to a
probing mechanism, that indicates some expected benefits from selecting
some relays in preference to others.  Details about the structure and
collection of this information is out of scope for this document, but a
gateway in possession of such information MAY use it to prefer
topologically closer relays.
"

(suggestions welcome on tightening that up, but I prefer to keep timing
information if possible.)
</jh2>

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 23 Apr 2019 14:24:05 -0700

On Tue, 23 Apr 2019, Holland, Jake wrote:

| <jh2>replies inline, and thanks Lenny!</jh2>
| 
| On 2019-04-23, 12:32, "Leonard Giuliano" <[email-masked]> wrote:
|     Jake- sorry for the delayed reply, took some time to fully digest.
|     Comments inline, and let me know if you already covered this in the 
|     lastest version:
|     
|     On Mon, 15 Apr 2019, Holland, Jake wrote:
|     
|     | Thanks Lenny, much appreciated.  <jh>Responses inline.</jh>
|     | 
|     | On 2019-04-15, 09:10, "Leonard Giuliano" <lenny=[email-masked]> wrote:
|     | 
|     |     
|     |     <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?
|     | 
|     | <jh>
|     | I'm not completely sure what you mean by "3-way handshake" here, but I'm assuming
|     | you mean the one mentioned in RFC 7450, particularly sections 5.1.3 and 5.1.4:
|     | https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7450-23section-2D5.1.3&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=GnlMUunygK9RB-Dv7QFmxyc6Mk8ZVbhA6DdDeV4slPA&e=
|     | https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7450-23section-2D5.1.4&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=5B2Q9Qi_7Vs-C0IJQ8m6_1mazviWrkJeBlTCBKB5rvs&s=9Z1ODsciEKqfCyQy8UvMrp9JOlQ8M2MzuTOAut8dee4&e=
|     | 
|     | The definition in section 2.3.2 of this draft calls the connection complete
|     | during the 2nd part of this 3-way handshake, which is receipt of the Membership
|     | Query message.  (Since we're talking about a gateway-side decision, I don't
|     | think there's anything the client knows about after the 3rd part of the handshake,
|     | before starting to receive data traffic.)
|     | 
|     | I agree with you that it would be nice to have information about multicast
|     | connectivity to the source, but I don't think this can be safely discovered when
|     | probing connectivity of multiple connections in parallel (as described by the
|     | Happy Eyeballs part), because if we actually forward the subscription to
|     | one or more (S,G)s to multiple relays, we might start getting traffic from all
|     | of them, and that traffic might be larger than we should receive, or could
|     | result in forwarding multiple copies of packets routinely, if an implementation
|     | doesn't take specific steps to avoid it.
|     | 
|     | Therefore, the way this doc handles it is to allow multiple connections to
|     | start in parallel up until receiving the Membership Query (which is stage 2 of
|     | the 3-way handshake), and then to pick the most preferred of those connections
|     | to get the Membership Update including a subscription to data traffic, and then
|     | after subscribing, to use the Traffic Health heuristics (section 2.5.4) to decide
|     | whether the gateway needs to restart discovery with a hold-down for the relay that
|     | had bad health on the traffic.
|     | 
|     | Do you think I need a reference to 2.5.4 in section 2.3.2 to make this more
|     | clear?  Or is there a deeper objection here?
|     
|     Yeah, I think that would be helpful, as I didn't quite get that 
|     connection.  Again, I'm concerned with the case where the AMT tunnel comes 
|     up but the relay lacks multicast connectivity to the source, which I 
|     suspect will not be an uncommon case.  As you've worded above- probe the 
|     relays til you get a good session, then join, then pick another relay if 
|     you get no data, sounds reasonable to me.  I think making that clear in 
|     2.3.2 would be helpful.
| <jh2>
| Does this work for you?
| 
| OLD:
|    See Section 2.5.5 of this document for further information about the
|    relevance of the L flag to the establishment of a Happy Eyeballs
|    connection.
| 
| NEW:
|    See Section 2.5.5 of this document for further information about the
|    relevance of the L flag to the establishment of a Happy Eyeballs
|    connection.  See Section 2.5.4 for an overview of how to respond if
|    the connection does not provide multicast connectivity to the source.
| </jh2>

Looks good.

|         
|     In the same video (mboned mtg recording), I talked about this at 1:23:20 
|     till ~ 1:26:00 and then Mikael confirmed my suspicions that it was a bad 
|     idea at 1:31:20.  Bottom line is Global Anycast is a backhole waiting to 
|     happen, so I don't think it'll be a viable deployment option.  Now, local 
|     relays using anycast addresses from a provider's space, such that each AMT 
|     provider will have it's own anycast set (analogous to anycast RPs), does 
|     seem like it'll be a good deployment option.
|     
| <jh2>
| Ah, I see.  Thanks for pointing me there, now I remember.
| 
| Yes, I agree global anycast is a blackhole waiting to happen, and won't
| see wide deployment until at least after there's a way to do good brokering
| somehow.
| 
| What I'm trying to suggest here is that if you're an ISP providing multicast
| connectivity, and you're deploying a relay near the end user edge, you can put
| the global anycast address on that AMT relay and expect it to be discovered by
| gateways inside your customers' networks.*  (I think you've got that picture,
| just wanted to check to make sure.)
| 
| In the case when the ISP isn't supporting multicast and hasn't deployed a relay,
| this means the gateway will try to discover the global anycast, hopefully in parallel
| with the DRIAD discovery, with a slight head start (under the happy eyeballs logic).
| 
| But yes, if it gets a response from the global anycast about the discovery, it'll use
| that by preference under the latest proposal, maybe discover it's a black hole, and
| then fail over to the DRIAD version according to 2.5.5.
| 
| Do I understand correctly that this 2nd case is what you're most concerned about
| with the preference ordering that puts the global anycast ahead of DRIAD?

Yes, I would put DRIAD ahead of global anycast, but also that local relays 
should be preferred ahead of DRIAD.  And yes, I recognize the potential 
contradiction/tension here.  See below for suggested resolution...

| 
| I agree that this can also be solved by administrative configuration, so that ISPs
| operating a relay local to their customers can tell their customers to configure a
| particular address or hostname on their gateways.
| 
| However, by specifying that gateways should search for one particular thing (such as
| the existing anycast address), we can hopefully make it possible for the ISPs to deploy
| a relay without having to get all their customers to configure their gateways, even
| where DNS-SD doesn't work (which I think is up to the router in the customer network,
| which the ISP might not control).
| 
| I see this as especially important for ISPs with customers that may have a lot of
| mobile devices coming and going, with wifi hotspots or something, because you can't
| get those devices to configure the gateway, so if the ISP can't capture the joins
| when the customer network isn't operating its own local AMT relay, the ISP can't
| really get those devices to make use of its multicast-enabled network instead of
| discovering their own unicast tunnels.
| </jh2>
| 
|     | </jh>
|     |     
|     |     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
|     | 
|     | <jh>
|     | I like this idea, thanks, I think it will make things clearer here.
|     | 
|     | However, I don't think the ordering you've given is right.  In the absence
|     | of administrative config, I think (pending further discussion of the above
|     | comment) the order would look like this:
|     | 
|     |    1) DNS-SD
|     |    2) Global Anycast (mainly to support local usage!)
|     |    3) DRIAD
|     | 
|     | I guess one way to look at this is to just put admin config in the very front:
|     |    0) Administrative config
|     | 
|     | However, I think in general, administrative config is also capable of doing
|     | things like suppressing one or more of these steps, or changing the ordering
|     | of these steps, or adding other steps that take account of other information
|     | about the network to influence ordering.
|     | 
|     | In that sense, I'm not sure just sticking "administrative config" on the front
|     | of the list makes as much sense as keeping it outside this list, in order to be
|     | a super-override for the list as a whole.
|     | 
|     | So my proposed update to incorporate your excellent suggestion for making a
|     | numbered short summary list for easy reference is to make this change:
|     | 
|     | OLD:
|     |    Accordingly, AMT gateways SHOULD by default prefer relays first by
|     |    DNS-SD if available, then with the anycast addresses defined in
|     |    Section 7 of [RFC7450] (namely: 192.52.193.1 and 2001:3::1), then by
|     |    DRIAD as described in this document (in precedence order, as
|     |    described in Section 4.2.1).
|     | 
|     |    This default behavior MAY be overridden by administrative
|     |    configuration where other behavior is more appropriate for the
|     |    gateway within its network.
|     | 
|     | NEW:
|     |    Accordingly, AMT gateways SHOULD by default prefer relays in this
|     |    order:
|     | 
|     |       1. DNS-SD
|     |       2. Anycast addresses from Section 7 of [RFC7450]
|     |       3. DRIAD
|     | 
|     |    This default behavior MAY be overridden by administrative
|     |    configuration where other behavior is more appropriate for the
|     |    gateway within its network.
| ...
|     
|     OK, what you suggest for the admin config sounds reasonable and does 
|     provide ample wiggle room for flexibility.  I am still a bit nervous about 
|     having Global Anycast, a mechanism so fraught with peril, ahead of DRIAD, 
|     though I do understand your pref for local relays.  What if you mentioned 
|     something like "#2 Locally deployed relays in the receiver's ISP, which 
|     may (or may not) utilize the Anycast addresses from Section 7 of 
|     [RFC7450]"?  Or must it use the global anycast addresses?
| 
| <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.

| 
| 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.

| 
| I think this is allowed already with happy eyeballs--the gateway would have to
| give the global anycast a particular minimum head start, but I think if the
| connection finishes with DRIAD first, that could be used.  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?
| </jh2>
|     
|     And having a simple numbered list with explanations for each, and perhaps 
|     rationalization for the order, sounds like agood approach.
|     
|     
|     | NEW:
| ...
|     |    The gateway MAY introduce a bias in the non-deterministic choice
|     |    according to network topology or timing information obtained out of
|     |    band or from a historical record.  The collection of this information
|     |    is out of scope for this document, but a gateway in possession of
|     |    such information MAY use it to prefer topologically closer relays.
|     
|     How about "... according to network topology or response to some sort of 
|     probing mechanism obtained ..."?
| <jh2>
| I like adding "probing mechanism", thanks.  Do you object to keeping "timing
| information"?  I'm thinking maybe a minor refinement here to make a bigger list
| work better:
| 
| NEW:
| "
| ... according to information obtained out of band or from a historical
| record about network topology, timing information, or the response to a
| probing mechanism, that indicates some expected benefits from selecting
| some relays in preference to others.  Details about the structure and
| collection of this information is out of scope for this document, but a
| gateway in possession of such information MAY use it to prefer
| topologically closer relays.
| "

Looks good!

| 
| (suggestions welcome on tightening that up, but I prefer to keep timing
| information if possible.)
| </jh2>
| 
| 
|

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 23 Apr 2019 22:22:14 +0000

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-masked]> wrote:
    | <jh2>

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?

>Nah, probably too complex to rely upon.

| But maybe another

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

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 25 Apr 2019 11:59:30 -0700

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?

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.

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.

| 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-masked]> 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
| 
| 
|

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 25 Apr 2019 19:13:19 +0000

On 2019-04-25, 11:59, "Leonard Giuliano" <[email-masked]> wrote:

    

[JH] Yes, I expect this scenario would be resolved by 2.5.4.

[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.

[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.

---

From: Leonard Giuliano <[email-masked]>
Date: Thu, 25 Apr 2019 14:15:24 -0700

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

| On 2019-04-25, 11:59, "Leonard Giuliano" <[email-masked]> 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-masked]> 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
|     | 
|     | 
|     | 
|     
| 
|

---

From: "Holland, Jake" <[email-masked]>
Date: Thu, 25 Apr 2019 22:10:26 +0000

Great, that works for me, and thanks very much for the feedback.

A new version is posted, please let me know if you've got any more concerns.
https://tools.ietf.org/html/draft-ietf-mboned-driad-amt-discovery-05

-Jake

On 2019-04-25, 14:15, "Leonard Giuliano" <[email-masked]> wrote:
    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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 26 Apr 2019 11:17:00 +0200 (CEST)

On Tue, 23 Apr 2019, Holland, Jake wrote:

> 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.

I don't know if I misunderstood, but as soon as someone says "anycast 
address" I get PTSD flashbacks from 6to4:

https://tools.ietf.org/html/rfc7526

Whatever you do, don't implement a well-known anyone-can-run-relay address 
because it simply doesn't work in real life.

---

From: "Holland, Jake" <[email-masked]>
Date: Sat, 27 Apr 2019 02:07:11 +0000

Hi Mikael,

Thanks for the reference, that was interesting reading.

I think part of the problem here is that RFC 7450 already seemed to make
a well-known anyone-can-run-relay discovery address (unless maybe you read
section 4.1.4.2 the right way), and there's a concern that someone might
do that.

I don't think anything in here is meant as advice that anyone should do it.
The goal with this is to make it so the anycast address can be used for
discovery that stays local to an end receiver, and the risk is that someone
might be running one globally even though it's probably a black hole.

I don't think anyone's doing it yet, and if they do maybe we can convince
them to stop.  As long as they don't, I think this usage should be ok, and
would mean there's a check for whether there's a (hopefully local) listener
at that anycast, followed in parallel by finding the sender's relay by
reverse IP lookup, and still failing over if there is a listener but it's
a black hole (as long as the gateway follows the advice from 2.5.4 in DRIAD).

So I don't think this is meant to be asking for an implementation of a
well-known anyone-can-run-relay address.  In this draft, it's only meant for
ISPs trying to offer multicast to their nearby downstream receivers, and it's
not supposed to get propagated elsewhere.

I'm not sure what I can do about possible misinterpretations of RFC 7450, and
people who think they should run it globally.  Do you think DRIAD needs a
RECOMMEND against that?  That might not be a bad idea. 

Thanks and regards,
Jake

On 2019-04-26, 02:17, "Mikael Abrahamsson" <[email-masked]> wrote:

---

From: Leonard Giuliano <[email-masked]>
Date: Tue, 30 Apr 2019 13:03:26 -0700

The changes in th elatest version look good to me and I support advancing 
the doc.

-Lenny 

| Great, that works for me, and thanks very much for the feedback.
| 
| A new version is posted, please let me know if you've got any more concerns.
| https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmboned-2Ddriad-2Damt-2Ddiscovery-2D05&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=iw2TU3OZ0CDpCbqeV23zdah2FoG9Do-zEmGgWTaavDg&m=E8pepHUIgoLt77Af4piNBeND-5wBth6y8-2-3nenkMI&s=rh83gCrMYbSsuVmFIHanA3LbrPGreqmiZjAqUGOiZnw&e=
| 
| -Jake
| 
| On 2019-04-25, 14:15, "Leonard Giuliano" <[email-masked]> wrote:
|     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.
|  
| 
|