Re: [MBONED] draft meeting minutes

["SAYKO, ROBERT J" <[e-mail]>]

On this following issue - can anyone quantify,  over a time interval (years perhaps),  this problem.   I need to understand it better (would like to chat with Toerless) but if need be I can try and find out the size of problem at AT&T and any solutions already being looked at or even implemented.

4. Toerless: Immediate Options for Multrans avoiding NAT:
a. Use Case 1: Leverage this case to avoid NAT for v4 multicast ==> v6 in
routers.
b. Use Case 2: Longer term use case (new v6 centric network designs). NAT
can be simple static v6 ==> v4 multicast group address mapping.
c. Stig: Link local addresses considered as option? Also home gateway may
need some addresses? Toerless responded positively. Stig approves of this
approach.
d. Greg on the wall: Approves of this simple approach to resolve issue.
e. Lenny: Next steps?? Create I-D?? Toerless: Possible to Write up 3-4 Use
Cases in I-D??
f. Simon: Question on Details on Step 2?? Toerless provides answers  Maybe
home gateway issue may need additional configuration setup??
g. Tim??: Homenet gives IPv6 address?? Dont make homenet stuff or home
gateway more complex but supports going forward.
h. Lenny: Source is v4 & receiver is v6  important to remember.
i. Stig: Get this documented & clear up problem statement.
j. Tina Tsou: Solution should not be in MBONED. Joel: Maybe solution could
go to PIM WG if not in MBONED but MBONED can define problem statement for
eventual protocol solution. Tina: Has cable market supported v6 for home
gateways?? Toerless: If not v6 support then no multicast?? Majority of
IPTV is over DSL and is running out of v4 addresses.
k. Simon: Really nice if ths could be in an I-D.
l. Tim: This is positive spin on use of Homenet  v6 architecture
m. Lenny: Lets see a draft

My comments on following:
-I do think this is an important issue to address.   I think it becomes a key business problem for MC in general
-If I understood all of what Bill is proposing then I can sum up my biggest concern about the approach in one word "TRUST" ,    Content owners need/want complete assurance from network provider that a) their content is safe (meaning cannot be accessed by unauthorized EU  b) the content delivered to an EU is measurable and  that is for proper billing/accounting. And they need to know the measurement of data delivered is accurate.   If this is what Bill means by transparent then that is good,  but I was not sure enough information about this was explained (at least for me) in the presentation.   AT&T has been dealing with this issue for quite some time now......we have dealt with some very large content owners and providers
-I think a clear definition of a content owner and content provider needs to be made to avoid confusion.   An owner to my mind is a movie studio or a producer of the media.   A content owner can be a provider too,  but there are providers that are not owners (e.g. Akamai) and I think that depending on the business relationships (and even the relationship between content provider and service provider) entailed it might help to examine this in Bill's work...........just a suggestion
-I think some of this work could dovetail with the BCP Percy and I are working on (the MC CDNi document).
6. Bill Atwood: Multicast Access Control:
a. Trust relationships for Unicast between Source & User  Network is
transparent.
b. Not so for Multicast: Many EUs & fewer streams from source.
c. AAA & QoS Issues  how can they be addressed
d. Network comes into play for AAA  use of ticket (solution 1)
e. Toerless: Why does network need to be protected?? At network level??
Bill: Do not allow traffic on subnet level if not authorized. Scope here
is Access Control.
f. Greg: Content could be acquired illegitimately but if it is encoded
then what are we trying to achieve??
g. Bill: Requirements for mechanisms for Access Control & specify
Architecture for this.
h. Stig: Authentication server on the link?? Bill: PAA does not have to be
on the link.
i. Stig: Docs only talk about group membership. Should they also talk
about {S,G}?? Bill: Only looking at groups & not at technologies.
j. Toerless: How many entities under consideration? Content providers?
Network providers? Bill: Only considering network providers to EUs. Good
stuff here with Use Cases.

In response to some of the questions raised please see inline.  These are my thoughts prior to going back to my colleague to discuss,  but wanted to address some of the issues today if I could
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??
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.
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.
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.
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.
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.