Subject: Re: [MBONED] draft meeting minutes Update

From: "SAYKO, ROBERT J" <[email-masked]>
Date: Tue, 5 Nov 2013 15:50:26 +0000

I spoke with my colleague David and have included his answers inline.

8. Bob: AMT Multicast Based Method for Finding Optimal Relay Gateway Combo
for AMT Tunnel:
a. Anycast Addressing Issue
b. Solution presented in Quebec
c. Two requirements for solution
d. Greg: Across network providers should have same DNS??

-------------------------------------------------------------------------------

Each network provider will have its own authoritative DNS, but they must all be reachable by the same anycast address (but see below), and they can resolve to the AMT relay of that network's choice.

-------------------------------------------------------------------------------

e. Bob: Provisioning type solution
f. Jeffrey Zhang:  Optimal relay should be closest to Gateway? Bob: Yes.
To reiterate from the network providers point of view this is generally correct.  However, as mentioned there could be policies imposed that might require providing the GW with a Relay that is not necessarily the closest in a physical sense (e.g. Relay supporting a low utilized peering point to GW's network might be a better choice).  The AMT DNS in the source network could implement this.
g. Stig: Question on DNS server lookup. All DNS servers be reachable by
same Anycast address? Why? Bob: Answer to be provided.
Specifically,  we are talking about the AMT DNS (a special set of DNS set up for this solution).   In thinking about this I think the reason an anycast would be used is because it ensures that the AMT DNS reached is closest to the GW's local DNS.  At least that is how I read my colleagues paper (having only been able to read it last week I've not been able to delve into it with him before Vancouver.   Other reasons might be consistency of the process across networks providing AMT access interdomain.   Additionally,  I think it helps if the source network is in a federation of networks that all have multicast connectivity to the source.   That is my read on it,  but as soon as I can confirm with David I will get back to you on it.   I will say that after considering the comments made I don't think it is absolutely necessary to be an anycast address - particularly in light of the fact we also say policy might dictate which AMT Relay is eventually provided to GW.

-------------------------------------------------------------------------------

The network that hosts the source is the network whose authoritative DNS will receive the recursive query from the local network's resolver DNS (since the in-addr.arpa query points to that source network).

That DNS server could conceivably determine the origin of the resolver DNS's network, based on the origin of the resolver's recursive query, and the source network's DNS server could redirect to that resolver network's authoritative DNS,

and that would thus not require all the relevant DNS servers in all coordinating provider networks to have the same anycast address.

But it is simpler if the source network's authoritative DNS has one record that redirects the query to a single anycast address.

Nevertheless, one could use the method of having separate records for each coordinating network provider, and thereby different addresses for those coordinating network provider DNS servers.

It only depends on the ability of the source network's authoritative DNS to determine the resolver DNS's network based on the original recursive query.

-------------------------------------------------------------------------------

h. Jeffrey Zhang: Best Relay for one source may not be best relay for
anther source. Bob: Answer to be provided.
This is true of course - but perhaps I misunderstood the question initially.  The problem is solved by provisioning the AMT DNS.

-------------------------------------------------------------------------------

Correct.  It depends on what provider hosts the source, and whether coordinating network providers wish to carry that source content via multicast to their own AMT relay.

-------------------------------------------------------------------------------

i. Jeffrey Haas: Same question as Stig  seems idea may be a unique
approach.
j. Karthik: How would Gateway know if no multicast connectivity? Greg:
possible.
This document does not include that in scope.  The assumption is that it can.

-------------------------------------------------------------------------------

The gateway attempts to join a stream, and the join times out.  Then it invokes the gateway functionality.

If the question is how the network local to the gateway can know if it has multicast connectivity to the source, the mechanism inherently provides a determination of its ability to have multicast connectivity to the source based on whether it hosts a DNS server that is reachable by the anycast address pointed to in the source network's authoritative DNS record for that in-addr.arpa query.  If not, the redirection to the anycast DNS ends up going to the nearest network that does have such a DNS, and that is hence multicast connected to the source network (or it will be the source network itself).

-------------------------------------------------------------------------------

k. Toerless: Question on relay in other network? Bob: EU is on second
network. So purpose is not to find multihop tunnels.
l. Jeffrey Zhang: Why not multihop per previous draft? Bob: To be
provided?
After speaking briefly with Jeffrey I think I also misunderstood his question.  First let's be clear  on the fact that Percy and I are working on 2 documents.  One is the BCP for MC CDNi which describes various interdomain use cases and guidelines for technological solutions to the business issues.   The presentation I made was for a specific solution to one aspect of the BCP.  Namely finding the right AMT.    My fault for not making this clear.   My presentation does not directly involve multi-hop solution.   But,  yes on a point to point consideration of multi-hop it should work,  but again the solution does not encompass multi-hop end to end.

-------------------------------------------------------------------------------

That is not discussed in the paper, but an extension to address that possibility is straightforward.

-------------------------------------------------------------------------------

m. Lenny: Some thoughts on whether optimal could be overridden by EU.
There are many ways to find optimal. So should there be a generic way to
find optimal?
n. Greg: Should this be extended to support different policies?
Greg's point is a very good one.   Percy and I also discussed this briefly with Lenny after meeting.  We should expand this document to include other solutions (e.g. manifest file could easily include best interdomain Relay - a solution that works even if not very dynamic).   In that light we will probably rename the document to something like "Finding the right/optimal Relay".   I think we will also address what is "optimal"  as there could be several solutions.    Lenny has volunteered to become a co-author on the document.    I will post the current document later today.

 -------------------------------------------------------------------------------

The nearest network that has multicast connectivity to the source can implement its own policy on which AMT relay to point to.

The method does not specifically address the question of more general, cross-network policies.

-------------------------------------------------------------------------------